Kubernetes v1.35 入门完整学习笔记（基于官方基础教程）

本文整合 Kubernetes 官方中文基础教程核心内容，以 v1.35 稳定版为基准，从环境搭建到应用运维，完整覆盖入门全流程，兼顾概念讲解与实操落地，适合零基础学习者系统掌握 K8s 基础能力。

前置篇：Kubernetes v1.35 学习环境搭建——Minikube 快速上手

一、学习目标

• 在本地快速搭建一个单节点 Kubernetes v1.35 实验集群
• 安装并配置与集群版本匹配的 kubectl 命令行工具
• 掌握集群启动、停止、检查状态等最基础运维操作
• 为后续所有 Kubernetes 入门实操提供稳定、可复现的环境

二、环境要求

2.1 硬件最低要求

CPU：至少 2 核；内存：至少 2GB；磁盘：20GB 以上空闲空间；支持虚拟化（Intel VT-x / AMD-V）并在 BIOS 中开启。

2.2 操作系统支持

Windows 10/11（WSL2 或 Hyper-V）、macOS（Intel / Apple Silicon 均支持）、Linux（Ubuntu、CentOS、Rocky Linux 等主流发行版）。

2.3 必须依赖

容器/虚拟化环境（二选一即可）：Docker / Docker Desktop、Hyper-V（Windows）、QEMU / KVM（Linux）、HyperKit（macOS）。

三、安装 Minikube

Minikube 是官方推荐的本地 Kubernetes 运行工具，可一键拉起单节点集群。

3.1 Linux 安装（以 x86_64 为例）

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

3.2 macOS 安装

# Intel
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
sudo install minikube-darwin-amd64 /usr/local/bin/minikube
​
# Apple Silicon(M1/M2/M3)
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-arm64
sudo install minikube-darwin-arm64 /usr/local/bin/minikube

3.3 Windows 安装

New-Item -Path 'C:\minikube' -ItemType Directory -Force
Invoke-WebRequest -OutFile 'C:\minikube\minikube.exe' -Uri 'https://storage.googleapis.com/minikube/releases/latest/minikube-windows-amd64.exe' -UseBasicParsing

然后将 C:\minikube 加入系统 PATH。

四、安装 kubectl v1.35

kubectl 是 Kubernetes 命令行客户端，建议版本与集群严格对齐 v1.35。

4.1 Linux 安装 kubectl v1.35

curl -LO "https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

4.2 macOS 安装

curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

4.3 Windows 安装

curl.exe -LO "https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe"

放入 C:\minikube 目录并加入 PATH。

4.4 验证版本

kubectl version --client

应输出：Client Version: v1.35.0

五、启动 Kubernetes v1.35 集群

5.1 指定版本启动（关键步骤）

Minikube 默认会拉最新版，我们强制指定 v1.35.0：

minikube start --kubernetes-version=v1.35.0 --driver=docker

--driver=docker：使用 Docker 作为运行环境（最通用）；--kubernetes-version=v1.35.0：精确锁定集群版本。

启动成功后会看到类似输出：Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

5.2 常见启动问题

• 提示虚拟化未开启：进 BIOS 开启 VT-x / AMD-V
• Windows 推荐优先使用 WSL2 + Docker
• Linux 提示权限不足：将当前用户加入 docker 组

sudo usermod -aG docker $USER && newgrp docker

六、验证集群状态

6.1 检查集群信息

kubectl cluster-info

输出应包含：Kubernetes control plane、CoreDNS，地址均为 minikube 本地地址。

6.2 查看节点状态

kubectl get nodes

理想状态：

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10m   v1.35.0

STATUS=Ready、VERSION=v1.35.0 说明环境完全就绪。

6.3 查看集群组件

kubectl get pods -n kube-system

所有 Pod 均应为 Running。

七、Minikube 常用基础命令

# 停止集群
minikube stop
​
# 再次启动（无需重新指定版本）
minikube start
​
# 删除集群（彻底重置）
minikube delete
​
# 打开 Kubernetes 面板
minikube dashboard
​
# 查看 Minikube 状态
minikube status

八、环境验证小实验

执行一个最简单的 Nginx 部署，确认环境可用：

kubectl create deployment nginx-test --image=nginx
# 查看 Pod
kubectl get pods

出现 Running 即表示 Kubernetes v1.35 环境搭建完成，可以进入正式学习。

第一篇：Kubernetes v1.35 核心认知与集群架构入门

一、学习目标

• 理解 Kubernetes 到底解决什么问题，为什么容器时代必须用编排工具
• 掌握 Kubernetes v1.35 集群的整体架构与核心组件作用
• 认识 Pod、Deployment、Service 三大核心入门资源
• 熟练使用 kubectl 完成最基础的集群查看操作
• 为后续部署应用、扩容、更新、发布打下概念基础

二、什么是 Kubernetes？为什么需要它？

2.1 从容器到容器编排

