前言
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网络模型也有初步得认识，这是上半部部分，别忘了还有下半部分，还请大家多多支撑。
华为云官网链接:
- https://support.huaweicloud.com/usermanual-cce/cce_01_0249.html
- https://support.huaweicloud.com/usermanual-cce/cce_01_0094.html
Kubernetes官方文档:
. Service:https://kubernetes.io/docs/concepts/services-networking/servicel
. Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/
本文整理自华为云社区【内容共创】活动第13期。
查看活动详情：https://bbs.huaweicloud.com/blogs/330939
相关任务详情：任务23.华为云云原生钻石课程06：Kubernetes网络架构原理深度剖析（上）
2957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
