Kubernetes CNI诉Kube代理

Question

我不知道CNI插件和Kubernetes的Kube代理之间有什么区别。根据我从文档中得到的，我得出以下结论：

Kube代理负责与主节点的通信和路由.

CNI通过为豆荚和服务分配IP地址来提供连通性，并通过其路由deamon实现可达性。

路由似乎是两者之间的一个重叠函数，是这样吗？

你好，查尔斯

Answer 1

覆盖网络

Kubernetes假设每个pod都有一个IP地址，并且您可以使用该IP地址与该吊舱内的服务进行通信。当我说“覆盖网络”时，这就是我的意思(“允许您通过IP地址引用一个pod的系统”)。

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

有很多覆盖网络后端(棉布，法兰绒，编织)和景观是相当混乱的。但就我而言，覆盖网络有两个责任：

1. 确保您的吊舱可以将网络请求发送到群集之外。
2. 保持节点到子网的稳定映射，并使用该映射更新集群中的每个节点。在添加和删除节点时执行正确的操作。

KUBE-PROXY

为了理解kube，以下是Kubernetes服务的工作原理！服务是豆荚的集合，每个豆荚都有自己的IP地址(如10.1.0.3、10.2.3.5、10.3.5.6)

1. 每个Kubernetes服务都有一个IP地址(比如10.23.1.2)
2. kube将Kubernetes服务DNS名称解析为IP地址(因此my-svc.my-name pace.svc.cluster.local可以映射到10.23.1.2)
3. kube设置iptable规则，以便在它们之间进行随机负载平衡。

因此，当您向my-svc.my- make pace.svc.cluster.local发出请求时，它将解析为10.23.1.2，然后在本地主机(由kube生成)上的iptables规则随机将其重定向到10.1.0.3或10.2.3.5或10.3.5.6。

简而言之，overlay networks定义了可用于通信kubernetes的各种组件的底层网络。虽然kube-proxy是一种生成IP表的工具，但是它允许您连接到kubernetes中的任何一个pod (使用servics)，而不管该pod存在于哪个节点上。

这个答案的一部分摘自这个博客：

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

希望这能让你对kubernetes的关系网有一个简单的了解。

Answer 2

在kubernetes中有两种IP : ClusterIP和Pod。

CNI

CNI关心Pod IP。

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

在Calico中，这是由N个主机路由( cali veth设备的N=the号)和tun0上的M条直接路由( K8s集群节点的M=the数)来实现的。

$ 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，而10.130.29.81是集群中的一个节点。您可以想象，如果您有一个TCP请求到10.244.1.141，它将按照第7条规则发送到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的工作相当简单，它只是将请求从集群IP重定向到Pod IP。

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

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的真正服务器：10.244.0.137和10.244.0.138。

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

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

Answer 3

我的两分钱，如果不准确就纠正我

Kube代理控制K8s网络通信，而网络是基于CNI插件的.

CNI插件实现CNI

CNI是用于简化网络通信的覆盖网络。