2

当 CNI 插件在容器级别工作时，kubernetes pod 如何获取 IP 而不是容器而不是它？

同一个 pod 的所有容器如何共享同一个网络堆栈？

4

4 回答 4

1

容器使用内核中称为虚拟网络接口的功能，创建虚拟网络接口（让它命名为veth0）然后分配给命名空间，当创建容器时，它也分配给命名空间，当创建多个容器时在同一个命名空间中，只会创建一个网络接口 veth0。

POD 只是用于指定一组资源和功能的术语，其中之一是命名空间和在其中运行的容器。

当您说 POD 获取 IP 时，实际上获取 ip 的是 veth0 接口，容器应用程序看到 veth0 就像容器外的应用程序看到服务器上的单个物理网卡一样。

CNI 只是关于如何在不更改平台的情况下使多个网络插件工作的技术规范。上面的过程应该对所有网络插件都是一样的。

这篇博文中有一个很好的解释

于 2019-02-24T17:38:54.493 回答
0

首先，让我们深入研究 CNI 方面。在生产系统中，workload/pod（workload 可以被认为是一个或多个容器化应用程序，用于完成某种功能）网络隔离是一流的安全要求。此外，根据基础设施的设置方式，路由平面可能还需要是工作负载（kubectl 代理）或主机级代理（kube 代理）或中央路由平面（apiserver 代理）的属性主机级代理为其公开网关。

对于服务发现和实际从工作负载/pod 发送请求，您不希望单个应用程序开发人员与 apiserver 代理通信，因为这可能会产生开销。相反，您希望它们通过 kubectl 或 kube 代理与其他应用程序通信，这些层负责了解何时以及如何与 apiserver 平面通信。

因此，当启动一个新的工作负载时，可以传递 kubelet--network-plugin=cni和一个配置路径，告诉 kubelet 如何为这个工作负载/pod 设置虚拟网络接口。

例如，如果您不希望 pod 中的应用程序容器能够直接与主机级 kube 代理通信，因为您想做一些特定于基础设施的监控，那么您的 CNI 和工作负载配置将是：

  • 最外层容器监控
  • 最外层容器为 pod 中的每个其他容器创建虚拟网络接口
  • 最外层的容器位于可以与主机上的 kube 代理通信的桥接接口（也是私有虚拟网络接口）上

Pod 获得的 IP 是为了允许其他工作负载通过其桥接接口向该 Pod 发送字节 - 因为从根本上说，其他人应该与 Pod 交谈，而不是 Pod 内的单个工作单元。

于 2019-02-24T17:45:32.407 回答
0

有一个称为“暂停容器”的特殊容器，它保存 pod 的网络命名空间。它不做任何事情，它的容器进程只是进入睡眠状态。

Kubernetes 为每个 pod 创建一个暂停容器，以获取相应 pod 的 IP 地址并为属于特定 pod 的所有其他容器设置网络命名空间。pod 中的所有容器都可以使用 localhost 相互访问。

这意味着您的“应用程序”容器可能会死掉，然后恢复生机，所有网络设置仍然完好无损。

于 2019-02-24T17:52:57.930 回答
0

它是让一切正常工作的 kubeproxy。一个 pod 有一个代理，它通过一个 IP 为其余容器转换所有端口。只有在特定情况下，才会说您希望在同一个 pod 中拥有多个容器。它不是首选，但可能。这就是为什么他们称之为“紧密”耦合的原因。请参考：https ://kubernetes.io/docs/concepts/cluster-administration/proxies/

于 2019-02-24T17:18:56.590 回答