K8S架构

Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示。

架构主要自底向上分为：

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）、Service Mesh（部分位于应用层）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）、Service Mesh（部分位于管理层）
接口层：kubectl命令行工具、客户端SDK以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

Kubernetes外部：日志、监控、配置管理、CI/CD、Workflow、FaaS、OTS应用、ChatOps、GitOps、SecOps等
Kubernetes内部：CRI、CNI、CSI、镜像仓库、Cloud Provider、集群自身的配置和管理等

总体架构

Kubernetes借鉴了Borg的设计理念，比如Pod、Service、Label和单Pod单IP等。Kubernetes的整体架构跟Borg非常像，如下图所示。

Kubernetes主要由以下几个核心组件组成：

etcd保存了整个集群的状态；
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；
container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：

CoreDNS负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Prometheus提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群

Master架构

Node架构

核心概念

Node：Kubernetes 集群中的计算能力由 Node 提供，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行 kubelet 管理节点上运行的容器。

Pod：Pod 是在 Kubernetes 集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod 的设计理念是支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。根据业务场景的不同，Pod可以分为：长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application），分别对应的控制器为 Deployment、Job、DaemonSet 和 StatefulSet。

Service：Deployment等控制器只能控制服务的Pod数量，不能解决服务访问的问题。在 K8 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。

Labels and Selectors：用于标识Pod的KV对

Namespace：命名空间为 Kubernetes 集群提供虚拟的隔离作用，Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。

Secret：Secret 是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用 Secret 的好处是可以避免把敏感信息明文写在配置文件里，比如数据库访问账户和密码等。

Annotation：注解可以为对象附加任意的非标识的KV形式的元数据。

K8S容器网络

Kubernetes为每个Pod分配一个IP，即“IP-Per-Pod”，Pod内所有容器共享一个网络命名空间，Pod间无需NAT即可直接通信。

Kubernetes网络通信主要分为如下几部分：

Pod内部容器间通信
Pod间通信

同一个Node内的Pod之间
不同Node上的Pod之间

Pod与Service之间的网络通信
外界与Service之间的网络通信

具体可以将容器网络通信细分为：

Pod访问

Pod访问其他Node的Pod
Pod访问同Node的Pod
Node访问其他Node的Pod
Node访问本Node的Pod

Service访问

Client Pod访问Service在其他Node上的BackEnd Pod
Client Pod访问Service在本Node上的BackEnd Pod
Node访问Service在其他Node上的BackEnd Pod
Node访问Service在本Node上的BackEnd Pod
External访问Service

容器网络基础

Pod使用了Linux中的Cgroup和Namespace技术，其中Cgroup用于资源限制，Namespace用于资源隔离。每个Namespace都会拥有自己的协议栈，包括接口、路由表、Socket和iptables规则，一个接口只会属于一个network namespace。为了支持多个Pod有多种方法，一种是使用多个硬件接口，一种是生成软件模拟的接口。下面是几种软件接口实现方式：

Virtual bridge

创建一个虚拟接口对veth pair，一端放在Pod中作为eth0，一端放在root ns中插在linux bridge或者是ovs bridge上，实现接口的连通。这种方式下网桥可能会带来一些额外的性能开销。

Multiplexing

多路复用是将一个中间网络设备暴露出多个虚拟接口，并支持通过转发规则控制报文转发至哪个接口。MACVLAN为每个虚拟接口分配独立的MAC地址，出向报文带上这个MAC地址，入向报文通过目的MAC地址进行多路复用转发。IPVLAN也是类似的，但是在单个MAC地址上使用多个IP地址进行多路复用，对VM更友好一些。Linux Kernel从3.9开始支持MACVLAN，从3.19 开始支持 IPVLAN。

Hardware switching

当前大部分的网卡都支持SRIOV（Single Root I/O Virtualization），可以将一个物理网卡分拆成多个虚拟网卡，每个虚拟网卡都是一个独立的PCI设备，可以拥有独立的VLAN和硬件QoS能力，可以提供与原始硬件网卡一致的性能，但是由于无法灵活实现VPC网络的各种功能，因此在公有云上使用并不多。

在不考虑性能的情况下业界通常使用virtual bridge的方式实现单机容器网络拓扑，如果考虑性能和安全策略可以考虑使用MACVLAN/IPVLAN（SRIOV方案的安全策略隔离需要依赖交换机上配置VLAN和ACL，不够灵活）。

CNI

Container Network Interface (CNI) 最早是由CoreOS发起的容器网络规范，是Kubernetes网络插件的基础。其基本思想为：Container Runtime在创建容器时，先创建好network namespace，然后调用CNI插件为这个netns配置网络，其后再启动容器内的进程。