• 单个 Docker 容器：解决“应用打包、环境一致”问题
• 多个容器、多台机器：出现调度、自愈、扩缩容、网络、服务发现、升级回滚等难题

Kubernetes（简称 K8s）就是用来自动化管理容器化应用的平台，是云原生时代的操作系统。

2.2 Kubernetes 核心能力（v1.35 通用）

服务发现与负载均衡、容器编排与调度、自愈（重启、重建、替换异常容器）、自动扩缩容、滚动更新与回滚、密钥与配置管理、存储编排。

2.3 Kubernetes v1.35 版本说明

• v1.35 是 Kubernetes 标准正式版，API 稳定
• 核心资源（Pod/Deployment/Service/ConfigMap 等）API 无破坏性变更
• 对容器运行时（containerd、CRI-O）、网络、安全能力持续优化
• 完全兼容官方基础教程中的所有入门示例

三、Kubernetes v1.35 集群架构

一个标准 K8s 集群分为两部分：控制平面（Master） + 工作节点（Node）

3.1 控制平面（Control Plane）

负责整个集群的决策与管理，相当于“大脑”。在 Minikube 中，控制平面和节点在同一台机器上。

核心组件

0. kube-apiserver：集群唯一入口，所有操作（kubectl、UI、组件）都通过它交互，负责认证、授权、访问控制。
1. etcd：键值存储数据库，保存集群所有配置、状态、元数据，必须高可用。
2. kube-controller-manager：运行各种控制器（节点、副本、端点、服务账号等），确保实际状态 = 期望状态。
3. kube-scheduler：监视新创建的 Pod，根据资源、策略、亲和性等选择节点运行。
4. cloud-controller-manager（可选）：与云厂商 API 交互，负载均衡、路由、存储卷等云资源对接。

3.2 工作节点（Worker Node）

运行实际容器和业务负载，相当于“工人”。

核心组件

0. kubelet：节点上的代理，与 apiserver 通信，管理本机 Pod，确保容器正常运行。
1. kube-proxy：维护节点网络规则，实现 Service 的负载均衡与转发。
2. 容器运行时（Container Runtime） ：负责运行容器，v1.35 主流：containerd（推荐）、CRI-O，不再支持 Docker 原生（通过 cri-dockerd 兼容）。
3. Pod：K8s 最小调度单元，一个 Pod 包含一个或多个紧密相关的容器。

3.3 架构整体流程（极简理解）

0. 你通过 kubectl 向 apiserver 发送指令
1. apiserver 把期望状态存入 etcd
2. scheduler 挑选合适节点
3. kubelet 在节点上启动 Pod
4. controller-manager 持续保证状态一致

四、Kubernetes 核心概念（入门必懂 4 个）

0. Pod：最小部署单元，不是容器；一个 Pod 可以包含多个容器（共享网络、存储）；有短暂生命周期，IP 不固定；不能直接管理，一般用 Deployment 管理。
1. Deployment：用来管理无状态应用最常用资源；控制 Pod 副本数量；支持滚动更新、版本回滚；自动自愈：挂掉就重建。
2. Service：为一组 Pod 提供固定访问入口；解决 Pod IP 漂移问题；提供负载均衡；常见类型：ClusterIP、NodePort、LoadBalancer。
3. Namespace：集群虚拟隔离；用于多环境、多团队区分；默认：default、kube-system、kube-public 等。

五、kubectl 基础操作（v1.35 通用）

# 查看集群信息
kubectl cluster-info
​
# 查看节点
kubectl get nodes
​
# 查看命名空间
kubectl get ns
​
# 查看集群组件 Pod
kubectl get pods -n kube-system
​
# 查看资源详细信息
kubectl describe node minikube
​
# 查看 kubectl 版本
kubectl version --short

六、集群组件快速验证（判断集群是否健康）

0. 节点状态必须是 Ready
1. kube-system 下所有 Pod 为 Running
2. 能够正常执行 kubectl run 临时创建容器

简单测试：

kubectl run test-nginx --image=nginx --restart=Never
kubectl get pods
kubectl delete pod test-nginx

能正常创建删除，说明集群可用。

第二篇：Kubernetes v1.35 部署第一个应用（Deployment）

一、学习目标

• 理解 Deployment 在 Kubernetes 中的作用
• 学会使用 kubectl create deployment 快速部署应用
• 学会编写并使用 YAML 文件部署应用（v1.35 标准格式）
• 掌握查看 Deployment、ReplicaSet、Pod 状态的方法
• 理解“期望状态”与“实际状态”的自愈机制

二、前置环境确认

确保你的 minikube 集群已经启动且版本为 v1.35：

minikube status
kubectl get nodes

节点状态为 Ready 且版本为 v1.35.0 即可继续。

三、Deployment 是什么？为什么用它？

3.1 核心作用

Deployment 是 Kubernetes 中最常用、最推荐的部署无状态应用的资源对象；负责管理 Pod 的创建、副本数量、更新、回滚、自愈；不直接管理 Pod，而是通过管理 ReplicaSet 间接管理 Pod。

