Kubernetes слишком старая версия ресурса - PullRequest
0 голосов
/ 24 апреля 2020

Я работаю над оператором, который создает часы для разных ресурсов k8s. Время от времени я вижу ниже исключения в журналах, и приложение просто останавливается. Что вызывает эту проблему и как я могу это исправить?

io.fabric8.kubernetes.client.KubernetesClientException: too old resource version: 29309228 (33284573)
    at kubernetes.client@4.6.4/io.fabric8.kubernetes.client.dsl.internal.WatchConnectionManager$1.onMessage(WatchConnectionManager.java:263)
    at okhttp3.internal.ws.RealWebSocket.onReadMessage(RealWebSocket.java:323)
    at okhttp3.internal.ws.WebSocketReader.readMessageFrame(WebSocketReader.java:219)
    at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.java:105)
    at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.java:274)
    at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:214)
    at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
    at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)

1 Ответ

0 голосов
/ 26 апреля 2020

Я из команды клиентов Fabric8 Kubernetes. Я думаю, что стандартное поведение Kubernetes давать 410 через некоторое время во время наблюдения. Обычно ответственность за это лежит на клиенте. В контексте часов он вернет HTTP_GONE, когда вы попросите увидеть изменения для resourceVersion, который слишком стар - то есть, когда он больше не может сказать вам, что изменилось с этой версии, так как изменилось слишком много вещей , В этом случае вам нужно будет начать заново, не указав resourceVersion, и в этом случае часы отправят вам текущее состояние того, что вы смотрите, а затем отправьте обновления с этого момента.

Fabric8 не справляется с обычными часами. Но он обрабатывает его в SharedInformer API, см. ReflectorWatcher . Я бы рекомендовал использовать информер API при написании операторов, так как это лучше, чем простой список и просмотр. Вот простой пример использования SharedInformer API:

try (KubernetesClient client = new DefaultKubernetesClient()) {
  SharedInformerFactory sharedInformerFactory = client.informers();
  SharedIndexInformer<Pod> podInformer = sharedInformerFactory.sharedIndexInformerFor(Pod.class, PodList.class, 30 * 1000L);
  podInformer.addEventHandler(new ResourceEventHandler<Pod>() {
    @Override
    public void onAdd(Pod pod) {
      // Handle Creation
    }

    @Override
    public void onUpdate(Pod oldPod, Pod newPod) {
      // Handle update
    }

    @Override
    public void onDelete(Pod pod, boolean deletedFinalStateUnknown) {
      // Handle deletion
    }
  });
  sharedInformerFactory.startAllRegisteredInformers();
}

Вы можете найти полную демонстрацию простого оператора с использованием Fabric8 SharedInformer API здесь: Оператор PodSet In Java

...