适用版本与系统

• Kubernetes 版本：v1.37.x（当前基线），兼容 v1.35 / v1.36 核心概念

• 主机系统：Rocky Linux / RHEL 9.x、Ubuntu 22.04+ / Debian 12+

• 容器运行时：containerd（主）、CRI-O（备）

• 前置知识：Linux 命令行基础、Docker 基本操作、TCP/IP 基础

学习目标

1. 准确理解 Kubernetes 的官方定义、核心价值与能力边界

2. 掌握 Kubernetes 与 Docker、Linux、CNCF 的三角关系

3. 理解声明式 API + 控制器模式的核心设计思想

4. 建立生产环境 Kubernetes 的架构认知基线

5. 能够从零开始规划一个学习/实验集群

核心结论

Kubernetes 不是“更好的 Docker”，而是“生产级容器编排平台”。 Docker 负责让一个容器在单机上运行，Kubernetes 负责让成千上万个容器在多台机器上协同工作、自动恢复、弹性伸缩。二者是互补而非替代关系。Kubernetes 的核心设计思想是 声明式 API（期望状态） + 控制器模式（调谐循环） ，这决定了它的所有行为方式——你描述“要什么”，Kubernetes 负责“怎么达成并维持”。

一、为什么需要 Kubernetes：从单机容器到集群编排

1.1 单机容器管理的天花板

容器技术解决了应用打包和隔离的问题，但当一个应用需要跨多台机器运行数十甚至数百个容器实例时，手工管理会迅速失控。单机 Docker 的核心局限包括：

• 单点故障：容器崩溃后无法自动恢复，需要人工介入重启

• 手动扩缩容：流量激增时需人工决定在哪台机器上启动多少容器

• 服务发现困难：容器 IP 动态变化，服务之间无法稳定地互相调用

• 资源调度低效：无法跨多台机器智能分配负载，资源利用率低

这正是 Kubernetes 要解决的问题。Kubernetes 提供了一个可弹性运行分布式系统的框架，能够满足扩展要求、执行故障转移、提供部署模式。

1.2 Kubernetes 的核心能力

Kubernetes 为生产环境提供以下核心能力：

能力	说明
服务发现与负载均衡	使用 DNS 名称或 IP 暴露容器，自动负载均衡
存储编排	自动挂载本地存储、云存储、网络存储
自动部署与回滚	描述期望状态，Kubernetes 以受控速率变更实际状态
自动装箱计算	根据资源需求和约束调度容器，优化资源利用
自我修复	重启失败容器、替换容器、杀死不健康的容器
密钥与配置管理	在不重建镜像的情况下部署和更新敏感信息
批处理执行	管理 Job 和 CI 工作负载，替换失败的容器
水平扩缩	根据 CPU 使用率等指标自动扩缩应用

1.3 Kubernetes 不是什么

理解 Kubernetes 的边界同样重要。Kubernetes 不是传统的包罗万象的 PaaS 系统。它在容器级别而非硬件级别运行，默认解决方案都是可选、可插拔的。Kubernetes 不限制支持的应用程序类型，不部署源代码也不构建应用，不提供应用程序级别的内置服务（如消息中间件）。

Kubernetes 只提供 API、编排与调度以及资源管理。要获得完整的应用平台，还需要 Linux 操作系统、容器注册表、容器网络、容器存储、日志记录、监控以及 CI/CD 流程。

二、Kubernetes 与 Docker：互补而非竞争

2.1 定位差异

Docker 是一种容器运行时技术，将软件打包成名为容器的标准化单元，包含库、系统工具和代码等运行软件所需的所有项目。Kubernetes 是一种容器编排工具，用于大规模地管理、协调和调度容器。

用一个形象的比喻：Docker 帮你准备好每个演员（容器），而 Kubernetes 是聪明的舞台经理和城市规划师，确保整个演出或城市的运行是高效、有序、健壮的。

2.2 关注点对比

维度	Docker	Kubernetes
核心职责	容器构建、运行、分发	容器编排、调度、管理
作用范围	单机	集群（多机）
典型场景	开发环境、单机部署	生产环境、微服务集群
关键工具	Docker Engine、Dockerfile、Docker Hub	kube-apiserver、kubelet、kubectl
配置方式	命令式为主	声明式为主

2.3 重要的版本变迁

2021 年 Kubernetes 宣布不再将 Docker 作为容器运行时选项支持，这引发了许多误解。实际上这不意味着“Kubernetes 不能用 Docker”，而是 Kubernetes 从直接依赖 Docker Engine 转向了通过 CRI（容器运行时接口） 与容器运行时通信。containerd 和 CRI-O 成为主流选择。Docker 构建的镜像仍然完全兼容 Kubernetes，因为二者都遵循 OCI（Open Container Initiative）标准。

