Kubernetes 完全指南：从集群架构到应用模型

文章目录

Kubernetes 完全指南：从集群架构到应用模型
- 一、Kubernetes 集群架构
- - 1.1 控制平面组件
  - - API Server（kube-apiserver）
    - etcd
    - Scheduler（kube-scheduler）
    - Controller Manager（kube-controller-manager）
    - Cloud Controller Manager（cloud-controller-manager）
  - 1.2 工作节点组件
  - - kubelet
    - container runtime（容器运行时）
    - kube-proxy
    - Pod 网络
- 二、Kubernetes 应用模型
- - 2.1 核心概念：Pod
  - 2.2 工作负载资源（Workload Resources）
  - 2.3 服务发现与负载均衡
  - 2.4 配置管理
  - 2.5 存储管理
  - 2.6 命名空间（Namespace）
  - 2.7 应用打包与部署工具
  - 2.8 声明式 API 与控制器模式
- 三、总结：Kubernetes 应用模型与架构的协同
- 扩展学习资源

Kubernetes（常简称为 K8s）是一个开源的容器编排平台，用于自动化部署、扩缩和管理容器化应用。它的核心理念是
声明式配置与
自动化运维：用户通过描述期望的最终状态（例如“运行 3 个 nginx 副本”），系统则持续协调实际状态与之匹配。这种基于控制器和 API 的设计，使得 Kubernetes 成为云原生时代的通用应用底座。

本文将全面介绍 Kubernetes 的两大支柱：集群架构组件（支撑系统的物理与逻辑部件）与应用模型（用于定义和管理应用的 API 对象）。通过理解它们如何协同工作，你将掌握 Kubernetes 的核心原理与实践方法。

一、Kubernetes 集群架构

一个 Kubernetes 集群由**控制平面（Control Plane）和工作节点（Worker Nodes）**构成。控制平面负责全局决策与状态管理，工作节点负责运行实际的容器化应用。

架构速览：你可以想象一个典型的集群包含至少一个控制平面节点（通常为3个以实现高可用）和多个工作节点。控制平面节点上运行着API Server、etcd、Scheduler、Controller Manager等组件；工作节点上运行着kubelet、kube-proxy和容器运行时。所有组件通过API Server进行通信，形成一个有机整体。

1.1 控制平面组件

控制平面组件对集群做出全局决策，并存储所有状态数据。它们通常部署在专用节点上以保证稳定性。

API Server（kube-apiserver）

API Server 是整个集群的“交通枢纽”，它暴露了 Kubernetes API，供用户、命令行工具（如 kubectl）以及内部组件通信。所有对集群的操作请求都经过 API Server，它会执行认证（Authentication）、**授权（Authorization）和准入控制（Admission Control）**三层安全校验，然后将资源状态持久化到后端存储中。API Server 是唯一直接与 etcd 交互的组件。

etcd

etcd 是一个高可用、强一致性的分布式键值存储，作为 Kubernetes 的后端数据库。它保存了所有集群数据，包括 Pod、Service、Deployment 等资源的定义和当前状态。etcd 通常以奇数个节点集群部署，并基于 Raft 共识算法确保数据一致性（例如，3节点集群可容忍1节点故障）。etcd 被视为集群的“真相来源”，定期备份 etcd 数据是灾难恢复的关键。

Scheduler（kube-scheduler）

Scheduler 负责监视新创建的、尚未分配到节点的 Pod，并根据一系列策略（如资源需求、节点亲和性、污点容忍等）选择一个最合适的节点运行该 Pod。调度决策会考虑单个 Pod 和集群整体的资源状况、硬件/软件约束以及高可用要求。常见的调度策略包括：nodeSelector（节点标签选择）、节点亲和性/反亲和性、Pod 亲和性/反亲和性，以及自定义调度器扩展。

Controller Manager（kube-controller-manager）

Controller Manager 运行着多个控制器进程，每个控制器通过 API Server 监视集群状态，并努力将当前状态调整为期望状态。这些控制器并发运行，各自负责不同的资源类型。常见的内置控制器包括：

节点控制器：监控节点健康，处理节点宕机时的 Pod 驱逐。
副本控制器：确保指定数量的 Pod 副本正在运行（Deployment 等高级资源依赖此逻辑）。
端点控制器：维护 Service 与 Pod 之间的端点（Endpoints）对象。
Service 账户与令牌控制器：管理命名空间中的默认账户和 API 访问令牌。
其他控制器（如 Namespace、Job、CronJob 等）。所有控制器被编译成单个二进制文件并作为单个进程运行，以降低复杂性。

