Kubernetes 概念与核心设计哲学

为什么需要容器编排

当你只有一个 Docker 容器时，docker run 就够了。但当你的系统由数十个微服务组成、需要在数百台服务器上运行时，问题就变得复杂：如何保证服务高可用？容器崩溃后谁来重启？流量如何分发？配置如何统一管理？这些问题催生了容器编排系统。

Google Borg：K8s 的精神前身

Kubernetes 并非凭空而来。它的设计深受 Google 内部使用了十余年的集群管理系统 Borg 的启发。Borg 在 Google 内部管理着数十万台机器上的作业调度，积累了大量实战经验。

Google 集群管理演进

┌─────────────────────────────────────────────────────────┐
│                    Google Borg (2003)                     │
│  · 管理 Google 全部在线/离线作业                            │
│  · BorgMaster(控制平面) + Borglet(节点代理)               │
│  · 引入 alloc(资源分配单元，Pod 的前身)                    │
└─────────────────┬───────────────────────────────────────┘
                  │ 开源 + 重新设计
┌─────────────────▼───────────────────────────────────────┐
│               Kubernetes 1.0 (2014 开源)                  │
│  · Pod = alloc + 容器                                     │
│  · 声明式 API (Borg 是命令式配置文件)                      │
│  · 开放生态，CRD/Operator 扩展                             │
└─────────────────────────────────────────────────────────┘

声明式 API vs 命令式 API

这是 Kubernetes 最核心的设计思想之一。声明式（Declarative）意味着你只告诉系统"我想要什么"，而不是"如何去做"。Kubernetes 会持续对比当前状态与期望状态，并自动执行必要的操作来使两者一致。

# 告诉系统"如何做"
docker run -d --name web nginx
docker stop web
docker rm web
docker run -d --name web nginx:1.25

# 容器崩溃 → 你不知道 → 服务中断

# 告诉系统"想要什么"
spec:
  replicas: 3
  image: nginx:1.25

# K8s 自动保证 3 个副本运行
# Pod 崩溃 → K8s 自动重建

控制循环（Control Loop）原理

Kubernetes 的自愈能力来自于遍布整个系统的控制循环（也叫 Reconciliation Loop，调和循环）。每个 Controller 都在不断地执行同一个逻辑：

控制循环示意

         ┌──────────────────────────┐
         │      期望状态 (Desired)    │
         │   replicas: 3, nginx:1.25 │
         └───────────────┬──────────┘
                         │
          ┌──────────────▼──────────────┐
          │         Controller           │
          │   ① 观察当前状态 (Observe)   │
          │   ② 计算差异 (Diff)          │◄──┐
          │   ③ 执行操作 (Act)           │   │ 循环
          └──────────────┬──────────────┘   │
                         │               └──┘
         ┌──────────────▼──────────────┐
         │      当前状态 (Actual)     │
         │  当前 Pod 数量、健康状态等   │
         └─────────────────────────────┘

以 Deployment Controller 为例：

1. 观察：从 etcd 读取 Deployment 的 spec.replicas=3，以及当前实际运行的 Pod 数量
2. 差异：当前只有 2 个 Pod（有一个崩溃了），差距为 1
3. 操作：调用 API Server 创建 1 个新 Pod
4. 返回第 1 步，持续循环

K8s 与 Docker Compose 的区别

很多人入门 K8s 时都会问：Docker Compose 不是已经能编排多个容器了吗？为什么还需要 K8s？

第一个 Kubernetes YAML

让我们看一个完整的 YAML 文件，感受声明式 API 的形态：

apiVersion: apps/v1          # API 版本，决定该资源类型的 schema
kind: Deployment             # 资源类型
metadata:
  name: hello-k8s            # 资源名称，集群内唯一（同 namespace）
  namespace: default         # 所属命名空间
  labels:                    # 标签，用于选择器筛选
    app: hello-k8s
spec:                        # 期望状态（最重要的部分）
  replicas: 3                # 期望运行 3 个 Pod 副本
  selector:
    matchLabels:
      app: hello-k8s        # Deployment 通过此标签关联 Pod
  template:                  # Pod 模板
    metadata:
      labels:
        app: hello-k8s      # Pod 携带的标签，必须匹配 selector
    spec:
      containers:
      - name: web            # 容器名，Pod 内唯一
        image: nginx:1.25   # 容器镜像
        ports:
        - containerPort: 80 # 容器监听端口（文档性质，不影响网络）

# 应用此 YAML（创建或更新）
kubectl apply -f hello-k8s.yaml

# 查看 Deployment 状态
kubectl get deployment hello-k8s

# 查看自动创建的 Pod
kubectl get pods -l app=hello-k8s

# 删除资源
kubectl delete -f hello-k8s.yaml

核心术语速查