D'une manière ou d'une autre, dans les commentaires, ils ont posé la question de savoir en quoi la participation au Slurm diffère de la lecture des manuels sur Kubernetes. J'ai demandé à Pavel Selivanov, président de Slurm-2 et MegaSlurm, de donner un petit exemple de ce qu'il dira sur Slurm. Je lui donne la parole.
J'administre le cluster Kubernetes. Récemment, j'ai dû mettre à jour la version de k8s et, notamment, redémarrer toutes les machines du cluster. J'ai commencé le processus à 12h00 et à la fin de la journée de travail, tout était prêt. Et pour la première fois, j'ai tout de même suivi la progression de la mise à jour, et la deuxième fois je suis parti déjeuner pour une heure et demie (en toute honnêteté, en saisissant un ordinateur portable). Le cluster a été mis à jour lui-même, sans ma participation et de manière invisible pour les clients, le développement n'a rien remarqué, les déploiements se sont poursuivis, le service a fonctionné comme d'habitude.
À quoi cela ressemblait.
Problèmes probables
Lors du redémarrage des machines, il existe deux mauvais scénarios.
- Le développeur a lancé l'application / redis dans une seule instance. Peu importe la précaution avec laquelle vous mettez la voiture hors service, des temps d'arrêt se produiront.
- Il existe 2 répliques de l'application et une est déployée. Elle est sortie, il n'y avait qu'une seule réplique, puis l'administrateur vient et éteint la dernière réplique. Encore une fois, jusqu'à ce que la réplique augmente après le déploiement, il y aura des temps d'arrêt.
Je pourrais coordonner le redémarrage avec le développement, disent-ils, arrêter le déploiement, vérifier les instances, je redémarrerai les machines, mais j'aime l'idée DevOps que la communication humaine doit être minimisée. Il est préférable de configurer l'automatisation une fois que de coordonner vos actions à chaque fois.
Conditions de tâche
J'utilise Amazon avec sa commodité et sa stabilité. Tout est automatisé, vous pouvez créer et éteindre des machines virtuelles, vérifier leur disponibilité, etc.
Le cluster Kubernetes est déployé, géré et mis à jour via l'utilitaire kops, que j'aime beaucoup.
Lors de la mise à jour de kops, il draine automatiquement un nœud (nœud de drainage kubectl), attend jusqu'à ce que tout ait été évacué de ce nœud, le supprime, crée un nouveau nœud dans Amazon avec la version correcte des composants Kubernetes, l'attache au cluster, vérifie que le nœud est bien entré dans le cluster, et donc avec tous les nœuds dans un cercle jusqu'à ce que la version souhaitée de Kubernetes soit partout.
Solution
Dans CI, j'utilise kube-lint pour vérifier tous les manifestes qui seront lancés dans Kubernetes. Helm Template jette tout ce qu'il va lancer, j'ai mis un linter pour le déchargement, qui évalue tout selon les règles données.
Par exemple, l'une des règles stipule que pour toute application du cluster Kubernetes, le nombre de réplicas doit être d'au moins 2.
S'il n'y a pas de réplicas du tout (ce qui par défaut est 1), il y en a 0 ou 1, kube-lint interdit le déploiement sur le cluster afin d'éviter de futurs problèmes.
Imaginons que le déploiement par conception soit conçu de sorte qu'il n'y ait qu'une seule réplique. Dans ce cas, il existe un budget de perturbation des pods, où max_unavailable et min_available sont définis pour une application exécutée dans Kubernetes. Si vous souhaitez toujours avoir au moins 1 réplique, définissez min_available = 1.
Il y avait 2 répliques, le déploiement a commencé, 1 réplique est morte, il en restait 1. Sur la machine où réside la réplique, l'administrateur démarre le nœud de vidange kubectl. En théorie, Kubernetes devrait commencer à supprimer ce signal en direct et à le transporter vers un autre nœud. Mais le budget de perturbation des pods fonctionne. Kubernetes dit à l'administrateur: désolé, la réplique vit ici, si nous la supprimons, nous violerons le budget de perturbation du pod. Le nœud de drain intelligent se bloque avant l'expiration du délai d'expiration et essaie de dériver le nœud. Si le déploiement est terminé et que les deux réplicas deviennent disponibles, le réplica sur ce nœud sera affiché.
Chez MegaSlerme, je montrerai un ensemble complet de règles qui me permet de boire du café dans un café pendant que le cluster Kubernetes est mis à jour avec un redémarrage de tous les nœuds.
Mes sujets sur Slurm :
- Présentation de Kubernetes, composants clés
- Périphérique de cluster, composants principaux, tolérance aux pannes, réseau k8s
- Abstractions avancées de Kubernetes
- Journalisation et surveillance
Mes sujets sur MegaSlerme :
- Processus de cluster de basculement interne
- Autorisation de cluster à l'aide d'un fournisseur externe
- Applications sécurisées et hautement disponibles dans le cluster
- Implémentation de stratégies de déploiement autres que RollingUpdate
- Dépannage à Kubernetes