使用fabric8 kubernetes client重建deployment后如何按标签获取最新Pod

问题根因 #

• 标签匹配逻辑错误：你当前使用Deployment自身元数据的labels（deployment.metadata.labels）查询Pod，但该标签是绑定在Deployment资源对象本身的，并非Deployment用于匹配所属Pod的规则。Deployment实际是通过spec.selector.matchLabels匹配管理的Pod，如果你新旧Deployment的自身标签没有变更，旧Pod的标签和该值匹配就会被误查出来。
• 集群状态异步延迟：Deployment的重建（无论是替换还是删了重建）对应的Pod销毁、调度、启动都是异步操作。你执行完Deployment操作后立刻查询Pod，旧Pod尚未完全销毁退出、新Pod还未完成创建，就会只返回残留的旧Pod。
• 删除操作未等待级联完成：删除Deployment默认触发级联删除Pod，但该操作需要几秒的执行时间，你删除后立刻创建同名Deployment，旧Pod还处于Terminating阶段未被清理，查询时仍然会被纳入结果。

解决方案 #

1. 修正Pod查询逻辑 #

将查询Pod的标签替换为Deployment定义中spec.selector.matchLabels，这才是Deployment和Pod绑定的官方匹配规则，修正后的代码如下：

List<Pod> otelCollectorPods =
  client
    .pods()
    .inNamespace(LOGCOLLECTION_NAMESPACE)
    // 替换为selector的matchLabels，不要用Deployment自身的labels
    .withLabels(otelCollectorDeployment.getSpec().getSelector().getMatchLabels())
    .list()
    .getItems();

2. 增加状态等待逻辑 #

根据你使用的重建方式增加对应等待逻辑，确保查询时集群状态已经收敛：

先删后建场景

删除Deployment后，循环等待对应selector下的Pod完全清理后再执行创建操作：

// 先删除Deployment
client
  .apps()
  .deployments()
  .inNamespace(LOGCOLLECTION_NAMESPACE)
  .withName(otelCollectorDeployment.getMetadata().getName())
  .delete();

// 等待旧Pod全部清理，无Wait工具类可自行实现循环查询逻辑
Wait.until(
  () -> client
    .pods()
    .inNamespace(LOGCOLLECTION_NAMESPACE)
    .withLabels(otelCollectorDeployment.getSpec().getSelector().getMatchLabels())
    .list()
    .getItems()
    .isEmpty(),
  Duration.ofSeconds(30), // 最多等待30秒
  Duration.ofSeconds(1) // 每秒轮询一次
);

// 再创建新的Deployment
client
  .apps()
  .deployments()
  .inNamespace(LOGCOLLECTION_NAMESPACE)
  .create(otelCollectorDeployment);

替换更新场景

调用createOrReplace后，等待新Pod就绪、且所有返回的Pod的ownerReference指向新的Deployment：

// 先执行替换操作，获取新创建的Deployment对象
Deployment newDeploy = client
  .apps()
  .deployments()
  .inNamespace(LOGCOLLECTION_NAMESPACE)
  .withName(otelCollectorDeployment.getMetadata().getName())
  .createOrReplace(otelCollectorDeployment);
String newDeployUid = newDeploy.getMetadata().getUid();

// 等待所有匹配的Pod都归属于新的Deployment且处于就绪状态
Wait.until(
  () -> {
    List<Pod> pods = client
      .pods()
      .inNamespace(LOGCOLLECTION_NAMESPACE)
      .withLabels(newDeploy.getSpec().getSelector().getMatchLabels())
      .list()
      .getItems();
    if(pods.isEmpty()) return false;
    for(Pod pod : pods) {
      // 检查Pod的所有者是不是新的Deployment
      boolean ownerMatch = pod.getMetadata().getOwnerReferences()
        .stream()
        .anyMatch(ref -> ref.getUid().equals(newDeployUid));
      // 检查Pod是否处于就绪状态
      boolean ready = pod.getStatus().getConditions()
        .stream()
        .anyMatch(cond -> "Ready".equals(cond.getType()) && "True".equals(cond.getStatus()));
      if(!ownerMatch || !ready) return false;
    }
    return true;
  },
  Duration.ofSeconds(60),
  Duration.ofSeconds(2)
);

3. 可选优化：增加版本标签隔离 #

每次更新Deployment时，在spec.template.metadata.labels中增加一个版本标签（比如app-version），每次更新时修改该标签值，查询时直接带上版本标签，完全避免和旧版本Pod混淆。

内容的提问来源于stack exchange，提问作者lprakashv