Kubernetes CNI与Kube-proxy

Question

我不确定CNI插件和Kubernetes中的Kube-proxy有什么区别。从文档中得出的结论如下：

Kube-proxy负责与主节点进行通信并进行路由。

CNI通过将IP地址分配给Pod和服务来提供连接性，并通过其路由守护进程实现可达性。

路由似乎是两者之间的重叠功能，对吗？

亲切的问候，查尔斯

Answer 1

kubernetes中有两种IP：ClusterIP和Pod IP。

CNI

CNI 关心 Pod IP。

CNI Plugin 专注于建立一个覆盖网络，没有它，Pod 就无法相互通信。CNI 插件的任务是在调度时为 Pod 分配 Pod IP，并为该 IP 构建一个虚拟设备，并使该 IP 可从集群的每个节点访问。

在 Calico 中，这是通过 N 个主机路由（N=cali veth 设备的数量）和 tun0 上的 M 个直接路由（M=K8s 集群节点的数量）来实现的。

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.29.1     0.0.0.0         UG    100    0        0 ens32
10.130.29.0     0.0.0.0         255.255.255.0   U     100    0        0 ens32
10.244.0.0      0.0.0.0         255.255.255.0   U     0      0        0 *
10.244.0.137    0.0.0.0         255.255.255.255 UH    0      0        0 calid3c6b0469a6
10.244.0.138    0.0.0.0         255.255.255.255 UH    0      0        0 calidbc2311f514
10.244.0.140    0.0.0.0         255.255.255.255 UH    0      0        0 califb4eac25ec6
10.244.1.0      10.130.29.81    255.255.255.0   UG    0      0        0 tunl0
10.244.2.0      10.130.29.82    255.255.255.0   UG    0      0        0 tunl0

在本例中，10.244.0.0/16是 Pod IP CIDR，10.130.29.81是集群中的一个节点。你可以想象，如果你有一个 TCP 请求到10.244.1.141，它将10.130.29.81按照第 7 条规则发送到。在 上10.130.29.81，会有这样的路由规则：

10.244.1.141    0.0.0.0         255.255.255.255 UH    0      0        0 cali4eac25ec62b

这将最终将请求发送到正确的 Pod。

我不确定为什么需要守护进程，我猜守护进程是为了防止手动删除它创建的路由规则。

kube代理

kube-proxy 的工作相当简单，它只是将请求从集群 IP 重定向到 Pod IP。

kube-proxy 有两种模式，IPVS和iptables. 如果您的 kube-proxy 在IPVS模式下工作，您可以通过在集群中的任何节点上运行以下命令来查看 kube-proxy 创建的重定向规则：

ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 10.130.29.80:6443            Masq    1      6          0         
  -> 10.130.29.81:6443            Masq    1      1          0         
  -> 10.130.29.82:6443            Masq    1      0          0         
TCP  10.96.0.10:53 rr
  -> 10.244.0.137:53              Masq    1      0          0         
  -> 10.244.0.138:53              Masq    1      0          0   
...

在这种情况下，可以看到 CoreDNS 的默认集群 IP，其10.96.0.10背后是两个真实的服务器，带有 Pod IP：10.244.0.137和10.244.0.138。

这个规则就是 kube-proxy 要创建的，也是 kube-proxy 创建的。

PSiptables模式几乎一样，但iptables规则看起来很难看。我不想把它贴在这里。:p

Answer 2

覆盖网络

Kubernetes假定每个Pod都有一个IP地址，并且您可以使用该IP地址与该Pod中的服务进行通信。当我说“覆盖网络”时，这就是我的意思（“使您可以通过其IP地址引用Pod的系统”）。

所有其他Kubernetes网络东西都依赖于覆盖网络正常工作。

有很多覆盖网络后端（印花布，法兰绒，编织），而且情况非常混乱。但就我而言，覆盖网络有2个职责：

1. 确保您的Pod可以向集群外部发送网络请求
2. 保持节点到子网的稳定映射，并使用该映射更新群集中的每个节点。添加和删​​除节点时，请做正确的事。

KUBE-PROXY

只是为了了解kube-proxy，这就是Kubernetes服务的工作方式！服务是Pod的集合，每个Pod都有自己的IP地址（例如10.1.0.3、10.2.3.5、10.3.5.6）

1. 每个Kubernetes服务都获得一个IP地址（例如10.23.1.2）
2. kube-dns将Kubernetes服务DNS名称解析为IP地址（因此my-svc.my-namespace.svc.cluster.local可能映射到10.23.1.2）
3. kube-proxy设置iptables规则以便在它们之间进行随机负载平衡。

因此，当您向my-svc.my-namespace.svc.cluster.local请求时，它解析为10.23.1.2，然后本地主机（由kube-proxy生成）上的iptables规则将其重定向到10.1之一。 0.3或10.2.3.5或10.3.5.6随机。

简而言之，overlay networks定义可用于通信kubernetes各种组件的基础网络。While kube-proxy是一个生成IP表魔术的工具，无论该Pod存在于哪个节点上，它都可以使您连接到kubernetes中的任何Pod（使用servics）。

此答案的一部分来自此博客：

https://jvns.ca/blog/2017/10/10/operating-a-kubernetes-network/

希望这能给您有关kubernetes网络的简要介绍。