LabHub
学习 学习路径 课程

KCNA — Kubernetes 与云原生入门

部署成功了，为什么看不到新版本

在 LabHub 中继续学习

目标

在真实 k3s 中，用不同证据区分声明已被接受、滚动发布完成、就绪失败、手动回滚和外部配置恢复。

为什么重要

部署命令结束并不意味着新版本已经在处理请求。 滚动更新会保留原有健康副本，因此即使新版本失败，服务也可能看起来正常。 此时若修改 liveness 或删除所有 Pod，连故障证据也会丢失。 本实验保留正常对照组和最后的健康副本，只注入指定的就绪失败。 实验时长 50 分钟，必要时请在到期前延长。会话结束后 VM 和文件会被回收。

已准备的环境与辅助工具

个人 VM 的 kcna-delivery 空间中已有包含两个副本的 web Deployment、settings ConfigMap、web Service 和 control Pod。 应用镜像固定到 digest，并使用 non-root、cap drop ALL、RuntimeDefault、只读根目录和不挂载 ServiceAccount 令牌。 v1、v2、v3 是在同一镜像中区分行为的合成应用版本。本实验不会构建新镜像，也不会修改真实 CI 或 GitOps。 请勿更改节点、健康对照组或滚动发布保护设置，也不要带入生产 kubeconfig 或秘密。 所有学生文件都放在 /root/kcna-delivery 下。输入 JSON 由你直接编写，实际观测 JSON 使用 capture 生成。 在 python3 /opt/fixtures/kcna_delivery_lab.py 后附加 act、capture、grade、prepare 和步骤编号 1~8。 observe 读取当前 API 与 HTTP 响应。grade 不修改文件或对象。 act 将操作完成记录写入 /opt/fixtures/kcna-delivery-action-N.json。不要伪造文件 UID、响应或完成状态。

步骤

  1. 使用 capture 1 保存 /root/kcna-delivery/baseline.json。调查两个 v1·blue 健康 Pod、Deployment·ReplicaSet·Pod UID、容器 ID·重启次数、Ready、EndpointSlice 和 Service 响应。control Pod 是独立的健康对照组。
  2. 在 annotation.json 中保存字符串 note=reviewed，用 act 2·capture 2 创建 metadata_only.json。只改变 Deployment 对象的注解，原 ReplicaSet·Pod·容器·revision 必须保持不变。反证“对象变化就等于新进程”的假设。
  3. 在 config-green.json 中保存字符串 color=green，用 act 3·capture 3 创建 config_only.json。ConfigMap settings 的值为 green，但现有 Pod 和 Service 运行中的 COLOR 仍是 blue。区分环境变量的消费时机和 API 中存储的值。
  4. 在 release-v2.json 中保存字符串 release=v2 和布尔值 ready=true。用 act 4·capture 4 创建 v2_complete.json。新的 ReplicaSet 和两个 Pod 应响应 v2·green，且 updatedReplicas=2。把健康 revision 编号保留在该观测中。
  5. 在 release-v3.json 中保存字符串 release=v3、布尔值 ready=false、字符串 color=purple。用 act 5·capture 5 创建 v3_unready.json。v3 处于 Running 但不 Ready，直接返回 HTTP 503。原有两个 v2·green 副本必须保留相同 UID 和容器，Service 应把流量转发给这些健康副本。
  6. 不做额外更改，用 capture 6 保存 deadline_exceeded.json。确认真实的 Progressing=False·ProgressDeadlineExceeded，以及期望模板仍为 v3。这不是 liveness 重启或自动回滚，而是新版本未就绪造成的进度失败。本实验的 20 秒阈值并非生产建议值。
  7. 查询 v2_complete.json 中保存的 Deployment deployment.kubernetes.io/revision，把它作为字符串写入 rollback.json 的 revision。用 act 7·capture 7 创建 rolled_back.json。比较真实 rollout undo 命令的完成记录、保留的原 v2 Pod、增加的 revision，以及仍为 purple 的外部 ConfigMap。
  8. 在 restore-green.json 中保存字符串 color=green，用 act 8·capture 8 创建 config_restored.json。单独恢复外部配置，并确认 v2·green 响应以及原健康 Pod 和对照组得到保留。根据先前记录解释 Deployment 回滚和外部配置恢复为何是不同操作。