3.2 简单理解

• Pod：集装箱
• ReplicaSet：保证一定数量的集装箱在运行
• Deployment：管理这批集装箱的“大管家”，支持升级、回滚

3.3 v1.35 版本说明

Deployment 的 API 版本依然是 apps/v1，无任何破坏性变更，完全兼容旧版写法。

四、方式一：命令行快速部署（适合测试）

我们以官方示例镜像 k8s.gcr.io/echoserver 或国内可拉取的 nginx 为例。

4.1 创建 Deployment

kubectl create deployment web-server --image=nginx

web-server：Deployment 名称；--image=nginx：使用 nginx 官方镜像。

4.2 查看 Deployment

kubectl get deployments
# 简写
kubectl get deploy

正常输出：

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
web-server   1/1     1            1           30s

字段说明：READY：当前就绪副本数 / 期望副本数；UP-TO-DATE：已更新到最新版本的副本数；AVAILABLE：可对外提供服务的副本数。

4.3 查看 ReplicaSet

kubectl get replicasets
# 简写
kubectl get rs

4.4 查看 Pod

kubectl get pods

你会看到类似：

NAME                          READY   STATUS    RESTARTS   AGE
web-server-79f474645c-2bljz   1/1     Running   0          60s

Running 说明应用已正常运行；名称中随机字符串是 ReplicaSet 自动生成的。

五、方式二：YAML 文件部署（生产标准方式）

v1.35 标准 Deployment YAML 模板如下，可直接复制使用。

5.1 编写 deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  # 副本数量
  replicas: 1
  # 标签选择器，必须匹配 template 中的标签
  selector:
    matchLabels:
      app: web-server
  # Pod 模板
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

5.2 应用 YAML 部署

kubectl apply -f deployment.yaml

5.3 对比命令行部署

• kubectl create：适合快速测试
• kubectl apply -f：适合版本管理、CI/CD、生产环境（推荐）

六、查看应用详情与日志

6.1 查看 Deployment 详细描述

kubectl describe deployment web-server

可以看到：创建时间、事件（Events）：调度、拉取镜像、启动容器记录、副本状态、标签与注解。

6.2 查看 Pod 日志

# 先获取 Pod 名称
kubectl get pods
# 查看日志
kubectl logs web-server-xxxx-xxxx

6.3 进入容器内部（可选）

kubectl exec -it web-server-xxxx-xxxx -- /bin/bash

七、验证 Deployment 自愈能力（核心特性）

7.1 删除 Pod

kubectl delete pod web-server-xxxx-xxxx

7.2 立即查看 Pod

kubectl get pods

你会发现：旧 Pod 被删除；自动新建了一个新名称的 Pod；副本数始终保持为 1。这就是 Kubernetes 的自愈能力，由 Deployment + ReplicaSet 保证。

八、扩容与缩容（基础演示）

# 扩容到 3 个副本
kubectl scale deployment web-server --replicas=3
​
# 查看结果
kubectl get pods
​
# 缩容回 1 个副本
kubectl scale deployment web-server --replicas=1

九、清理环境（为下一章做准备）

kubectl delete deployment web-server
# 或
kubectl delete -f deployment.yaml

第三篇：Kubernetes v1.35 使用 Service 暴露应用（ClusterIP / NodePort）

一、学习目标

• 理解为什么 Pod 不能直接对外提供访问（IP 会变、会重建）
• 掌握 Service 的作用与核心原理
• 学会创建并使用 ClusterIP（集群内部访问）
• 学会创建并使用 NodePort（集群外部访问）
• 熟练使用 kubectl 查看、访问、管理 Service
• 在 Minikube 中完成完整访问验证

二、前置环境准备

先部署一个用于测试的 Nginx 应用（沿用第二篇内容）：

kubectl create deployment web-server --image=nginx

查看 Pod 确保运行：

kubectl get pods

三、为什么需要 Service？

0. Pod IP 不固定：Pod 重建、重启、扩容后 IP 会变
1. 多个副本需要统一入口：不能每次都去访问不同 Pod IP
2. 需要负载均衡：流量自动分发到多个 Pod
3. 需要跨节点访问：集群内任意节点都能访问同一服务

Service = 固定 IP + 负载均衡 + 服务发现

在 Kubernetes v1.35 中：Service API 版本仍然是 v1，无 breaking change；核心类型：ClusterIP、NodePort、LoadBalancer、ExternalName 不变。

四、Service 常用类型说明

类型	作用范围	适用场景
ClusterIP	仅集群内部可访问	微服务之间调用
NodePort	集群外部可访问	本地测试、对外简单暴露
LoadBalancer	公网访问	云厂商环境使用
ExternalName	映射外部域名	调用外部服务
本章重点：ClusterIP + NodePort

五、第一种：ClusterIP（集群内访问）

ClusterIP 是默认类型，会分配一个集群内部固定虚拟 IP，只能在集群内访问。

5.1 创建 Service

