Pod 内部网络

Pod 是 Kubernetes 中的最小部署单元，由一个或多个容器组成。Pod 内部的网络设计是 Kubernetes 网络模型的基础，它使得同一 Pod 内的容器能够像在同一主机上运行的进程一样进行通信。本页将深入探讨 Pod 内部网络的工作原理和实现细节。

Pod 内部网络模型

Kubernetes Pod 的一个核心特性是其内部的所有容器共享同一个网络命名空间。这种设计有以下几个关键特点：

共享网络命名空间

在 Linux 中，网络命名空间是一种隔离机制，它为一组进程提供独立的网络栈，包括网络接口、路由表、iptables 规则等。在 Kubernetes 中：

每个 Pod 都有自己的网络命名空间
Pod 内的所有容器共享这个网络命名空间
这种共享是通过 Docker/containerd 的 --net=container:<id> 功能实现的

共享网络命名空间意味着 Pod 内的所有容器：

共享同一个 IP 地址和 MAC 地址
共享同一套网络接口
共享同一个端口空间（port space）
共享同一个路由表
共享同一套 iptables/netfilter 规则

Pause 容器（Infrastructure Container）

在 Kubernetes 中，每个 Pod 都有一个特殊的容器，称为 "pause" 容器或基础设施容器（Infrastructure Container）。这个容器有几个重要作用：

创建和持有 Pod 的网络命名空间
作为 Pod 内所有容器的父容器，提供 PID 命名空间（在启用 PID 共享的情况下）
处理已终止容器的僵尸进程
使 Pod 的生命周期不依赖于任何特定的应用容器

pause 容器通常非常小（几 MB），几乎不消耗资源，它的唯一目的就是作为 Pod 内其他容器的"基础设施"。

# 查看节点上的 pause 容器
docker ps | grep pause

# 或者在 containerd 环境中
crictl ps | grep pause
                

Pod 内部通信机制

Pod 内部容器间的通信非常简单高效，因为它们共享同一个网络命名空间。这种设计带来了几个重要的通信特性：

localhost 通信

端口管理

IPC 通信

共享卷

通过 localhost 通信

由于共享网络命名空间，Pod 内的容器可以通过 localhost（127.0.0.1）直接相互通信，就像在同一台主机上运行的进程一样。

工作原理：

容器 A 在特定端口（如 8080）上启动服务
容器 B 可以通过 localhost:8080 访问容器 A 的服务
这种通信完全在内核内部进行，不经过任何网络设备，因此性能极高

示例：

# 在容器 A 中启动 Web 服务
# Dockerfile 片段
FROM nginx
EXPOSE 80

# 在容器 B 中访问容器 A 的服务
# 容器 B 的命令
curl localhost:80
                        

这种通信方式的优点：

极低的延迟，因为数据不经过网络栈
无需 NAT 或路由
简化了应用程序的配置，无需处理跨容器的网络寻址
安全性更高，通信不经过外部网络

端口管理

由于 Pod 内的容器共享同一个端口空间，这意味着它们必须协调端口使用，以避免冲突。

端口分配考虑：

Pod 内的不同容器不能在同一端口上监听
如果容器 A 使用了端口 8080，那么容器 B 就不能再使用这个端口
Pod 内的端口分配需要在设计时考虑，或通过配置文件协调

端口冲突处理：

在 Kubernetes 中，可以通过以下方式处理潜在的端口冲突：

在 Pod 规范中明确定义每个容器使用的端口
使用不同的端口范围（如系统服务使用低端口，应用服务使用高端口）
使用动态端口分配（让应用自动选择可用端口）

# Pod 规范中的端口定义示例
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: web
    image: nginx
    ports:
    - containerPort: 80
  - name: api
    image: my-api
    ports:
    - containerPort: 8080
                        

注意：containerPort 字段主要是文档性质的，不会实际限制容器使用其他端口，但它有助于明确记录端口使用情况。

IPC 通信

除了网络命名空间外，Pod 内的容器还可以共享 IPC（进程间通信）命名空间，这使得它们可以使用 System V IPC 或 POSIX 消息队列等机制进行通信。

IPC 共享机制：

共享内存段（Shared Memory Segments）
信号量（Semaphores）
消息队列（Message Queues）
命名管道（Named Pipes）

示例：使用共享内存通信

# 在容器 A 中创建共享内存段
# C 代码片段
int shmid = shmget(KEY, SIZE, IPC_CREAT | 0666);
char *shm = shmat(shmid, NULL, 0);
strcpy(shm, "Hello from container A");

# 在容器 B 中访问共享内存段
# C 代码片段
int shmid = shmget(KEY, SIZE, 0666);
char *shm = shmat(shmid, NULL, 0);
printf("Message: %s\n", shm);
                        

IPC 通信的优点：

比网络通信更高效，特别是对于大量数据交换
可以实现更复杂的同步机制
适合需要低延迟的应用场景

共享卷

虽然不是严格意义上的网络通信，但共享卷是 Pod 内容器间交换数据的另一种重要方式。

工作原理：

在 Pod 规范中定义一个卷（Volume）
将该卷挂载到多个容器中
容器可以通过写入/读取该卷来交换数据

示例：

apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-pod
spec:
  containers:
  - name: producer
    image: busybox
    volumeMounts:
    - name: shared-data
      mountPath: /data
    command: ["/bin/sh", "-c", "while true; do echo $(date) > /data/date.txt; sleep 10; done"]
  - name: consumer
    image: busybox
    volumeMounts:
    - name: shared-data
      mountPath: /data
    command: ["/bin/sh", "-c", "while true; do cat /data/date.txt; sleep 10; done"]
  volumes:
  - name: shared-data
    emptyDir: {}
                        

共享卷的优点：

简单直观，易于理解和使用
适合传输大文件或持久化数据
可以用于配置文件共享、日志收集等场景
支持多种卷类型，包括 emptyDir、hostPath、configMap、secret 等