Imaginez le scénario suivant :
- Vous exécutez un cluster kubernetes dans votre centre de données, qui a été déployé avec kubeadm.
- Il se compose d'un masternode (exécutant etcd en tant que pod statique, tel que déployé par kubeadm) et de trois nœuds de travail.
- les noeuds en tant que machines virtuelles fonctionnant sur vmware
Aujourd'hui, vous ouvrez votre courrier électronique et vous êtes informé que le centre de données va déménager vers un nouveau site. Les serveurs physiques seront éteints, déplacés vers le nouveau site et remis sous tension.
Quelle est la procédure d'arrêt correcte pour votre cluster kubernetes (sans perturber vos données etcd) ?
C'est ce que j'ai fait :
- J'ai d'abord arrêté le serveur maître (ce qui inclut etcd bien sûr), pour éviter que les pods ne soient reprogrammés sur d'autres nœuds lorsque j'éteins les nœuds ouvriers.
- arrêté chaque nœud de travail
Après la migration :
- mettre sous tension les nœuds de travail en premier
- alimenté sur le nœud maître suivant
Après avoir fait cela, je me suis retrouvé avec l'un des deux scénarios suivants :
- les données etcd sont corrompues et le pod etcd sort avec une erreur
- Je reçois des erreurs comme celle-ci : "Operation cannot be fulfilled on nodes "worker-002" : the object has been modified ; please apply your changes to the latest version and try again". Mes journaux sont inondés de ces messages.
Comment cela aurait-il pu être évité ? Je ne pense pas que l'exécution d'Etcd en mode HA soit utile ici, car tous les nœuds d'Etcd devraient également être arrêtés en même temps, et vous vous retrouvez dans une situation similaire à celle d'un scénario à nœud unique. J'ai l'impression que Etcd est assez... fragile, comparé à d'autres magasins K/V comme Consul.
