k8s网络通信的模式

Kubernetes网络通信实战指南：生产环境必须掌握的7种模式

Kubernetes的网络就像快递公司的物流系统，既要保证包裹（数据包）准时到达，又要确保不同区域的快递站（节点）高效协作。以下是我们在生产环境中趟过的坑和积累的实战经验：

一、基础通信模型（快递收发原理）

同Pod内容器通信（同一包裹分拣区）

# 模拟两个容器共享网络命名空间
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
  - name: log-collector
    image: fluentd:latest

通过localhost:80直接通信
共享同一IP，类似同一办公室的同事递文件

同节点Pod间通信（同城快递）

# 查看docker网桥配置
ip addr show docker0
# 典型输出：inet 172.17.0.1/16

数据走docker0网桥（默认CIDR：172.17.0.0/16）
延时<0.1ms，带宽可达10Gbps

跨节点Pod通信（跨省物流）

# 查看Flannel网络路由
ip route show | grep flannel
# 输出示例：10.244.1.0/24 via 192.168.0.102 dev flannel.1

依赖Overlay网络（如VXLAN）
典型延时增加0.5-2ms，需关注MTU配置

二、服务发现核心机制（智能分拣系统）

ClusterIP模式（内部快递专线）

apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

虚拟IP+iptables/IPVS实现负载均衡
生产建议：超过1000个Endpoint时启用IPVS模式

NodePort+LoadBalancer（对外服务窗口）

apiVersion: v1
kind: Service
metadata:
  name: payment-gateway
spec:
  type: LoadBalancer
  loadBalancerIP: 203.0.113.10
  ports:
  - port: 443
    targetPort: 8443
  selector:
    app: payment

阿里云/ AWS等云厂商自动绑定SLB
自建集群推荐MetalLB方案

Ingress七层路由（智能分拣中心）

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: store-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: store.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

搭配Cert-Manager实现自动HTTPS
生产级配置：启用HSTS+OWASP防护规则

三、高阶网络方案选型（物流公司选择）

方案	适用场景	性能损耗	网络策略支持
Flannel	中小集群快速搭建	8-15%	有限
Calico	大型集群/BGP网络	3-5%	完整支持
Cilium	服务网格/安全审计	5-8%	eBPF增强
Weave	无ETCD依赖的简易方案	10-20%	基础支持

选型决策树：

是否需要BGP组网？→ Calico
是否关注Service Mesh性能？→ Cilium
是否跨公有云组网？→ Cilium + Cluster Mesh
是否资源受限？→ Flannel host-gw模式

四、生产环境网络调优

1. MTU黑洞问题解决

# 查看网卡MTU设置
ip link show flannel.1
# 调整VXLAN MTU（物理网卡MTU-50）
kubectl -n kube-system patch ds kube-flannel-ds --type='json' -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--iface-mtu=1450"}]'

2. DNS性能优化

# CoreDNS配置示例
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        cache 30
        reload
        forward . /etc/resolv.conf
        prometheus :9153
        health
        loop
        log
        errors
    }

3. 网络策略实战（金融级隔离）

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-isolation
spec:
  podSelector:
    matchLabels:
      role: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend
    ports:
    - protocol: TCP
      port: 5432

五、故障排查工具箱

连通性测试Pod

kubectl run net-tool --image=nicolaka/netshoot --rm -it --restart=Never

抓包诊断命令

# 进入容器网络命名空间
nsenter -t <PID> -n tcpdump -i eth0 port 80

性能基准测试

# 安装qperf
kubectl exec -it pod1 -- qperf
# 在另一个Pod执行
qperf -t 60 --use_bits_per_sec pod1_ip tcp_bw tcp_lat

六、血泪教训总结

CIDR规划陷阱

单个集群预留至少 /16 的Pod网段
避免与物理网络重叠（曾因172.16.0.0/12网段冲突导致全网瘫痪）

云厂商网络限制

阿里云VPC默认路由条目上限200条，大规模集群需提工单扩容

内核参数调优

# 调整conntrack表大小
sysctl -w net.netfilter.nf_conntrack_max=1000000

监控指标必查项

丢包率（ifdropped）
TCP重传率（retrans）
DNS查询延迟（coredns_request_duration）

某电商平台经过网络优化后，支付接口P99延迟从230ms降至85ms。记住：K8s网络不是魔法，而是需要精心设计的基建工程。每个参数调优的背后，都可能藏着百万级的性能提升！

posted on 2025-03-08 12:39 Leo-Yide 阅读(37) 评论(0) 收藏举报