k8s网络模型

---

一、同一pod（sidecar）

好处

• 在同一个pod，将关系紧密的容器放在一起，通过挂载同一数据卷来共享数据
• 共享网络，内部相互调用访问更高效

坏处

• 共享网络，每个容器的端口需要规划
• 一个容器需要升级，会影响到整个pod滚动升级

二、pod和集群网络

在容器启动前，会为容器创建一个虚拟Ethernet接口对，这个接口对类似于管道的两端，其中一端在主机命名空间中，另外一端在容器命名空间中，并命名为eth0。在主机命名空间的接口会绑定到网桥(2层)。网桥的地址段会取IP赋值给容器的eth0接口。

同一节点下

当pod发往网桥时，会成功被arp解析转发

不同节点

Kubernetes网络模型要求Pod IP在整个网络上都是可访问的。通常，为群集中的每个节点分配一个CIDR块，以指定该节点上运行的Pod可用的IP地址。目的地为CIDR块的流量一旦到达该节点，会将其转发到指定的pod上。这里的数据包在网桥处并会被arp解析失败从而通过路由根据CIDR发送到正确的节点。

三、service网络

为了解决Pod IP地址不是持久性的，可能会进行更改，k8s采用service对pod进行抽象，service为pod组提供虚拟ip，任何路由到这个虚拟ip的，都将转发到对应关联的pod上，而且service还提供高可用与负载均衡

netfilter

为了在群集内执行负载平衡，Kubernetes依赖于Linux内置的网络框架netfilter； Netfilter是Linux提供的框架，它允许以自定义处理程序的形式实现与网络相关的各种操作。数据包筛选，网络地址转换和端口转换的操作，提供了通过网络引导数据包所需的功能，并提供了禁止数据包到达计算机网络内敏感位置的功能。

iptables

默认采用iptables，其是一个用户空间程序，它提供了一个基于表的系统，用于定义netfilter模块的处理和转换数据包的规则；iptables规则监视发往服务虚拟的流量IP，并从一组可用的Pod中随机选择一个Pod IP地址，并且iptables规则将数据包的目标IP地址从服务的虚拟IP更改为所选Pod的IP。
clustip
nodeport，在node上面开启一个监听端口，负责将service暴露给外面访问，通过访问这个service的这个端口可以确认访问这个service，会有iptables做地址转换
pod去访问service是需要通过宿主机的，不然没法通过宿主机的内核net_filter模块做nat地址转换

• 数据包通过eth0离开pod1
• 数据包来到网桥，arp协议不了解服务，发往默认路由eth0
• 在到达eth0前，iptables改写目标ip为特点的pod ip，并记录下来这次的pod选择，以便将来的相同事件

coreDNS

k8sDns的默认实现，配置在每个Node上运行的kubelet，集群中的服务都分配有DNS名称，当容器需要解析DNS名称时进行解析。

四、networkpolicy

pod级别的网络访问策略
常见实现有iptables规则控制和ovs流表控制。
flannal实现方案

五、CNI容器网络标准

cni

CNI(container network interface)是一个接口规范，用于编写k8s集群的网络插件。有四个命令，add、del、check、version。
插件分类

• main,负责容器网卡的初始化或者清理。。
  bridge，和 docker 默认的网络模型很像，把所有的容器连接到虚拟交换机上

• meta，本身并不会提供具体的网络功能，它会调用其他插件，或者单纯是为了测试；
  flannel，结合 bridge 插件使用，根据 flannel 分配的网段信息，调用 bridge 插件，保证多主机情况下容器
  tunning、bandwith

• ipam，负责ip管理，常见的实现有host-local、dhcp

这些插件可以链式调用
插件运行过程

• 会先去/etc/cni/net.d/*读取的第一个文件作为配置文件，然后去/opt/cni/bin/*执行cni插件
• 当kubelet创建pod的时候会去创建pause容器，当发现pause容器可以了后，会尝试为这个容器配置网络，当发现某个pod要删除了，会删除这个pod的业务容器，并检查其对应的pause容器是否不需要了，如果不需要则进行删除
  
  这里的流程是，kubelet创建pause容器 -> 检查pause容器 -> 根据配置文件，执行add命令->先去执行bridge插件，bridge插件查看到ipam有内容，会执行host-local -> 然后把其执行结果配置作为bridge的输入，去配置ip路由，将结果组装起来返回给kubelet -> kubelet会去执行下一个插件tuning -> tuning执行完，kubelet认为网络配置成功 -> 开始创建pod的业务容器

pause容器(PodSandbox)

每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。

cni调用和设计