kubectl expose deployment web-server \
  --type=ClusterIP \
  --port=80 \
  --target-port=80

说明：--port=80：Service 自身端口；--target-port=80：Pod 内部容器端口。

5.2 查看 Service

kubectl get svc
# 或完整写法
kubectl get services

典型输出：

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
web-server    ClusterIP   10.96.123.111   <none>        80/TCP    30s

5.3 集群内访问验证

kubectl run -it --rm test-curl --image=curlimages/curl -- sh

在容器内执行：

curl http://web-server
# 或使用 ClusterIP
curl http://10.96.123.111

能看到 Nginx 默认页面即成功。

六、第二种：NodePort（集群外部访问）

NodePort 在每个节点开放一个端口（30000–32767），外部可通过 节点IP:NodePort 访问。

6.1 先删除旧 Service（避免冲突）

kubectl delete svc web-server

6.2 创建 NodePort 类型 Service

kubectl expose deployment web-server \
  --type=NodePort \
  --port=80 \
  --target-port=80

6.3 查看 Service

kubectl get svc

输出示例：

NAME          TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
web-server    NodePort   10.96.210.25    <none>        80:30088/TCP   20s

30088 是自动分配的 NodePort

6.4 Minikube 环境快速访问

Minikube 提供一键打开浏览器访问服务：

minikube service web-server

会自动打开浏览器并访问 节点IP:NodePort。

6.5 手动获取访问地址

minikube ip
# 得到节点 IP，例如 192.168.49.2

访问地址：http://192.168.49.2:30088

七、使用 YAML 创建 Service（标准方式）

v1.35 标准 Service YAML：

apiVersion: v1
kind: Service
metadata:
  name: web-server
spec:
  type: NodePort
  selector:
    app: web-server   # 必须与 Pod 标签一致
  ports:
  - port: 80          # Service 端口
    targetPort: 80    # Pod 端口
    nodePort: 30123   # 可选，手动指定端口

应用：

kubectl apply -f service.yaml

八、查看 Service 关联的 Pod

kubectl describe svc web-server

查看 Endpoints 部分，可以看到所有被负载均衡的 Pod IP:端口。

也可以直接查看 endpoints：

kubectl get endpoints web-server

九、验证负载均衡

1. 扩容副本：
kubectl scale deploy web-server --replicas=3
​
2. 多次访问服务：
minikube service web-server

流量会自动轮询分发到 3 个 Pod。

十、清理环境（为下一章准备）

kubectl delete svc web-server
kubectl delete deploy web-server

第四篇：Kubernetes v1.35 应用扩缩容与副本管理

一、学习目标

• 理解副本（Replica）的作用与高可用原理
• 掌握 kubectl scale 手动扩缩容应用
• 理解 Deployment、ReplicaSet、Pod 三者在扩缩容中的关系
• 观察扩缩容过程中 Pod 的创建与销毁
• 验证多副本下的负载均衡与自愈能力
• 了解 v1.35 中 HPA 自动扩缩容的基础概念

二、前置环境准备

先重新部署应用并创建 Service，方便后续验证：

# 部署应用
kubectl create deployment web-server --image=nginx
​
# 暴露服务（方便后续测试负载均衡）
kubectl expose deployment web-server --type=NodePort --port=80

查看状态：

kubectl get pods
kubectl get deploy
kubectl get svc

确保所有 Pod 均为 Running。

三、为什么需要扩缩容？

• 业务高峰期流量大，需要增加副本提高并发能力
• 低谷期资源闲置，需要减少副本节约资源
• 多副本可以实现高可用，单个 Pod 挂掉不影响服务
• Kubernetes 通过 ReplicaSet 保证副本数量始终符合期望

在 v1.35 中：扩缩容逻辑无变化，稳定兼容；副本调度、负载均衡策略与旧版本一致。

四、核心概念梳理

0. Pod：最小运行单元
1. ReplicaSet：负责维持固定数量的 Pod 副本
2. Deployment：管理 ReplicaSet，提供扩缩容、更新、回滚能力
3. 期望状态 vs 实际状态：你告诉 K8s：我要 3 个副本；K8s 自动检查并保证始终运行 3 个

五、手动扩容（Scale Up）

5.1 查看当前副本数

kubectl get deploy

默认是 READY 1/1。

5.2 扩容到 3 副本

kubectl scale deployment web-server --replicas=3

5.3 观察 Pod 变化

kubectl get pods -w

会看到：立即新增 2 个 Pod；状态从 ContainerCreating → Running。

最终结果：

NAME                          READY   STATUS    RESTARTS   AGE
web-server-79f474645c-2bljz   1/1     Running   0          5m
web-server-79f474645c-f9j7z   1/1     Running   0          20s
web-server-79f474645c-xhz8g   1/1     Running   0          20s

5.4 查看 Deployment 状态

kubectl get deploy

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
web-server   3/3     3            3           5m

六、手动缩容（Scale Down）

6.1 缩容到 1 个副本

