📚 课程目录第3章 Kubernetes基础回顾

3. Kubernetes基础回顾

在进入高可用部署实战之前，有必要把 Kubernetes 的核心组件与常用对象重新梳理一遍。高可用部署并不是简单地把副本数调大，而是建立在对控制平面、数据平面、调度与网络模型清晰理解之上的工程实践。本节围绕集群组件、Pod、Deployment、Service、Ingress、ConfigMap 与 Secret 展开，帮助你把零散概念串成一条可落地的知识链。

一、控制平面与工作节点：谁在决策，谁在执行

Kubernetes 集群分为控制平面（Control Plane）与工作节点（Worker Node）两部分。控制平面负责“期望状态”的维护与决策，工作节点负责“实际状态”的落地。

kube-apiserver：集群唯一入口，所有读写请求都经过它，并负责认证、鉴权、准入控制。
etcd：保存集群全部状态数据，是高可用部署中最需要优先保障的组件。
kube-scheduler：为新创建的 Pod 选择合适节点，依据资源、亲和性、污点等策略打分。
kube-controller-manager：运行各类控制器，持续把实际状态拉回期望状态。
kubelet：节点上的“代理人”，负责 Pod 生命周期与容器运行时交互。
kube-proxy：实现 Service 的流量转发规则，常见模式为 iptables 或 IPVS。

理解高可用的第一步：控制平面组件是无状态或可多副本的，而 etcd 是有状态且需要仲裁的。因此 etcd 的部署方式往往决定了整个集群的可用性上限。

二、从 Pod 到 Deployment：工作负载的抽象层次

Pod 是最小调度单元，一个 Pod 内可以包含一个或多个共享网络命名空间与存储卷的容器。实际生产中很少直接创建裸 Pod，而是通过控制器管理。

Deployment 面向无状态应用，通过 ReplicaSet 管理 Pod 副本，支持滚动更新与回滚。它的核心价值在于声明式地描述“我要几个副本、用什么镜像、如何更新”。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      containers:
      - name: api
        image: registry.example.com/payment-api:v1.4.2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080

注意 readinessProbe 与 livenessProbe 的区别：前者决定 Pod 是否接入流量，后者决定容器是否需要重启。高可用场景中，探针配置不当会直接导致流量打到未就绪实例上。

三、Service 与 Ingress：服务发现与外部入口

Pod 的 IP 会随重建而变化，因此需要 Service 提供稳定的虚拟 IP 与 DNS 名称。常见类型包括 ClusterIP、NodePort、LoadBalancer 与 ExternalName。

对象	作用范围	典型用途	高可用关注点
ClusterIP	集群内部	微服务间调用	kube-proxy 规则同步
NodePort	节点端口	临时暴露、测试	端口冲突与节点漂移
LoadBalancer	云负载均衡	生产外部入口	云厂商 LB 健康检查
Ingress	七层路由	域名与路径分发	Ingress Controller 多副本

Ingress 本身只是路由规则，真正生效依赖 Ingress Controller（如 NGINX Ingress、Traefik）。在高可用部署中，Ingress Controller 通常以 DaemonSet 或 Deployment 多副本方式运行，并配合外部负载均衡器。

四、ConfigMap 与 Secret：配置与敏感信息分离

ConfigMap 用于存放非敏感配置，Secret 用于存放密码、、证书等敏感数据。两者都可以通过环境变量或卷挂载方式注入 Pod。

kubectl create configmap app-config \
  --from-literal=LOG_LEVEL=info \
  --from-literal=MAX_CONN=200

kubectl create secret generic db-secret \
  --from-literal=username=payment \
  --from-literal=password=S3cureP@ss

Secret 默认仅做 Base64 编码，并非加密。生产环境应开启 etcd 静态加密，并结合 RBAC 限制读取权限。把 Secret 提交到 Git 仓库是常见的高危误区。

五、典型场景复盘：一次滚动更新引发的 502

某支付服务在滚动更新时出现间歇性 502。排查发现 Deployment 未配置 readinessProbe，新 Pod 启动后立即被加入 Endpoints，而应用初始化需要约 8 秒。修复方式是补充就绪探针并设置合理的 initialDelaySeconds 与 failureThreshold，同时配置 maxUnavailable: 0 保证更新期间可用副本不减少。

回顾这些基础对象，可以形成一条清晰的主线：控制平面维护期望状态，Deployment 管理 Pod 副本，Service 提供稳定访问入口，Ingress 负责七层暴露，ConfigMap 与 Secret 完成配置注入。高可用部署的每一步优化，本质上都是围绕这条主线提升冗余、隔离故障与缩短恢复时间。