第 1/30 天
引言
在云原生时代，Kubernetes（简称 K8s）已经成为容器编排领域的事实标准。无论你是运维工程师、后端开发者还是 SRE，Kubernetes 都是一项绕不开的核心技能。但很多初学者在接触 K8s 时，常常被其庞杂的概念体系所困扰：Pod、Deployment、Service、Namespace……这些名词背后到底代表什么？它们之间如何协同工作？
本文将从零开始，为你构建一个完整的 Kubernetes 知识框架。读完本文，你将理解：
- Kubernetes 是什么，它解决了哪些问题
- 控制平面（Control Plane）和工作节点（Worker Node）各自承担什么角色
- 核心 API 资源对象的关系与功能
- 一次完整的请求如何从外部进入集群并抵达业务容器
Kubernetes 是什么？
Kubernetes（希腊语意为「舵手」或「飞行员」）是由 Google 开源的容器编排平台，于 2014 年首次发布，目前由 Cloud Native Computing Foundation（CNCF）维护。它的核心目标可以概括为一句话：自动部署、扩展和管理容器化应用。
Kubernetes 解决的核心问题
在没有 K8s 之前，我们如何管理容器？
# 传统方式：手动管理单个容器
docker run -d --name my-app -p 8080:80 nginx:latest
# 应用挂了需要手动重启
docker restart my-app
# 流量增大需要手动创建更多副本
docker run -d --name my-app-2 -p 8081:80 nginx:latest
# 然后用 Nginx 手动配置负载均衡……
这种方式的痛点显而易见：
| 问题 | 描述 |
|---|---|
| 单点故障 | 容器挂了不会自动恢复 |
| 手动扩缩 | 流量高峰需要人工介入 |
| 服务发现 | 容器 IP 变化后需要手动更新配置 |
| 滚动更新 | 更新应用时需要中断服务 |
| 资源利用率 | 无法有效调度到最优节点 |
Kubernetes 通过声明式 API 和分布式系统设计，优雅地解决了上述所有问题。
Kubernetes 架构全景
一个标准的 Kubernetes 集群由两大部分组成：控制平面（Control Plane） 和 工作节点（Worker Nodes）。
┌─────────────────────────────────────────────────┐
│ Control Plane │
│ ┌─────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │API Server│ │ Scheduler│ │Controller Manager│ │
│ └────┬────┘ └──────────┘ └──────────────────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ etcd │ (分布式键值存储) │
│ └─────────┘ │
├─────────────────────────────────────────────────┤
│ Worker Node 1 │
│ ┌──────────────┐ ┌───────────────┐ │
│ │ Kubelet │ │ Kube-proxy │ │
│ └──────┬───────┘ └───────┬───────┘ │
│ │ │ │
│ ┌──────▼──────────────────▼───────┐ │
│ │ Pod (容器组) │ Pod (容器组) │ │
│ │ ┌─────┐ ┌───┐ │ ┌────┐ ┌───┐ │ │
│ │ │ ctr1│ │ctr2│ │ │ctr1│ │ctr2│ │ │
│ │ └─────┘ └───┘ │ └────┘ └───┘ │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
1. 控制平面（Control Plane）
控制平面是集群的大脑，负责全局决策和状态管理。
kube-apiserver
所有组件和用户操作的唯一入口。它对外提供 RESTful API，是 Kubernetes 的「前端网关」。
# 一个典型的 API 请求示例：创建 Deployment
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
将这个 YAML 提交给 API Server 后，K8s 会自动创建 3 个 Nginx Pod 并确保它们始终运行。
etcd
etcd 是一个高可用的分布式键值存储，Kubernetes 用它存储所有集群数据（配置、状态、元数据）。etcd 是集群的「数据库」，也是唯一有状态的核心组件。
# 通过 etcdctl 查看集群中存储的 Pod 数据
# 注意：生产环境中不建议直接操作 etcd
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379
--cacert=/etc/kubernetes/pki/etcd/ca.crt
--cert=/etc/kubernetes/pki/etcd/server.crt
--key=/etc/kubernetes/pki/etcd/server.key
get /registry/pods/default/nginx-deployment-xyz
kube-scheduler
调度器负责为新创建的 Pod 选择最合适的节点。调度决策基于以下因素：
- 资源需求（CPU、内存）
- 亲和性/反亲和性规则
- 污点与容忍度
- 节点当前负载
- 数据本地性
kube-controller-manager
控制器管理器运行着多个控制器进程，每个控制器负责维护集群的某种期望状态：
# 常见的控制器及其职责
controllers:
- name: "Deployment Controller"
responsibility: "确保 Deployment 的期望副本数与实际副本数一致"
- name: "Node Controller"
responsibility: "监控节点健康状态，响应节点故障"
- name: "ReplicaSet Controller"
responsibility: "维护指定数量的 Pod 副本"
- name: "Endpoint Controller"
responsibility: "维护 Service 与 Pod 的映射关系"
- name: "Namespace Controller"
responsibility: "管理命名空间的生命周期"
2. 工作节点（Worker Node）
工作节点是实际运行业务容器的机器。
kubelet
kubelet 是运行在每个节点上的「节点头号代理」，它负责：
- 接收 API Server 下发的 Pod 规范
- 确保 Pod 中的容器按规范运行
- 定期向 API Server 汇报节点和 Pod 状态
- 执行存活探针（Liveness Probe）和就绪探针（Readiness Probe）
# 查看 kubelet 日志
journalctl -u kubelet -f --no-pager
# 查看节点状态
kubectl get nodes
kubectl describe node worker-1
kube-proxy
kube-proxy 是每个节点上的网络代理，负责实现 Service 的虚拟 IP 路由和负载均衡。它支持三种模式：
# 查看当前 kube-proxy 模式（iptables / IPVS / userspace）
kubectl get configmap kube-proxy -n kube-system -o yaml
| grep -A5 "mode:"
在 iptables 模式下，kube-proxy 会在每个节点上创建 iptables 规则：
# 查看 K8s 创建的 iptables 规则
iptables-save | grep KUBE-SERVICES
# 输出示例（简化）
# -A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 443 -j KUBE-SVC-NGINX
# -A KUBE-SERVICES -d 10.96.0.10/32 -p tcp --dport 53 -j KUBE-SVC-COREDNS
容器运行时（Container Runtime）
Kubernetes 通过 CRI（Container Runtime Interface）与容器运行时交互。常见的运行时包括：
- containerd：最常用的生产级运行时，Docker 的底层引擎
- CRI-O：专为 Kubernetes 优化的轻量级运行时
- Docker（已弃用）：K8s 1.24+ 已移除 dockershim
核心 API 资源对象
Kubernetes 的资源对象体系可以用一个简单的层次结构来理解：
# 集群层级（作用于整个集群）
# - Node : 集群中的物理/虚拟机
# - Namespace : 虚拟集群划分
# - ClusterRole : 集群级别的权限
#
# 命名空间层级（作用于特定 Namespace）
# - Pod : 最小的部署单元
# - Service : 稳定的网络访问入口
# - Deployment : 声明式应用管理
# - ConfigMap : 非敏感配置
# - Secret : 敏感信息（密码、证书）
#
# 存储层级
# - PersistentVolume : 存储资源
# - PersistentVolumeClaim : 存储请求
# - StorageClass : 动态存储供给
#
# 网络层级
# - Ingress : 七层流量接入
# - NetworkPolicy : 网络安全策略
Pod：最小的调度单元
Pod 是 Kubernetes 中最小、最基本的部署单元。一个 Pod 包含一个或多个容器，这些容器共享网络命名空间和存储卷。
# 一个最简单的 Pod 定义
apiVersion: v1
kind: Pod
metadata:
name: my-app
labels:
app: my-app
env: production
spec:
containers:
- name: app
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /healthz
port: 80
initialDelaySeconds: 3
periodSeconds: 5
关键特性：
– Pod 是逻辑主机，所有容器共享 IP 和端口空间
– Pod 是临时性的，IP 会在重建后改变
– 永远不要直接创建 Pod，而是通过 Deployment 等上层控制器管理
Service：稳定的网络端点
由于 Pod 是动态创建和销毁的（IP 会变），Service 提供了一个稳定的虚拟 IP 和 DNS 名称来访问一组 Pod。
# ClusterIP 类型的 Service（默认）
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx # 选择具有此标签的 Pod
ports:
- protocol: TCP
port: 80 # Service 端口
targetPort: 80 # Pod 容器端口
type: ClusterIP # 仅在集群内部可达
Service 的类型：
| 类型 | 访问方式 | 适用场景 |
|---|---|---|
| ClusterIP | 集群内虚拟 IP | 内部服务通信 |
| NodePort | 节点 IP + 端口 | 外部调试/测试 |
| LoadBalancer | 云负载均衡器 IP | 生产环境对外暴露 |
| ExternalName | DNS CNAME | 引入集群外部服务 |
Deployment：声明式应用管理
Deployment 是 Kubernetes 中最常用的工作负载控制器。它通过管理 ReplicaSet 来实现 Pod 的声明式更新和回滚。
# 创建 Deployment
kubectl create deployment nginx --image=nginx:1.25 --replicas=3
# 滚动更新（将 nginx 版本升级到 1.26）
kubectl set image deployment/nginx nginx=nginx:1.26
# 查看更新状态
kubectl rollout status deployment/nginx
# 如果更新出问题，回滚到上一个版本
kubectl rollout undo deployment/nginx
一次完整的请求流
理解了各个组件后，让我们追踪一次完整的 API 请求流程——当你执行 kubectl apply -f deployment.yaml 时，后台发生了什么：
1. kubectl 将 YAML 发送给 kube-apiserver
│
2. API Server 验证请求 → 存储到 etcd
│
3. Controller Manager 中的 Deployment Controller
检测到新的 Deployment 资源 → 创建 ReplicaSet
│
4. ReplicaSet Controller 检测到期望副本数与实际不符
→ 创建新的 Pod 对象（写入 etcd）
│
5. Scheduler 监听到未调度的 Pod
→ 根据策略选择最佳节点 → 将调度信息写回 etcd
│
6. 目标节点上的 kubelet 监听到自己被分配了 Pod
→ 调用容器运行时（containerd）拉取镜像并启动容器
│
7. kubelet 持续监控容器健康状态
→ 向 API Server 汇报状态
整个过程由控制器循环驱动，是一种典型的 Reconciliation Loop（调谐循环） 模式：
# 控制器调谐循环的伪代码
while true:
desired_state = read_from_etcd() # 期望状态
actual_state = observe_cluster() # 当前状态
if desired_state != actual_state:
actions = compute_diff(desired_state, actual_state)
for action in actions:
execute(action) # 执行变更
else:
sleep(reconciliation_interval) # 等待下次调谐
常见问题 FAQ
Q1：Kubernetes 和 Docker 是什么关系？
Docker 是容器引擎（创建、运行单个容器），Kubernetes 是容器编排平台（管理成百上千的容器）。从 K8s 1.24+ 开始，K8s 不再直接支持 Docker 作为运行时，改用 containerd。
Q2：学习 K8s 需要先学 Docker 吗？
建议学。理解 Docker 的核心概念（镜像、容器、数据卷、网络模式）是学习 K8s 的良好基础。
Q3：生产环境需要多少个节点？
最小生产集群建议 3 个 Control Plane 节点 + 2 个 Worker 节点，实现高可用。
Q4：Kubernetes 和云原生有什么关系？
云原生是一种构建和运行应用的方法论，Kubernetes 是云原生生态的核心基础设施。你可以把 K8s 看作云原生时代的「操作系统内核」。
总结
本文从宏观到微观，为你剖析了 Kubernetes 的架构和核心概念：
| 概念 | 一句话总结 |
|---|---|
| API Server | 集群的「前端网关」，所有操作唯一入口 |
| etcd | 集群的「数据库」，存储所有状态数据 |
| Scheduler | 「调度员」，为 Pod 选择最合适的节点 |
| Controller Manager | 「监工」，确保集群状态与期望一致 |
| Kubelet | 节点上的「代理人」，管理本地容器 |
| Kube-proxy | 节点上的「网络工程师」，实现 Service 路由 |
| Pod | 最小的部署单元，一个或多个容器的组合 |
| Service | 稳定的访问入口，屏蔽 Pod IP 变化 |
| Deployment | 声明式的应用管理，支持滚动更新和回滚 |
Kubernetes 的设计哲学是——声明期望状态，系统自动完成剩余工作。你只需要告诉 K8s「我要跑 3 个 Nginx 容器，对外暴露 80 端口」，剩下的调度、健康检查、负载均衡、滚动更新，全部交给平台自动完成。
下期预告
第 2 天：手把手搭建你的第一个 K8s 集群（kubeadm 实战）
我们将使用 kubeadm 工具，从零开始搭建一个生产级可用的三节点 Kubernetes 集群，涵盖环境准备、容器运行时安装、控制平面初始化、工作节点加入、网络插件部署全过程。跟着动手操作一遍，你就能拥有一个属于自己的可运行 K8s 集群。
📚 K8s 系列目录（持续更新中）
| 天数 | 标题 | 状态 |
|---|---|---|
| 第 1 天 | Kubernetes 是什么？核心概念与架构全景解析 | ✅ 本文 |
| 第 2 天 | 手把手搭建你的第一个 K8s 集群 | 🔜 即将发布 |
| 第 3 天 | Pod 详解：最小的调度单元与生命周期管理 | 🔜 即将发布 |
| … | 更多内容敬请期待 |
标签：Kubernetes K8s系列 DevOps 容器编排 云原生 架构解析
暂无评论内容