前言

kubernetes网络和服务的概念与使用场景主要有以下两点：

Service概念及使用场景

Ingress概念及使用场景

本文主要介绍

Kubernetes工作负载POD之间的互通、负载均衡等网络功能是如何实现的

kubernetes容器网络模型，Service负载均衡机制、CNI接口的实现原理以及若干实践案例

一、Kubernetes诞生背景

1.云原生的概念

云原生是基于分布部署和统一运管的分布式云 ，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。是一种新型技术体系，是云计算未来的发展方向。

云原生应用也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。

云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

2.云原生架构

云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

微服务： 几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。

微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。

容器化： Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。

DevOps： 这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

持续交付： 持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

3.Kubernetes(k8s)

Kubernetes(k8s)是云原生架构体系中不可缺少的一环，是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes(k8s)是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes(k8s)提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

二、Kubernetes基本网络模型剖析

1.概念厘清

1.1 二层桥接 VS 三层路由

1.2 Underlay VS Overlay

1.3 物理网络 VS 虚拟网络

1.4 传统网络 VS SDN网络

1.5 Docker网络 VS K8S网络

1.5.1 Docker网络

Docker 采用插件化的网络模式，默认提供 bridge、host、none、overlay、maclan 和 Network plugins 这几种网络模式，运行容器时可以通过--net 参数设置具体使用那一种模式。

bridge： 这是Docker默认的网络驱动，此模式会为每一个容器分配Network Namespace和设置IP等，并将容器连接到一个虚拟网桥上。如果未指定网络驱动，这默认使用此驱动。

host： 此网络驱动直接使用宿主机的网络。

none： 此驱动不构造网络环境。采用了none网络驱动，那么就只能使用loopback网络设备，容器只能使用127.0.0.1的本机网络。

overlay： 此网络驱动可以使多个Docker daemons连接在一起，并能够使用swarm服务之间进行通讯。也可以使用overlay网络进行swarm服务和容器之间、容器之间进行通讯。

macvlan： 此网络允许为容器指定一个MAC地址，允许容器作为网络中的物理设备，这样Docker daemon就可以通过MAC地址进行访问的路由。对于希望直接连接网络网络的遗留应用，这种网络驱动有时可能是最好的选择。

Network plugins： 可以安装和使用第三方的网络插件。可以在Docker Store或第三方供应商处获取这些插件。

在默认情况，Docker 使用 bridge 网络模式，bridge 网络驱动的示意图如下，此文以bridge 模式对 Docker 的网络进行说明。

实际上 Docker 是采用 NAT的方式，将容器内部的服务监听端口与宿主机的某一个端口 port 进行绑定，使得宿主机外部可以将网络报文发送至容器。

1）通过-P参数，将容器的端口映射到宿主机的随机端口：

2）通过-D参数，以守护进程方式运行：

2）通过- -net参数，指定网络：

docker run -d -p {hostPort}:{containerPort} {images} --net={network}

1.5.2 K8S网络

K8S网络与Docker网络有些不同。K8S网络需要解决下面的4个问题：

集群内：

容器与容器之间的通信

Pod和Pod之间的通信

Pod和服务之间的通信

集群外：

外部应用与服务之间的通信

2.K8S网络模型对互通性的要求

节点node网络互通性的要求：

节点上的容器POD可以与集群内任意节点上的容器POD无需NAT实现互访

节点上的代理agent(比如:系统后台进程、kubelet)可以与同节点上的容器POD互访

对于支持容器POD以主机网络模式运行的平台(如:Linux)互通性的要求：

主机网络模式的容器POD可以与集群内任意节点上的容器POD无需NAT互访

3.K8S网络模型

3.1 Overlay组网模型

3.1.1 模型特征

同节点内POD二、三层直接互通

跨节点POD互通通过隧道(VXLAN/IPIP)

POD访问宿主节点地址或集群外地址需SNAT

3.1.2 优势

与底层网络解耦，节点IP互通

3.1.3 劣势

隧道封装解封装开销大，小包带宽损耗可达30%+ ，互通性差，SNAT

3.1.4 典型实现

Flannel/VXLAN,Calico/IPIP,CCE隧道网络

3.2 二层组网模型

3.2.1 组网特点

容器和宿主节点属于同一子网

宿主节点间要求二层互通(物理网络)

3.2.2 优势

扁平网络，容器与节点具有同等互通能力

