20250718-1-Kubernetes 应用程序生命周期管理-应用部署、升级、弹性_笔记

一、资源字段太多，记不住怎么办

可通过以下两种方式导出配置：

• 使用get命令导出：通过get命令获取现有资源的YAML配置，例如导出deployment资源配置时，添加-o yaml参数即可生成完整YAML文件。但需注意导出的配置包含大量默认字段，需手动筛选必要内容。
• 通过explain命令查询字段：若忘记容器字段拼写，可使用kubectl explain递归查询层级结构。例如：
  • 查询pod级别字段：kubectl explain pod.spec.containers
  • 查询deployment级别字段：kubectl explain deployment.spec
  • 关键点：explain输出包含字段描述及子字段支持列表，适用于快速定位配置位置。

注意事项：

• dry-run模式：仅生成YAML模板而不实际执行，适用于测试配置格式。
• 导出差异：get导出的配置包含系统默认字段，而create生成的YAML仅含用户定义内容。

1.部署应用

部署流程核心步骤：

• 编写YAML文件：需定义镜像名称及副本数（replicas），确保应用高可用性。
• 执行部署：通过kubectl apply -f命令应用YAML文件，例如部署web2应用后可通过get命令验证状态。

典型配置示例：

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: web2  
spec:  
  replicas: 2  
  template:  
    spec:  
      containers:  
      - name: nginx  
        image: nginx:latest  

• 部署方式：可以通过YAML文件或命令行完成应用部署，通常推荐使用YAML文件方式
• 核心要素：

  • 镜像指定：必须明确指定容器镜像，如 nginx:1.16nginx:1.16nginx:1.16

  • 副本数量：通过replicas字段设置预期Pod副本数（示例中为3个）

  • 标签匹配：需要确保 selector.matchLabelsselector.matchLabelsselector.matchLabels

    与Pod模板中的labels一致

• 部署目的：
  • 保证应用的高可用性
  • 提高应用的并发处理能力
• 2. 应用升级

1）升级方式

• 三种升级方法：
  • 使用kubectl set image命令直接更新镜像版本
  • 通过kubectl edit命令编辑Deployment配置
  • 修改YAML文件后重新应用
• 升级频率：实际生产中可能每天多次或每周一次，属于频繁操作

2）滚动升级机制

• 核心特点：
  • 逐步替换：新版本Pod逐步替换旧版本Pod
  • 零停机：确保服务持续可用，用户无感知
  • 默认策略：Kubernetes的默认升级方式
• 类比说明：类似桶从高处滚落的过程，升级操作持续不间断进行

3）发布策略对比

• 常见发布策略类型：
  • 停机发布：最简单直接的发布方式
  • 蓝绿发布：同时维护新旧两套环境
  • 灰度发布：
    • 金丝雀发布
    • AB测试
    • 冒烟测试
• 策略价值：
  • 保障业务连续性
  • 确保上线稳定性
  • 解决应用上线的"最后一公里"问题
• K8S选择：默认采用滚动升级策略平衡稳定性和连续性

3. 滚动升级

1）例题:pod升级流程图

• 滚动升级原理 升级过程：K8s默认采用滚动升级策略，通过逐步替换Pod实现零停机发布。例如一个应用有3个Pod副本，升级时先升级1个Pod（红色变蓝色），完成后升级第二个，最后升级第三个。

  • 业务连续性：升级过程中始终有新旧版本Pod同时运行（绿色和蓝色共存），确保服务不间断。
  • 与传统升级对比：
    • 瀑布式升级：需要停服更新，若升级失败回滚耗时较长（可能达半小时）
    • 滚动升级优势：用户无感知，自动回滚机制更完善

• 触发升级的三种方式
  *

  • kubectl apply：
    • 修改yaml文件中的镜像版本后执行kubectl apply -f xxx.yaml
    • 示例：将nginx从1.16升级到1.17
  • kubectl set image：
    • 直接指定镜像版本：kubectl set image deployment/web2 web=nginx:1.18
    • 注意：web参数对应yaml中的容器名称
  • kubectl edit：
    • 交互式编辑：kubectl edit deployment/web2
    • 使用系统编辑器（如vi）在线修改镜像版本

