K8s入门第一课：从零理解Kubernetes核心概念与架构设计

前言

说实话，刚开始接触 Kubernetes 时，我是有点懵的。

那时候公司要上容器化，leader丢给我一句话："把这套系统用K8s部署一下"。我打开官方文档，迎面扑来一堆概念------Pod、Deployment、Service、ReplicaSet... 这都啥跟啥啊？

更崩溃的是，看懂了概念，实际用起来又是另一回事。Pod和容器啥关系？Service到底怎么把请求转发到Pod的？为什么有时候Pod起来了Service却访问不了？

花了一周多时间，啃完官方文档，翻了N篇博客，踩了一堆坑，才慢慢摸清楚K8s的门道。今天这篇文章，把我当时的学习路径和踩坑经验分享出来，帮你少走点弯路。

---

一、Kubernetes 是什么？

1.1 从 Docker 到 K8s

如果你用过 Docker，那你一定体验过这种爽感：一条命令就能启动一个应用，环境隔离、快速部署，简直太香了。

但是，当容器数量多了以后，问题就来了：

• 怎么管理成百上千个容器？
• 某个容器挂了怎么自动恢复？
• 流量大了怎么自动扩容？
• 怎么实现负载均衡？

这就是 Kubernetes 登场的原因。

Kubernetes（简称K8s） 是 Google 在2014年开源的容器编排系统。它的名字很有意思------Kubernetes 希腊语意思是"舵手"，而 K8s 是 Kubernetes 的缩写（k和s之间有8个字母）。

🔥 关键认知 ：K8s 不是替代 Docker 的，而是用来管理 Docker 容器的。Docker 负责"造"容器，K8s 负责"管"容器。

1.2 K8s 的血统

K8s 可不是凭空出现的。它源自 Google 内部一个叫 Borg 的系统------Google 用 Borg 管理了十几年的容器集群，支撑着搜索、Gmail、YouTube 这些超级服务。

所以你可以理解为：K8s 是 Borg 的开源版，凝聚了 Google 十年容器管理的精华。

---

二、K8s 到底能做什么？

很多人（包括刚开始的我）以为 K8s 就是个容器管理工具。其实它提供的是一整套容器化应用的解决方案：

核心能力清单

能力	说明	实际价值
自动化部署	声明式配置，一键部署	告别手动操作，减少人为错误
弹性伸缩	根据CPU/内存自动扩缩容	应对流量高峰，节省资源成本
自我修复	容器挂了自动重启、重新调度	提升系统可用性
服务发现与负载均衡	自动分配IP，流量分发	无需手动配置Nginx
滚动更新	不停机更新版本	零停机发布新版本
资源监控	集成Prometheus、Grafana	可视化集群状态
配置管理	ConfigMap、Secret管理配置	配置与代码分离

---

三、K8s 核心对象：你必须知道的7个概念

K8s 的概念虽然多，但核心就这几个。理解它们的关系，K8s 就入门了一半。

3.1 Pod：最小的部署单元

Pod 是 K8s 中最小的部署单元。你可以把它理解为"容器的容器"。

关键特性：

• 一个 Pod 可以包含一个或多个容器（通常是紧密耦合的）
• Pod 内的容器共享网络命名空间和存储卷
• Pod 是临时性的，不应该被视为持久化的实体

为什么设计 Pod 而不是直接用容器？

想象一下：你有一个 Web 应用和一个日志收集 sidecar。它们需要共享网络（localhost通信）、共享存储（日志文件）。如果用独立的容器，这些会很麻烦。Pod 把它们打包在一起，形成一个逻辑单元。

# Pod 示例
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web
    image: nginx:latest
  - name: logger
    image: fluentd:latest

3.2 Service：稳定的访问入口

Pod 是临时的，IP 地址会变化。那前端怎么稳定地访问后端服务？

Service 就是解决这个问题的。它为一组 Pod 提供一个稳定的访问入口（ClusterIP），并且自动实现负载均衡。

Service 的核心能力：

• 为一组 Pod 提供统一的访问地址
• 通过 Label Selector 选择目标 Pod
• 自动负载均衡流量到后端 Pod

# Service 示例
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app  # 选择带有 app=my-app 标签的 Pod
  ports:
  - port: 80
    targetPort: 8080

⚠️ 踩坑记录：我曾经遇到 Service 创建成功但访问不了的情况。查了半天发现是 selector 和 Pod 的 label 不匹配。K8s 不会报错，只是流量转发不出去。务必检查标签是否一致！

3.3 Deployment：管理应用的生命周期

实际生产中，我们很少直接创建 Pod，而是通过 Deployment 来管理。

Deployment 能做什么：

• 声明式管理 Pod 副本数量
• 支持滚动更新（Rolling Update）
• 支持版本回滚
• 自动维护 ReplicaSet

# Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3  # 保持3个Pod副本
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.0

Deployment vs ReplicaSet vs Pod 的关系：

Deployment (管理)
  └── ReplicaSet (保证副本数)
        └── Pod (实际运行容器)

• Deployment：高层抽象，负责声明式更新
• ReplicaSet：中间层，确保指定数量的 Pod 在运行
• Pod：最底层，实际运行容器

建议：直接用 Deployment，不要手动操作 ReplicaSet 或 Pod。

3.4 StatefulSet：有状态应用的选择

如果你的应用需要稳定的网络标识 （如数据库集群），用 Deployment 就不合适了。这时候需要 StatefulSet。

StatefulSet 的特点：

• Pod 有固定的网络标识（hostname 不变）
• 支持持久化存储
• 有序的部署、扩展、删除
• 适合 MySQL、Redis、Kafka 等有状态服务

