k8s 网络基础
k8s是为了办理大集群(Cluster)中容器部署、伸缩和管理的各种标题而出现的一种容器编排引擎。我们上次已经讲了k8s的基础架构，假如各人对基础架构不相识，那么发起先观看k8s的基础架构，那么本日我们来分析，k8s中的网络是怎么构成的。
Node之间的通信
Node IP 是节点在物理网络或云网络中的真实IP地点，可以是内网IP，也可以是公网IP。
构建集群时，必须包管全部节点可以通过Node IP互通，之后kubelet、kube-proxy 等组件通过 Node IP 连接到 API Server。
在 Kubernetes 集群中，节点（Node）之间的通信是通过Node IP来实现的，详细示例有：
通信范例到场组件协议目的控制平面通信API Server ↔ kubeletHTTPS节点状态上报、Pod 生命周期管理控制平面通信API Server ↔ SchedulerHTTP资源调理决定控制平面通信API Server ↔ Controller ManagerHTTP集群状态维护（如 Deployment 扩缩容、Service 同步等）数据平面通信kube-proxy ↔ API ServerHTTPS同步 Service/Endpoint 信息 控制平面通信始终基于节点真实 IP，例如当新节点参加集群时，kubelet 使用 Node IP 访问 API Server，定期向API Server陈诉节点状态等。
pod中容器的通信
Pod 是 Kubernetes 的最小调理单元，同一 Pod 内的全部容器共享同一个网络命名空间，详细表现为：
- 共享同一 IP 地点
- 共享同一端口空间（需避免端口冲突）
- 共享同一网络设备（如虚拟网卡）
- 共享同一主机名（hostname）
此机制与 Docker 的 --network=container:<id> 模式原理一致。
Kubernetes 创建 Pod 时，首先启动一个 pause 容器（镜像为 k8s.gcr.io/pause）,用来创建并持有网络命名空间（Network Namespace）。其作为其他容器的网络基础办法锚点且生命周期与 Pod 完全绑定（Pod 停止时才会销毁）。
其他业务容器通过 container 网络模式接入 pause 容器的网络命名空间。
由于pod中全部容器共享同一个IP地点，所以他们之间可以直接通过localhost举行访问。注意，需要差别服务注册差别的端口号。此外，也可以通过共享内存或文件系统举行通讯。
在docker原生模式下，Pod 通过 docker0 网桥获得私有 IP（如 172.17.0.0/16），此时Pod IP 仅在宿主机内部可达，跨节点通信需通过 NodePort 或外部负载平衡。
此时 Pod 网络举动与传统 Docker 容器完全一致，要实现Pod IP 在全集群内可达，需要用到CNI网络插件。此时 Docker 仅作为容器运行时，网络由 CNI 插件接管。
集群中pod的相互通信
CNI先容
Docker创建的IP只能在本地服务器上访问，怎么在才能在别的节点上访问这个 Pod IP，实现集群中全部pod的通信呢？
Kubernets网络模型中，有一个叫CNI的网络接口。
CNI（Container Network Interface，容器网络接口） 是 Kubernetes 中用于管理容器网络的尺度接口规范，而 CNI 网络插件 是详细实现这一规范的组件，负责为容器（或 Pod）分配 IP 地点、设置网络设备、设置路由规则等，确保容器之间可以或许跨节点通信。
Kubernetes 本身不直接处置处罚容器网络，而是通过 CNI 插件将网络管理能力解耦。
CNI可以为为每个 Pod 分配唯一的集群内 IP，而且可以确保Pod跨节点通信。
CNI原理
1、 pod创建时：
- Kubernetes 调用 CNI 插件，为 Pod 创建虚拟网络接口（如 eth0）。
- 分配 IP 地点，并设置路由规则（如 Pod 访问其他节点时的下一跳地点）。
2、跨节点通信：
- Overlay 模式（如 Flannel VXLAN）：封装数据包，在物理网络之上构建虚拟网络。
- BGP 模式（如 Calico）：通过路由协议将 Pod IP 通告到整个集群。
- Underlay 模式（如 Macvlan）：直接使用物理网络设备分配 IP。
3、 pod销毁时
BGP 模式的实现
在 BGP（Border Gateway Protocol）模式下（如 Calico 的实现），Pod IP 是全局路由可达的，数据包 无需 NAT 即可跨节点直达目标 Pod。
每个节点 会通过 BGP 协议向集群 宣告本节点的 Pod 子网例。假如有两个节点，节点1和节点2：
节点 1 的 Pod CIDR 为 10.244.1.0/24
节点 2 的 Pod CIDR 为 10.244.2.0/24
之后，每个节点通过 BGP 学习到其他节点的路由信息，我们可以查看节点1的的路由信息。
- # 节点 1 的路由表
- $ ip route
- 10.244.2.0/24 via 192.168.0.2 dev eth0 # 目标 Pod IP 段下一跳为节点 2 的物理 IP
依据BGP协议跨节点通信的流程
下面我们观察跨节点通信流程，以
以 Pod A（10.244.1.2）→ Pod B（10.244.2.3）为例子。
1、源节点（节点 1）：
- 根据 Pod B 的 IP 10.244.2.3 匹配路由规则 10.244.2.0/24 via 192.168.0.2
- 直接通过物理网卡 eth0 将数据包发送到 节点 2 的物理 IP（192.168.0.2）
2、目标节点：
- 收到数据包后，根据本地路由规则 10.244.2.0/24 dev caliXXXX 转发到 Pod B 的虚拟网卡
- 全程无 NAT 转换，源 IP 保持 10.244.1.2，目标 IP 保持 10.244.2.3
3、BGP 对等体（Peer）设置
- BGP Speaker：每个节点运行 BGP 客户端（如 Calico 的 bird）
BGP模式的必要条件
1、 网络基础办法的支持
- 节点间物理网络需互通
- 物理交换机/路由器需支持 BGP 协议
2、 IP地点规划
- Pod CIDR 必须为 全局唯一且可路由 的 IP 段（如 10.244.0.0/16）
- 节点物理 IP 需在同一 Layer 3 网络
CNI的功能
下面我们总结CNI的功能。
- 节点上的 Pod 可以和其他任何节点上的 Pod 通信(称为扁平化网络)，即节点间 Pod 的相互访问；
- 节点上的代理（好比：系统守护历程、kubelet）可以和节点上的全部 Pod 通信，即系统组件访问 Pod；
验证命令
我们给出是否乐成设置k8s网络的验证命令(需提前安装calicoctl工具):
- # 查看节点 BGP 邻居状态
- calicoctl node status
- # 检查节点路由表
- ip route show | grep cali
- # 测试跨节点 Pod 通信（tcpdump 抓包验证无 NAT）
- kubectl exec -it pod-a -- curl http://10.244.2.3
- tcpdump -i eth0 host 192.168.0.2 and port 80
|
