Kubernetes 架构详解

本文档面向已有 Linux、Shell、Docker 和 Docker Compose 基础的开发者，通过类比和实际示例帮助理解 Kubernetes 的架构设计。

从 Docker 到 Kubernetes

Docker Compose 的局限性

如果你使用过 Docker Compose，你可能熟悉这样的场景：

# docker-compose.yml
version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    volumes:
      - ./data:/usr/share/nginx/html
  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: mypassword

Docker Compose 非常适合：

单机部署：所有容器运行在一台机器上
开发环境：快速启动多个关联服务
简单场景：服务数量少，依赖关系简单

但是，当你的应用需要：

高可用性：容器挂了怎么办？如何自动重启？
水平扩展：如何轻松地从 1 个实例扩展到 100 个？
多机器部署：如何管理分布在多台服务器上的容器？
滚动更新：如何在不中断服务的情况下更新应用？
服务发现：容器 IP 变化时，其他服务如何找到它？

Docker Compose 就显得力不从心了。

Kubernetes 的核心价值

Kubernetes（简称 K8s）是一个容器编排平台，它解决了以下问题：

自动化运维：自动重启失败的容器、自动扩展、自动调度
多节点管理：统一管理分布在多台服务器上的容器
服务发现与负载均衡：自动为服务分配 IP 和 DNS，实现负载均衡
滚动更新与回滚：支持零停机更新，出错可快速回滚
配置与密钥管理：集中管理配置文件和敏感信息
存储编排：自动挂载存储系统（本地、云存储等）

简单理解：如果说 Docker 是”集装箱”，Docker Compose 是”单船的货物清单”，那么 Kubernetes 就是”整个港口的自动化管理系统”。

Kubernetes 整体架构

架构概览

Kubernetes 采用主从架构（Master-Worker），包含两类节点：

Master 节点（控制平面）：负责管理和调度，是整个集群的”大脑”
Worker 节点（工作节点）：负责运行实际的容器，是”干活的工人”

graph TB
    subgraph Master["Master 节点（控制平面）"]
        API[API Server<br/>统一入口]
        ETCD[etcd<br/>状态存储]
        CM[Controller Manager<br/>控制器管理器]
        SCHED[Scheduler<br/>调度器]
    end
    
    subgraph Worker1["Worker 节点 1"]
        KUBELET1[kubelet<br/>节点代理]
        PROXY1[kube-proxy<br/>网络代理]
        RUNTIME1[Container Runtime<br/>容器运行时]
        POD1[Pod<br/>容器组]
    end
    
    subgraph Worker2["Worker 节点 2"]
        KUBELET2[kubelet<br/>节点代理]
        PROXY2[kube-proxy<br/>网络代理]
        RUNTIME2[Container Runtime<br/>容器运行时]
        POD2[Pod<br/>容器组]
    end
    
    API --> ETCD
    API --> CM
    API --> SCHED
    API <--> KUBELET1
    API <--> KUBELET2
    SCHED --> KUBELET1
    SCHED --> KUBELET2
    KUBELET1 --> RUNTIME1
    KUBELET2 --> RUNTIME2
    RUNTIME1 --> POD1
    RUNTIME2 --> POD2
    PROXY1 --> POD1
    PROXY2 --> POD2

组件通信方式

API Server 是所有组件通信的唯一入口（类比：所有请求都通过一个统一的 API 网关）
etcd 存储集群状态，只有 API Server 能直接访问（类比：数据库，只有应用层能访问）
Worker 节点 通过 kubelet 与 API Server 通信，定期报告状态并接收指令
组件之间通过 RESTful API 或 gRPC 进行通信

Master 节点（控制平面）组件详解

Master 节点是 Kubernetes 集群的”大脑”，负责整个集群的决策和管理。通常建议至少 3 个 Master 节点以实现高可用。

1. API Server（kube-apiserver）

作用：集群的统一入口，所有操作都必须通过它。

类比：就像 Docker 的 docker 命令，所有对容器的操作都通过这个命令。在 K8s 中，所有操作（创建、删除、查询）都通过 API Server。

特点：

提供 RESTful API（HTTP/HTTPS）
验证和授权所有请求
是唯一与 etcd 直接通信的组件
支持多种客户端：kubectl、Web UI、编程语言 SDK