kubectl scale deployment web-server --replicas=1

6.2 观察 Pod 销毁

kubectl get pods -w

会看到多余副本被优雅终止（Terminating）。

七、通过 YAML 文件实现扩缩容（生产推荐）

编辑 deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3    # 直接修改这个数字
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

应用变更：

kubectl apply -f deployment.yaml

K8s 会自动调整到目标副本数。

八、验证多副本负载均衡

8.1 获取访问地址

minikube service web-server --url

示例输出：http://192.168.49.2:30088

8.2 多次访问

curl http://192.168.49.2:30088

流量会被 kube-proxy 自动轮询分发到不同 Pod。

8.3 查看 Endpoints

kubectl get endpoints web-server

会显示多个 Pod IP:端口，代表负载均衡列表。

九、验证副本自愈能力（重要）

9.1 手动删除一个 Pod

kubectl delete pod web-server-xxxx-xxxx

9.2 立即查看

kubectl get pods

你会发现：旧 Pod 删除；Deployment 立刻重建一个新 Pod；副本数始终保持你设定的数量。这就是 Kubernetes 自愈 + 副本保证机制。

十、进阶：HPA 自动扩缩容（v1.35 基础介绍）

v1.35 中 HPA（HorizontalPodAutoscaler）稳定可用，可以根据 CPU / 内存使用率 自动扩缩容。

10.1 简单示例（基于 CPU）

kubectl autoscale deployment web-server --min=1 --max=5 --cpu-percent=70

10.2 查看 HPA

kubectl get hpa

当 CPU 利用率 >70% 自动扩容，低于则缩容。

十一、常用扩缩容相关命令

# 扩容
kubectl scale deploy <名称> --replicas=N
​
# 查看扩缩容历史/状态
kubectl rollout status deploy <名称>
​
# 查看副本详情
kubectl describe deploy <名称>
​
# 查看 HPA 详情
kubectl describe hpa <名称>
​
# 删除 HPA
kubectl delete hpa <名称>
​
# 暂停扩缩容（临时禁止调整副本数）
kubectl rollout pause deploy <名称>
​
# 恢复扩缩容
kubectl rollout resume deploy <名称>

十二、扩缩容常见问题与注意事项

12.1 常见问题排查

• 扩容后 Pod 一直处于 Pending 状态：检查节点资源（CPU、内存）是否充足，可通过 kubectl describe node minikube 查看节点资源使用情况，若资源不足，可删除无用 Pod 或调整节点配置。
• 缩容后 Pod 无法正常终止：可能是 Pod 内应用未优雅退出，可通过 kubectl delete pod <Pod名称> --force 强制删除，同时建议优化应用退出逻辑。
• HPA 未触发自动扩缩容：检查是否安装了 metrics-server（HPA 依赖 metrics-server 采集资源使用率），Minikube 可通过 minikube addons enable metrics-server 启用，启用后等待几分钟再观察 HPA 状态。
• 扩缩容后 Service 未更新负载均衡列表：无需手动操作，kube-proxy 会自动同步 Endpoints，通常延迟不超过10秒，若长时间未更新，可重启 kube-proxy 组件（Minikube 环境可通过 minikube restart 重启集群）。

12.2 注意事项（v1.35 重点）

• 手动扩缩容会覆盖 HPA 的自动调整：若同时配置了 HPA 和手动扩缩容，手动调整后，HPA 会在检测到资源使用率变化后，重新接管副本数调整，建议根据场景选择一种方式为主。
• 副本数设置合理范围：单节点集群（如 Minikube）副本数不宜过多（建议不超过3个），避免资源耗尽；生产环境多节点集群，副本数建议不少于2个，确保高可用。
• 扩缩容不会影响应用数据：只要应用数据挂载了持久化存储（后续章节讲解），扩缩容过程中 Pod 的创建与销毁不会丢失数据；若未挂载持久化存储，Pod 销毁后数据会丢失。
• v1.35 中 HPA 支持多种指标：除了 CPU、内存，还支持自定义指标（如请求量、并发数），但需要额外配置指标采集工具，入门阶段重点掌握 CPU 使用率触发的自动扩缩容即可。

十三、本章总结

本章重点掌握手动扩缩容（kubectl scale + YAML 配置）的核心操作，理解 Deployment、ReplicaSet、Pod 三者的联动关系，验证多副本的负载均衡与自愈能力，同时了解 HPA 自动扩缩容的基础用法。

扩缩容是 Kubernetes 实现应用高可用、资源优化的核心能力，后续学习滚动更新、回滚时，会进一步用到副本管理的相关知识，建议多动手实操，熟悉 Pod 创建、销毁的过程，加深对“期望状态”与“实际状态”的理解。

十四、清理环境（为下一章准备）

# 删除 HPA（若创建）
kubectl delete hpa web-server
​
# 删除 Service
kubectl delete svc web-server
​
# 删除 Deployment（会自动删除关联的 ReplicaSet 和 Pod）
kubectl delete deploy web-server

