如何通过实践实验来调试那些无法正常进行的Kubernetes部署操作

检查哪些Pod在处理请求

k get endpointslices -l kubernetes.io/service-name=rollout-demo -o json
k exec --pod-running-timeout=30s --request-timeout=60s http-client -- \
  python -u /app/probe.py --url http://rollout-demo:8080/ \
  --expected-version v2 --count 10 --interval 0.2

该探针会检查这些Pod的状态和版本信息，并记录下响应请求的Pod的名称。将这些名称与之前正常的ReplicaSet中的Pod进行比较；同时，也要将EndpointSlice中的targetRef.uid值与相应的UUID进行对比。

在本次测试中，所有10个响应都来自那些更新了两个版本的Pod。这些Pod的EndpointSlice信息已经准备就绪；而那个被阻塞的图像Pod也被列了出来，但其端点的状态显示为ready: false且serving: false。

由于新的Pod无法正常投入使用，因此控制器仍然保留着那些正常的旧副本。服务样本确认这些Pod确实做出了响应；10次成功的请求测试结果说明了在这段时间内发生的情况，但这些结果并不能证明在两次测量期间服务始终处于正常运行状态。

如何区分两种超时情况

第一种超时情况发生在你的终端中。执行命令kubectl rollout status --timeout=10s后，由于客户端超时设置，系统会停止等待操作，但并不会取消更新过程或恢复之前的配置。kubectl命令参考文档中对这种超时机制有详细说明。

第二种超时情况是由Deployment控制器引起的。你需要等待它指定的截止时间，然后查看具体的原因：k wait --for=jsonpath="{.status_conditions[?(@.type=="Progressing")].reason}'=ProgressDeadlineExceeded \ deployment/rollout-demo --timeout=240s k get deployment rollout-demo -o json

这次等待操作设置了240秒的超时时间限制。检查后会发现，Progressing的状态为False，原因也是ProgressDeadlineExceeded。kubectl wait参考文档对这种使用JSONPath进行等待的操作进行了说明。

在之前的测试记录中，Progressing状态的最后更新时间从04:57:14Z变为了05:00:15Z，间隔时间为181秒，而配置的截止时间是180秒。因此，控制器的计时并不能保证实际等待时间一定正好是180秒。

Available=True这一状态仍然存在，是因为那些旧的Pod仍在提供所需的服务能力。Progressing=False表示更新过程已经停滞。相反，即使更新成功完成了，Progressing=True这一状态也可能会持续存在，因此一定要查看具体的原因以及副本的数量。

Deployment控制器会报告截止时间，但不会自动执行回滚操作。在截止时间点进行的快照显示中，缺失的图像仍然被视为所需的图像。

现在再次执行服务检查。在截止时间之后记录的十次请求，也都来自那些旧的Pod。只有在处理“图像相关的问题”时，才需要等待控制器的操作完成。

如何恢复健康的配置状态

在引发新的故障之前，立即进行恢复操作。请将BAD_POD设置为你刚刚检查过的那个出现故障的Pod：

k apply -f failure-lab/manifests/healthy.json
k rollout status deployment/rollout-demo --timeout=300s
k wait --for=delete "pod/$BAD_POD" --timeout=120s
k get deployment rollout-demo -o json
k get replicasets -l app=rollout-demo -o wide
k get pods -l app=rollout-demo -o wide
k get endpointslices -l kubernetes.io/service-name=rollout-demo -o json
k exec --pod-running-timeout=30s --request-timeout=60s http-client -- \
  python -u /app/probe.py --url http://rollout-demo:8080/ \
  --expected-version v2 --count 10 --interval 0.2

要检查整个恢复过程，而不仅仅是`rollout`命令是否成功执行。最终的配置状态应该与文件`healthy.json`中规定的内容一致。控制器必须已经观察到了这些变化：副本的数量、已更新的副本数量、处于“准备就绪”状态的副本数量，以及可用的副本数量，都应该是2。

最终应该只剩下两个应用程序Pod，它们都属于当前的ReplicaSet，且都处于“准备就绪”状态，并不会终止运行。它们的UID应该与那些处于“准备就绪”状态的Service端点相对应，而通过HTTP请求访问这些Pod时，应该能够得到版本号为v2的响应。

在最初的实验中，恢复操作是使用现有的健康状态下的ReplicaSet和那两个Pod来完成的。它们的配置模板本来就已经与需要恢复的状态相匹配了，因此出现故障的ReplicaSet会被自动缩减到0个副本。

尽管那些健康的Pod仍然存在，但修订信息却发生了变化。这些数据来自于之前的实验记录：

你的实验结果可能会与这些数据有所不同。请恢复已知的健康配置状态，而不要依赖这些示例中的修订数值。

如何诊断“准备就绪”状态失败的问题

在确认恢复操作成功之后，再引发第二次故障：

k apply -f failure-lab/manifests/readiness.json
k rollout status deployment/rollout-demo --timeout=10s

这次修改仅涉及`readinessProbe.httpGet.path`这个配置项，将其从`/ready`改为`/not-ready`。这样一来，短暂的监控等待时间又会导致操作超时。