实际使用：

# 当你执行 kubectl 命令时，实际上是在调用 API Server
kubectl get pods
# ↓ 转换为 HTTP 请求
# GET https://api-server:6443/api/v1/namespaces/default/pods

2. etcd

作用：分布式键值存储数据库，保存集群的所有状态数据。

类比：就像 Docker 的配置文件（docker-compose.yml），但 etcd 是动态的、实时的数据库。

存储内容：

Pod、Service、Deployment 等资源的状态
节点信息
配置信息
集群元数据

特点：

高可用：支持多节点部署（通常 3 或 5 个节点）
一致性：保证数据在所有节点间一致
快速：基于内存的键值存储，读写速度快

重要提示：etcd 是集群的”记忆”，如果 etcd 数据丢失，整个集群状态会丢失。因此需要定期备份。

3. Controller Manager（kube-controller-manager）

作用：运行各种控制器，确保集群状态符合预期。

类比：就像 Docker Compose 的自动重启功能，但更强大。Controller Manager 包含多个”控制器”，每个控制器负责一类资源的生命周期管理。

主要控制器：

Replication Controller：确保 Pod 副本数量符合预期（比如要求 3 个，如果只有 2 个，会自动创建 1 个）
Deployment Controller：管理 Deployment 的创建、更新、回滚
Node Controller：监控节点状态，节点故障时做出响应
Service Controller：管理 Service 和 LoadBalancer

工作原理：

期望状态：Deployment 要求运行 3 个 Pod
实际状态：当前只有 2 个 Pod 在运行
→ Controller Manager 检测到差异
→ 通过 API Server 创建 1 个新 Pod
→ 持续监控，直到实际状态 = 期望状态

4. Scheduler（kube-scheduler）

作用：决定 Pod 应该运行在哪个 Worker 节点上。

类比：就像 Docker Compose 的 deploy.placement.constraints，但更智能。Scheduler 会考虑：

节点资源（CPU、内存）是否充足
节点是否有污点（Taint）不允许调度
Pod 的亲和性要求（希望和某些 Pod 在同一节点）
负载均衡（尽量分散 Pod 到不同节点）

调度流程：

1. 新 Pod 被创建
2. Scheduler 发现这个 Pod 还没有被分配到节点
3. Scheduler 评估所有可用节点
4. 为每个节点打分（0-100）
5. 选择分数最高的节点
6. 通过 API Server 将 Pod 绑定到该节点
7. 该节点的 kubelet 开始创建 Pod

Worker 节点组件详解

Worker 节点是实际运行容器的地方，每个 Worker 节点都需要运行以下组件。

1. kubelet

作用：节点代理，负责管理本节点上 Pod 的生命周期。

类比：就像 Docker 守护进程（dockerd），但 kubelet 是 K8s 的”节点管家”。

主要职责：

定期向 API Server 报告节点状态
监听 API Server，接收 Pod 创建/删除指令
管理 Pod 的生命周期（创建、启动、停止、删除）
监控 Pod 健康状态，执行健康检查
挂载 Volume（存储卷）

工作流程：

API Server: "在节点 A 上创建一个 Pod"
    ↓
kubelet 收到指令
    ↓
kubelet 调用 Container Runtime（如 Docker）
    ↓
Container Runtime 创建容器
    ↓
kubelet 监控容器状态，定期报告给 API Server

2. kube-proxy

作用：网络代理，实现 Service 的网络功能（负载均衡、服务发现）。

类比：就像 Docker Compose 的端口映射和内部网络，但更强大。kube-proxy 负责：

将 Service 的虚拟 IP 转发到后端 Pod
实现负载均衡（将请求分发到多个 Pod）
维护网络规则（iptables 或 IPVS）

工作原理：

用户请求 → Service IP (10.96.0.1:80)
    ↓
kube-proxy 拦截请求
    ↓
根据负载均衡算法选择后端 Pod
    ↓
转发请求到 Pod IP (192.168.1.10:8080)

三种工作模式：

userspace：在用户空间处理（性能较低，已弃用）
iptables：使用 Linux iptables 规则（默认，性能好）
IPVS：使用 Linux IPVS（性能最好，适合大规模集群）

3. Container Runtime（容器运行时）

作用：实际运行容器的底层软件。