CNI插件包括两部分：

CNI Plugin负责给容器配置网络，它包括两个基本的接口

配置网络: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
清理网络: DelNetwork(net NetworkConfig, rt RuntimeConf) error

IPAM Plugin负责给容器分配IP地址、网关和DNS，主要实现包括host-local和dhcp

CNI插件是一个二进制程序，其输入和输出遵守 appc/CNI 规约。当创建Pod的时候，kubelet通过apiserver watch到之后，在本地执行创建操作，其中创建网络步骤会执行CNI配置文件中指定的CNI插件二进制文件，由CNI插件配置Pod的网络。

IPAM插件也是一个二进制程序，默认使用host-local方式，使用本地文件维护一个“本地数据库”，为每个Node配置一个容器网络网段，比如/24这样的C段。当Pod创建时从"本地数据库"中分配一个IP地址。当没有较多剩余IP地址无法为每个Node分配/24网段，或者是有状态Pod漂移时想保留IP地址，这个时候就需要使用集中式地址管理，比如dhcp方案（可以借助neutron中的nn/vn来实现dhcp），社区中也有一些基于redis、consul、etcd等共享存储的集中式IPAM方案。（Pod被分配到一个Node上运行之后，就不会离开这个Node，直到被删除。当某个Pod失败，首先会被Kubernetes清理掉，之后ReplicationController将会重建Pod，重建之后Pod的ID会变化，即一个新的Pod。所以Kubernetes中Pod的迁移，实际指的是在新Node上重建Pod。）

Pod间通信

社区容器网络方案主要有两种：

隧道方案：隧道方案在IaaS层的网络中应用也比较多，将pod分布在一个大二层的网络规模下。网络拓扑简单，但随着节点规模的增长复杂度会提升。

Weave：UDP广播，本机建立新的BR，通过PCAP互通
Open vSwitch（OVS）：基于VxLan和GRE协议，但是性能方面损失比较严重
Flannel：UDP广播，VxLan
Racher：IPsec

路由方案：路由方案一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。

Calico：基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。
Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。

下面重点介绍一些常用的Flannel和Calico方案。

Flannel

Flannel是kubernetes默认提供网络插件，由CoreOs团队开发社交的网络工具，采用L3 Overlay模式。同宿主机下各个Pod属于同一个子网，不同宿主机下的Pod属于不同的子网。Flannel会在每一个宿主机上运行名为flanneld代理，其负责为宿主机预先分配一个子网，并为Pod分配IP地址。Flannel使用Kubernetes或etcd来存储网络配置、分配的子网和主机公共IP等信息。数据包则通过VXLAN、UDP或host-gw这些类型的后端机制进行转发。

Flannel的主要组件：

docker0：网桥设备，每创建一个pod都会创建一对 veth pair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口（网卡）上。
flannel.1: overlay网络的设备，用来进行 vxlan 报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

不同node上的pod的通信流程：

pod中产生数据，根据pod的路由信息，将数据发送到docker0
docker0 根据节点的路由表，将数据发送到隧道设备flannel.1
flannel.1查看数据包的目的ip，从flanneld获得对端隧道设备的必要信息，封装数据包。
flannel.1将数据包发送到对端设备。对端节点的网卡接收到数据包，发现数据包为overlay数据包，解开外层封装，并发送内层封装到flannel.1设备。
flannel.1设备查看数据包，根据路由表匹配，将数据发送给docker0设备。
docker0匹配路由表，发送数据给网桥上对应的端口。

flannel默认使用vxlan后端，如果内核版本较老使用udp后端。udp后端的封包格式如下：

使用udp后端时，flanneld创建flannel.1 tun设备，当数据包到达flannel.1虚拟网卡的时候，由flanneld进行读取并进行udp封装，查找路由表发送出去。

vxlan和上文提到的udp backend的封包结构是非常类似，不同之处是多了一个vxlan header，以及原始报文中多了个二层的报头。

VXLAN网络数据包转发的核心是 RIB 路由表、FDB 转发表、ARP 路由表，即VXLAN要解决二层 Guest MAC 地址寻址、跨三层 Guest IP 地址寻址的问题，并实现全网高效路由分发和同步。早期的Flannel版本实现，借助于Linux 3.8内核开始引入的Distributed Overlay Virtual Ethernet（DOVE）机制，当数据包无法在 FDB 转发表中找到对应的 MAC 地址转发目的地时 kernel 发出 l2miss 通知事件，当在 ARP 表中找不到对应 IP-MAC 记录时 kernel 发出 l3miss 通知事件。flanneld通过NETLINK监听L2 Miss和L3Miss消息，查询从etcd中watch到的元信息进行响应。l2miss 和 l3miss 方案缺陷：

