引言：为什么 Kubernetes 成为容器编排的事实标准
Kubernetes（简称 K8s）自 2014 年由 Google 开源以来，迅速成为容器编排领域的事实标准。它源于 Google 内部 Borg 系统十余年大规模容器管理经验的结晶，通过声明式 API、自动化调度和自愈能力，彻底改变了应用部署和管理的方式。如今，从初创到大型企业，Kubernetes 已成为云原生架构的核心基石。本文将从实战角度深入剖析 Kubernetes 的关键概念、核心组件和工程实践。
一、Kubernetes 核心架构设计
Kubernetes 采用典型的分布式主从（Master-Worker）架构。控制平面（Control Plane）负责全局决策和工作节点管理，而数据平面则由实际运行应用的 Worker 节点组成。
控制平面核心组件：
- API Server (kube-apiserver)：集群的唯一入口，处理所有 REST 请求，验证并更新 etcd 中的对象状态。它是唯一直接与 etcd 交互的组件。
- etcd：分布式键值存储，保存集群所有状态数据和配置。采用 Raft 共识算法保证强一致性，通常部署 3 或 5 个节点以实现高可用。
- Scheduler (kube-scheduler)：监听新创建的未调度 Pod，综合考虑资源需求、亲和性规则、污点容忍度等约束，选择最优节点进行调度。
- Controller Manager (kube-controller-manager)：运行一系列控制器循环，确保实际状态向期望状态收敛，包括 Node Controller、Replication Controller、Endpoint Controller 等。
Worker 节点核心组件：
- kubelet：节点代理，接收 PodSpec 并确保容器运行且健康。通过 CRI（容器运行时接口）与容器运行时交互。
- kube-proxy：维护节点网络规则，实现 Service 的负载均衡和流量转发。支持 iptables、ipvs 和 userspace 三种代理模式。
- 容器运行时（Container Runtime）：遵循 CRI 规范下载镜像并运行容器，常见的有 containerd、CRI-O 和 Docker（已通过 dockshim 适配）。
二、Pod：调度的最小原子单元
Pod 是 Kubernetes 中创建和部署的最小单元，代表集群中一个可运行的工作负载实例。一个 Pod 可以包含一个或多个紧密耦合的容器，它们共享网络和存储命名空间。
2.1 Pod 生命周期与状态机
Pod 的状态（phase）反映了其在生命周期中的宏观位置：
- Pending：已被 API Server 接受，但尚未被调度到节点，或正在下载镜像。
- Running：所有容器已被创建，至少一个容器正在运行、启动或重启中。
- Succeeded：所有容器成功终止，不会重启（Job/CronJob 场景）。
- Failed：所有容器至少一个以非零状态退出。
- Unknown：节点通信异常，无法获取 Pod 状态。
2.2 容器探针（Probe）深度配置
探针是 kubelet 对容器定期执行的诊断，决定容器是否健康：
- Liveness Probe（存活探针）：判断容器是否运行正常，失败时 kubelet 重启容器。适用于死锁、死循环等场景。
- Readiness Probe（就绪探针）：判断容器是否可接收流量，失败时从 Service Endpoint 摘除。适用于启动依赖外部服务、临时过载等场景。
- Startup Probe（启动探针）：判断容器应用是否已完成启动，适用于慢启动应用，启动成功后移交 Liveness 管理。
实战示例：
apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 15
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 2
failureThreshold: 3
startupProbe:
httpGet:
path: /healthz
port: 80
failureThreshold: 30
periodSeconds: 10
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
三、控制器模式：声明式期望状态的守护者
Kubernetes 的核心设计哲学是声明式 API + 控制循环。用户定义期望状态（Desired State），控制器持续驱动实际状态（Actual State）向期望状态收敛。
3.1 Deployment：无状态应用的最佳实践
Deployment 管理 ReplicaSet，提供滚动更新、回滚和扩缩容能力。
3.2 StatefulSet + DaemonSet + Job + CronJob
- StatefulSet：为 Pod 提供稳定的网络标识和持久化存储，有序部署和扩缩。
- DaemonSet：每个节点运行一个 Pod，适用于日志采集、监控等系统守护进程。
- Job / CronJob：运行一次性任务和定时任务。
四、Service 与网络模型深度解析
- Service 类型：ClusterIP（内部）、NodePort（节点端口）、LoadBalancer（云负载均衡）、ExternalName（外部域名映射）
- 代理模式：iptables（简单随机）、ipvs（高性能多种算法）、nftables（未来趋势）
- Ingress / Gateway API：七层路由、TLS 终止、灰度发布
五、存储体系：卷、PV 与 CSI 架构
- PV/PVC：StorageClass 动态供给、AccessMode 读写模式、ReclaimPolicy 回收策略
- CSI（容器存储接口）：标准插件接口，对接各类分布式存储
六、资源调度与 QoS 保障机制
- Requests & Limits：调度保证最小资源 + 运行时强制限制
- QoS 等级：Guaranteed（最后被Kill）、Burstable（中等）、BestEffort（优先被Kill）
- 高级调度：Node/Pod Affinity、Taints & Tolerations、Topology Spread Constraints
七、HPA 自动扩缩与弹性伸缩
- 指标来源：Resource/Custom/External Metrics
- 算法：desiredReplicas = ceil(currentReplicas x (currentMetricValue / desiredMetricValue))
- Behavior 配置：稳定窗口防止抖动、速率限制
- VPA & KEDA：垂直伸缩 + 事件驱动扩缩至零
八、安全加固：RBAC、Network Policy 与 Pod Security
- RBAC：Role/ClusterRole + RoleBinding 实现最小权限原则
- Network Policy：基于标签的入站/出站微隔离
- Pod Security Standards：Privileged/Baseline/Restricted 三级强制策略
九、可观测性三大支柱
- Metrics：Prometheus Operator + Grafana + kube-state-metrics
- Logs：EFK 或 Loki + Fluent Bit 轻量采集
- Traces：OpenTelemetry 统一框架 + Jaeger 分布式追踪
十、生产环境运维实战
- 高可用：多 Master + etcd 奇数节点集群 + 快照备份
- 升级：逐版本滚动升级，cordon → drain → upgrade → uncordon
- Helm：Chart 模板化部署，Helmfile 多环境管理
- GitOps：Argo CD / Flux CD 声明式持续交付
总结与实践建议
Kubernetes 是一个功能极其丰富的容器编排平台，掌握它需要理解其声明式核心设计哲学、控制循环模式和分层架构。在实际生产中，建议从小规模集群开始深入实践，逐步覆盖 Pod 生命周期、控制器选型、网络策略、存储规划、安全防护和可观测性等方面。关注 CNCF 生态演进（Gateway API、eBPF Service Mesh、Wasm 多运行时），持续跟进社区最佳实践，将 Kubernetes 打造为稳定高效的云原生应用基石。
发表评论 取消回复