类比：这就是你熟悉的 Docker！Kubernetes 本身不直接运行容器，而是通过 Container Runtime。

支持的运行时：

Docker：最常用，你已经熟悉
containerd：Docker 的底层运行时，更轻量
CRI-O：专为 Kubernetes 设计的运行时
其他符合 CRI（Container Runtime Interface）标准的运行时

重要理解：

Kubernetes 通过 CRI（Container Runtime Interface） 与 Container Runtime 通信
这意味着你可以替换 Container Runtime，而不影响 Kubernetes 的功能
就像你可以用不同的数据库驱动，只要它们实现了相同的接口

核心概念（类比 Docker Compose）

理解 Kubernetes 的核心概念，最好的方式是通过与 Docker Compose 的对比。

Pod

Kubernetes 的最小调度单位，一个 Pod 可以包含一个或多个容器。

类比 Docker Compose：

# Docker Compose
services:
  web:
    image: nginx
    # 这是一个 service，通常对应一个容器

# Kubernetes
apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
  # 这是一个 Pod，可以包含多个容器

关键特点：

Pod 内的容器共享网络和存储
Pod 是临时的，会被创建和销毁
通常不直接创建 Pod，而是通过 Deployment 等资源管理

多容器 Pod 示例（类比 Docker Compose 的 depends_on）：

# 一个 Pod 包含两个容器：Web 服务器 + 日志收集器
spec:
  containers:
  - name: web
    image: nginx
  - name: log-collector
    image: fluentd
    # 两个容器共享网络，可以通过 localhost 通信

Deployment

管理 Pod 副本的控制器，确保指定数量的 Pod 运行。

类比 Docker Compose：

# Docker Compose - 只能手动指定实例数
services:
  web:
    image: nginx
    deploy:
      replicas: 3  # 但需要手动管理

# Kubernetes Deployment - 自动管理
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3  # 自动确保有 3 个 Pod 运行
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:latest

Deployment 的优势：

自动恢复：Pod 挂了，自动创建新的
滚动更新：更新时逐步替换，不中断服务
回滚：更新出错可以快速回滚到上一版本
扩缩容：可以轻松调整副本数量

实际命令对比：

# Docker Compose - 扩展需要手动操作
docker-compose up -d --scale web=5

# Kubernetes - 一行命令
kubectl scale deployment web-deployment --replicas=5

Service

为 Pod 提供稳定的网络访问，实现服务发现和负载均衡。

类比 Docker Compose：

# Docker Compose - 通过服务名访问
services:
  web:
    image: nginx
    ports:
      - "8080:80"
  app:
    image: myapp
    # 可以通过 "web" 这个服务名访问
    environment:
      - API_URL=http://web:80

# Kubernetes Service - 更强大的网络抽象
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web  # 选择标签为 app=web 的 Pod
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP  # 集群内部访问

Service 类型：

ClusterIP（默认）：集群内部访问，类比 Docker Compose 的内部网络
NodePort：通过节点 IP 访问，类比 Docker Compose 的端口映射
LoadBalancer：云平台提供的负载均衡器
ExternalName：外部服务别名

服务发现对比：

# Docker Compose - 通过服务名
curl http://web:80

# Kubernetes - 通过 Service 名 + Namespace
curl http://web-service.default.svc.cluster.local:80
# 或简写（同一 Namespace）
curl http://web-service:80

Namespace

逻辑隔离，将集群资源分组管理。

类比 Docker Compose：

# Docker Compose - 通过项目名隔离
docker-compose -p project1 up
docker-compose -p project2 up
# 两个项目的容器不会互相干扰

# Kubernetes - 通过 Namespace 隔离
kubectl create namespace production
kubectl create namespace development
# 两个 Namespace 的资源完全隔离

默认 Namespace：

default：默认命名空间
kube-system：系统组件（API Server、etcd 等）
kube-public：公共资源
kube-node-lease：节点心跳

实际使用：

# 在不同 Namespace 创建同名资源
kubectl create deployment web --image=nginx -n production
kubectl create deployment web --image=nginx -n development
# 两个 Deployment 互不干扰

ConfigMap 和 Secret

管理配置和敏感信息，类比 Docker Compose 的环境变量。

类比 Docker Compose：