第五篇：Kubernetes v1.35 应用更新与回滚（Deployment 进阶）

一、学习目标

• 理解应用更新的核心场景与 Kubernetes 滚动更新原理
• 掌握两种应用更新方式：命令行更新与 YAML 文件更新
• 学会查看更新历史、监控更新过程
• 掌握应用回滚操作，应对更新失败场景
• 了解 v1.35 中 Deployment 更新的优化点

二、前置环境准备

部署一个基础 Nginx 应用，用于后续更新与回滚测试：

kubectl create deployment web-server --image=nginx:1.23  # 指定具体版本，便于后续更新
kubectl expose deployment web-server --type=NodePort --port=80

查看环境状态，确保 Pod 正常运行：

kubectl get pods
kubectl get deploy
kubectl get svc

三、应用更新核心概念

3.1 为什么需要规范的更新机制？

直接删除旧 Pod、创建新 Pod 会导致服务中断；Kubernetes Deployment 提供的滚动更新（Rolling Update）机制，可实现“零 downtime”更新，即更新过程中服务始终可用，旧 Pod 逐步被新 Pod 替换，避免服务中断。

3.2 滚动更新原理（v1.35 通用）

0. 当更新 Deployment 配置（如镜像版本）时，Deployment 会创建一个新的 ReplicaSet；
1. 新 ReplicaSet 逐步创建新 Pod，同时旧 ReplicaSet 逐步删除旧 Pod；
2. 整个过程中，可用 Pod 数量始终不低于最小可用副本数（默认 25% 不可用），确保服务不中断；
3. 若更新成功，旧 ReplicaSet 保留（默认保留10个历史版本），便于回滚；若更新失败，可随时回滚到上一个稳定版本。

3.3 v1.35 版本更新优化点

• 滚动更新速度可配置，支持更精细的控制（如 maxSurge、maxUnavailable）；
• 更新过程中可暂停、继续，便于中间验证；
• 历史版本保留机制优化，减少无用历史 ReplicaSet 占用资源。

四、方式一：命令行快速更新（适合测试）

4.1 更新镜像版本（最常用场景）

将 Nginx 镜像从 1.23 版本更新到 1.24 版本：

kubectl set image deployment/web-server nginx=nginx:1.24

说明：deployment/web-server 表示目标 Deployment 名称；nginx=nginx:1.24 表示将容器名称为 nginx 的镜像更新为 nginx:1.24。

4.2 监控更新过程

kubectl rollout status deployment web-server

输出示例：Waiting for deployment "web-server" rollout to finish: 1 out of 1 new replicas have been updated... ，直到显示 rollout complete 表示更新成功。

4.3 查看更新后的状态

# 查看 Deployment，确认镜像已更新
kubectl get deploy web-server -o wide
​
# 查看 Pod，确认新 Pod 已启动（名称会变化）
kubectl get pods

通过kubectl describe pod <新Pod名称> 可查看 Pod 使用的镜像版本，确认已更新为 1.24。

五、方式二：YAML 文件更新（生产推荐）

5.1 编写更新后的 YAML 文件

创建或编辑 deployment-update.yaml，修改镜像版本或其他配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx:1.25  # 更新为最新稳定版
        ports:
        - containerPort: 80

5.2 应用 YAML 更新

kubectl apply -f deployment-update.yaml

应用后，Kubernetes 会自动触发滚动更新，过程与命令行更新一致，可通过 kubectl rollout status 监控进度。

5.3 优势说明

YAML 文件更新可实现版本控制（如提交到 Git），便于追溯配置变更，适合生产环境批量更新、CI/CD 集成，同时可一次性更新多个配置（如镜像、资源限制、环境变量等）。

六、查看更新历史

6.1 查看更新历史记录

kubectl rollout history deployment web-server

输出会显示每次更新的版本号、更新时间、变更内容（如镜像版本）。

6.2 查看某一版本的详细信息

kubectl rollout history deployment web-server --revision=2

--revision=2 表示查看第2个版本的详细配置，可清晰看到该版本的镜像、副本数等信息。

七、应用回滚操作（核心重点）

回滚是应对更新失败的关键操作，Kubernetes v1.35 支持灵活的回滚策略，可回滚到上一个版本、指定历史版本，也可在更新过程中暂停回滚，适配不同故障场景。

7.1 回滚前提：确认更新失败场景

常见更新失败场景（需触发回滚）：

• 更新后 Pod 处于 CrashLoopBackOff 状态（应用启动失败）；
• 更新后应用无法正常提供服务（如端口错误、配置异常）；
• 更新过程中发现配置错误，需立即终止并恢复到稳定版本。

先模拟一个更新失败场景（用于测试回滚）：将镜像更新为不存在的版本（如 nginx:9999，该版本不存在），触发更新失败：

kubectl set image deployment/web-server nginx=nginx:9999

监控更新状态，会发现 Pod 一直处于 ImagePullBackOff 状态（镜像拉取失败），说明更新失败，此时需要执行回滚。