2）例题:web应用滚动升级

• 实战演示
  *
  • 验证方法：
    • 使用while true; do curl -I web2-service; sleep 1; done持续访问服务
    • 观察响应头中的nginx版本变化（如从1.16→1.17→1.18）
  • 常见错误：
    • 容器命名不规范：Invalid value: "nginx:1.16"（不能包含冒号）
    • 解决方法：在yaml中确保name字段只包含[a-z0-9]和连字符
• 实现机制
  *
  • 底层原理：
    • 通过2个ReplicaSet控制新旧Pod交替
    • 新ReplicaSet逐步扩容，旧ReplicaSet同步缩容
  • 镜像来源：
    • 默认从Docker Hub拉取（如nginx:1.18）
    • 私有仓库需指定完整路径（如192.168.1.100:5000/nginx:1.18）
    • 支持阿里云等第三方仓库（需配置域名或IP）
• 升级策略配置
  *
  • 策略类型：
    • 蓝绿部署：同时运行两套环境，流量切换
    • 金丝雀发布：先小范围验证新版本
    • A/B测试：根据用户属性分流
  • 标签管理：
    • 必须保证至少一个标签匹配（如app: web2）
    • 典型标签组合：项目名称+应用名称（project:ms + app:web2）

4. 镜像管理

1）镜像获取机制

• 自动拉取机制：K8s会自动从指定镜像仓库拉取所需镜像，无需手动操作
• 默认仓库配置：未指定地址时默认从Docker Hub官方仓库拉取
• 私有仓库使用：必须显式指定私有仓库地址（如reg.lisiedu.cn/library/nginx:1.18）

2）镜像仓库配置

• 仓库类型：
  • 公共仓库：Docker Hub等官方仓库
  • 私有仓库：需自行搭建并配置访问权限
• 配置限制：
  • 不支持通过别名配置仓库地址
  • 修改默认仓库需要改动源码，实际使用中建议显式指定完整镜像路径

5. 滚动升级机制

1）基本概念

• 定义：K8s默认的Pod升级策略，通过逐步替换Pod实现零停机发布
• 核心特点：
  • 始终保持有Pod在运行状态
  • 用户对升级过程无感知
  • 通过新旧版本Pod共存保证业务连续性

2）实现原理

• 架构设计：
  • Deployment作为顶层控制器
  • 每个版本对应一个ReplicaSet（RS）
  • 每个RS维护特定镜像版本的Pod副本
• 升级流程：
  • 创建新RS并设置副本数为1（新版本）
  • 将旧RS副本数减1（如从3→2）
  • 新RS扩容至2副本，旧RS再缩容至1副本
  • 循环操作直至旧RS副本数为0，新RS达到目标副本数

3）操作验证

• 查看升级过程
  • 监控方法：
    • 使用kubectl describe deployment <name>查看事件流
    • 通过kubectl get rs观察各版本RS状态
  • 关键指标：
    • DESIRED：预期副本数
    • CURRENT：当前实际副本数
    • READY：就绪副本数
    • AGE：资源存活时间
• 版本控制验证
  • 版本追踪：
    • 每个RS严格对应一个镜像版本（如nginx:1.16→RS1，nginx:1.17→RS2）
    • 通过kubectl describe rs <name>可查看维护的具体镜像版本
  • 升级证据：
    • 事件日志记录完整的扩容/缩容过程
    • 旧RS最终副本数会归零，新RS达到目标副本数

二、水平扩缩容

• 副本数控制：通过修改yaml文件中的replicas值或使用kubectl scale命令来调整Pod副本数量
• 扩容场景：当单个Pod只能承载500个请求而需要承载1000个请求时，可通过水平扩容增加实例数
• 两种扩容方式：
  • 修改yaml文件中的replicas字段后执行apply
  • 直接使用kubectl scale命令（如：kubectl scale deployment web --replicas=10）