# Docker Compose
services:
  app:
    image: myapp
    environment:
      - DATABASE_HOST=db.example.com
      - API_KEY=secret123
    env_file:
      - .env

# Kubernetes ConfigMap（非敏感配置）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_host: "db.example.com"
  log_level: "info"
---
# Kubernetes Secret（敏感信息）
apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  api_key: c2VjcmV0MTIz  # base64 编码
---
# 在 Pod 中使用
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp
    envFrom:
    - configMapRef:
        name: app-config
    - secretRef:
        name: app-secret

优势：

集中管理：配置与代码分离
版本控制：可以追踪配置变更
动态更新：可以更新 ConfigMap，Pod 自动获取新配置（需要应用支持）
安全性：Secret 可以加密存储

网络架构

Pod 网络模型

核心原则：每个 Pod 都有独立的 IP 地址，Pod 之间可以直接通信。

类比 Docker：

Docker 默认使用桥接网络，容器通过 Docker 网络通信
Kubernetes 要求所有 Pod 可以在不使用 NAT 的情况下互相访问

网络插件：
Kubernetes 本身不实现网络，通过 CNI（Container Network Interface） 插件实现：

Flannel：简单的覆盖网络
Calico：基于 BGP 的网络，支持网络策略
Weave：自动网络发现
Cilium：基于 eBPF 的高性能网络

Service 网络

Service 提供稳定的虚拟 IP，实现服务发现和负载均衡。

graph LR
    User[用户请求] --> Service[Service<br/>10.96.0.1:80]
    Service --> Pod1[Pod 1<br/>192.168.1.10:8080]
    Service --> Pod2[Pod 2<br/>192.168.1.11:8080]
    Service --> Pod3[Pod 3<br/>192.168.1.12:8080]
    
    style Service fill:#e1f5ff
    style Pod1 fill:#fff4e1
    style Pod2 fill:#fff4e1
    style Pod3 fill:#fff4e1

Service 类型详解：

ClusterIP（默认）
- 只在集群内部可访问
- 类比：Docker Compose 的内部网络
- 使用场景：微服务之间的内部通信
NodePort
- 在每个节点上开放一个端口（30000-32767）
- 类比：Docker Compose 的 ports: - "8080:80"
- 使用场景：开发测试、简单的外部访问
LoadBalancer
- 云平台提供的负载均衡器
- 类比：AWS ELB、阿里云 SLB
- 使用场景：生产环境的外部访问
ExternalName
- 外部服务的别名
- 使用场景：访问集群外的服务

与 Docker 网络对比

特性	Docker	Kubernetes
网络隔离	通过网络驱动	通过 Namespace + 网络策略
服务发现	通过服务名（DNS）	通过 Service 名（DNS）
负载均衡	需要额外工具（Nginx）	Service 内置负载均衡
端口映射	`-p host:container`	NodePort 或 LoadBalancer
网络插件	可选的网络驱动	必须的 CNI 插件

存储架构

Volume 概念

类比 Docker Volume：

1 2	# Docker Volume docker run -v /data:/app/data nginx

# Kubernetes Volume
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /app/data
  volumes:
  - name: data
    hostPath:
      path: /data

Volume 类型：

emptyDir：临时存储，Pod 删除时清除（类比 Docker 的匿名卷）
hostPath：挂载节点文件系统（类比 Docker 的 bind mount）
nfs：网络文件系统
云存储：AWS EBS、Azure Disk、GCE PD 等

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)

核心概念：将存储的提供和使用分离。

类比理解：

PV（PersistentVolume）：就像”硬盘”，是集群中的存储资源
PVC（PersistentVolumeClaim）：就像”申请使用硬盘的请求”，Pod 通过 PVC 使用 PV

工作流程：

1. 管理员创建 PV（提供存储）
2. 用户创建 PVC（申请存储）
3. Kubernetes 自动将 PVC 绑定到合适的 PV
4. Pod 通过 PVC 使用存储

示例：

# 1. 管理员创建 PV（类比：准备一块硬盘）
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data/mysql
---
# 2. 用户创建 PVC（类比：申请使用硬盘）
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
# 3. Pod 使用 PVC（类比：在容器中挂载硬盘）
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    volumeMounts:
    - name: data
      mountPath: /var/lib/mysql
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mysql-pvc

