16.1.6 集群通信与基本工作流程

本节聚焦 Kubernetes 集群内的通信链路与基础工作流程，结合示例、命令、排错与练习，帮助理解请求如何在控制平面与工作节点间流转，以及对象从提交到运行的完整闭环。

一、集群通信核心链路（含原理草图）

文章图片
  • 客户端到 API Server：所有管理操作统一经 kube-apiserver；kubectl、控制器、调度器与外部系统均以 HTTP/HTTPS 调用 REST API。
  • 控制平面内部通信：kube-apiserver 与 etcd 通过安全通道读写状态；kube-controller-manager 与 kube-scheduler 通过 API Watch 监听资源变更并写回结果。
  • API Server 到 Node：kubelet 通过 Watch 监听所需资源，并向容器运行时下发创建/更新/删除指令。
  • Pod 内与 Pod 间通信：CNI 提供扁平网络，Pod 拥有独立 IP；Service 通过虚拟 IP 与 kube-proxy 实现负载分发。
  • 外部访问：Ingress/LoadBalancer/NodePort 将服务暴露给集群外部访问者。

二、基础对象驱动的工作流程（含可执行示例）

1）声明式提交：创建 Deployment 与 Service

# /tmp/web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

# 提交资源并观察状态
kubectl apply -f /tmp/web.yaml
kubectl get deploy,po,svc -o wide

预期效果：Deployment 变为 READY 2/2，Pod Running，Service 获得 ClusterIP。

2）调度决策：查看绑定过程与事件

# 查看 Pod 调度与事件
kubectl describe pod -l app=web | sed -n '/Events/,$p'

命令解释：
- kubectl describe pod：输出 Pod 详细信息。
- Events：查看调度、拉取镜像、启动等关键事件。

3）节点执行：kubelet 与容器运行时协同

# 在工作节点上查看 kubelet 日志（systemd 场景）
journalctl -u kubelet -n 100 --no-pager

4）网络与服务就绪：Service 与 Endpoints

# 查看 Service 后端 Endpoints 是否生成
kubectl get endpoints web-svc -o wide

预期效果：Endpoints 中包含两个 Pod IP。

5）访问验证：集群内访问

# 启动临时 Pod 进行访问测试
kubectl run -it --rm netcheck --image=busybox:1.36 -- sh -c 'wget -qO- http://web-svc'

预期效果：返回 Nginx 欢迎页 HTML。

三、关键机制与保障（含命令）

  • Watch 与事件驱动：控制器与 kubelet 依赖资源 Watch 实现实时响应 
kubectl get events --sort-by=.metadata.creationTimestamp | tail -n 10
  • 最终一致性：组件持续比对期望与实际状态 
kubectl scale deploy web --replicas=3
kubectl get deploy web -w
  • 健康探针：Liveness/Readiness/Startup
# /tmp/probe.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-demo
  template:
    metadata:
      labels:
        app: probe-demo
    spec:
      containers:
      - name: app
        image: nginx:1.25
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 2
          periodSeconds: 3

kubectl apply -f /tmp/probe.yaml
kubectl describe pod -l app=probe-demo | sed -n '/Conditions/,$p'

四、常见通信问题与排查要点（含明确命令）

1）API Server 不可达

# 验证 API Server 健康
kubectl get --raw=/healthz
# 检查控制平面 Pod 状态（若为静态 Pod）
kubectl -n kube-system get pods -o wide

可能原因：证书过期、端口被防火墙阻断、负载均衡异常。

2）Pod 无法互通

# 查看 CNI 组件状态（以 Calico 为例）
kubectl -n kube-system get pods -l k8s-app=calico-node
# 查看节点路由与 CNI 接口
ip addr
ip route

可能原因：CNI 未就绪、路由/隧道异常、NetworkPolicy 限制。

3）Service 不生效

# 检查 Endpoints
kubectl get endpoints web-svc -o yaml
# 查看 kube-proxy 规则（iptables 模式）
iptables -t nat -L -n | grep web-svc

可能原因：Service selector 错误、Pod 未就绪、kube-proxy 故障。

4）调度失败

kubectl get pods -A --field-selector=status.phase=Pending
kubectl describe pod <pod-name> | sed -n '/Events/,$p'

可能原因：资源不足、污点/容忍、亲和性冲突。

五、练习与实战

  1. 练习1：验证 Service 转发
    - 将 web 部署副本调整为 3；
    - 在 netcheck 中连续访问 5 次，观察返回内容变化或响应一致性。
kubectl scale deploy web --replicas=3
kubectl run -it --rm netcheck --image=busybox:1.36 -- sh -c 'for i in 1 2 3 4 5; do wget -qO- http://web-svc | head -n 1; done'
  1. 练习2：故障注入与自愈
    - 手动删除一个 Pod，观察控制器补齐副本。
kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 --force
kubectl get pods -l app=web -w

通过以上链路、示例与排错流程，可快速定位集群通信问题，并在设计与运维中正确把握各组件职责与交互边界。