3.2.3 劣势

规模扩展受子网限制

要求节点网络二层广播域开放

桥接模式转发性能较差

3.2.4 典型方案

Azure CNI, Rancher扁平网络，CCEUnderlay L2

3.3 三层组网模型

3.3.1 组网特点

按节点掩码长度，给每个节点分配容器子网

同节点内POD二、三层直接互通

跨节点POD互通通过本地路由表及节点网络路由转发

POD访问宿主节点地址无需SNAT

3.3.2 优势

无隧道开销，互通性好

规模扩展性高

3.3.3 劣势

需要对接节点网络，支持BGP协议或路由配置接口

3.3.4 典型方案

Calico Native, CCE VPC路由

三、K8S Service负载均衡机制实现原理

1.IPTables

1.1 方案说明

利用linux内核原生Netfilter/IPTable的HOOK/Chain及Conntrack连接状态机制，实现NAT和负载均衡

1.2 优势

内核原生能力，经历了长期的考验，稳定性好(k8s1.2开始作为default方案)

易于与不同容器网络模型集成

1.3 劣势

线性遍历查表机制，造成大规模规则场景下，新建连接开销大

大规模规则刷新较慢

负载均衡算法相对少，均衡效果较差

2.IPVS

2.1 方案说明

基于内核负载均衡模块IPVS，实现NAT和负载均衡。

2.2 优势

专用负载均衡方案，基于IPSet/Hash查表机制，性能高(k8s1.11GA,由华 为云原生容器团队贡献给K8S社区)

负载均衡算法丰富，均衡性好(round-robin, min connection etc)

规模扩展性好，规则数对匹配性能影响小和刷新规则快

2.3 劣势

原始设计针对南北向边界负载均衡，对于分布式东西向某些特殊访问场景 存在限制

仍然依赖IPTables+Conntrack实现MASQUADE(SNAT)

3.eBPF

3.1 方案说明

基于高内核版本eBPF机制

东西向采用Socket Layer LB机制 实现，支持会话保持

南北向采用XDP/TCBPF实现负载 均衡/NAT和状态表

3.2 优势

适合容器场景，转发路径短，最大开 销下降可达80%

3.3 劣势

内核版本要求社区内核5.7+

缺乏大规模的商用检验，处于快速迭 代过程，社区不断有新patch合入

负载均衡算法待增强和丰富

3.4 典型方案

Cilium,Calico

四、华为云CCE Yangtse网络模型

1.VPC 路由模式

1.1 方案说明

按照创建集群时设定的节点长度为节点分配容器子网

将每个节点的容器子网路由配置到VPC路由表

1.2 优势

无隧道开销，转发性能与主机网络持平

VPC内节点与容器互通无SNAT,支持源地址保持

1.3 劣势

集群规模受限于VPC路由表规格，比如:200

互通性受限:

需要通过nodeport对接ELB后端，存在多跳损耗，负载均衡性差

访问OBS或外网等服务需要SNAT为节点地址

2.ENI/TrunkPort

2.1 方案说明

容器网络与VPC网络一体化融合方案，充分利用VPC网络的软硬协同和分布式架构为容器提供云原生的规模扩展、极致弹性、负载均衡和安全隔离能力。

每个容器POD具有独立的VPC 子网地址，统一IPAM(节点 容器、服务子网统一管理)

BMS节点支持128个VF直通网 口到容器POD

虚机节点Trunkport模式ENI, 最多支持创建256个VLAN子接 口直通容器POD

每个POD具有独立的安全组， 支持容器粒度的网络隔离

POD间互访不经过节点root namespace,直通模式转发0损 耗

不再依赖节点内核，IPVS/IPTables实现Service负载 均衡，不再需要kube-proxy组 件，service负载均衡卸载到VPC分布式ELB

裸机容器支持POD级网络QoS 极简组网，运维更简单

总结

在微服务化情况下,容器数量会非常多,不利于管理和编排。kubernetes诞生得益于kubernetes网络架构设计,使得管理容器,持续集成和容器编排问题都得以很好解决。

本文介绍得内容主要有：云原生、K8S容器网络模型原理、K8SService负载均衡实现原理、华为CCEYangtse容器网络模型和原理。通过以上讲解相信大家对Kubernetes网络架构有所理解，对华为云CCE Yangtse网络模型也有初步得认识，这是上半部部分，别忘了还有下半部分，还请大家多多支撑。