CRI (containerd/CRI-O) + hostNetwork

喝醉酒的小白

于 2025-05-20 15:16:18 发布

阅读量610

点赞数 24

分类专栏： K8s 文章标签：学习

本文链接：https://blog.csdn.net/hezuijiudexiaobai/article/details/148088505

版权

K8s 专栏收录该内容

297 篇文章

订阅专栏

目录标题

在 Kubernetes 1.24 中移除了 Dockershim，转而使用 CRI（如 containerd 或 CRI-O）来管理容器运行时；此时若在 PodSpec 中设置 hostNetwork: true，Pod 就会跳过独立网络命名空间的创建，直接附着到节点的网络命名空间上，容器进程绑定的端口和接口即为宿主机的端口和接口，无需中间的代理或 DNAT 规则。下面分几部分详细说明这一机制在 “无 Docker” 环境下的实现原理。

1. Docker Shim 移除与 CRI 架构变更

Dockershim 移除
Kubernetes 1.24 正式删除了对 Docker Engine 作为容器运行时的原生支持（Dockershim）(Kubernetes)。
CRI 取代方案
当前主流集群通常采用 containerd 或 CRI-O，通过 Kubelet 的 CRI 接口管理容器生命周期与网络命名空间（Network Namespace）(Kubernetes)。

2. `hostNetwork: true` 的网络暴露原理

共享网络命名空间
当 hostNetwork: true 时，Kubelet 不会为 Pod sandbox 创建独立的网络命名空间，而是让其共享所在节点的网络命名空间——容器的 eth0、IP、路由等即为主机的(support.huaweicloud.com)。
直接绑定宿主机接口
容器里应用监听的端口直接绑定到宿主机的网络接口，等同在宿主机上启动该进程；访问时使用节点 IP + 对应端口即可命中容器服务，无需 Docker-proxy 或 iptables DNAT 规则(腾讯云, GitHub)。
跳过 CNI 插件
对于 hostNetwork 模式，CNI 插件通常不对网络进行额外配置，因为不需要创建或设置独立的网络命名空间(tetrate.io, tigera.io)。

3. CRI-O / containerd 中的实现流程

Pod 调度与沙箱创建
Kubelet 调用 CRI（containerd 或 CRI-O）创建一个 Pod-level 的沙箱容器（Pause Container），并准备网络命名空间。此步骤在非 hostNetwork 时会通过 CNI 创建独立命名空间(博客园)。
HostNetwork 跳过
如果检测到 hostNetwork: true，CRI 直接将沙箱和后续应用容器附加到节点的默认网络命名空间，不执行 CNI 的网络 namespace 配置(support.huaweicloud.com)。
容器启动与端口绑定
应用容器在此共享的命名空间中启动，监听的端口即为宿主机接口上的端口。容器运行时（containerd/cri-o + crun/runc）直接调用 bind() 到宿主机接口，无需任何中间转发(GitHub, GitHub)。

4. 与旧有 Docker-proxy 方案的对比

特性	Docker + docker-proxy	CRI (containerd/CRI-O) + hostNetwork
端口转发	通过独立进程 `/usr/bin/docker-proxy` 或者 `iptables DNAT` 实现	直接在容器进程中绑定宿主机接口，无额外代理或 DNAT
性能与延迟	存在一层进程/iptables 转发开销	无额外转发环节，性能更优
网络隔离	Pod 仍在独立网络命名空间，通过 hostPort 或 Proxy 暴露端口	无隔离，容器与宿主机、其他 `hostNetwork` Pod 共享网络
CNI 插件参与度	通常不影响 CNI 配置	不调用 CNI 插件，跳过网络 namespace 及 IPAM 配置

5. 典型使用场景与注意事项

高性能网络服务
需要最低延迟或较大带宽的场景（如网络探针、监控代理）常用此模式。
端口冲突与安全风险
多个 Pod 或宿主机进程监听同一端口会导致冲突；且失去网络隔离，必须谨慎评估安全边界。
DNS 策略
若同时使用内部服务发现，建议将 dnsPolicy 设置为 ClusterFirstWithHostNet，确保能正确解析集群内服务名。