Recommandations concernant la mise à niveau

Meilleure pratique : utiliser la dernière version de Kubernetes

Les nouvelles versions de Kubernetes incluent généralement de nombreuses mises à jour, des fonctionnalités supplémentaires et, surtout, des correctifs pour résoudre les problèmes de sécurité dans les versions précédentes. Kubernetes Engine prend en charge trois versions mineures de Kubernetes, avec la dernière version de patch pour chacune de ces versions.

Il est donc recommandé :

• Les clusters de production exécutent toujours la dernière version stable de Kubernetes.
• Vous indiquez la dernière version mineure prise en charge de Kubernetes lors de la création de clusters à l'aide de Kubernetes Engine.
• Vous mettez à niveau les clusters existants lorsqu'Oracle annonce la prise en charge de Kubernetes Engine pour une version majeure de Kubernetes, une version mineure ou une version de patch. La mise à niveau régulière des clusters vous permet d'éviter les situations où les clusters exécutent des versions plus anciennes de Kubernetes qui n'incluent pas les dernières fonctionnalités et corrections.

Reportez-vous à Versions Kubernetes et moteur Kubernetes (OKE), Mise à niveau des clusters vers des versions de Kubernetes plus récentes.

Meilleure pratique : Configurer des environnements de test et de production

Nous vous recommandons d'utiliser plusieurs environnements Kubernetes Engine dans le cadre d'un workflow pour déployer et publier des applications. L'utilisation de plusieurs environnements permet de minimiser les risques et les temps d'arrêt indésirables en vous permettant de tester les mises à jour logicielles et d'infrastructure dans un environnement distinct de l'environnement de production. Au minimum, nous vous recommandons de disposer d'un environnement de production et d'un environnement de pré-production ou de test.

Avant de mettre à niveau un cluster vers une nouvelle version de Kubernetes, nous vous recommandons également de tester toutes les applications déployées sur le cluster pour vérifier qu'elles sont compatibles avec la nouvelle version de Kubernetes. Une fois que vous avez mis à niveau les noeuds de plan de contrôle vers une version plus récente de Kubernetes, vous ne pouvez pas les faire revenir à une version antérieure de Kubernetes. Il est donc important de tester les applications avant de mettre à niveau le cluster vers une nouvelle version de Kubernetes. Par exemple, avant de mettre à niveau un cluster, vous pouvez créer un cluster distinct exécutant la nouvelle version de Kubernetes et tester des applications sur ce cluster.

Reportez-vous à Mise à niveau des clusters vers des versions de Kubernetes plus récentes.

Meilleure pratique : utiliser une stratégie de déploiement bleu/vert

Nous vous recommandons d'utiliser une stratégie de déploiement bleu-vert pour réduire les risques et minimiser les temps d'arrêt lors de la mise à niveau des clusters Kubernetes. Les déploiements bleu-vert utilisent deux environnements de production, appelés "bleu" et "vert", pour fournir des tests fiables, des mises à niveau continues sans coupure et des annulations instantanées. L'utilisation d'une stratégie de déploiement bleu/vert garantit que les utilisateurs ont accès à un environnement de production pendant la mise à jour de l'autre environnement de production.

Meilleure pratique : Programmer des fenêtres de maintenance

Nous vous recommandons de programmer des activités de maintenance pendant les heures creuses afin de limiter l'impact sur les applications qui ne gèrent pas correctement l'interruption de pod causée par les mises à niveau et la maintenance de cluster/noeud.

Par exemple, lors des mises à niveau, il peut y avoir des interruptions temporaires lorsque des charges globales sont déplacées afin de recréer des noeuds. Pour s'assurer que ces perturbations causent un impact minimal, dans la mesure du possible :

• planifier des mises à niveau pour les heures creuses
• Concevoir des déploiements d'applications pour gérer les perturbations partielles de manière transparente

Meilleure pratique : traiter les noeuds de processus actifs comme non mutables

Nous vous recommandons de traiter les noeuds de processus actif existants comme des entités non mutables.

Les modifications apportées aux propriétés des noeuds de processus actifs d'un pool de noeuds ne s'appliquent qu'aux nouveaux noeuds créés par la suite. Vous ne pouvez pas modifier les propriétés des noeuds de processus actifs existants.

Par exemple, plutôt que de mettre à jour l'image de système d'exploitation exécutée sur des noeuds de processus actif existants, envisagez de créer un pool de noeuds avec des noeuds de processus actif dotés de l'image de système d'exploitation mise à jour. Une fois que vous avez spécifié des options de cordon et de purge pour le pool de noeuds d'origine afin d'empêcher les nouveaux pods de démarrer et de supprimer les pods existants, vous pouvez déplacer le travail du pool de noeuds d'origine vers le nouveau pool de noeuds. Vous pouvez ensuite supprimer le pool de noeuds d'origine.

Reportez-vous à Création de noeuds de salarié avec des propriétés mises à jour.

Meilleure pratique : Cordon et purge des noeuds de processus actifs en préparation de la maintenance

Nous vous recommandons de mettre en cordon et de purger un noeud de processus actif avant la maintenance programmée sur ce noeud.

Le cordon marque un noeud de processus actif comme non programmable et empêche le kube-scheduler de placer de nouveaux pods sur ce noeud. La purge expulse en toute sécurité les pods d'un noeud de processus actif, ce qui garantit que les conteneurs se terminent progressivement et effectuent tout nettoyage nécessaire.

Reportez-vous à la section Cordoning and Draining Managed Nodes Before Shut Down or Termination. Reportez-vous également aux sections Administration manuelle des noeuds et Drainage sécurisé d'un noeud dans la documentation Kubernetes.