引言
我们之前了解了在不同场景下，Kubernetes中Pod之间的通信是如何路由的。
- 【Kubernetes Pod间通信-第1篇】在单个子网中使用underlay网络实现Pod到Pod的通信
- 【Kubernetes Pod间通信-第2篇】使用BGP实现Pod到Pod的通信
现在，我们来看看在集群中，Pod与服务之间的通信是如何管理的，这里仍使用Calico作为容器网络接口（CNI）。在本文中，我们只探讨集群内部的通信，与外部世界的通信留到下次讨论。
服务到Pod的转换可以通过不同方式实现，我们将了解Linux系统中的三种主要情况：使用kube-proxy配置iptables或IPVS数据平面，以及最终无需iptables的eBPF。
本文的目的并非选择管理服务的最佳模式，而是获取关于如何配置它们以及它们如何工作的基础知识。为此，我们将使用TCPDUMP和Wireshark来观察数据包，使用iptables、ipvsadm或calico-node-bpf来查看相关表。
前置条件
进行本实验需要具备Kubernetes、kubectl和网络协议的基本经验。我们将使用一个现有的两节点Kubernetes集群，版本为1.31，使用Calico作为已安装的CNI。CNI安装方法在这篇文章的案例3中 ——【Kubernetes Pod间通信-第1篇】在单个子网中使用underlay网络实现Pod到Pod的通信。
创建ClusterIP服务
首先，我们创建一个部署，其中包含两个httpd镜像的副本，以及一个使用alpine镜像的Pod，用于访问Web服务器工作负载。
k run pod-alpine --image alpine -- sleep 1d
k create deploy monwebserver --replicas 2 --image httpd
检查两个副本是否不在同一节点上，如果在，则进行调整。然后，为该部署创建一个服务，并在pod-alpine中安装curl。
k expose deployment monwebserver --port 8080 --target-port 80 --name svc-webserver
k exec - it pod-alpine -- apk update
k exec - it pod-alpine -- apk add curl
服务会获取一个IP地址和两个端点来提供服务。
然后，你可以从“pod-alpine” Pod访问该服务，在“monwebserver”部署的两个后端Pod之间将进行随机的等价负载均衡。
当有对服务IP（10.97.0.69:8080）的请求时，目标地址会通过Iptables中的DNAT（目的网络地址转换）转换为其中一个端点地址。
案例1：Kube-Proxy与Iptables配合使用
Iptables是Linux内核的一个特性，设计初衷是作为一个高效的防火墙，具有足够的灵活性，能够处理各种常见的数据包操作和过滤需求。这是Kubernetes在Linux系统中使用的默认情况，上一段中的服务就是以这种模式运行的。在这种场景下，每个节点上都有一个kube-proxy Pod。
