Kubernetes网络详解：从ClusterIP到Cilium服务网格
内容提要
本教程深入讲解Kubernetes网络底层原理，涵盖Pod IP分配、CNI插件作用、kube-proxy通过iptables实现ClusterIP、Ingress路由外部流量、Network Policies实现微隔离，并对比Cilium、Calico等CNI方案。重点推荐Cilium的eBPF技术，因其性能更优、可观测性强，且无需sidecar即可实现mTLS，适合满足SOC2合规要求。
延伸解读
为什么Pod IP不稳定？
Pod IP在每次重启后都会变化，直接硬编码Pod IP会导致服务中断。Kubernetes Service通过提供稳定的ClusterIP和DNS名称解决了这个问题。kube-proxy利用iptables规则将流量从ClusterIP负载均衡到后端的Pod IP，并在Pod变化时自动更新规则。因此，应用应始终通过Service DNS名称访问其他服务，而不是直接使用Pod IP。
Ingress如何节省成本？
每个LoadBalancer Service都会创建一个独立的云负载均衡器，在AWS上每个ALB每月约需$16-27。如果有20个微服务，每月仅负载均衡器费用就高达$320-540。使用Ingress控制器可以将所有服务路由到一个ALB上，每月成本仅约$27，大幅节省开支。Ingress通过主机名和URL路径将外部流量路由到不同的Service，是生产环境的推荐做法。
默认拒绝策略的重要性
Kubernetes默认允许所有Pod之间通信，这不符合SOC2等安全标准。通过实施默认拒绝的Network Policy，可以阻止所有未授权的流量，然后按需添加允许规则。Cilium的Hubble工具可以观察网络流量，提供被阻止和允许的流日志，这些日志可作为SOC2合规的证据。
Cilium vs 传统服务网格
传统服务网格如Istio和Linkerd需要注入sidecar代理，每个Pod会增加内存和延迟开销。Cilium利用eBPF在内核层面实现服务网格，无需sidecar，内存开销为零，延迟开销小于1%。对于需要mTLS和可观测性但资源有限的环境，Cilium是更优选择。
Q&A
Kubernetes中每个Pod为什么都有独立的IP地址？
Kubernetes网络模型规定每个Pod都有唯一的IP地址，并且Pod之间可以直接通信，无需NAT。这是通过CNI插件实现的，它创建网络命名空间、veth对，分配IP并添加路由规则。
kube-proxy如何使用iptables实现ClusterIP的负载均衡？
kube-proxy在每个节点上添加iptables规则，拦截发往ClusterIP的流量，并根据规则将其重定向到后端的Pod IP。规则中每个KUBE-SEP条目对应一个Pod端点，通过概率分配实现负载均衡。
为什么应该使用Ingress而不是为每个微服务创建LoadBalancer Service？
每个LoadBalancer Service都会创建一个云负载均衡器，成本高。Ingress控制器通过一个负载均衡器根据主机名和路径路由到多个服务，节省成本。例如，20个微服务使用LoadBalancer每月约400美元，而使用Ingress只需约27美元。
如何实现Kubernetes网络策略的默认拒绝？
使用CiliumNetworkPolicy，设置endpointSelector为空（匹配所有Pod），并定义空的ingress和egress规则，即可阻止所有入站和出站流量。然后添加允许特定通信的规则。
Cilium相比Calico和AWS VPC CNI有哪些优势？
Cilium基于eBPF，支持Layer 7策略、Hubble可观测性、无需sidecar的mTLS，并提供SOC2合规证据。Calico支持网络策略但无Layer 7，AWS VPC CNI集成AWS但功能有限。
Cilium服务网格与传统Istio相比有什么不同？
Cilium使用eBPF在内核层面实现服务网格，无需sidecar，内存开销为0，延迟开销小于1%。Istio需要Envoy sidecar，每个Pod约128MB内存，延迟增加5-10%。Cilium提供mTLS和Hubble可观测性，但流量管理功能有限。
如何验证Kubernetes网络策略是否生效？
使用Cilium的Hubble工具，通过`hubble observe`命令查看网络流量，可以显示允许和丢弃的流量。例如，`hubble observe --namespace production --verdict DROPPED`可以查看被策略阻止的连接。
Kubernetes中Pod IP不稳定，如何解决服务发现问题？
使用Service资源，它提供稳定的ClusterIP和DNS名称。Pod应通过Service DNS名称（如redis.production.svc.cluster.local）访问，而不是直接使用Pod IP。Service通过kube-proxy自动更新后端Pod IP。