参考

题目中的 note=reviewed 等表达是字段和值的说明。请按格式示例编写有效 JSON。 true·false 是不带引号的布尔值。revision 是字符串，必须从健康的 v2 观测中读取。 capture 会等待真实条件收敛。6 次 Service 响应只是学习样本，不是长期可用性保证。 请保留已完成的观测和输入。prepare 只补齐缺失的先前步骤，不会覆盖当前步骤的答案或已有错误答案。 若记录中途断裂，不会自动初始化。尤其不能在回滚完成记录丢失后，仅因当前是 v2 就重建过去的成功记录。 此时请保存所需文件后启动新实验。同一 VM 不提供重置全部历史的命令。 评分预算为 60 秒，步骤准备预算为 90 秒。正常启动或等待就绪失败的期限由 capture 执行。 记录哈希只用于检测意外文件变更，并非对 VM root 的远程证明或安全保证。 官方依据：Deployment · ConfigMap。

健康版本的声明与运行证据

使用 capture 1 保存 /root/kcna-delivery/baseline.json。调查两个 v1·blue 健康 Pod、Deployment·ReplicaSet·Pod UID、容器 ID·重启次数、Ready、EndpointSlice 和 Service 响应。control Pod 是独立的健康对照组。

不要只记录名称，还要同时保留 UID 和容器 ID。

对象注解不是滚动发布

在 annotation.json 中保存字符串 note=reviewed，用 act 2·capture 2 创建 metadata_only.json。只改变 Deployment 对象的注解，原 ReplicaSet·Pod·容器·revision 必须保持不变。反证“对象变化就等于新进程”的假设。

请区分变更位置是 metadata 还是 spec.template。

配置变更与运行中的环境变量

在 config-green.json 中保存字符串 color=green，用 act 3·capture 3 创建 config_only.json。ConfigMap settings 的值为 green，但现有 Pod 和 Service 运行中的 COLOR 仍是 blue。区分环境变量的消费时机和 API 中存储的值。

ConfigMap 中的存储值和现有进程环境变量不会在同一时刻变化。

新模板确实已部署的证据

在 release-v2.json 中保存字符串 release=v2 和布尔值 ready=true。用 act 4·capture 4 创建 v2_complete.json。新的 ReplicaSet 和两个 Pod 应响应 v2·green，且 updatedReplicas=2。把健康 revision 编号保留在该观测中。

availableReplicas 可能仍来自旧版本。请同时查看 updatedReplicas 和响应版本。

新版本存活但尚未就绪

在 release-v3.json 中保存字符串 release=v3、布尔值 ready=false、字符串 color=purple。用 act 5·capture 5 创建 v3_unready.json。v3 处于 Running 但不 Ready，直接返回 HTTP 503。原有两个 v2·green 副本必须保留相同 UID 和容器，Service 应把流量转发给这些健康副本。

Running、Ready、HTTP 响应和 Service 转发是不同的观测。

超过进度期限不等于自动回滚

不做额外更改，用 capture 6 保存 deadline_exceeded.json。确认真实的 Progressing=False·ProgressDeadlineExceeded，以及期望模板仍为 v3。这不是 liveness 重启或自动回滚，而是新版本未就绪造成的进度失败。本实验的 20 秒阈值并非生产建议值。

检查 Progressing 条件的 status 与 reason，并确认期望模板是否保持不变。

按查得的 revision 手动回滚

查询 v2_complete.json 中保存的 Deployment deployment.kubernetes.io/revision，把它作为字符串写入 rollback.json 的 revision。用 act 7·capture 7 创建 rolled_back.json。比较真实 rollout undo 命令的完成记录、保留的原 v2 Pod、增加的 revision，以及仍为 purple 的外部 ConfigMap。

不要凭记忆填写 revision。rollback 不会回滚外部 ConfigMap。

单独恢复外部配置

在 restore-green.json 中保存字符串 color=green，用 act 8·capture 8 创建 config_restored.json。单独恢复外部配置，并确认 v2·green 响应以及原健康 Pod 和对照组得到保留。根据先前记录解释 Deployment 回滚和外部配置恢复为何是不同操作。

不要只看健康响应，还要检查下一个 Pod 将读取的配置。