前言：
现在各位老铁们对“ipcnginx”大约比较重视，大家都需要学习一些“ipcnginx”的相关资讯。那么小编在网摘上收集了一些对于“ipcnginx””的相关内容，希望你们能喜欢，朋友们快快来学习一下吧！Kubernetes 网络需求
在深入了解数据包如何在 Kubernetes 集群内流动的详细信息之前，让我们首先弄清楚 Kubernetes 网络的要求。
Kubernetes 网络模型定义了一组基本规则：
群集中的 Pod 应该能够与任何其他 Pod 自由通信，而无需使用网络地址转换 （NAT）。在群集节点上运行的任何程序都应与同一节点上的任何 Pod 通信，而无需使用 NAT。每个容器都有自己的 IP 地址（IP-per-Pod），并且每个其他容器都可以通过同一地址访问它。
为了满足这些约束，我们必须解决以下挑战：
如何确保同一 Pod 中的容器的行为就像它们在同一主机上一样？Pod 能否到达集群中的其他 Pod？容器能否访问服务？服务是否对请求进行负载平衡？Pod 能否接收集群外部的流量？
这里我们将重点介绍前三点，从容器内网络或容器到容器通信开始。
Linux 网络命名空间在 Pod 中的工作原理
让我们考虑一个托管应用程序的主容器和另一个与它一起运行的主容器。
在此示例中，我们有一个带有 Nginx 容器的 pod，另一个带有 busybox 的容器：
pod.yaml
apiVersion: v1kind: Podmetadata: name: multi-container-podspec: containers: - name: container-1 image: busybox command: ['/bin/sh', '-c', 'sleep 1d'] - name: container-2 image: nginx
部署后，会发生以下情况：
Pod 在节点上获取自己的网络命名空间。将为容器分配一个 IP 地址，并在两个容器之间共享端口。两个容器共享相同的网络命名空间，并且可以在本地主机上看到彼此。
网络配置在后台以闪电般的速度发生。
但是，让我们退后一步，尝试理解为什么容器需要上述内容才能运行。
在 Linux 中，网络命名空间是单独的、隔离的逻辑空间。
我们可以将网络命名空间视为将物理网络接口切成更小的独立部分。
每个部分都可以单独配置，并具有自己的网络规则和资源。
这些范围可以从防火墙规则、接口（虚拟或物理）、路由以及所有其他与网络相关的内容。
物理接口最终必须处理所有真实数据包，因此所有虚拟接口都是从中创建的。
网络命名空间可由管理工具管理，并且可用于列出主机上的命名空间。ip-netnsip netns list
例如，这些是来自 Kubernetes 节点的命名空间：
ip netns listcni-0f226515-e28b-df13-9f16-dd79456825ac (id: 3)cni-4e4dfaac-89a6-2034-6098-dd8b2ee51dcd (id: 4)cni-7e94f0cc-9ee8-6a46-178a-55c73ce58f2e (id: 2)cni-7619c818-5b66-5d45-91c1-1c516f559291 (id: 1)cni-3004ec2c-9ac2-2928-b556-82c7fb37a4d8 (id: 0)
请注意前缀;这意味着命名空间的创建已由 CNI 负责。
当您创建一个 Pod 并且该 Pod 被分配给一个节点时，CNI 将：
分配 IP 地址。将容器连接到网络。
如果 pod 包含上述多个容器，则两个容器都放在同一个命名空间中。
那么，当您在节点上列出容器时会发生什么？
你可以通过 SSH 连接到 Kubernetes 节点并探索命名空间：
lsns -t net NS TYPE NPROCS PID USER NETNSID NSFS COMMAND4026531992 net 171 1 root unassigned /run/docker/netns/default /sbin/init noembed norestore4026532286 net 2 4808 65535 0 /run/docker/netns/56c020051c3b /pause4026532414 net 5 5489 65535 1 /run/docker/netns/7db647b9b187 /pause
其中 是用于列出主机上所有可用命名空间的命令。lsns
请记住，Linux 中有多种命名空间类型。
Nginx容器在哪里？
lsns NS TYPE NPROCS PID USER COMMAND# truncated output4026532414 net 5 5489 65535 /pause4026532513 mnt 1 5599 root sleep 1d4026532514 uts 1 5599 root sleep 1d4026532515 pid 1 5599 root sleep 1d4026532516 mnt 3 5777 root nginx: master process nginx -g daemon off;4026532517 uts 3 5777 root nginx: master process nginx -g daemon off;4026532518 pid 3 5777 root nginx: master process nginx -g daemon off;
这里还可以看到一个 pause容器，整个容器是什么？
Pause容器在 Pod 中创建网络命名空间
我们可以使用以下命令检索 还有Nginx 容器的所有命名空间：
sudo lsns -p 5777 NS TYPE NPROCS PID USER COMMAND4026531835 cgroup 178 1 root /sbin/init noembed norestore4026531837 user 178 1 root /sbin/init noembed norestore4026532411 ipc 5 5489 65535 /pause4026532414 net 5 5489 65535 /pause4026532516 mnt 3 5777 root nginx: master process nginx -g daemon off;4026532517 uts 3 5777 root nginx: master process nginx -g daemon off;4026532518 pid 3 5777 root nginx: master process nginx -g daemon off;
这里你有看到了 这个 pause 容器。
pause 容器到底是什么？
集群中的每个 Pod 都有一个额外的隐藏容器在后台运行，称为 pause。
如果列出节点上运行的容器并获取pause容器
docker ps | grep pausefa9666c1d9c6 registry.k8s.io/pause:3.4.1 "/pause" k8s_POD_kube-dns-599484b884-sv2js…44218e010aeb registry.k8s.io/pause:3.4.1 "/pause" k8s_POD_blackbox-exporter-55c457d…5fb4b5942c66 registry.k8s.io/pause:3.4.1 "/pause" k8s_POD_kube-dns-599484b884-cq99x…8007db79dcf2 registry.k8s.io/pause:3.4.1 "/pause" k8s_POD_konnectivity-agent-84f87c…
我们将看到，对于节点上每个分配的 Pod，都会自动与它配对一个容器。pause
此Pause容器负责创建和保存网络命名空间。
正在创建命名空间？
是和不是。
网络命名空间创建由底层容器运行时完成。通常或.containerdCRI-O
在部署 Pod 和创建容器之前，（除其他事项外）创建网络命名空间是运行时的责任。
Pause容器自动执行从创建网络命名空间的操作。ip netns
它包含很少的代码，一旦部署，就会立即进入睡眠状态。
然而，它是必不可少的，并且在 Kubernetes 生态系统中起着至关重要的作用。
为了理解Pause容器的效用，让我们想象有一个带有两个容器的 pod，如上一个示例所示，但没有容器：Pause
容器启动后，CNI：
使 busybox 容器加入以前的网络命名空间。分配 IP 地址。将容器连接到网络。
如果 Nginx 崩溃会发生什么？
CNI将不得不再次完成上面列出所有步骤，并且两个容器的网络都将中断。
因为一个sleep的简单的容器，它通常是更安全，简单，健壮的。 用它来创建网络命名空间，更不容易出错。
如果 Pod 中的一个容器（非Pause）崩溃，其余容器仍然可以回复任何网络请求。Pause 容器就是这么一个带着简单任务来的容器，不容易出错。
Pod 被分配了一个 IP 地址
我提到 pod 和两个容器接收相同的 IP。
这是如何配置的？
在 Pod 网络命名空间内，将创建一个接口，并分配一个 IP 地址。就和上面的图画的一样。
现在我们介绍了容器之间的通信，下一讲我们看看 Pod 到 Pod 的通信是如何建立的。
标签： #ipcnginx