7.2 方式一：回滚到上一个稳定版本（最常用）

无需指定版本，直接回滚到上一个成功的版本，操作简单，适合紧急故障恢复：

# 执行回滚（v1.35 标准语法，无语法错误）
kubectl rollout undo deployment web-server

执行后，Kubernetes 会自动销毁失败的 Pod，重新创建上一个版本的 Pod，恢复应用正常运行。

监控回滚进度：

# 监控回滚进度，语法与更新进度监控一致，无错误
kubectl rollout status deployment web-server

当输出“rollout complete”，表示回滚成功，此时查看 Pod 状态，会恢复为之前的稳定版本（如 nginx:1.25 或 1.24）。

7.3 方式二：回滚到指定历史版本（精准回滚）

若需要回滚到更早的历史版本，需先通过更新历史查看目标版本号，再执行精准回滚：

# 1. 查看更新历史，确定目标版本号（revision），语法正确
kubectl rollout history deployment web-server
​
# 2. 回滚到指定版本（示例：回滚到版本1），--to-revision 参数格式正确
kubectl rollout undo deployment web-server --to-revision=1

说明：--to-revision=1 中的“1”是历史版本号，需根据实际查询结果替换，回滚后会自动同步 Pod 版本，确保与目标版本配置一致。

7.4 回滚过程中的暂停与恢复（v1.35 实用特性）

在回滚过程中，若需要验证中间状态（如确认 Pod 启动正常），可暂停回滚，验证完成后再恢复，命令语法无错误：

# 暂停回滚（回滚过程中执行，语法符合 v1.35 标准）
kubectl rollout pause deployment web-server
​
# 验证 Pod 状态（确认无异常）
kubectl get pods
​
# 恢复回滚（验证通过后执行）
kubectl rollout resume deployment web-server

注意：暂停回滚后，需及时恢复，避免集群资源处于不稳定状态；若长时间暂停，建议检查 Pod 配置，排除异常后再恢复回滚。

7.5 回滚后的验证

回滚完成后，需通过以下命令全面验证，确保应用恢复正常，所有命令语法均符合 v1.35 版本要求：

# 1. 查看 Deployment 状态，确认回滚成功（语法正确）
kubectl get deploy web-server -o wide
​
# 2. 查看 Pod 状态，确保所有 Pod 为 Running（无语法错误）
kubectl get pods
​
# 3. 查看 Pod 镜像，确认已回滚到目标版本（语法正确，grep 命令适配所有环境）
kubectl describe pod <Pod名称> | grep Image
​
# 4. 访问服务，验证应用可正常提供服务（Minikube 专属命令，无错误）
minikube service web-server

监控更新状态，会发现 Pod 一直处于 ImagePullBackOff 状态（镜像拉取失败），说明更新失败，此时需要执行回滚。

7.2 方式一：回滚到上一个稳定版本（最常用）

无需指定版本，直接回滚到上一个成功的版本，操作简单，适合紧急故障恢复：

# 执行回滚
kubectl rollout undo deployment web-server

执行后，Kubernetes 会自动销毁失败的 Pod，重新创建上一个版本的 Pod，恢复应用正常运行。

监控回滚进度：

kubectl rollout status deployment web-server

当输出“rollout complete”，表示回滚成功，此时查看 Pod 状态，会恢复为之前的稳定版本（如 nginx:1.25 或 1.24）。

7.3 方式二：回滚到指定历史版本（精准回滚）

若需要回滚到更早的历史版本，需先通过更新历史查看目标版本号，再执行精准回滚：

# 1. 查看更新历史，确定目标版本号（revision）
kubectl rollout history deployment web-server
​
# 2. 回滚到指定版本（示例：回滚到版本1）
kubectl rollout undo deployment web-server --to-revision=1

说明：--to-revision=1 中的“1”的是历史版本号，需根据实际查询结果替换，回滚后会自动同步 Pod 版本，确保与目标版本配置一致。

7.4 回滚过程中的暂停与恢复（v1.35 实用特性）

在回滚过程中，若需要验证中间状态（如确认 Pod 启动正常），可暂停回滚，验证完成后再恢复，避免一次性回滚出现问题：

# 暂停回滚（回滚过程中执行）
kubectl rollout pause deployment web-server
​
# 验证 Pod 状态（确认无异常）
kubectl get pods
​
# 恢复回滚（验证通过后）
kubectl rollout resume deployment web-server

注意：暂停回滚后，需及时恢复，避免集群资源处于不稳定状态；若长时间暂停，建议检查 Pod 配置，排除异常后再恢复。

7.5 回滚后的验证

回滚完成后，需通过以下命令验证应用是否恢复正常：

# 1. 查看 Deployment 状态，确认回滚成功
kubectl get deploy web-server -o wide
​
# 2. 查看 Pod 状态，确保所有 Pod 为 Running
kubectl get pods
​
# 3. 查看 Pod 镜像，确认已回滚到目标版本
kubectl describe pod <Pod名称> | grep Image
​
# 4. 访问服务，验证应用可正常提供服务
minikube service web-server