StorageClass（动态供应）：

手动创建 PV 很麻烦，StorageClass 可以自动创建 PV
类比：云平台的”按需分配存储”，不需要提前准备

与 Docker Volume 对比

特性	Docker Volume	Kubernetes Volume
临时存储	匿名卷	emptyDir
持久化存储	命名卷、bind mount	PV + PVC
动态供应	需要手动创建	StorageClass 自动创建
多容器共享	通过命名卷	通过 PVC
数据迁移	需要手动操作	通过 PVC 抽象，易于迁移

工作流程示例

让我们通过一个完整的例子，看看从创建 Deployment 到 Pod 运行的整个流程。

场景：部署一个 Nginx 应用

sequenceDiagram
    participant User as 用户
    participant Kubectl as kubectl
    participant API as API Server
    participant ETCD as etcd
    participant Sched as Scheduler
    participant CM as Controller Manager
    participant Kubelet as kubelet (Worker)
    participant Runtime as Container Runtime
    participant Proxy as kube-proxy

    User->>Kubectl: kubectl create deployment nginx --image=nginx
    Kubectl->>API: POST /apis/apps/v1/namespaces/default/deployments
    API->>ETCD: 存储 Deployment 定义
    ETCD-->>API: 确认存储成功
    API-->>Kubectl: 返回 Deployment 对象
    Kubectl-->>User: Deployment 创建成功

    Note over CM: Controller Manager 检测到新 Deployment
    CM->>API: 查询 Deployment 期望状态
    API->>ETCD: 读取 Deployment
    ETCD-->>API: 返回 Deployment（replicas: 1）
    API-->>CM: 返回 Deployment
    CM->>API: 查询当前 ReplicaSet
    API-->>CM: 返回 ReplicaSet（0 个 Pod）
    CM->>API: 创建 ReplicaSet（期望 1 个 Pod）
    API->>ETCD: 存储 ReplicaSet
    CM->>API: 创建 Pod（未调度）
    API->>ETCD: 存储 Pod

    Note over Sched: Scheduler 发现未调度的 Pod
    Sched->>API: 查询所有节点资源
    API-->>Sched: 返回节点列表
    Sched->>Sched: 评估节点，选择最佳节点
    Sched->>API: 绑定 Pod 到节点 Worker-1
    API->>ETCD: 更新 Pod 状态

    Note over Kubelet: kubelet 监听 API Server
    API->>Kubelet: Pod 调度到本节点
    Kubelet->>Runtime: 创建容器（通过 CRI）
    Runtime->>Runtime: 拉取镜像 nginx:latest
    Runtime->>Runtime: 创建并启动容器
    Runtime-->>Kubelet: 容器运行中
    Kubelet->>API: 更新 Pod 状态为 Running
    API->>ETCD: 更新 Pod 状态

    Note over Proxy: kube-proxy 监听 Service 变化
    User->>Kubectl: kubectl expose deployment nginx --port=80
    Kubectl->>API: 创建 Service
    API->>ETCD: 存储 Service
    API->>Proxy: 通知 Service 创建
    Proxy->>Proxy: 更新 iptables 规则
    Proxy-->>API: 规则更新完成

    Note over User: 应用部署完成，可以通过 Service 访问

关键步骤说明

用户创建 Deployment
- 通过 kubectl 发送请求到 API Server
- API Server 验证请求，存储到 etcd
Controller Manager 响应
- 检测到期望状态（1 个 Pod）与实际状态（0 个 Pod）不一致
- 创建 ReplicaSet 和 Pod
Scheduler 调度
- 发现未调度的 Pod
- 评估所有节点，选择最佳节点
- 将 Pod 绑定到节点
kubelet 执行
- 收到 Pod 调度通知
- 通过 Container Runtime 创建容器
- 监控容器状态，报告给 API Server
kube-proxy 配置网络
- 监听 Service 变化
- 更新网络规则，实现负载均衡

与 Docker Compose 的对比

功能对比表

