Easy-Vibe 云原生基础：Kubernetes 编排原理与 kubectl 实战指南-育师

Easy-Vibe 云原生基础：Kubernetes 编排原理与 kubectl 实战指南

【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding，项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe

导读

在 Easy-Vibe 的云计算与基础设施章节中，Docker 解决了"打包"问题，而 Kubernetes（K8s）解决的是"管理"问题——当你的服务需要数十上百个容器副本同时运行、自动扩缩容、故障自愈时，人工管理已完全不现实。本文以 K8s 编排原理为主线，系统讲解控制平面与工作节点的架构分层、Pod/Deployment/Service 等核心资源对象、"声明期望状态、系统自动收敛"的声明式管理哲学，并给出基于 kubectl 与 YAML 的滚动更新、HPA 自动扩缩容与健康探针等生产级运维实操，帮助你在完成本篇后具备独立部署与管理一个完整应用的能力。

1. 为什么需要 Kubernetes：容器编排的挑战

Docker 让"打包并运行单个容器"变得非常简单，但当业务演进到以下场景时，手工管理立刻失效：

挑战	描述	K8s 的解决方案
多副本部署	一个服务需要同时运行 10 个副本	Deployment 自动管理副本数量
故障自愈	容器崩溃后需要自动重启	控制器自动检测并重建 Pod
服务发现	容器 IP 会变化，服务之间如何找到彼此？	Service 提供稳定的 DNS 与虚拟 IP
滚动更新	更新版本时不能停服	逐步替换旧 Pod，做到零停机
弹性伸缩	流量高峰时自动扩容	HPA 依据 CPU/内存等指标自动调整副本数
资源调度	把容器放到最合适的机器上	Scheduler 智能调度

K8s 核心思想：声明式（Declarative）你不需要告诉 K8s"给我启动 3 个容器"（命令式），而是告诉它"我希望有 3 个副本在运行"（声明式）。K8s 会持续监控，确保实际状态与你的期望状态一致。一旦某个 Pod 崩溃，它会自动新建一个来补齐。

从 Easy-Vibe 自身的技术栈看，这一章节与 docker-containers.md 中讲解的镜像、容器、Registry 概念一脉相承：Docker 解决"单容器如何跑起来"，K8s 则解决"大量容器如何被编排"。仓库根目录的 Dockerfile 就是一个典型的容器化范例——它采用多阶段构建，先用node:20-alpine编译 VitePress 文档站，再用nginx:alpine提供静态文件服务，这种"构建产物与运行环境分离"的思路正是云原生交付的基础。

2. Kubernetes 架构：控制平面与工作节点

一个 K8s 集群由两部分组成：控制平面（Control Plane）与工作节点（Worker Node）。

控制平面：集群的"大脑"，负责做出全局决策（调度、副本管理、故障检测），核心组件包括 kube-apiserver（所有 API 请求的入口）、kube-scheduler（把 Pod 调度到合适的节点）、kube-controller-manager（运行各类控制器）、etcd（保存集群全部状态）。
工作节点：集群的"手脚"，负责真正运行容器，核心组件包括 kubelet（与 apiserver 通信、管理节点上的 Pod）、kube-proxy（维护网络规则、实现 Service 流量转发）、容器运行时（如 containerd）。

请求的完整路径

用户请求 → Ingress Controller → Service → kube-proxy → Pod（容器） ↑ Endpoint 列表（由 Service 维护）

Ingress 是集群对外的流量入口，Service 提供稳定的服务发现抽象，kube-proxy 依据 Service 维护的 Endpoint 列表把请求转发到具体的 Pod。容器 IP 再怎么漂移，Service 的名字和虚拟 IP 始终不变，这正是解决"服务发现"问题的关键。

3. 核心资源对象

K8s 通过各种各样的"资源对象"来描述集群的期望状态，它们是 YAML 清单中的apiVersion、kind与metadata的具体化。按用途可以划分为五大类：

类别	资源	用途
工作负载	Pod、Deployment、StatefulSet、DaemonSet、Job	运行应用
网络	Service、Ingress、NetworkPolicy	服务发现与流量管理
配置	ConfigMap、Secret	配置管理与敏感数据
存储	PersistentVolume、PersistentVolumeClaim	持久化存储
调度与隔离	Node、Namespace、ResourceQuota	资源隔离与限额

其中最关键的是四件套：