生产实践要点：当前生产环境推荐使用 containerd 作为容器运行时。Docker 在开发阶段仍然是非常有价值的工具，用于构建和测试镜像。

三、Kubernetes 与 Linux：容器技术的根基

Linux 是容器的基础。容器最初是在 Linux 中创建的，也正是得益于一些关键 Linux 子系统，容器技术才得以存在。将应用部署到容器中时，这些应用就是在 Linux 上运行的。

Kubernetes 本身也是从 Linux 构建而来的，它采用了关键 Linux 结构、系统调用、库和功能来管理容器的基础架构并对容器进行编排。

3.1 容器隔离的 Linux 内核基础

Kubernetes 的容器隔离能力依赖以下 Linux 内核机制：

• Namespace：提供进程、网络、文件系统、用户等维度的隔离。每个 Pod 中的容器共享 Network Namespace，这是 Pod 内多容器通过 localhost 通信的基础。

• cgroups：限制和隔离容器的 CPU、内存、I/O 等资源使用。Kubernetes 的资源请求（requests）和限制（limits）最终通过 cgroups 实现。当前推荐使用 cgroups v2，需要 Linux 内核 5.8 或更高版本。

• Capabilities：细粒度的特权控制，Kubernetes 的 SecurityContext 可以精确控制容器拥有的 Linux Capabilities。

3.2 生产环境的 Linux 选择

为 Kubernetes 环境选择操作系统时，需要技术领先、值得信赖的 Linux 发行版。本系列教程统一覆盖两大体系：

• RHEL / Rocky Linux：企业级稳定性，SELinux 默认启用，cgroups v2 支持完善

• Ubuntu / Debian：社区生态活跃，AppArmor 安全模块，容器工具链更新快

3.3 Kubernetes 与操作系统的关系边界

需要明确的是，Kubernetes 运行在操作系统之上，不替代操作系统。节点上的 Linux 需要负责：

• 内核参数调优（网络转发、连接跟踪、文件句柄等）

• 存储挂载（fstab、LVM、文件系统选择）

• 时间同步（chrony / NTP，影响证书有效性和日志排序）

• 防火墙规则管理（iptables / nftables / firewalld）

这些主题将在本系列 1.2 节“Linux 基础环境”中逐一展开。

四、Kubernetes 与 CNCF：云原生生态的核心

4.1 CNCF 与 Kubernetes 的关系

Kubernetes 是云原生计算基金会（CNCF） 的旗舰项目，由 Google 于 2014 年开源。Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上，结合了社区中最优秀的想法和实践。

CNCF 成立于 2015 年，从最初只有 Kubernetes 和大约二十个成员，已发展成为一个拥有超过 230 个项目和来自 190 多个国家的 30 万以上贡献者的生态系统。CNCF 的范围已经远远超出了容器编排，涵盖可观测性、服务网格、平台工程、FinOps 以及 AI 技术栈。

4.2 Kubernetes 的定位演进：从编排器到“事实操作系统”

CNCF CTO Chris Aniszczyk 在 2026 年的回顾中指出，Kubernetes 已经从最初的编排器定位，演变为“云原生工作负载的事实操作系统”。Kubernetes 是继 Linux（34 年历史）之后开发速度最高的项目。Kubernetes 维护者有意避免功能膨胀，通过将存储功能移至 CSI、运行时移至 CRI 等模块化方式保持核心精简。

4.3 云原生生态全景

Kubernetes 不是孤立的技术，而是整个云原生生态的核心控制面。以下是与 Kubernetes 紧密相关的 CNCF 项目类别：

类别	代表项目	与 Kubernetes 的关系
容器运行时	containerd、CRI-O	通过 CRI 接口对接
网络	Calico、Cilium、Flannel	通过 CNI 接口对接
存储	Rook、Longhorn、OpenEBS	通过 CSI 接口对接
可观测性	Prometheus、Grafana、OpenTelemetry	监控 K8s 集群和应用
服务网格	Istio、Linkerd	增强 K8s 服务通信
GitOps	Argo CD、Flux	声明式持续交付
安全	Falco、Trivy、OPA	运行时安全与策略

CNCF 当前明确认可 Kubernetes 作为 AI 工作负载通用控制面的定位。2026 年 KubeCon 上，Kubeflow 正式从 CNCF 毕业，标志着 K8s 作为生产 AI 工作负载控制面的信心增长。

五、Kubernetes 核心设计思想

理解了“Kubernetes 是什么”，还需要理解它“怎么工作”。Kubernetes 的核心能力建立在两个设计原则之上：声明式 API 和 控制器模式。

