Kubernetes网络入门002篇【20260407】
文章目录
- Kubernetes 网络全景深度解析
- 一、 核心设计哲学与模型再审视
- 1.1 四大核心原则的深层含义
- 1.2 网络命名空间：Pod网络隔离的基石
- 二、 Pod间网络：CNI插件的实现图谱
- 2.1 主要实现模式对比
- 2.2 数据包流转示例：跨节点Pod通信
- 三、 Service网络：kube-proxy的三种模式与演进
- 3.1 kube-proxy模式深度对比
- 3.2 Service类型与流量路径
- 3.3 服务发现：CoreDNS如何工作
- 四、 Ingress：七层流量网关
- 4.1 Ingress vs. Service
- 4.2 核心组件交互
- 4.3 常见Ingress Controller
- 五、 网络策略：Pod的微防火墙
- 5.1 关键概念
- 5.2 示例与详解
- 六、 服务网格：下一代服务网络
- 6.1 服务网格与K8S原生网络的关系
- 6.2 服务网格增强的能力
- 七、 多集群网络与高级模式
- 7.1 多集群网络方案
- 7.2 网络性能优化
- 八、 典型网络故障排查思路
Kubernetes 网络全景深度解析
一、 核心设计哲学与模型再审视
Kubernetes网络模型并非一个具体的实现，而是一套设计契约。理解这套契约的初衷是理解其所有复杂性的基石。
1.1 四大核心原则的深层含义
Pod拥有唯一IP（IP-per-Pod）：
- 目的：消除端口管理的复杂性。在传统基础设施中，单个主机上的多个进程需要协调端口使用。在K8S中，每个Pod都被视为一个独立的“逻辑主机”，拥有自己的IP，因此其内部所有容器都可以绑定到任何端口，无需担心集群范围内的冲突。
- 影响：这简化了应用从物理机/虚拟机向容器化迁移的过程，应用可以像在独立机器上一样配置网络。
Pod间直接通信（No NAT）：
- 目的：保留源IP，简化网络故障排查、安全策略实施（如基于IP的防火墙规则）和网络日志记录。数据包从源Pod到目标Pod，其IP头中的地址保持不变。
- 挑战：这意味着整个集群必须位于一个“平坦的”、可路由的IP网络中。任何Pod IP必须能被任何节点直接路由，这直接催生了CNI插件生态的繁荣。