Pod：K8s 中最小的部署单元，一个或多个容器的组合，共享网络与存储；
Deployment：管理无状态应用的副本数，负责滚动更新与回滚；
Service：为一组 Pod 提供稳定的访问入口（DNS 与虚拟 IP）；
Ingress：集群外部流量进入集群的统一网关，可按域名/路径路由。

4. 声明式管理与 kubectl 实战

4.1 调谐循环（Reconciliation Loop）

K8s 的核心工作机制是一个不断循环的调谐过程：

观察（Observe） → 比对（Diff） → 执行（Act） → 再观察... ↓ ↓ ↓ 读取实际状态 与期望状态比对 执行修正动作

例如你声明了replicas: 3，控制器发现当前只有 2 个 Pod 在运行，就会新建 1 个补齐。这个循环每隔几秒执行一次，保证系统始终向期望状态收敛。这与 Easy-Vibe 部署体系中"声明配置、系统自动趋同"的理念一致——vercel.json 用声明式的buildCommand、outputDirectory描述构建期望，ms_deploy.json 则声明了魔搭创空间的运行资源与端口，平台据此自动完成部署。

4.2 常用 kubectl 命令速查

命令	功能	示例
`kubectl apply -f`	应用 YAML 配置	`kubectl apply -f deployment.yaml`
`kubectl get`	查看资源列表	`kubectl get pods -o wide`
`kubectl describe`	查看资源详情	`kubectl describe pod my-app-xxx`
`kubectl logs`	查看 Pod 日志	`kubectl logs -f my-app-xxx`
`kubectl exec`	进入 Pod 终端	`kubectl exec -it my-app-xxx -- sh`
`kubectl delete`	删除资源	`kubectl delete -f deployment.yaml`
`kubectl scale`	手动扩缩容	`kubectl scale deploy my-app --replicas=5`

apply 与 create 的区别kubectl create是命令式的——"创建这个资源"，如果资源已存在会直接报错。kubectl apply是声明式的——"确保资源处于此状态"，不存在则创建、已存在则更新。生产环境应始终使用apply，这也是 Kubernetes 声明式哲学的日常体现。

5. 运维实战：滚动更新、HPA 与健康探针

5.1 滚动更新与回滚

Deployment 默认采用滚动更新（RollingUpdate）策略：一边逐步创建新版本 Pod，一边逐步终止旧版本 Pod，整个过程对用户无感知。通过strategy字段可以精细控制节奏：

spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 最多允许额外创建 1 个 Pod maxUnavailable: 0 # 不允许任何 Pod 处于不可用状态

日常发布与回滚操作：

操作	命令
更新镜像	`kubectl set image deploy/my-app app=my-app:2.0`
查看更新状态	`kubectl rollout status deploy/my-app`
查看发布历史	`kubectl rollout history deploy/my-app`
回滚到上一版本	`kubectl rollout undo deploy/my-app`

以 Easy-Vibe 为例，其 Dockerfile 产出的镜像就是可以被kubectl set image平滑替换的"新版本"——先构建新镜像推送到镜像仓库，再执行一条kubectl set image即可完成一次零停机的版本升级。

5.2 水平自动扩缩容（HPA）

HPA（Horizontal Pod Autoscaler）根据 CPU、内存或自定义指标自动调整 Pod 副本数，解决流量高峰的弹性扩容问题：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

当 Deployment 的 CPU 平均利用率超过 70% 时，HPA 会在 2～10 副本之间自动扩容；压力回落后再自动缩容。这与 cloud-platforms.md 中"按需付费、弹性伸缩"的云原生理念一脉相承，也是云上资源成本控制的关键手段。

5.3 健康探针（Probe）

K8s 通过三种探针持续监控 Pod 的健康状态：

探针	作用	失败后果
livenessProbe	检测容器是否存活	重启容器
readinessProbe	检测容器是否就绪	从 Service 摘除，不再接收流量
startupProbe	检测容器是否完成启动	启动期间不执行其他探针

探针的重要性如果不配置健康探针，K8s 只能通过"进程是否存在"判断健康。但很多时候进程还活着、服务却已无法响应（例如死锁、濒临 OOM）。配置 livenessProbe 能让 K8s 自动重启这些"假死"容器，这是生产环境故障自愈的第一道防线。在服务刚启动慢的场景下，还应配合 startupProbe，避免启动阶段被误判为不健康而反复重启。