Cloud Controller Manager（cloud-controller-manager）

这是一个可选组件，用于将 Kubernetes 与特定云服务商（如 AWS、GCP、Azure）的 API 集成。它运行云平台相关的控制器，例如：

节点控制器：检查云平台以确定节点是否已被删除。
路由控制器：在云基础设施中设置网络路由。
服务控制器：创建、更新和删除云负载均衡器（当 Service 类型为 LoadBalancer 时）。引入 Cloud Controller Manager 使得核心 Kubernetes 代码与云平台逻辑解耦，便于云原生扩展。在自建机房（on-premise）环境中，通常不需要此组件。

1.2 工作节点组件

工作节点是运行容器化应用的机器（物理机或虚拟机），每个节点上都运行着必要的代理服务。

kubelet

kubelet 是运行在每个节点上的主要代理，它负责确保节点上的容器按照 PodSpec（Pod 的描述）运行。kubelet 会监视 API Server 上分配给本节点的 Pod，并通过容器运行时接口（CRI）与底层的容器运行时交互，以启动、停止容器，并定期上报节点和 Pod 的状态给控制平面。它还负责执行存活探针（livenessProbe）和就绪探针（readinessProbe），以实现应用健康检查和流量切换。

container runtime（容器运行时）

容器运行时是实际运行容器的软件，例如 Docker、containerd、CRI-O 等。Kubernetes 通过 CRI 与容器运行时解耦，使得集群可以支持多种运行时。kubelet 通过 CRI 调用运行时来创建、删除容器，并获取容器日志和资源统计信息。

kube-proxy

kube-proxy 是每个节点上的网络代理，它负责实现 Service 的抽象。它维护节点上的网络规则，将发往 Service 的流量（通过 ClusterIP、NodePort 或 LoadBalancer）负载均衡到正确的后端 Pod。kube-proxy 支持三种工作模式：

userspace：旧模式，性能较低，现已很少使用。
iptables：默认模式，基于 Linux iptables 实现，性能较好，但规则更新时存在延迟。
IPVS：更高效的模式，支持更复杂的负载均衡算法（如轮询、最少连接），适合大规模集群。

Pod 网络

虽然不是独立的组件，但每个节点上需要配置一个集群网络插件（如 Calico、Flannel、Weave 等），以实现跨节点的 Pod 间直接通信。这些插件遵循 CNI（Container Network Interface）规范，负责为每个 Pod 分配唯一 IP，并设置路由规则，确保 Pod 之间可以无障碍通信，且符合 Kubernetes 的网络模型要求：所有 Pod 可直接通信，无需 NAT；节点与 Pod 之间也可直接通信；Pod 看到的自身 IP 与其他 Pod 看到的 IP 一致。

二、Kubernetes 应用模型

Kubernetes 通过一系列 API 对象来描述应用的状态，再由控制器不断调整实际状态以匹配期望状态。下面从基础到高级，详细介绍这些对象及其用法。

2.1 核心概念：Pod

Pod 是 Kubernetes 中最小的部署和调度单元，代表集群中运行的一个或多个紧密相关的容器（如主应用和边车容器）。Pod 内的容器共享网络命名空间（相同的 IP 和端口空间）、存储卷（Volume）以及资源限制。Pod 是短暂易失的，其生命周期不与任何永久存储绑定，因此需要更高级别的控制器来管理 Pod 的副本、更新和自愈。

Init 容器是 Pod 的一种特殊容器，它在应用容器启动前运行，用于完成初始化任务（如等待依赖服务、数据迁移）。Init 容器成功退出后，才会启动主容器。

Pod 的实际运行依赖于工作节点的 kubelet 和容器运行时：kubelet 通过 API Server 获取分配到本节点的 Pod 定义，然后调用容器运行时创建容器，并持续监控其状态。

示例：一个简单的 nginx Pod YAML

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx:1.21
ports:
– containerPort: 80

2.2 工作负载资源（Workload Resources）

工作负载资源负责管理 Pod 的生命周期，包括创建、扩缩容、滚动更新等。常见的控制器有：