5.1 声明式管理：从“怎么做”到“要什么”

传统运维方式是命令式的——你需要告诉系统每一步怎么做：先启动容器 A，再配置网络 B，然后挂载存储 C。

Kubernetes 采用声明式方式——你只需要描述期望的最终状态：应用需要 3 个副本、使用哪个镜像、暴露哪个端口、需要多少 CPU 和内存。你通过创建对象来告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的，这就是所谓的期望状态。

实践中的声明式管理：

# deployment.yaml — 声明式描述期望状态
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

# 应用声明式配置
kubectl apply -f deployment.yaml
​
# 查看实际状态
kubectl get deployment nginx-deployment
kubectl get pods -l app=nginx
​
# 修改期望状态（例如扩展到 5 个副本）
kubectl scale deployment nginx-deployment --replicas=5

5.2 控制器模式：调谐循环

Kubernetes 控制平面持续主动地管理每个对象的实际状态，以匹配你提供的期望状态。这个持续调谐的过程称为 Reconciliation Loop（调谐循环） 。

控制器模式的典型工作流程是：外部输入一个“期望值”，控制器不断观测“环境状态”的“实际值”和“期望值”之间的差异，然后不断调整“实际值”向“期望值”靠拢。

以 Deployment 为例：

┌──────────────────────────────────────────────────┐
│  Deployment Controller 的调谐循环                 │
│                                                  │
│  期望状态: replicas = 3                           │
│       │                                          │
│       ▼                                          │
│  观察实际状态: kubectl get pods → 2 个 Running    │
│       │                                          │
│       ▼                                          │
│  差异 = 1 个副本缺失                              │
│       │                                          │
│       ▼                                          │
│  动作: 创建 1 个新 Pod                            │
│       │                                          │
│       ▼                                          │
│  回到观察步骤，持续循环                            │
└──────────────────────────────────────────────────┘

5.3 “一切皆资源”的 API 驱动架构

Kubernetes 的控制平面核心是 API 服务器及其暴露的 HTTP API。用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。

在 Kubernetes 中，Pod、Deployment、Service、Node 等一切对象都通过 API 以资源（Resource） 的形式暴露。每个资源都可以通过 API 进行创建、读取、更新和删除（CRUD）操作。

这意味着 Kubernetes 的扩展性极强——你可以通过 CRD（自定义资源定义）添加新的资源类型，而无需修改 Kubernetes 核心代码。这正是 Operator 模式的基础。

六、核心术语速览

以下术语是理解后续所有教程的基础，本系列将在后续章节逐一深入展开：

术语	定义	深入章节
Cluster（集群）	Kubernetes 管理的整个系统，包含控制面和所有工作节点	071
Node（节点）	集群中的一台机器，可以是物理机或虚拟机	071 / 084
Pod	最小可部署和调度的单元，包含一个或多个共享网络/存储的容器	121-140
Workload（工作负载）	管理 Pod 副本创建和生命周期的资源对象	141-155
Service	为动态 Pod 提供稳定访问入口的抽象	156-175
Namespace	集群内的逻辑隔离单元，用于多租户和资源分组	112
Control Plane	集群的大脑，包含 API Server、etcd、Scheduler、Controller Manager	071-090
Worker Node	运行实际工作负载的节点，包含 kubelet、kube-proxy、容器运行时	077-084

Kubernetes 的控制面包含以下核心组件：

• kube-apiserver：唯一 API 入口，处理所有 REST 请求

• etcd：分布式键值存储，保存集群所有状态数据

• kube-scheduler：决定 Pod 调度到哪个 Node

• kube-controller-manager：运行各种控制器（ReplicaSet、Node Controller 等）

• cloud-controller-manager（可选）：对接云厂商 API

每个工作节点则运行：

• kubelet：节点代理，确保容器按预期运行

• kube-proxy：维护网络规则，实现 Service 负载均衡

• Container Runtime：容器运行时（containerd / CRI-O）

七、生产实战：从零搭建学习集群

7.1 生产环境 vs 学习环境的关键差异

生产质量的 Kubernetes 集群需要更多考量：

• 可用性：单机学习环境具有单点失效特点。生产集群需要将控制面与工作节点分开、在多个节点上提供控制面组件副本、为 API 服务器流量提供负载均衡

• 规模：需要规划如何处理请求上升时对控制面和节点的压力

• 安全与访问管理：需要 RBAC 和其他安全机制来确保用户和负载只能访问所需资源

7.2 学习环境搭建选项

对于入门阶段，推荐以下工具搭建本地集群：

工具	特点	适用场景
kind	容器化 K8s 集群，CI 友好	快速验证、CI 测试
minikube	单节点集群，功能完整	本地学习
K3s	轻量级，资源占用少	边缘、资源受限环境