每一台 Host 需要配置所有需要互通 Guest 路由，路由记录会膨胀，不适合大型组网
通过 netlink 通知学习路由的效率不高
Flannel Daemon 异常后无法持续维护 ARP 和 FDB 表，从而导致网络不通

为了弥补 l2miss 和 l3miss 的缺陷，新版Flannel 改用了三层路由的实现方案，给每个Node上的Pod子网网段添加远端 Host 路由，同时为 vtep 和 bridge 各自分配三层 IP 地址，当数据包到达目的 Host 后，在内部进行三层转发。这样的好处就是 Host 不需要配置所有的 Guest 二层 MAC 地址，从一个二层寻址转换成三层寻址，路由数目与 Host 机器数呈线性相关。

新的Node A加入flannel网络时，它会将自己的三个信息写入etcd中，分别是：subnet 10.1.16.0/24、Public IP 192.168.0.101、vtep设备flannel.1的mac地址 MAC A。其他Node会得到EventAdded事件，并从中获取Node A添加至etcd的各种信息，并在本机上添加三条信息：

路由信息：所有通往目的地址10.1.16.0/24的封包都通过vtep设备flannel.1设备发出，发往的网关地址为10.1.16.0，即Node A中的flannel.1设备。
FDB信息：MAC地址为MAC A的封包，都将通过vxlan发往目的地址192.168.0.101，即Node A。
ARP信息：网关地址10.1.16.0的地址为MAC A。

udp后端和vxlan后端工作方式本质上是一样的，vxlan后端中将VNI设置为1，将udp的proxy换成了内核中的vxlan处理模块。

Calico

K8S默认的Flannel容器网络方案主要关注Pod间互通，并不支持Network Policy，如果想要Network Policy安全隔离策略就需要使用Calico。Calico 不使用隧道或 NAT 来实现转发，而是巧妙的把所有二三层流量转换成三层流量，并通过 Host 上路由配置完成跨 Host 转发。Calico规避了二层网络通通信的广播开销、VLAN 4096规则限制和VXLAN隧道技术的开销。

Calico网络模型主要工作组件：

Felix：运行在每一台 Host 的 agent 进程，主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等。
etcd：分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，可以与kubernetes共用；
BGP Client（BIRD）：Calico 为每一台 Host 部署一个 BGP Client，使用 BIRD 实现，BIRD 是一个单独的持续发展的项目，实现了众多动态路由协议比如 BGP、OSPF、RIP 等。在 Calico 的角色是监听 Host 上由 Felix 注入的路由信息，然后通过 BGP 协议广播告诉剩余 Host 节点，从而实现网络互通。
BGP Route Reflector：在大型网络规模中，如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制，因为所有节点之间俩俩互联，需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有 BGP Client 仅与特定 RR 节点互联并做路由同步，从而大大减少连接数。

Calico网络节点间有两种：IPIP和BGP，默认选择IPIP网络。IPIP网络与BGP网络原理一样，都是在Host配置Pod访问的路由到Node。

IPIP网络：

流量：tunlo设备封装数据，形成隧道，承载流量
适用网络类型：适用于互相访问的pod不在同一个网段中，跨网段访问的场景。外层封装的ip能够解决跨网段的路由问题
效率：流量需要tunl0设备封装，效率略低

BGP网络：

流量：使用路由信息导向流量
适用网络类型：适用于互相访问的Pod在同一个网段，适用于大型网络
效率：原生HostGW，效率高

编辑

Calico由于在Host设置三层路由，无法解决多租户场景中网络地址冲突的问题，同时BGP网络需要物理网络工程师配合配置交换机来建立BGP邻居，大规模网络会在Host设置较多的路由和Iptables规则导致调试困难。

DNS

Kubernetes DNS 在群集上调度 DNS Pod 和服务，并配置 kubelet 以告知各个容器使用 DNS 服务的 IP 来解析 DNS 名称。

Kube-dns 会作为 Deployment 运行并将冗余 kube-dns Pod 调度到集群中的各节点。kube-dns Pod 位于 kube-system 命名空间中。kube-dns 部署通过相应的 Service 访问，该 Service 会对 kube-dns Pod 进行分组并为其提供单一 IP 地址。默认情况下，集群中的所有 Pod 均使用此服务来解析 DNS 查询。

Kube-dns 会从容扩缩以满足集群的 DNS 需求。此扩缩过程由 kube-dns-autoscaler 控制，kube-dns-autoscaler 会根据集群中的节点数和核心数调整 kube-dns 部署中副本的数量。

