从部署到退役：K8s集群全生命周期运维手册 - 第1节

1.1 Kubernetes 发展史：从 Borg 到云原生事实标准

Kubernetes（常简写为 K8s）并非凭空诞生，其设计思想源于 Google 内部大规模集群管理系统 Borg（后演化为 Omega）。2014 年，Google 将 Borg 的经验以 Go 语言重写并开源，命名为 Kubernetes（希腊语“舵手”之意），并联合 Linux 基金会成立了 CNCF（Cloud Native Computing Foundation） 进行托管。

时间节点 里程碑事件 关键影响
2014 年 6 月 Google 开源 Kubernetes v1.0 首次将 Borg 的调度、资源管理经验开放给社区
2015 年 7 月 CNCF 成立，K8s 作为首个孵化项目 确立云原生生态治理模式，吸引 Red Hat、IBM、Microsoft 等巨头
2017 年 10 月 Docker 宣布支持 Kubernetes 编排 容器编排标准之争尘埃落定，K8s 成为事实标准
2018 年 3 月 Kubernetes v1.10 稳定版发布 生产级特性（RBAC、CSI、CRD）成熟，企业大规模采用开始
2020 年至今 K8s 成为 CNCF 毕业项目，版本迭代至 v1.30+ 覆盖边缘计算、AI/ML、Serverless 等场景，生态持续扩展
运维视角： 理解 K8s 发展史有助于判断版本升级策略。例如，v1.20 弃用 Docker 作为容器运行时（仅保留 containerd/CRI-O），v1.24 移除 Dockershim——这些变更直接影响集群部署和节点维护方案。

1.2 核心组件架构：控制平面与工作节点

Kubernetes 采用 Master-Worker（控制平面-工作节点） 架构。控制平面负责全局决策和集群状态管理，工作节点负责运行容器化应用。以下 SVG 展示了各组件的协作关系：

Kubernetes 核心组件架构图 控制平面 (Control Plane) API Server (kube-apiserver) 集群入口，RESTful API，认证/授权/准入 Scheduler (kube-scheduler) Pod 调度决策，资源匹配与约束 Controller Manager 节点/副本/端点/服务账户等控制器 etcd (分布式键值存储) 集群状态持久化，强一致性 工作节点 (Worker Nodes) Node-1 kubelet kube-proxy Pod(s) Node-2 kubelet kube-proxy Pod(s) 组件通信说明 • kubelet 通过 API Server 注册节点状态 • Scheduler 监听未调度的 Pod，绑定到最优节点 • Controller Manager 通过 API Server 维持期望状态 • kube-proxy 监听 Service/Endpoint，更新节点 iptables/IPVS • etcd 仅由 API Server 直接读写，其他组件间接访问

1.2.1 控制平面组件详解

组件 核心职责 高可用部署要点
API Server 集群唯一入口，提供 RESTful API；处理认证（Authentication）、授权（Authorization）、准入控制（Admission Control）；所有组件和 kubectl 均通过它交互 多实例负载均衡（至少 2 个），前端配置 SLB/HAProxy；etcd 集群独立部署
Scheduler 监听未调度的 Pod（spec.nodeName 为空），根据资源需求、亲和性、污点/容忍度等策略选择最优节点 支持 Leader Election，多实例仅一个活跃调度器；可自定义调度器扩展
Controller Manager 运行多个控制器（Node Controller、Replication Controller、Endpoint Controller、Service Account Controller 等），确保集群实际状态与期望状态一致 同样通过 Leader Election 实现高可用；不同控制器可独立配置并发度
etcd 分布式键值存储，保存集群所有资源对象（Pod、Service、ConfigMap、Secret 等）；基于 Raft 协议保证强一致性 奇数节点（3/5/7），SSD 磁盘，定期快照备份；网络延迟敏感，建议独立部署

1.2.2 工作节点组件详解

组件 核心职责 运维关注点
kubelet 节点代理，负责管理 Pod 生命周期（创建、监控、重启、销毁）；通过 CRI（容器运行时接口）与 containerd/Docker 交互；定期向 API Server 上报节点状态 版本需与控制平面接近（±2 小版本）；关注 Node Status 和 Pod 状态；配置资源预留（Reserved Resources）
kube-proxy 网络代理，维护节点上的网络规则（iptables/IPVS）；实现 Service 的 ClusterIP、NodePort、LoadBalancer 等模式；支持会话保持 IPVS 模式性能优于 iptables（大规模集群推荐）；注意内核模块加载（ip_vs、nf_conntrack）
容器运行时 实际运行容器的底层引擎（containerd、CRI-O、Docker Engine）；通过 CRI 与 kubelet 对接 v1.24+ 默认使用 containerd；关注镜像 GC、日志轮转、存储驱动（overlay2）
常见误区： kube-proxy 不是 Service 的“代理服务器”，它只负责在节点上写入网络规则（iptables/IPVS），真正的流量转发由内核完成。不要将 kube-proxy 与 Ingress Controller 或 API Gateway 混淆。