功能	Docker Compose	Kubernetes
适用场景	单机、开发环境	多机、生产环境
服务定义	`docker-compose.yml`	YAML 清单文件
服务管理	`docker-compose up/down`	`kubectl apply/delete`
扩缩容	`--scale`（手动）	`kubectl scale`（自动管理）
自动重启	`restart: always`	自动（Deployment 保证）
滚动更新	不支持	内置支持
回滚	手动	内置支持
服务发现	服务名（同一网络）	Service + DNS
负载均衡	需要 Nginx/HAProxy	Service 内置
配置管理	环境变量、`.env` 文件	ConfigMap、Secret
存储管理	Volume、bind mount	PV、PVC、StorageClass
网络隔离	网络驱动	Namespace + 网络策略
健康检查	`healthcheck`	Liveness/Readiness Probe
资源限制	`deploy.resources`	`resources.requests/limits`
多节点部署	不支持	原生支持
高可用	需要外部工具	内置支持

使用场景建议

使用 Docker Compose 的场景：

✅ 本地开发环境：快速启动多个关联服务
✅ 单机部署：小型应用，不需要高可用
✅ CI/CD 测试：在 CI 中运行集成测试
✅ 学习 Docker：理解容器和网络概念

使用 Kubernetes 的场景：

✅ 生产环境：需要高可用、自动恢复
✅ 多节点部署：应用分布在多台服务器
✅ 微服务架构：大量服务需要统一管理
✅ 需要自动扩缩容：根据负载自动调整实例数
✅ 需要滚动更新：零停机更新应用
✅ 大规模部署：管理数百个容器

迁移路径

如果你熟悉 Docker Compose，迁移到 Kubernetes 的路径：

理解概念映射
- docker-compose.yml → Kubernetes YAML 清单
- service → Deployment + Service
- volumes → PV + PVC
- networks → Kubernetes 网络模型
学习 kubectl 命令
- docker-compose up → kubectl apply
- docker-compose ps → kubectl get pods
- docker-compose logs → kubectl logs
- docker-compose exec → kubectl exec
实践部署
- 先在本地环境（Minikube、Kind）练习
- 逐步迁移现有 Docker Compose 应用
- 学习 Kubernetes 特有的功能（滚动更新、自动扩缩容等）

总结

核心要点回顾

架构设计：Master-Worker 架构，控制平面与工作节点分离
组件职责：
- Master：API Server（入口）、etcd（存储）、Controller Manager（控制）、Scheduler（调度）
- Worker：kubelet（管理）、kube-proxy（网络）、Container Runtime（运行）
核心概念：Pod（容器组）、Deployment（副本管理）、Service（网络抽象）、Namespace（隔离）
网络模型：Pod 独立 IP，Service 提供稳定访问，支持多种访问方式
存储模型：PV/PVC 分离存储提供和使用，支持动态供应

下一步学习建议

实践操作：
- 安装 Minikube 或 Kind（本地 Kubernetes）
- 尝试部署简单的应用
- 练习 kubectl 命令
深入学习：
- 学习 YAML 清单文件的编写
- 理解 ConfigMap、Secret 的使用
- 掌握 Service 和 Ingress 的区别
- 学习 StatefulSet、DaemonSet 等高级资源
生产实践：
- 学习 Helm（包管理工具）
- 了解监控和日志（Prometheus、Grafana）
- 学习 CI/CD 与 Kubernetes 集成

文档版本：v1.0
最后更新：2024年
适合人群：已有 Linux、Shell、Docker、Docker Compose 基础的开发者

Kubernetes 架构详解

目录

从 Docker 到 Kubernetes

Docker Compose 的局限性

Kubernetes 的核心价值

Kubernetes 整体架构

架构概览

组件通信方式

Master 节点（控制平面）组件详解

1. API Server（kube-apiserver）

2. etcd

3. Controller Manager（kube-controller-manager）

4. Scheduler（kube-scheduler）

Worker 节点组件详解

1. kubelet

2. kube-proxy

3. Container Runtime（容器运行时）

核心概念（类比 Docker Compose）

Pod

Deployment

Service

Namespace

ConfigMap 和 Secret

网络架构

Pod 网络模型

Service 网络

与 Docker 网络对比

存储架构

Volume 概念

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)

与 Docker Volume 对比

工作流程示例

场景：部署一个 Nginx 应用

关键步骤说明

与 Docker Compose 的对比

功能对比表

使用场景建议

使用 Docker Compose 的场景：

使用 Kubernetes 的场景：

迁移路径

总结

核心要点回顾

下一步学习建议