kube-dns Pod由三个容器组成：

kube-dns：DNS 服务的核心组件，主要由 KubeDNS 和 SkyDNS 组成

KubeDNS 负责监听 Service 和 Endpoint 的变化情况，并将相关的信息更新到 SkyDNS 中
SkyDNS 负责 DNS 解析，监听在 10053 端口 (tcp/udp)，同时也监听在 10055 端口提供 metrics
kube-dns 还监听了 8081 端口，以供健康检查使用

dnsmasq-nanny：负责启动 dnsmasq，并在配置发生变化时重启 dnsmasq

dnsmasq 的 upstream 为 SkyDNS，即集群内部的 DNS 解析由 SkyDNS 负责

sidecar：负责健康检查和提供 DNS metrics（监听在 10054 端口）

Service

Service是将运行在一组 Pods上的应用程序抽象为网络服务，Kubernetes为Pods提供自己的IP地址和一组Pod的单个DNS名称，并且可以在它们之间进行负载平衡，应用程序无需修改即可使用Service这套服务发现机制。

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式。从Kubernetes v1.0开始，可以使用用户空间代理模式；Kubernetes v1.1添加了 iptables 模式代理，并从Kubernetes v1.2 开始 kube-proxy 的 iptables 模式成为默认设置；Kubernetes v1.8添加了 ipvs 代理模式。

常规的Service都有ClusterIP，还有一种Headless Service。顾名思义这种Service没有Cluster IP，只有一个EndPoint列表（默认是PodIP:Port列表，yaml中显式指定nodeport之后也会有NodeIP:Port列表，不过只对外提供访问入口），没有负载均衡功能，通常用于与其他外部服务发现机制对接。

Userspace代理模式

这种模式下kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。对每个 Service，它会在本地 Node 上打开一个代理端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的某个上面。使用哪个 backend Pod，是 kube-proxy 基于 SessionAffinity 来确定的。最后，kube-proxy通过配置 iptables 规则，将到达该 Service 的 clusterIP（虚拟 IP）和 Port 的请求重定向到代理端口，代理端口再代理请求到 backend Pod。

当有多个后端Pod的时候，选择Pod的算法有两种：一种是Round-Robin，如果一个Pod没有响应就试下一个；一种是选择与请求来源IP地址更接近的Pod。默认Pod选择算法是round-robin。

Iptables代理模式

在iptables模式下，创建Service时Node节点上的kube-proxy会创建两个iptables规则。一个为Service服务，将的流量转给后端。另一个为EndPoints创建，用于选择Pod。默认情况下后端的选择是随机的。具体iptables规则示例如下：

-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ

-A KUBE-SEP-WNBA2IHDGP2BOBGZ -p tcp -m comment --comment "default/hostnames:" -m tcp -j DNAT --to-destination 10.244.1.7:9376

iptables模式下的kube-proxy不执行真正的数据转发，不需要在内核空间和用户空间进行切换，会比userspace模式下运行的更快更可靠。但是iptables模式下，如果选择的Pod没有响应，无法自动重试选择其他Pod，这个时候需要运行readiness probes（准备情况探测器）。kubelet使用readiness probes来探测容器还是可以开始接流量，将准备就绪的容器加入Service的EndPoints，将Pod未就绪的容器从EndPoints中删除，从而实现对Service的Endpoints的控制。

IPVS代理模式

IPVS模式跟iptables模式底层原理一致，都是基于netfilter hook函数。但是不同的是iptables规则是顺序匹配，当规则数较多时匹配时间较长；而IPVS模式是采用散列表作为存储数据结构，相比之下匹配时间会较短，能够更快的重定向流量。此外，ipvs还提供了多种负载均衡算法，比如rr（round-robin，轮询调度算法）、lc（least connection，最小连接数调度算法）、dh（destination hashing，目的地址散列调度算法）、sh（source hashing，源地址散列调度算法）、sed（shortest expected delay，最短期望延迟调度算法）、nq（never queue，永不排队调度算法）。需要注意的是IPVS模式需要在Node上预先安装ipvs内核模块，当kube-proxy配置为ipvs模式时，会先检测Node上是否安装了ipvs模块，如果未安装将使用iptables模式。Node上创建一个kube-ipvs0的虚拟网卡，将Service的VIP都绑定上去。

OVS方案