重复之前针对“图像相关问题”所进行的检查流程。识别出新的ReplicaSet，将NEW_RS和BAD_POD设置为与新ReplicaSet相关的名称，然后使用新的Pod UID来查询相关事件信息。这次容器会成功启动，但对应的Pod仍然不会处于“准备就绪”状态。

以下数值是根据之前记录的Pod状态快照得出的：

Pod的事件信息解释了原因：

准备就绪检查失败：HTTP请求失败，状态码为404。

该应用程序没有处理/not-ready路径的请求。HTTP检查会接受200到399之间的响应代码，因此状态码为404表示检查失败。即使准备就绪检查失败，容器也会继续运行，同时会被标记为“未准备就绪”，系统会持续进行检测。请参阅相关文档以获取更多信息。

记录中还显示了一些短暂的启动错误，例如“连接被拒绝”。但这些错误本身并不能确定问题所在；因为这样的错误也可能发生在服务器正常开始响应请求之前。后来出现的404状态码说明该服务器确实接收到了请求，而结合其他变化的数据以及已知的路由信息，可以判断是探针路径设置不正确导致的问题。

准备就绪检查失败并没有导致容器重启，因此记录中的重启次数为0。这种情况不属于“崩溃循环”现象。

请重新执行EndpointSlice和Service的相关检测。新的Pod在记录中仍然显示为“未准备就绪”，而另外两个旧的Pod则处于正常运行状态，所有请求响应都来自这两个旧Pod。

该Service并未启用publishNotReadyAddresses功能。因此，端点的准备就绪状态设置非常重要，不能将这一现象普遍应用于所有的Service配置中。EndpointSlice文档中对这些规则和例外情况有详细说明。

关于相关背景知识，freeCodeCamp的Kubernetes自修复教程中也介绍了准备就绪状态的相关内容。其中提到，探针检查失败会导致新的部署任务无法顺利完成。

请再次执行完整的恢复流程，这次使用这个“未准备就绪”的Pod作为测试对象。在继续下一步操作之前，请确保系统中的v2版本已经恢复正常运行状态。

如何诊断放置约束问题

在第三次测试中，我们在Pod模板中添加了以下选择器：

nodeSelector:
  rollout-lab.example.com/placement: no-matching-node

请确认这个选择器确实不会与任何节点匹配，然后再将其应用到Pod模板中：

k get nodes -l rollout-lab.example.com/placement=no-matching-node
k apply -f failure-lab/manifests/scheduling.json
k rollout status deployment/rollout-demo --timeout=10s

如果第一个命令返回了某个节点的信息，那就说明预期的“选择器不匹配任何节点”的情况并没有发生。在继续下一步操作之前，请先检查标签配置是否正确。

需要再次进行所有权检查及事件状态检测，并根据当前情况更新NEW_RS、BAD_POD和POD_UID这些变量。新的Pod目前处于Pending状态，这与图像下载失败时的情况相同。Pending状态实际上表示该Pod既在等待调度任务，也在等待容器环境的配置完成，其中包括图像文件的下载过程。

以下是记录下来的各种故障情况：

调度系统显示的信息如下：

0/1个节点可用：有1个节点不符合Pod的节点选择条件。抢占机制：0/1个节点可用；由于无法满足选择条件，抢占机制对调度没有帮助。

由于没有任何节点符合选择条件，因此该Pod始终没有被分配给任何kubelet节点，图像下载操作也从未开始。Kubernetes要求所有节点都必须满足指定的nodeSelector标签要求，这一点在Kubernetes的节点选择机制文档中有详细说明。

请重新执行相关检查。这个未能成功调度的Pod既没有IP地址，也没有EndpointSlice条目；而之前的Pod们则都返回了预期的响应结果。

再次按照整个恢复流程进行操作，这次将这个调度失败的Pod作为BAD_POD来使用。确认v2版本的Kubernetes系统运行正常，且相关服务能够正常响应请求。本次实验主要是用来测试节点选择条件不匹配导致的问题，并非为了检测资源耗尽或其他所有可能的调度故障情况。

如何进行清理

在保存好所有记录之后，请删除这个临时创建的实验室环境：

bash cleanup.sh

该脚本会选中Colima环境的Docker上下文，然后删除fcc-rollout-lab实验室目录，并明确指定要使用的kubeconfig文件。脚本还会记录操作结果，并检查其他类型的集群名称是否发生了变化。这样就可以彻底清除这个实验室环境创建后产生的所有工作负载。

所有的证据文件会保存在本地的对应目录中。如果想要再次运行这个实验，就需要在清理完成后重新提取相关数据；因为系统会自动拒绝使用之前的kubeconfig文件。

结论

共有三种不同的故障原因导致了新版本的部署失败，而之前的版本却能够正常响应所有请求：

在下次遇到部署失败的情况时，请从Deployment开始，依次检查其对应的ReplicaSet和Pod。需要确认Pod是否已经被成功调度、容器是否已经启动以及它是否已经处于“准备就绪”状态。通过查看相关的条件设置和事件记录，可以找出导致故障的具体原因；然后再根据服务端的响应结果，确定哪些Pod实际上完成了请求处理。