Le 23 septembre à 20h00 MSK, Sergey Bondarev animera un webinaire gratuit «», où il expliquera comment préparer kubespray afin qu'il soit rapide, efficace et tolérant aux pannes.
Sergey Bondarev expliquera la différence entre la version originale et notre fork :
La différence entre la version originale et notre fork.
Ceux qui ont déjà travaillé avec kubespray se demandent sans doute pourquoi je oppose kubeadm à kubespray, puisque kubespray appelle kubeadm pour créer un cluster, et à première vue, cela ressemble à un script pour installer des paquets et démarrer automatiquement.
Mais ce n'était pas toujours le cas, au départ kubespray installait tous les composants lui-même :
- il rassemblait le cluster etcd ;
- installait les kubelets, générait des certificats, des configurations et des tokens d'accès pour les pods statiques de la control plane et d'autres composants de service ;
- créait des comptes de service pour les nœuds de travail et les connectait au cluster.
Mais l'année d'avant celle dernière, ils ont supprimé cette fonctionnalité, ne conservant que kubeadm, qui, à l'époque, n'était pas très bon. Cela m’a déçu et j'ai créé mon propre fork, où j'ai maintenu le mode d'installation classique, et je maintiens maintenant ce fork à jour, en cherry-pickant des commits de l'original kubespray. En même temps, j'améliore le mode classique pour l'adapter aux nouvelles modifications.
En fin de compte, la différence entre les clusters créés par mon fork et l'original réside dans kube-proxy et la durée de validité des certificats.
Dans mon fork, tout est resté comme avant — kube-proxy s'exécute comme un pod statique, et les certificats sont délivrés pour 100 ans.
Dans Kubeadm, kube-proxy s'exécute comme un daemonset, et les certificats sont délivrés pour 1 an, et ils doivent être renouvelés périodiquement. kubeadm a enfin appris à le faire en une seule commande.
La différence est minime, et aujourd'hui, nous utilisons les deux options.
Caractéristiques (inconvénients) lors de l'exploitation industrielle :
Le scénario est universel, donc pas très rapide. La solution personnalisée peut être considérablement accélérée en supprimant les vérifications et en démarrant à partir d'une image prête.
Le scénario est complexe, avec des incohérences et un lourd héritage legacy. L'installation de contrôleurs supplémentaires et de logiciels via Kubespray est excellente pour l'apprentissage et les tests. En production, dépendre de Kubespray n'est pas une idée très judicieuse, de plus, les mises à jour du logiciel sont réalisées par la méthode "j'ai détruit et refait" — ce qui implique un arrêt du service.
On peut seulement ajouter des nœuds de travail, il y a quelques nuances avec les maîtres concernant les certificats, et le scénario ne traite pas tous les problèmes possibles qui pourraient survenir.
Par exemple, j'ai rencontré un problème avec kubeadm, lorsqu'il plantait lors de l'ajout du deuxième et du troisième maître, et après cela, Kubespray exécutait kubeadm reset sur le nœud, puis essayait d'ajouter le maître à nouveau.
Le problème était que, au moment de l'échec, la deuxième instance etcd avait déjà réussi à s'enregistrer, et comme elle était également supprimée après le reset, cela devenait un cauchemar — un cluster etcd de deux nœuds, dont un était supprimé, et l'autre ne prenait plus de clients. En fin de compte, le cluster est mort avant même de naître.
Open source tel quel.
Tout cela et bien plus encore lors du webinaire gratuit «» le 23 septembre à 20h00 MSK.
Rejoignez-nous !
Source : habr.com