Deployment 适用于无状态应用，管理 Pod 的多个副本，支持滚动更新和回滚。通过 spec.replicas 指定副本数，spec.strategy 定义更新策略（如 RollingUpdate 的 maxSurge 和 maxUnavailable 控制更新速率）。Deployment 由 Controller Manager 中的 Deployment 控制器驱动。

示例 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx–deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx:1.21
ports:
– containerPort: 80
StatefulSet 用于有状态应用（如数据库），为每个 Pod 提供稳定的网络标识（如 pod-name-0）和持久化存储。Pod 的启停顺序受控（按序创建、倒序删除），且删除后 PVC 通常保留，确保数据不丢失。StatefulSet 通常配合 Headless Service（ClusterIP: None）使用，以便直接通过 Pod 名称访问。
DaemonSet 确保所有（或部分）节点上运行一个 Pod 的副本，常用于日志收集（如 Fluentd）、监控代理（如 Prometheus Node Exporter）等节点级组件。DaemonSet 控制器会监视节点加入/退出，自动创建或删除对应的 Pod。
Job 与 CronJob Job 用于执行一次性任务（如批处理），确保 Pod 成功退出。CronJob 则在指定时间调度 Job，类似 Linux 的 crontab。

2.3 服务发现与负载均衡

容器化应用的 IP 是动态变化的，因此需要稳定的访问入口：

Service 为一组 Pod 提供固定的虚拟 IP 和 DNS 名称，通过标签选择器（Label Selector）关联目标 Pod。Service 类型包括：

类型访问范围典型用途

ClusterIP	集群内部	内部服务调用
NodePort	集群外部通过节点IP+端口访问	开发调试或简单对外暴露
LoadBalancer	外部通过云负载均衡器访问	生产环境对外服务
ExternalName	集群内部访问外部域名	将外部服务映射为内部服务

Service 的网络规则由各节点的 kube-proxy 维护，它将流量负载均衡到后端 Pod。在较大规模集群中，Kubernetes v1.19+ 引入了 EndpointSlice，替代传统的 Endpoints 对象以解决性能瓶颈。

Ingress 管理外部 HTTP/HTTPS 流量，提供基于域名和路径的路由、TLS 终止、虚拟主机等功能。Ingress 本身只是一个 API 对象，需要配合 Ingress Controller（如 Nginx Ingress Controller、Traefik）才能实际工作。Ingress Controller 通常以 Deployment 或 DaemonSet 形式运行在集群中，监听 Ingress 资源并配置相应的负载均衡器。

2.4 配置管理

将配置与容器镜像解耦，便于应用在不同环境间迁移：

ConfigMap 存储非机密性的配置数据（如环境变量、命令行参数、配置文件）。Pod 可通过环境变量或挂载 Volume 的方式使用 ConfigMap。注意：ConfigMap 动态更新后，Pod 内挂载的文件不会自动更新，除非 Pod 重启或应用支持热加载。可使用 Reloader 等工具自动触发滚动更新。
Secret 存储敏感信息（如密码、OAuth 令牌、SSH 密钥），数据以 Base64 编码，并支持加密存储（如集成 KMS）。使用方式与 ConfigMap 类似，但 Secret 对数据有更严格的安全约束（如内存中不持久化）。

2.5 存储管理

容器本身是无状态的，持久化数据需要借助存储卷：

Volume Pod 内可挂载的存储目录，生命周期与 Pod 相同。支持多种类型：emptyDir（临时目录）、hostPath（节点目录）、云存储（如 AWSElasticBlockStore）等。
PersistentVolume（PV）和 PersistentVolumeClaim（PVC） PV 是集群管理员提供的存储资源（如 NFS、云盘），PVC 是用户对存储的请求。PVC 绑定到满足要求的 PV，Pod 通过 PVC 挂载存储。这种方式实现了存储与应用的解耦。PV 的供给方式分为静态供给（管理员预先创建 PV）和动态供给（通过 StorageClass 自动创建）。
StorageClass 定义动态存储供给的类别（如“快速 SSD”或“慢速 HDD”），PVC 可指定 StorageClass，由 Provisioner（通常由 Cloud Controller Manager 或第三方驱动实现）自动创建 PV。StorageClass 包含参数如 provisioner、reclaimPolicy、allowVolumeExpansion 等。

2.6 命名空间（Namespace）