三、部署应用

1. 水平扩缩容实践

• 扩容执行：将副本数从1个修改为5个后apply，系统会自动创建新的Pod实例
• 底层机制：实际扩容操作由ReplicaSet控制器执行，Deployment负责管理ReplicaSet
• 实时监控：通过kubectl get pods可查看扩容后的Pod运行状态
• 扩容验证：使用kubectl describe命令可查看扩容事件记录
• 动态调整：从5个副本扩容到10个副本时，系统会立即创建所需数量的新Pod
• 控制器协作：Deployment控制器协调ReplicaSet完成实际的Pod创建和销毁工作
• 缩容原理：将replicas值调小（如从10改为3）后，系统会自动终止多余的Pod实例
• 资源优化：在负载较低时减少副本数以节省资源，高负载时增加副本数应对并发
• 事件追踪：通过describe命令可查看缩容过程中的ReplicaSet调整事件记录
• 状态检查：使用kubectl get pods确认最终保留的Pod数量符合预期
• 自动化管理：Kubernetes会自动维护指定的副本数量，确保系统始终处于期望状态
• 弹性伸缩：这种机制实现了根据实际负载动态调整资源的能力

四、回滚

1. 查看历史发布版本

命令语法：kubectl rollout history deployment <deployment名称>

• 显示内容：输出包含REVISION编号和CHANGE-CAUSE字段的历史版本记录
• 注意事项：默认CHANGE-CAUSE显示为<none>，需要通过--record参数记录变更原因

2. 回滚到上一个版本

• 命令语法：kubectl rollout undo deployment <deployment名称>
• 应用场景：新版本出现问题时快速回退到已验证的稳定版本
• 实现原理：通过ReplicaSet保留历史版本配置，回滚时重新激活对应RS
• 生产实践：90%以上的回滚操作都是回退到上一个版本

3. 指定版本回滚

• 命令语法：kubectl rollout undo deployment <deployment名称> --to-revision=<版本号>
• 版本查询：先通过history命令查看REVISION编号
• 示例操作：回滚到版本2对应nginx:1.17镜像
• 注意事项：参数是--to-revision而非-revision

4. 回滚记录与描述

• 记录方法：执行变更时添加--record=true参数
• 命令行记录：kubectl set image deployment web2 web=nginx:1.21 --record=true
• YAML限制：通过apply更新时无法记录具体镜像变更信息
• 替代方案：建议开发管理平台自行记录变更详情

5. 通过RS获取版本信息

• 查询方法：
  • kubectl describe rs <rs名称> | grep revision 获取版本号
  • kubectl describe rs <rs名称> | grep Image 获取镜像版本
• 自动化脚本：可通过awk等工具整合输出完整版本变更记录
• 底层原理：每个Deployment版本对应独立的ReplicaSet保留完整配置
• 生产建议：企业级环境建议开发管理平台完善版本记录功能

五、项目下线操作

1. 删除Deployment和Service

• 完整删除命令：使用kubectl delete deploy/web和kubectl delete svc/web可同时删除Deployment和Service资源
• 执行顺序：建议先删除Deployment再删除Service，确保应用完全下线

2. ReplicaSet的作用机制

• 自动恢复机制：直接删除Pod会被ReplicaSet重新拉起，因为ReplicaSet会持续监控并维持指定的副本数
• 正确删除方式：必须删除上层的Deployment资源才能彻底停止应用
• 典型场景：
  • 删除一个Pod会自动新建一个Pod
  • 多出一个Pod会自动删除一个Pod

3. 完整删除流程演示

• 状态变化过程：
  • 执行kubectl delete deployment web2后
  • 所有相关Pod会立即进入Terminating状态
  • 经过短暂时间后才会完全消失
• 注意事项：
  • 直接删除Pod无效，必须删除Deployment
  • Service需要单独删除，使用kubectl delete svc <service-name>

4. 常见错误处理

• 典型错误：
  • 误用kubectl svc命令（正确应为kubectl delete svc）
  • 直接删除Pod导致自动重建