1.3 Pod：最小调度单元

Pod 是 Kubernetes 中 可创建和部署的最小单元，代表集群中运行的一个进程组。一个 Pod 包含一个或多个容器（共享网络栈、存储卷和生命周期）。

Pod 核心特征

  • 共享网络命名空间： 同一 Pod 内的容器共享 IP 地址和端口空间，可通过 localhost 互相通信。
  • 共享存储卷： 通过 Volume 挂载，Pod 内所有容器可读写同一份数据。
  • 原子调度： Pod 内的所有容器必须调度到同一个节点上，要么全部运行，要么全部不运行。
  • 生命周期管理： Pod 具有明确的阶段（Pending → Running → Succeeded/Failed），支持 Init 容器、探针（Probe）、优雅终止。
设计原则： 将“进程组”而非单个进程作为调度单元。例如，一个 Web 服务 + 一个 Sidecar 日志收集容器应放在同一个 Pod 中，因为它们紧密耦合且需要共享网络和存储。

1.4 Service：稳定的网络抽象

Pod 具有 易失性（因故障、滚动更新、缩容等可能被销毁重建），其 IP 地址不固定。Service 提供了一种 稳定的网络端点，通过标签选择器（Label Selector）动态关联一组 Pod，实现负载均衡和服务发现。

Service 类型 访问方式 典型场景
ClusterIP（默认） 集群内部虚拟 IP，仅集群内可访问 内部微服务通信，数据库后端
NodePort 在每个节点上开放一个静态端口（30000-32767），集群内外均可通过 NodeIP:NodePort 访问 开发测试环境暴露服务，或配合外部负载均衡器
LoadBalancer 云厂商提供外部负载均衡器，自动分配公网 IP 生产环境对外暴露服务（AWS ELB、GCP LB、Azure LB）
ExternalName 通过 DNS CNAME 将 Service 映射到外部域名 将集群外服务（如数据库 RDS）映射为集群内 DNS 名称

1.5 Namespace：多租户隔离边界

Namespace 是 Kubernetes 实现 逻辑隔离 的核心机制。它将集群内的资源对象划分为不同的虚拟空间，每个 Namespace 内的资源名称必须唯一，但不同 Namespace 之间可以重名。

Namespace 的典型用途

  • 环境隔离： 将 dev、staging、production 环境放在不同 Namespace 中，避免资源冲突。
  • 团队隔离： 不同团队使用独立 Namespace，配合 RBAC 实现权限控制。
  • 资源配额： 通过 ResourceQuota 限制每个 Namespace 的 CPU、内存、存储总量。
  • 网络策略： 结合 NetworkPolicy 实现 Namespace 级别的网络访问控制。
默认 Namespace： 集群初始化后包含四个 Namespace：default（默认）、kube-system（系统组件）、kube-public（公共资源）、kube-node-lease（节点心跳）。生产环境中建议为每个业务创建独立 Namespace，避免使用 default。

1.6 概念关系总结

以下 SVG 展示了 Pod、Service、Namespace 之间的逻辑关系：

Pod、Service、Namespace 关系图 Namespace: production Service: web-svc (ClusterIP: 10.96.0.1) selector: app=web Pod A app=web Pod B app=web Pod C app=web Namespace: staging Service: web-svc (ClusterIP: 10.96.0.2) selector: app=web Pod X app=web Pod Y app=web 不同 Namespace 中的 Service 名称可以相同（web-svc），但 ClusterIP 和 Pod 完全隔离

1.7 本章核心要点速查

概念 一句话定义 运维关键命令
API Server 集群的“大脑”和唯一入口 kubectl get --raw /api/v1
Scheduler Pod 的“分配器”，决定 Pod 跑在哪个节点 kubectl describe pod <pod-name> 查看 Events
Controller Manager 集群的“维护工”，确保状态符合预期 kubectl get deployment / kubectl get replicaset
kubelet 节点的“管家”，管理 Pod 生命周期 journalctl -u kubelet -f 查看日志
kube-proxy 节点的“网络规则员”，实现 Service 转发 kubectl get svc / iptables -t nat -L
Pod 最小调度单元，一个或多个容器的组合 kubectl get pods -o wide
Service 稳定的网络抽象，关联一组 Pod kubectl get svc / kubectl describe svc <svc-name>
Namespace 逻辑隔离边界，多租户基础 kubectl get ns / kubectl config set-context --namespace=
学习路径建议： 本章是 K8s 全生命周期运维的基石。建议读者在理解概念后，使用 minikube 或 kind 搭建本地集群，通过 kubectl explain pod、kubectl explain service 等命令探索资源对象的详细字段，为后续章节的集群部署、监控、排障打下扎实基础。
← 上一章 📖 返回目录 下一章 →