命名空间提供多租户隔离，将集群内的资源划分为多个虚拟集群。同一命名空间内的资源名称必须唯一，不同命名空间间可重名。常用于区分环境（如 dev、prod）或团队。RBAC（基于角色的访问控制）可基于命名空间进行授权。

2.7 应用打包与部署工具

原生的 YAML 文件管理复杂，社区开发了多种工具来简化应用的定义、分发和部署：

Helm Kubernetes 的包管理器，通过 Chart（模板化的 YAML 集合）定义应用。Chart 可版本化、依赖管理，并支持通过 values.yaml 覆盖配置。Helm 将 Chart 渲染为最终 YAML 并安装到集群。适合复杂应用的打包和分发。
Kustomize 原生集成在 kubectl 中，通过 kustomization.yaml 对基础 YAML 进行覆盖、补丁和变换，实现环境差异化配置，而不使用模板。适合管理环境特定配置（如开发、生产）。
Operator 基于自定义资源（CRD）和自定义控制器，将运维知识编码成软件。Operator 能够自动处理应用的部署、备份、故障转移等复杂操作（如 etcd-operator、Prometheus-operator）。开发者可以使用 kubebuilder 或 operator-sdk 快速构建 Operator。

2.8 声明式 API 与控制器模式

这是 Kubernetes 应用模型的灵魂：

声明式 API：用户通过 YAML/JSON 描述期望的最终状态（如“运行 3 个 nginx 副本”），而非执行一系列命令。系统持续确保实际状态与期望状态一致。
控制器模式：每个工作负载资源对应一个控制器（如 Deployment 控制器），控制器通过调谐循环（Reconcile Loop）监控资源变化，并调用底层 API（如创建或删除 Pod）来达到期望状态。这些控制器运行在 Controller Manager 中，而 API Server 则作为所有交互的中介。

流程示意图：用户 kubectl apply -f deployment.yaml → API Server 将 Deployment 存储到 etcd → Deployment 控制器监听到新资源 → 控制器根据期望副本数创建 Pod 对象 → Scheduler 监听到未调度的 Pod → 选择合适的节点并更新 Pod 的 nodeName → 该节点上的 kubelet 监听到分配给本节点的 Pod → 调用容器运行时创建容器。

这种模型极大地提升了系统的自愈能力和可扩展性：当 Pod 意外终止时，控制器会自动重建；当节点故障时，Pod 会被重新调度到健康节点。

三、总结：Kubernetes 应用模型与架构的协同

Kubernetes 的强大之处在于其清晰的架构分层与声明式设计的完美结合：

控制平面（API Server、etcd、Scheduler、Controller Manager、Cloud Controller Manager）提供了全局协调与状态存储的基石。
工作节点（kubelet、容器运行时、kube-proxy、网络插件）则负责实际执行任务并维持网络连通性。
应用模型（Pod、工作负载资源、Service、ConfigMap、PV/PVC 等）为用户提供了标准化的接口，使得复杂的分布式应用可以像描述期望状态一样轻松部署和管理。

通过这种设计，Kubernetes 实现了：

基础设施抽象：隐藏底层 IaaS 差异，应用可移植。
自动化运维：自愈、弹性伸缩、滚动更新、回滚。
模块化与组合：各种 API 对象可自由组合，满足复杂应用需求。
可扩展性：通过 CRD 和 Operator 扩展平台功能，适应各类有状态应用。
声明式配置：便于版本控制、审计和自动化交付（GitOps）。

理解 Kubernetes 的架构组件与应用模型，就如同掌握了这个云原生操作系统的内部原理与用户接口，让你能够更高效地构建、部署和管理现代化的容器化应用。

扩展学习资源

官方文档：https://kubernetes.io/docs/ （最权威的资料）
Kubernetes The Hard Way：https://github.com/kelseyhightower/kubernetes-the-hard-way （手把手搭建集群，深入理解原理）
认证考试：CKA（Certified Kubernetes Administrator）和 CKAD（Certified Kubernetes Application Developer）是检验能力的权威认证。
社区工具：推荐尝试 kind（本地快速集群）、kubectx/kubens（快速切换上下文/命名空间）、k9s（终端 UI 管理）。

希望本文能帮助你夯实 Kubernetes 基础，在实际工作中得心应手。如有疑问或建议，欢迎交流讨论！

Kubernetes 完全指南：从集群架构到应用模型