标准社区中是没有OVS模式的，只在一些OVS和Kubernetes整合的方案中存在。在OVS支持容器网络的方案中有如下四种方案，其中linux bridge和tun方案比较常用，算是iptables代理模式在适配OVS时的折中。linux bridge方案可以支持多租户场景下地址重叠（不同VPC的规则使用不同的linux bridge），同理ovs流表也可以支持多租户网络隔离，但是tun方案不行（tun上无法做service地址隔离）。

linux bridge+iptables方案

Openstack在ComputeNode上的网络拓扑是将虚机的TAP设备插在一个linux网桥qbr上，然后qbr再与ovs网桥br-int连接，具体如下左图。为什么不将虚机的网卡直接连接到 OVS 桥 br-int，官方说法是：“理想地，TAP 设备最好能直接挂在 br-int 上。由于OpenStack 使用 TAP 设备上的 iptables 规则来实现 Security Group，而 open vswitch 不支持在直接连到其网桥上的 TAP 设备上使用 iptables。因此，不得不增加 Linux bridge qbr 来将 TAP 设备连到 OVS bridge 上。”。简单地说，OpenStack 需要在 qbr 桥上使用 iptables 过滤进出虚机的数据包，而 br-int 上无法做到这一点。

容器网络也可以参考Neutron的OVS拓扑，在在容器虚拟网卡跟ovs bridge之间再添加一个linux网桥docker0，并在上面设置iptables的nat规则来实现Service，类似之前百度云虚拟网络BLB的TTM跑在qbr上。

tun+iptables方案

Openshift的SDN采用这种方案，我们之前做的分布式Metadata也是采用这种方案。在OVS网桥br0上添加tun0设备，tun0是OVS 内部端口，它会被分配本机的 pod 子网的网关IP 地址，用于OpenShift pod 以及Docker 容器与集群外部的通信。通过OVS上流表配置规则，将Service的VIP流量导流到tun0设备上。针对tun0设备，可以在root ns中配置iptables nat规则来实现service。整个转发流程中不仅需要DNAT将目的地址VIP修改为后端pod的ip，还需要SNAT将源地址修改为tun0的ip，这样可以是的Service的回包依然能够回到tun0上，并再次走iptables实现De-SNAT，并再回到br0上最终送到对应的Pod。这种方案不仅可以解决宿主机访问Service，也可以解决Pod内访问Service。

OVS上具体的流表Pipeline结构如下所示：

使用CT流表规则

OVS 2.5之后开始支持ConnTrack，其底层也是跟iptables一样使用的内核中的conntrack模块。我们可以使用OVS中的CT Action实现类似iptables中的NAT规则，使用Group规则来实现负载均衡中多个Pod后端的选取。

