28

我不确定 CNI 插件和 Kubernetes 中的 Kube-proxy 有什么区别。根据我从文档中得到的信息，我得出以下结论：

Kube-proxy 负责与主节点通信和路由。

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

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

亲切的问候，查尔斯

4

3 回答 3

30

覆盖网络

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

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

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

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

KUBE-代理

只是为了了解 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，然后本地主机上的 iptables 规则（由 kube-proxy 生成）将其重定向到 10.1 之一。 0.3 或 10.2.3.5 或 10.3.5.6 随机。

简而言之，overlay networks定义可用于通信 Kubernetes 各个组件的底层网络。Whilekube-proxy是一个生成 IP 表魔法的工具，它可以让你连接到 kubernetes 中的任何 pod（使用服务），无论该 pod 存在于哪个节点上。

此答案的部分内容来自此博客：

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

希望这能让您简要了解 Kubernetes 网络。

于 2018-11-29T10:04:01.010 回答
27

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

CNI

CNI 关心 Pod IP。

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

在 Calico 中，这是通过 N 条主机路由（N=caliveth 设备的数量）和 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 的工作相当简单，它只是将请求从 Cluster 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 的默认 Cluster IP，其10.96.0.10后面是两个具有 Pod IP 的真实服务器：10.244.0.137和10.244.0.138。

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

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

于 2019-02-26T08:57:22.300 回答
-2

我的 2 美分，如果不准确，请纠正我

Kube-proxy 控制 K8s 网络通信，网络基于 CNI 插件。

CNI 插件实现 CNI

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

于 2021-08-23T15:38:58.533 回答