# StatefulSet 示例
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

💡 使用建议：无状态应用用 Deployment，有状态应用用 StatefulSet。

3.5 DaemonSet：每个节点一个 Pod

如果你需要在每个节点 上都运行一个 Pod（如日志收集、监控代理），用 DaemonSet。

典型场景：

• 日志收集（Fluentd、Filebeat）
• 监控代理（Node Exporter）
• 网络代理（Calico、Flannel）

# DaemonSet 示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      name: node-exporter
  template:
    metadata:
      labels:
        name: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest

3.6 Job & CronJob：一次性任务

Job 用于运行一次性任务，完成后 Pod 自动退出。

CronJob 用于定时任务，类似 Linux 的 crontab。

# Job 示例
apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing
spec:
  template:
    spec:
      containers:
      - name: processor
        image: data-processor:latest
        command: ["python", "process.py"]
      restartPolicy: Never
  backoffLimit: 4

3.7 Volume：数据持久化

容器是临时的，数据需要持久化保存。Volume 解决了 Pod 内数据的持久化和共享问题。

常用 Volume 类型：

• emptyDir：临时存储，Pod 删除后数据丢失
• hostPath：挂载宿主机目录（不推荐生产环境）
• persistentVolumeClaim (PVC)：持久化存储，数据独立于 Pod 生命周期

# 使用 PVC
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    image: my-app:latest
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: my-pvc

---

四、K8s 架构：Master 和 Node 如何协作

理解完核心对象，再来看看 K8s 的架构设计。

4.1 整体架构

K8s 集群由两类节点组成：

• Master 节点：控制平面，负责集群管理
• Node 节点：工作节点，负责运行应用

4.2 Master 节点：集群的大脑

Master 节点运行着控制平面的核心组件：

API Server

• K8s 的入口，所有操作都通过它
• 提供 RESTful API
• 负责认证、授权、准入控制

🔥 核心地位：无论是 kubectl 命令、还是其他组件通信，都要经过 API Server。它是整个集群的"交通枢纽"。

etcd

• 分布式键值存储数据库
• 保存集群的所有配置和状态数据
• 只有 API Server 能直接访问 etcd

Controller Manager

• 运行各种控制器（Controller）
• 持续监控集群状态，确保实际状态与期望状态一致
• 例如：Deployment Controller、Node Controller、Endpoint Controller

Scheduler

• 负责 Pod 的调度
• 根据资源需求、亲和性/反亲和性等策略，选择合适的 Node
• 如果没有合适的 Node，Pod 会处于 Pending 状态

4.3 Node 节点：工作负载的载体

每个 Node 上运行着：

Kubelet

• Node 上的"代理"
• 接收 API Server 的指令，管理 Pod 生命周期
• 定期向 Master 汇报节点状态

Container Runtime

• 容器运行时（如 Docker、containerd）
• 负责拉取镜像、启动/停止容器

Kube-proxy

• 负责 Service 的网络代理和负载均衡
• 维护节点的 iptables/ipvs 规则

---

五、学习路径建议

如果你刚开始学 K8s，建议按这个顺序：

1. 理解容器基础（Docker）
   ↓
2. 掌握核心概念（Pod、Service、Deployment）
   ↓
3. 学习 kubectl 基本命令
   ↓
4. 实践部署一个应用
   ↓
5. 深入架构原理
   ↓
6. 学习高级特性（网络、存储、调度）

推荐学习资源：

• 官方文档：https://kubernetes.io/zh/docs/
• Katacoda 交互式教程（已并入 O'Reilly）
• 动手实践：Minikube 或 Kind 本地搭建集群

---

六、生产环境检查清单

如果你准备把 K8s 应用到生产环境，别忘了检查这些：

• 集群高可用配置（多 Master）
• 网络策略（NetworkPolicy）
• 资源限制（ResourceQuota、LimitRange）
• 监控告警（Prometheus + Grafana）
• 日志收集（ELK 或 Loki）
• 备份策略（etcd 定期备份）
• 安全策略（RBAC、PodSecurityPolicy）
• 灾难恢复方案

---

七、总结

这篇文章我们聊了 K8s 的核心内容：

1. K8s 是什么：Google 开源的容器编排系统，源自 Borg
2. 核心对象：Pod（最小单元）、Service（访问入口）、Deployment（应用管理）、StatefulSet（有状态）、DaemonSet（守护进程）、Job（任务）、Volume（存储）
3. 架构设计：Master（控制平面）+ Node（工作节点）

关键认知：

• K8s 的设计是声明式的------你告诉它"想要什么"，而不是"怎么做"
• 理解 Pod 和容器的关系是入门的关键
• Service 解决了 Pod 动态 IP 的问题
• Deployment 是管理应用的首选方式

---

你踩过这些坑吗？

1. 刚开始学 K8s 时，哪个概念最让你困惑？Pod 和容器的关系？还是 Service 的工作原理？
2. 你在实际使用 K8s 时遇到过什么坑？欢迎在评论区分享
3. 对于 K8s 的 NetworkPolicy 和存储，你有什么想了解的吗？

---

延伸思考

• 如果集群规模从 10 个节点扩展到 1000 个，K8s 的架构需要做哪些调整？
• 在混合云场景下，K8s 如何管理不同云厂商的资源？
• 你觉得 Serverless（如 Knative）会取代 K8s 吗？

---

求助与交流

如果你对 K8s 入门还有疑问，或者有更好的学习方法，欢迎在评论区交流。

也欢迎分享你踩过的坑，我会整理补充到文章中，帮助更多初学者。

建议收藏关注，持续更新 K8s 系列教程！