table=0,ip,nw_src={pod_cidr},nw_dst={service_cidr},ct_state=-trk,action=ct(table=2)
table=0,ip,nw_src={pod_cidr},nw_dst={pod_cidr},ct_state=-trk,action=ct(table=4)
table=2,ip,nw_dst={svc1_ip},tp_dst={svc1_port},ct_state=+trk+new,action=group:1
table=2,ip,nw_dst={svc2_ip},tp_dst={svc2_port},ct_state=+trk+new,action=group:2
table=2,ct_state=+trk-new,action=table:4
table=4 contains the original switching / routing rules
group_id=1,type=select, bucket=ct(commit,nat(dst={pod1_ip}:{pod_port}),table=4,
bucket=ct(commit,nat(dst={pod2_ip}:{pod_port}),table=4,
bucket=ct(commit,nat(dst={pod3_ip}:{pod_port}),table=4

使用Stateless NAT规则

如果在看到Dst是Service IP的时候将其切换为Pod的IP，同时将Src修改为一个Shifted IP，比如10.244.x.y → 172.24.x.y。这种方式可以不使用任何内核中的规则，方便与一些DPDK之类的用户态程序整合。

table=0,ip,nw_src={pod_cidr},nw_dst={service_cidr},action=table:2
table=0,ip,nw_src={pod_cidr},nw_dst={shifted_pod_cidr},action=table:3
table=0,ip,nw_src={pod_cidr},nw_dst={pod_cidr},action=table:4
table=2,ip,nw_dst={svc1_ip},tp_dst={svc1_port},actions=load:44056->NXM_OF_IP_SRC[16..31],group:1
table=3,ip,nw_src={pod1_ip},tp_src={pod_port},actions=mod_nw_src:{svc1_ip},mod_tp_src:{svc1_port}
,load:2804->NXM_OF_IP_DST[16..31],resubmit:4
table=4 contains the original switching / routing rules
group_id=1,type=select, bucket=mod_nw_dst:{pod1_ip},mod_tp_dst:{pod_port},resubmit=4,
bucket=mod_nw_dst:{pod2_ip},mod_tp_dst:{pod_port},resubmit=4,
bucket=mod_nw_dst:{pod3_ip},mod_tp_dst:{pod_port},resubmit=4

就绪探针

kubelet 使用 liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness 探针将捕获到 deadlock，重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。

Kubelet 使用 readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当 Pod 中的容器都处于就绪状态时 kubelet 才会认定该 Pod处于就绪状态。该信号的作用是控制哪些 Pod应该作为service的后端。如果 Pod 处于非就绪状态，那么它们将会被从 service 的 load balancer中移除。

Ingress

Service 虽然解决了服务发现和负载均衡的问题，但它在使用上还是有一些限制：只支持4层负载均衡，不支持7层负载均衡；对外访问的时候，NodePort 类型需要在外部搭建额外的负载均衡，而 LoadBalancer 要求 kubernetes 必须跑在支持的 cloud provider 上面，Pod漂移后NodeIP也会变化。Ingress 就是为了解决这些限制而引入的新资源，主要用来将服务暴露到 cluster 外面，并且可以自定义服务的路由访问策略。

Ingress 可以给 service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 Ingress controller，它监听 Ingress 和 service 的变化，并根据规则配置负载均衡并提供访问入口。在TLS场景，可以通过指定包含 TLS 私钥和证书的 Secret来加密 Ingress。

Ingress 正常工作需要集群中运行 Ingress Controller。Ingress Controller 与其他作为 kube-controller-manager 中的在集群创建时自动启动的 controller 成员不同，需要用户选择最适合自己集群的 Ingress Controller，或者自己实现一个。Ingress Controller 以 Kubernetes Pod 的方式部署，以 daemon 方式运行，保持 watch Apiserver 的 /ingress 接口以更新 Ingress 资源，以满足 Ingress 的请求。常见的有Nginx Ingress Controller和Traefik Ingress Controller。下图是Nginx Ingress的工作流程，Nginx Pod直接访问具体Service的Pod，而不是通过Service的ClusterIP（通常后端Service使用Headless Service，没有ClusterIP）：

外界访问Service

对一些应用（如 Frontend）的某些部分，可能希望通过外部Kubernetes 集群外部IP 地址暴露 Service。Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。

Type 的取值以及行为如下：

Cluster IP：只在Cluster内部能够访问的Virtual IP（通过kube-proxy在Node上配置iptables规则，将ClusterIP DNAT到具体Service的PodIP）
Node Port：通过NodePort将Virtual IP暴露给Cluster外部（通过yaml文件中显式创建nodeport，底层自动创建ClusterIP，通过iptables将NodePort转到ClusterIP，再转到具体Service的PodIP）
Load Balancer：将K8S内部的Serivce通过云厂商的LoadBalancer暴露给外部（底层自动创建NodePort和ClusterIP，将NodePort作为RealServer挂载到云上LB）
ExternalName：将K8S内部DNS CNAME指向到外部DNS，并不指向K8S集群内部的Pod

公有云上容器网络方案

各家公有云厂商的容器网络方案有两种方案：

VPC路由方案
ENI弹性网卡和辅助IP方案

VPC路由

类似Flannel为每个Node分配一个网段，在公有云上使用实例路由的方式。

ENI

VPC路由方案虽然能够解决容器互通的需求，但是因为容器网络并没有被VPC纳管，只能依靠路由表进行引流。由于容器网络没有被VPC管理，在对等连接、专线等混合云场景容易出现VPC对端IP地址与容器网络地址冲突。为了解决地址冲突的问题，一种直观的解决方案是为Pod分配VPC内的地址。在ENI弹性网卡产品出来之后，可以简单的为每个Pod分配一个ENI的方式实现每个Pod一个IP，也可以通过ENI上辅助IP的方式来实现这个功能。

ENI在产品设计上都是有一些随资源规格相关的配额限制，下面是阿里云ENI的规格限制：

这里面需要注意的是由于QEMU虚拟的机器模型和PCIE总线的限制，只能插入32个PCIE设备，所以单个VM能够插入的ENI数量也是有限的，不能为每个Pod创建一个ENI。同时由于规格限制中单个ENI上最多能够挂载辅助IP的数量也有限制，所以也不能只插入一个ENI为这个VM上每个Pod创建一个辅助IP。使用ENI实现容器网络的话，就需要采用多弹性网卡多辅助IP的方式，按照VM规格最大辅助IP数量来计算需要多少个弹性网卡。

单ENI多辅助IP也有多种容器网络方案：

bridge：受限于VPC的源MAC检查
策略路由：走Host协议栈，性能下降明显
MACVLAN：受限于VPC的源MAC检查
IPVLAN：无MAC问题，不过Host协议栈，性能好

IPVLAN虽然性能很好，但是由于其驱动限制无法支持Pod和Node互通，并且Service的kube-proxy需要走Node的三层协议栈，这些都需要针对IPVLAN方案进行细化。

百度云方案

IPVLAN L3 + veth PTP(Point-to-Point)，为每个Pod插入两个网卡，一个网卡是Pod的主网卡，一个网卡用来跟Node和Service通信，跟Node和Service通信的网卡上也需要配置IP地址。

阿里云方案

IPVLAN L2+TC，无需veth Point-to-Point，在Node的主设备上除了Pod的IPVLAN从设备之外再创建一个Node的IPVLAN从设备用于Node与Pod通信。在主设备上设置TC重定向规则，将Service流量重定向给Node的IPVLAN从设备。

LB FastPath演进

借助于公有云网络的VPC路由和ENI方案解决了Pod间容器网络问题，对于Service如果继续采用K8S原生的iptables/ipvs实现方式，维护起来代价依然较大，可以考虑将Service也使用公有云网络的LB进行实现，不仅作为Service外部访问入口，也作为内部访问入口，将Service的VIP也纳入到VPC地址空间中。

K8S原生的Service实现相当于一种分布式LoadBalancer，Client上直接进行负载均衡，带外集中式健康检查。这种方案的好处是Service流量直接点对点，没有流量瓶颈、延迟也比较低、故障域较小。如果直接将Service映射到BLB上，BLB采用FullNAT方式的话，这样会存在流量瓶颈、较大的故障域、延迟会Double。这个时候我们需要对LB进行FastPath优化，来解决这些问题。

顾名思义，LB FastPath就是实现LB流量不过集中式的BGW网关，在LB三次握手完成之后即可通知Client和RealServer进行直通，在当前DSR数据流的基础上，Client上将后续发出的报文伪装成BGW发出的报文（实际过程是将VIP:VPORT DNAT成RIP:RPORT）。

公司内云原生容器网络方案

需求

需要Pod间东西向互访（Pod使用11.0.0.0/8，需配置默认路由）
需要Pod与非容器物理机东西向互访
需要跨机房网络QoS（CN设置overlay外层DSCP）
不需要组播、广播
不需要IPv6
不需要安全组
不需要DHCP（IPAM由K8S负责，指定IP创建Port）
不需要DNS（DNS由K8S的kube-dns/CoreDNS负责）

Service

百度IDC网络场景主要有如下几种：

外到内：EBGW+BFE的7层访问
内到外：BigNAT
内到内：BNS服务发现，IBGW VIP

K8S容器网络要在内部落地，除了传统K8S集群内Pod和Service的通信之外，还需要解决如下问题：

IDC非K8S机器和K8S内部Pod间通信
IDC非K8S机器和K8S内部Service间通信
外网访问K8S的Service/Ingress

IDC非K8S机器和K8S内部Pod间通信

通过上面的BVR可以将PodIP暴露到IDC网络中，Neutron采取Port的FixedIP=FloatingIP的方式，这样无需做NAT对业务比较友好。

IDC非K8S机器和K8S内部Service间通信

如上面百度IDC网络场景的分析，IDC非K8S机器要访问K8S内部的Service，我们需要兼容支持BNS和BGW VIP两种方式。BNS等同于K8S中的Headless Service，大部分时候将负载均衡交由RPC框架或者是Mesh，BGW和BFE也都支持挂载BNS。因此将Pod IP与BNS打通之后，就可以相对完美的支持IDC内服务访问常用的BNS、BGW VIP和BFE三种方式。

Kuryr

Kuryr是一个OpenStack子项目，是一个捷克语单词，意思是“信使”。顾名思义，Kuryr是连接K8S和Neutron之间的信使，通过使用K8S的CNI对接Neutron实现K8S的容器网络，借助Neutron的Overlay能力实现容器网络，在VM场景中可以避免嵌套Overlay。

Kuryr Controller主要实现了两个映射：

K8S的Pod映射到Neutron的Port (Pod → Port)
K8S的Service映射到Neutron的Loadbalancer（Service → VS, EndPoint → RS）

Kuryr的整体架构包括两部分：

Kuryr Controller，集中式控制器与Neutron进行Port和Loadbalancer的对接
Kuryr CNI，部署在每一个Worker Node上执行Pod绑定

Kuryr的设计是一个松耦合的架构，CNI驱动不直接依赖于Neutron，也不直接与Kuryr Controller通信，他们借助K8S的APIServer进行元信息传递（使用Pod元信息中的annotation）。CNI驱动也分为Client和Server两部分，Server是每个节点上的一个守护进程，Server响应来自Client的CNI网络创建和释放请求，并从APIServer中Watch Pod的网络信息，执行vif的绑定操作。具体执行流程如下：

Kuryr除了对接Neutron API来实现一些K8S容器网络概念与Neutron的对接之外，还有一个通用的VIF绑定层来在Node上执行VIF的绑定，创建一个veth pair，一块是Container Interface用于接在容器的Network Namespace中，一块是Host Interface用于接在Neutron的L2拓扑中。这里面包括一些通用的工作比如IPAM和vEth的创建等，也有可以根据vif_type执行不同vendor的绑定脚本。

Kuryr支持两种部署模式，一种是部署在裸机上，一种是部署在VM上。部署在裸机上比较容易理解，部署在VM中依然是单层Overlay，只是将整个K8S部署在VM中，打通Kuryr Controller与部署在Underlay上的OpenStack之间的访问通路。无论是裸机部署还是VM部署，底层思路是一样的，为每个Pod分配一个Neutron的Port，或者是Port上的一个辅助IP。

多云容器网络方案

现在越来越多的互联网公司开始上云，基于稳定性和议价因素他们大都选择使用Kubernetes做多云。K8S在做多云的时候，需要打通多个K8S集群的容器网络，解决多个K8S集群上面容器网络中提到的Pod间通信、Pod与Service的通信和外部访问Service问题。

虽然Kubernetes社区从1.3版本开始提供了Federation的方案，实现跨 Region 跨服务商 Kubernetes 集群服务。每个 Kubernetes Federation 有自己的分布式存储、API Server 和 Controller Manager。用户可以通过 Federation 的 API Server 注册子 Kubernetes Cluster，通过 Federation 的 API Server 创建、更改 API 对象时，会在子 Kubernetes Cluster 都创建一份对应的 API 对象，实现K8S集群的元信息同步。但是由于当前项目较新不成熟，且存在Federation控制面故障会波及全部Kubernetes集群，同时由于多K8S集群还引入了Template进行不同集群的Selector和配置派生，这些都带来了一些复杂性，因此较少在生产环境中使用。

Pod间互通

Pod间互通，不管容器网络使用的是VPC路由还是ENI方案，都可以通过专线+VPC路由的方式来打通。

Pod访问Service/外部访问Service

跨Cluster的Pod访问Service和外部访问Service是一个问题，将Service通过Cloud Provider的LoadBalancer暴露出去，这样Service的VIP就从只能内部访问变为外部也能访问了，通过上面Pod间互通的VPC专线路由配置就可以实现Pod访问Service。

如果专线对端是Underlay网络，可以使用Calico通过BGP动态路由方式将Service的VIP暴露出来，这样通过VPC专线路由也可以实现云上Pod访问云下Service。需要注意的是公有云VPC一般不支持BGP动态路由，因此无法在公有云上使用Calico BGP路由方式来发布Service的VIP，只能通过公有云的LoadBalancer来暴露出来。

DNS

可以通过Local DNS配置实现不同域名后缀递归到不同的K8S集群的kube-dns，每个集群的kube-dns也通过上面Pod访问Service中的LoadBalancer方式暴露到外部。比如在每个Node上部署一个dnsmasq/unbound都可以实现缓存和后缀按需递归（最初AWS的混合云DNS方案就是这样的）。

参考

Kubernetes架构

容器Flannel vxlan基本原理和验证

Kuryr Kubernetes Integration Design

macvlan/ipvlan调研及竞标知乎方案

Kubernetes网络的IPVlan方案

Kubernetes-Networking-Made-Easy-with-Open-vSwitch-and-OpenFlow-Péter-Megyesi-LeanNet-ltd..pdf

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

kubernetes容器网络

K8S架构

分层架构

总体架构

Master架构

Node架构

核心概念

K8S容器网络

容器网络基础

Virtual bridge

Multiplexing

Hardware switching

CNI

Pod间通信

Flannel

Calico

DNS

Service

Userspace代理模式

Iptables代理模式

IPVS代理模式

OVS方案

tun+iptables方案

就绪探针

Ingress

外界访问Service

公有云上容器网络方案

VPC路由

ENI

百度云方案

阿里云方案

LB FastPath演进

公司内云原生容器网络方案

需求

Service

IDC非K8S机器和K8S内部Pod间通信

IDC非K8S机器和K8S内部Service间通信

Kuryr

多云容器网络方案

Pod间互通

Pod访问Service/外部访问Service

DNS

参考

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像