Kubernetes网络

Kubernetes网络模型

Kubernetes网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端端口等问题。

在Kubernetes世界里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈（实际上是一个网络命名空间，包括它们的IP地址、网络设备、配置等都是共享的，同一个Pod内的容器可以通过localhost来连接对方的端口）。按照这个网络原则抽象出来的“一个Pod一个IP”的设计模型也被称作IP-per-Pod模型。

IP地址和端口在Pod内部和外部都保持一致，可以不使用NAT来进行转换，地址空间也自然是扁平的。Kubernetes的网络之所以这么设计的主要原因是可以兼容过去的应用，所以这种IP-per-Pod的方案能很好地利用现有的各种域名解析和发现机制。

IP-per-Pod模式和Docker原生的通过动态端口映射方式实现的多节点访问模式有什么区别呢？主要区别是后者的动态端口映射会引入端口管理的复杂性，而且访问者看到的IP地址和端口与服务提供者实际绑定的不同（因为NAT的缘故，它们都被映射成新的地址和端口了），这也会引起应用配置的复杂化。同时标准的DNS等名字解析服务也不适用了。甚至服务注册和发现机制都将受到挑战，因为在端口映射情况下，服务自身很难知道自己对外暴露的真实的服务IP和端口，而外部应用也无法通过服务所在容器的私有IP地址和端口来访问服务。

总的来说，IP-per-Pod模型是一个简单的兼容性较好的模型。从该模型的网络的端口分配、域名解析、服务发现、负载均衡、应用配置和迁移等角度来看，Pod都能够被看作一台独立的“虚拟机”或者“物理机”。

汇总下Kubernetes Pod网络设计模型：

1）基本原则：每个Pod都拥有一个独立的IP地址（IP per Pod），而且假定所有的Pod都在一个可以直接连通的、扁平的网络空间中。

2）设计原因：用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题。

3）网络要求：所有的容器都可以在不用NAT的方式下同其他容器通信；所有节点都可在不用NAT的方式下同所有容器通信；容器的地址和别人看到的地址是同一个地址。

容器和pod间通信

1. 同一pod内不同容器间通信

同一个Pod的容器共享同一个网络命名空间，它们之间的访问可以通过localhost地址和容器端口实现。

同一pod内容器间通信

2. 同一node节点不同pod间容器通信

同一Node中Pod的默认路由都是Docker0的地址，由于它们关联在同一个Docker0网桥上，地址网段相同，所以它们能直接通信。

同一node上不同pod间容器通信

Pod1和Pod2通过Veth连接在Docker0网桥上，它们的IP地址IP1、IP2都是从Docker0的网段上动态获取的，它们与网桥本身的IP3是同一个网段。所有非本地地址的网络数据都会默认发送到Docker0网桥，由Docker0网桥直接中转。

3. 不同node节点的pod间容器通信

Docker0网桥与宿主机网卡是两个完全不同的IP网段，并且Node之间的通信只能通过宿主机的物理网卡进行，因此要想实现位于不同Node上的Pod容器之间的通信，就必须想办法通过主机的IP地址进行寻址和通信。

要想支持不同Node上Pod之间的通信，就要达到两个条件：

1）在整个Kubernetes集群中对Pod的IP进行规划，不能有冲突。

2）找到一种方法，将Pod的IP和所在Node关联起来，通过这个关联让Pod可以相互访问。Pod中的数据在发出时需要有一个机制，能够知道对方Pod的IP地址挂在哪个具体的Node上，也就是说先要找到Pod对应宿主机的IP地址，将数据发送到这个宿主机的网卡上，然后在宿主机上将相应的数据发送到具体的Docker0上。一旦数据到达宿主机Node，则该Node内部的Docker0便知道如何将数据发送到Pod。

不同node上pod间容器通信

kube-proxy实现方式

kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责Service的实现：实现从Pod到Service，以及从NodePort向Service的访问。实现方式包括userspace方式和iptables方式。

kube-proxy监视Kubernetes主服务器对服务/端点对象的各种增、删、改等操作。

对于每个服务，它配置iptables规则，捕获Service的ClusterIP和端口的流量，并将流量重定向到服务的后端之一。

对于每个Endpoint对象，它选择后端Pod的iptables规则。 默认情况下，后端的选择是随机的。可通过service.spec.sessionAffinity设置为“ClientIP”来选择基于客户端IP的会话关联。

与用户空间代理一样，最终结果是绑定到服务的IP：端口的任何流量被代理到适当的后端，而客户端不知道关于Kubernetes或服务或Pod的任何信息。

DNS服务发现机制

kube-dns用来为Service分配子域名，以便集群中的Pod可通过DNS域名获取Service的访问地址；通常kube-dns会为Service赋予一个名为“service_name.namespace_name. svc. cluster_domain”的记录，用来解析Service的Cluster_IP。

Kubernetes v1.4版本及其以后的DNS服务

Kubedns通过Kubernetes API监视Service资源变化并更新DNS记录，并使用树形结构在内存中保存DNS记录，主要为Dnsmasq提供查询服务，服务端口是10053。

Dnsmasq是一款小巧的DNS配置工具，其在kube-dns插件中的作用是：通过kube-dns容器获取DNS规则，在集群中提供DNS查询服务；提供DNS缓存，提高查询性能；降低kube-dns容器的压力、提高稳定性。

Exechealthz主要提供健康检查功能。

摘抄自陆平的《基于Kubernetes的容器云平台实战》一书的第9章Kubernetes Service