# 使用 kind 快速搭建本地集群
# 安装 kind
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64
chmod +x ./kind && sudo mv ./kind /usr/local/bin/
​
# 创建单节点集群
kind create cluster --name learn-k8s
​
# 验证集群
kubectl cluster-info
kubectl get nodes

7.3 生产环境部署路线概览

本系列将覆盖以下生产部署路线：

• kubeadm HA（默认生产部署）：多控制平面 + 外部 etcd，适用于裸机和虚拟机

• Cluster API：声明式集群生命周期管理

• kOps：自动化集群供应

• Kubespray：Ansible 自动化集群部署

• 手工二进制：从零构建，理解每个组件

官方 kubeadm 文档当前按 Kubernetes v1.37 编写，明确覆盖安装、集群创建、高可用拓扑、外部 etcd 和双协议栈等内容。

八、验证方式

8.1 基础验证清单

完成本篇学习后，应能回答以下问题：

# 1. 验证集群可达
kubectl cluster-info
​
# 2. 查看集群节点
kubectl get nodes -o wide
​
# 3. 查看 API 资源列表（验证“一切皆资源”）
kubectl api-resources
​
# 4. 查看控制面组件状态
kubectl get pods -n kube-system
​
# 5. 创建一个测试 Pod 验证集群功能
kubectl run test-pod --image=nginx:1.25 --port=80
kubectl get pods
kubectl delete pod test-pod

8.2 概念验证问题

1. Kubernetes 和 Docker 分别负责什么？二者是替代关系还是互补关系？

2. “声明式管理”和“命令式管理”的区别是什么？举一个 Kubernetes 中的声明式管理例子。

3. 控制器模式的“调谐循环”是如何工作的？

4. Kubernetes 的容器隔离依赖哪些 Linux 内核机制？

5. CNCF 在 Kubernetes 生态中扮演什么角色？

九、常见故障与排障

9.1 入门阶段常见问题

问题现象	可能原因	排查方向
kubectl 连接失败	kubeconfig 未配置或集群未运行	检查 ~/.kube/config，运行 kubectl cluster-info
Pod 一直 Pending	节点资源不足或调度约束	kubectl describe pod <name> 查看 Events
Pod 无法拉取镜像	镜像地址错误或网络问题	kubectl describe pod 查看 ImagePull 事件
节点 NotReady	kubelet 未运行或网络插件未就绪	systemctl status kubelet，检查 CNI

9.2 生产环境考量

生产环境的排障复杂度远高于学习环境。以下问题需要在生产部署前规划：

• 控制面组件的高可用设计（多副本、负载均衡）

• 工作节点的容量规划和自动扩缩容

• RBAC 权限模型设计

• 网络插件选型（Calico / Cilium / Flannel）

• 存储方案选型（CSI 驱动、后端存储）

十、生产检查清单

部署生产 Kubernetes 集群前，确认以下基线：

• 控制面至少 3 节点，etcd 独立部署或 stacked 模式已规划
• API Server 前有负载均衡（HAProxy / Nginx / 云 LB）
• 工作节点规格、数量、节点池已按业务需求规划
• 容器运行时已选定（推荐 containerd）并完成 cgroups v2 配置
• CNI 插件已选定，Pod CIDR 和 Service CIDR 已规划
• 存储方案已确定（本地盘 / NFS / Ceph / 云 CSI）
• RBAC 最小权限模型已设计
• 监控方案已部署（Prometheus + Grafana）
• 日志采集方案已部署
• 备份策略已制定（etcd 快照 + Velero 对象备份）
• 升级路线已规划（版本偏差策略、升级窗口）
• 离线/在线镜像仓库已准备

十一、与前后章节的衔接

本篇定位：作为整个系列的第一篇，建立“Kubernetes 是什么”的全局认知，为后续所有章节提供概念框架。

下一篇：《002：Kubernetes 的发展历史——从 Borg、Omega 到 Kubernetes》将深入 Google 内部容器管理系统的演进历程，理解 Kubernetes 设计决策的历史根源。

关联章节：

• 004：Kubernetes 与 Docker 的关系——将进一步展开运行时层面的深入对比

• 005：Kubernetes 与 Linux 的关系——将深入内核机制

• 006：Kubernetes 与 CNCF——将展开云原生生态全景

• 007-010：核心术语与设计思想——将逐一深入

当前版本基线：Kubernetes v1.37.x，主机系统覆盖 Rocky Linux / RHEL 与 Ubuntu / Debian，容器运行时以 containerd 为主。后续教程将严格沿用本系列的编号体系，从 001 持续扩展。