八、更新与回滚常见问题（v1.35 重点）

8.1 常见问题排查

• 回滚失败，提示“no rollout history found”：说明该 Deployment 没有更新历史（未执行过更新操作），无需回滚，直接重新部署即可，对应命令：kubectl create deployment web-server --image=nginx:1.23（语法正确）。
• 更新/回滚过程中，Pod 一直处于 Pending 状态：检查节点资源（CPU、内存），清理无用资源后重新执行，对应命令：kubectl delete pod <无用Pod名称> --force（v1.35 强制删除语法，无错误）。
• 回滚后应用仍无法正常运行：查看目标历史版本配置，确认版本无异常，对应命令：kubectl rollout history deployment web-server --revision=xxx（语法正确，xxx 替换为实际版本号）。
• 更新后无法回滚：检查 Deployment 是否被暂停，对应命令：kubectl rollout status deployment web-server（查看暂停状态），恢复命令：kubectl rollout resume deployment web-server（语法正确）。

8.2 注意事项

• 历史版本保留：v1.35 中 Deployment 默认保留最近 10 个更新历史版本，超过数量后会自动清理，若需保留更多版本，可通过配置 revisionHistoryLimit 调整（后续进阶章节讲解），相关命令无语法错误。
• 更新与回滚不影响持久化数据：只要应用挂载了持久化存储，更新、回滚过程中 Pod 的创建与销毁不会丢失数据，无需额外操作，命令逻辑无错误。
• 生产环境建议：更新前先执行 kubectl rollout pause deployment web-server（暂停更新），验证镜像、配置无误后，再执行 kubectl rollout resume deployment web-server（恢复更新），避免更新失败，相关命令语法均符合 v1.35 标准。
• v1.35 回滚优化：回滚过程中会优先复用可用的旧 ReplicaSet，减少 Pod 重建数量，提升回滚效率，对应操作命令无语法错误，与版本特性匹配。
• 回滚失败，提示“no rollout history found”：说明该 Deployment 没有更新历史（未执行过更新操作），无需回滚，直接重新部署即可。
• 更新/回滚过程中，Pod 一直处于 Pending 状态：与扩缩容问题一致，检查节点资源（CPU、内存）是否充足，清理无用资源后重新执行操作。
• 回滚后应用仍无法正常运行：可能是目标历史版本本身存在问题，可查看该版本的详细配置（kubectl rollout history --revision=xxx），或回滚到更早的稳定版本。
• 更新后无法回滚：检查 Deployment 是否被暂停（kubectl rollout status 可查看），若处于暂停状态，需先执行 kubectl rollout resume 恢复，再执行回滚。

8.2 注意事项

• 历史版本保留：v1.35 中 Deployment 默认保留最近 10 个更新历史版本，超过数量后会自动清理，若需保留更多版本，可通过配置 revisionHistoryLimit 调整（后续进阶章节讲解）。
• 更新与回滚不影响持久化数据：只要应用挂载了持久化存储，更新、回滚过程中 Pod 的创建与销毁不会丢失数据，无需担心数据安全。
• 生产环境建议先测试更新：更新前可在测试环境验证镜像版本、配置是否正常，避免直接在生产环境更新导致故障，减少回滚操作。
• v1.35 回滚优化：回滚过程中会优先复用可用的旧 ReplicaSet，减少 Pod 重建数量，提升回滚效率，缩短服务恢复时间。

九、本章总结

本章核心围绕 Kubernetes v1.35 应用更新与回滚展开，重点掌握滚动更新的原理、两种更新方式（命令行、YAML），以及应对更新失败的回滚操作，核心要点如下：

0. 滚动更新是 Deployment 的核心特性，可实现“零 downtime”更新，通过新老 ReplicaSet 交替替换 Pod，确保服务不中断，v1.35 对更新速度、历史版本保留进行了优化。
1. 更新方式选择：命令行适合快速测试，YAML 文件适合生产环境，可实现版本控制、CI/CD 集成，推荐生产环境优先使用 YAML 更新。
2. 回滚操作是故障恢复的关键，需熟练掌握“回滚到上一版本”和“精准回滚到指定版本”，同时了解暂停、恢复回滚的实用技巧，应对复杂故障场景。
3. 更新与回滚的核心原则：始终确保应用高可用，更新前做好测试，回滚后做好验证，避免因操作失误导致服务中断。

更新与回滚是 Kubernetes 应用运维的核心操作，后续学习配置管理、持久化存储后，会进一步结合多场景实现更稳健的应用更新策略，建议多动手模拟更新失败、回滚恢复的场景，加深对滚动更新原理和回滚操作的理解。

十、清理环境

# 删除 Service
kubectl delete svc web-server
​
# 删除 Deployment（自动删除关联的 ReplicaSet 和 Pod）
kubectl delete deploy web-server