Pod之间的通信：像邻居串门一样自然
在ref="/tag/2020/" style="color:#2B406D;font-weight:bold;">Kubernetes里，每个Pod都像是一个独立的小房间，但这些房间之间需要能互相串门。Kubernetes给每个Pod分配一个唯一的IP地址，而且这个IP在整个集群内都能直接访问。这就意味着，同一个节点上的Pod可以像隔壁邻居一样直接对话，不需要经过复杂的转发。
比如你部署了一个前端服务和一个后端API服务，它们分别运行在不同的Pod里。只要处在同一个集群网络中，前端可以直接通过后端Pod的IP加端口发起请求，就像你在家里用内网访问NAS存储一样顺畅。
Service：给不稳定的Pod提供稳定入口
Pod是可能随时重启或迁移的，IP地址并不固定。这时候就需要Service出场了。它像是一个固定的门牌号，不管后面的住户怎么换，门口的号码始终不变。当你创建一个ClusterIP类型的Service时，Kubernetes会为它分配一个虚拟IP，所有发往这个IP的流量都会被自动转发到对应的后端Pod。
举个例子，你的订单服务背后有三个Pod实例在跑，随着负载变化可能会缩容到两个。但前端只需要认准Service提供的IP和端口，剩下的轮询转发工作由kube-proxy默默完成。
apiVersion: v1
kind: Service
metadata:
name: order-service
spec:
selector:
app: order
ports:
- protocol: TCP
port: 80
targetPort: 9376外部如何访问内部服务？
NodePort和Ingress是常见的解决方案。NodePort会在每个节点上打开一个固定端口，把外部流量引进来；而Ingress更像是智能网关，可以根据域名或路径将请求分发到不同服务，适合多应用共用一个公网IP的场景。
想象一下你在家搭建了一套私有云相册系统，用Ingress配置好photo.yourhome.com这个域名，无论后台服务怎么调度，你都可以通过统一入口查看照片。
网络插件的作用不可忽视
Kubernetes本身不负责实现具体的网络连接，而是依赖CNI（容器网络接口）插件来完成。常用的如Calico、Flannel，它们决定了数据包如何封装、传输和路由。比如Flannel使用VXLAN技术把各个节点组建成一个大二层网络，让跨主机的Pod通信变得透明。
这就好比你在不同城市的家里和办公室之间拉了一条专用光纤，虽然物理位置分散，但网络上就像在同一局域网里，文件互传毫无压力。