Question

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

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

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

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

亲切的问候，查尔斯

Answer 1

覆盖网络

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

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

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

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

KUBE-PROXY

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

每个Kubernetes服务都获得一个IP地址（例如10.23.1.2）
kube-dns将Kubernetes服务DNS名称解析为IP地址（因此my-svc.my-namespace.svc.cluster.local可能映射到10.23.1.2）
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各个组成部分的基础网络。 kube-proxy是生成IP表魔术的工具，无论您位于哪个Pod节点上，它都可以使您连接到kubernetes中的任何Pod（使用servics）。

我强烈建议您阅读以下博客，以加深了解：

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

希望这可以为您提供有关kubernetes网络的简要信息。

Answer 2

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

CNI

CNI关心Pod IP。

CNI插件专注于构建覆盖网络，没有它们，Pods将无法相互通信。 CNI插件的任务是在计划Pod时为其分配Pod IP，并为此IP构建虚拟设备，并使该IP可从群集的每个节点访问。

在Calico中，这是通过N个主机路由（N = calive设备的数量）和M个直接路由在tun0（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是群集中的节点。您可以想象，如果您有一个对10.244.1.141的TCP请求，它将按照第七条规则发送到10.130.29.81。在10.130.29.81上，将有一个如下的路由规则：

10.244.1.141    0.0.0.0         255.255.255.255 UH    0      0        0 cali4eac25ec62b

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

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

kube-proxy

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 10.96.0.10的默认群集IP，在其后面是两个具有Pod IP的真实服务器：10.244.0.137和10.244.0.138。

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

P.S。 iptables模式几乎相同，但是iptables规则看起来很丑。我不想在这里粘贴。：p

Kubernetes CNI与Kube-proxy

2 个答案:

CNI

kube-proxy