• 验证方法：
  • 使用kubectl get pods观察Pod状态变化
  • 确认所有相关资源都已Terminating

5. 完整卸载确认

• 最终确认：
  • 当Deployment和Service都删除后
  • 所有关联Pod会最终被清除
  • 系统不再保留任何应用资源
• 操作口诀：
  • "先删Deploy再删Svc"
  • "直接删Pod没有用"

六、复制集控制器用途

• 副本数量管理：通过死循环持续监控当前Pod数量与期望Pod数量是否匹配，自动执行增减操作保持预期状态
• 版本记录功能：Deployment每次发布都会创建新的ReplicaSet作为版本记录，这是实现回滚功能的基础机制
• 滚动升级实现：通过创建新的ReplicaSet并逐步替换旧的ReplicaSet来实现平滑的滚动升级过程
• 常用命令：
  • kubectl get rs 查看现有ReplicaSet记录
  • kubectl rollout history deployment web 查看Deployment版本对应的RS记录

七、练习

1. 基础操作练习

• Deployment创建与更新：
  • 创建nginx deployment（副本数3，镜像1.16）
  • 滚动更新至镜像1.17版本并记录过程
  • 执行版本回滚操作
• 扩容操作：将web deployment扩容至3个副本
• 配置导出与删除：
  • 将deployment导出为json格式文件
  • 删除已创建的deployment资源

2. 生成一个deployment yaml文件并保存

• 文件生成要求：

  • 保存路径：/opt/deploy.yaml
  • 基本参数：
    • 名称：web
    • 标签： app_env_stage=devapp\_env\_stage=devapp_env_stage=dev

• 命令对比：

  • kubectl create -f：仅创建资源
  • kubectl apply -f：创建+更新资源

• 提交方式：将作业结果截图提交至指定腾讯文档

• 注意事项：讲义最后一页均包含对应作业，建议及时完成

• 升级过程详解：

  • 首次部署创建3个副本
  • 升级时创建新RS（初始副本数1）
  • 逐步调整新旧RS副本数（2:1→1:2→0:3）
  • 最终旧RS副本数为0，新RS副本数为3

• 版本对应关系：

  • 每个RS对应一个镜像版本
  • 通过RS记录可实现精确版本回滚

八、知识小结

|----------------|------------------------------------------|--------------------------------------|------------------------------------|
| 知识点 | 核心内容 | 关键操作/易混淆点 | 技术要点 |
| Deployment基础功能 | 管理Pod和ReplicaSet，支持滚动升级、回滚、副本数调整 | 与直接管理Pod的区别 | 通过ReplicaSet间接控制Pod |
| 滚动升级机制 | 新版本Pod逐步替换旧版本，保证业务连续性 | 新旧版本共存过渡 | 默认策略，可通过kubectl set image或修改yaml触发 |
| ReplicaSet作用 | 1. Pod副本数管理 2. 版本记录用于回滚 | 直接删除Pod会被自动重建 | 每个Deployment变更生成新ReplicaSet |
| 版本回滚操作 | kubectl rollout undo deployment/[name] | 需配合--record记录变更命令 | 回滚依赖ReplicaSet保留的历史版本 |
| 扩容/缩容 | 修改replicas字段或kubectl scale命令 | 水平扩展应对流量变化 | ReplicaSet实时监控副本数差异 |
| YAML配置导出 | kubectl get deploy/[name] -o yaml | 导出配置包含系统默认字段 | --dry-run生成标准模板 |
| 字段查询技巧 | kubectl explain递归查看字段结构 | 容器配置集中在spec.template.spec.containers | 支持层级查询如deployment.spec |
| 工作负载概念 | 抽象层管理容器化应用生命周期 | 与Pod的直接管理对比 | 支持网站/API/微服务等场景 |
| 镜像管理 | 支持Docker Hub和私有仓库 | 镜像地址格式差异 | 版本升级通过修改image字段实现 |
| 应用下线流程 | 需删除Deployment而非直接删Pod | Service需单独删除 | 级联删除关联资源 |