web-dev-qa-db-fra.com

bonne façon d'utiliser les montres kubernetes

Je suis nouveau sur Kubernetes et je ne sais pas vraiment comment procéder pour implémenter correctement une montre; en particulier, je ne suis pas sûr de savoir comment gérer le paramètre resourceVersion.

Le but est de surveiller les nouveaux pods avec une étiquette spécifique, et en cas d'erreur ou de déconnexion du cluster de pouvoir redémarrer la veille depuis le dernier événement survenu.

Je fais quelque chose comme ça:

// after setting up the connection and some parameters
String lastResourceVersion = null; // at beginning version is unknown
while (true) {
  try {
    Watch<V1Pod> watcher = Watch.createWatch(
            client,
            api.listNamespacedPodCall(namespace, pretty, fieldSelector, labelSelector, lastResourceVersion, forEver, true, null, null),
            new TypeToken<Watch.Response<V1Pod>>() {}.getType()
    );
    for (Watch.Response<V1Pod> item : watcher) {
      //increment the version
      lastResourceVersion = item.object.getMetadata().getResourceVersion();
      // do some stuff with the pod
    }
  } catch (ApiException apiException) {
    log.error("restarting the watch from "+lastResourceVersion, apiException);
  }
}

Est-il correct d'utiliser la version de ressource d'un pod pour réinitialiser l'appel de surveillance? Ce nombre est-il une sorte d'horodatage pour tous les événements du cluster, ou différentes API utiliseront-elles des séquences différentes?

Dois-je surveiller des exceptions spécifiques? par exemple. en cas de ressourceVersion est trop ancienne?

merci

kuberneteswatch
10
G. Bricconi

Adam a raison.

Ceci est mieux expliqué par https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

Citant les parties pertinentes (c'est moi qui souligne):

Lors de la récupération d'une collection de ressources (espace de noms ou cluster), la réponse du serveur contiendra une valeur resourceVersion qui peut être utilisée pour lancer une surveillance contre le serveur.

... snip ...

Lorsque les opérations de surveillance demandées échouent parce que la version historique de cette ressource n'est pas disponible, les clients doivent gérer le cas en reconnaissant le code d'état 410 Gone, en effaçant leur cache local, en effectuant une opération de liste, et démarrage de la surveillance à partir de la resourceVersion renvoyée par cette nouvelle opération de liste.

Donc, avant d'appeler watch, vous devez lister et extraire le resourceVersion de la liste (pas les objets à l'intérieur). Ensuite, démarrez la montre avec cette ressourceVersion. Si la surveillance échoue pour une raison quelconque, vous devrez à nouveau répertorier, puis utiliser la version de ressource de cette liste pour rétablir la surveillance.

4
krousey