使用Kubernetes Java客户端创建Deployment后Pod状态显示异常排查

阿华AIGC实验室

2026-5-15

问题分析与解决方案

看起来你遇到的问题主要是API版本不兼容和客户端缓存/数据同步延迟导致的，下面一步步拆解原因和解决办法：

1. 核心问题：使用了过时的Deployment API

你代码里创建Deployment用的是client.extensions().deployments()，这个对应的是旧的extensions/v1beta1 API版本。现在Kubernetes早已将Deployment迁移到apps/v1 API组，旧API不仅可能被集群弃用，还会导致客户端与API Server交互时返回的资源结构不完整，甚至状态同步延迟。

修复方式：切换到`apps/v1` API

改用apps/v1 API创建Deployment，同时确保导入对应版本的模型类：

// 替换旧的import，确保使用apps/v1版本的Deployment模型
import io.kubernetes.client.openapi.models.V1Deployment;
import io.kubernetes.client.openapi.models.V1DeploymentBuilder;

// 重构创建Deployment的代码
V1Deployment deployment = new V1DeploymentBuilder()
    .withNewMetadata()
        .withName("first-deployment")
    .endMetadata()
    .withNewSpec()
        .withReplicas(3)
        .withNewTemplate()
            .withNewMetadata()
                .addToLabels(namespaceID, "hello-world-example")
            .endMetadata()
            .withNewSpec()
                .addNewContainer()
                    .withName("nginx-one")
                    .withImage("nginx")
                    .addNewPort()
                        .withContainerPort(80)
                    .endPort()
                    .withResources(resourceRequirements)
                .endContainer()
            .endSpec()
        .endTemplate()
    .endSpec()
    .build();

// 使用apps API创建Deployment
deployment = client.apps().deployments().inNamespace(namespace).create(deployment);

2. 客户端缓存导致获取旧状态

Kubernetes Java客户端默认会启用本地缓存优化请求性能，即使你等待了3分钟，直接调用list()可能还是拿到缓存里的旧数据（也就是Pod处于Pending状态时的快照）。而kubectl每次请求都是直接从API Server拉取最新数据，所以能看到Running状态。

修复方式：强制刷新获取最新数据

在list()前添加withResourceVersion("0")参数，这个配置会告诉客户端忽略本地缓存，直接从API Server拉取最新资源状态：

PodList podList = client.pods()
    .withLabel(namespaceID, "hello-world-example")
    .withResourceVersion("0") // 强制跳过缓存，拉取最新数据
    .list();

// 输出时增加null判断，避免空指针异常
for (Pod pod : podList.getItems()) {
    String reason = pod.getStatus().getReason() != null ? pod.getStatus().getReason() : "N/A";
    String limits = pod.getSpec().getContainers().get(0).getResources() != null 
        && pod.getSpec().getContainers().get(0).getResources().getLimits() != null 
        ? pod.getSpec().getContainers().get(0).getResources().getLimits().toString() 
        : "N/A";
    
    System.out.println(String.format("Name %s Status %s Reason %s Containers Limits %s",
        pod.getMetadata().getName(),
        pod.getStatus().getPhase(),
        reason,
        limits));
}

3. 进阶优化：用Watch机制监听Pod状态（更可靠）

固定等待3分钟不是可靠的做法，推荐使用Kubernetes的Watch API监听Pod状态变化，直到所有Pod进入Running状态：

// 监听符合标签的Pod状态变更
Watch<Pod> watch = client.pods()
    .withLabel(namespaceID, "hello-world-example")
    .watch(new Watcher<Pod>() {
        int runningPods = 0;
        final int expectedPods = 3;

        @Override
        public void eventReceived(Action action, Pod pod) {
            String podName = pod.getMetadata().getName();
            Phase phase = pod.getStatus().getPhase();
            
            System.out.println(String.format("Pod %s %s -> %s", podName, action, phase));
            
            // 统计Running状态的Pod数量，全部就绪后关闭监听
            if (Phase.RUNNING.equals(phase) && Action.MODIFIED.equals(action)) {
                runningPods++;
                if (runningPods == expectedPods) {
                    try {
                        close();
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
            }
        }

        @Override
        public void onClose(WatcherException cause) {
            System.out.println("监听关闭: " + cause.getMessage());
        }
    });

// 等待监听完成（可添加超时时间）
watch.awaitTermination(5, TimeUnit.MINUTES);
watch.close();