Mise à niveau des clusters vers des versions de Kubernetes plus récentes
Découvrez les différentes façons de mettre à niveau les noeuds de plan de contrôle et les noeuds de processus actif vers des versions plus récentes de Kubernetes à l'aide de Kubernetes Engine (OKE).
Lorsqu'une nouvelle version de Kubernetes est publiée et que Kubernetes Engine prend en charge cette nouvelle version, vous pouvez mettre à niveau la version de Kubernetes exécutée sur les noeuds de plan de contrôle et les noeuds de processus actif d'un cluster.
Les noeuds de plan de contrôle et les noeuds de processus actif qui composent le cluster peuvent exécuter différentes versions de Kubernetes, à condition de suivre la stratégie de prise en charge des écarts de version de Kubernetes décrite dans la documentation Kubernetes.
Les noeuds de plan de contrôle et les noeuds de processus actif sont mis à niveau différemment :
-
Mise à niveau d'un noeud de plan de contrôle : vous mettez à niveau les noeuds de plan de contrôle en mettant à niveau le cluster et en spécifiant une version de Kubernetes plus récente pour ce dernier. Les noeuds de plan de contrôle exécutant d'anciennes versions de Kubernetes sont mis à niveau. Etant donné que Kubernetes Engine distribue le plan de contrôle Kubernetes sur plusieurs noeuds de plan de contrôle gérés par Oracle afin de garantir une haute disponibilité (répartis entre différents domaines de disponibilité dans une région où ils sont pris en charge), vous pouvez mettre à niveau la version de Kubernetes exécutée sur les noeuds de plan de contrôle sans aucun temps d'inactivité.
Une fois que vous avez mis à niveau les noeuds de plan de contrôle vers une nouvelle version de Kubernetes, vous pouvez créer des pools de noeuds de processus actif exécutant la nouvelle version. Vous pouvez également continuer à créer des pools de noeuds de processus actif exécutant d'anciennes versions de Kubernetes (à condition que ces anciennes versions soient compatibles avec la version de Kubernetes exécutée sur les noeuds de plan de contrôle).
Pour plus d'informations sur la mise à niveau d'un noeud de plan de contrôle, reportez-vous à Mise à niveau de la version de Kubernetes sur les noeuds de plan de contrôle dans un cluster.
- Mise à niveau d'un noeud de salarié : vous mettez à niveau les noeuds gérés, les noeuds autogérés et les noeuds virtuels différemment :
- Mise à niveau de noeud gérée : vous pouvez mettre à niveau les noeuds de processus actifs de l'une des manières suivantes :
- En effectuant une mise à niveau "in-place" d'un pool de noeuds dans le cluster, en indiquant une version Kubernetes plus récente pour le pool de noeuds existant, puis en cyclant les noeuds pour remplacer les volumes d'initialisation des instances hébergeant des noeuds de processus actifs existants, ou pour mettre fin et remplacer des noeuds de processus actifs existants.
- En effectuant une mise à niveau "sur place" d'un pool de noeuds dans le cluster, en indiquant une version de Kubernetes plus récente pour le pool de noeuds existant, puis en remplaçant manuellement chaque noeud de processus actif existant par un nouveau noeud de processus actif.
- en effectuant une mise à niveau "sans réutilisation de la mémoire" d'un pool de noeuds dans le cluster, c'est-à-dire en remplaçant le pool de noeuds d'origine par un nouveau pool de noeuds pour lequel vous avez spécifié une version de Kubernetes plus récente.
Pour plus d'informations sur la mise à niveau de noeud géré, reportez-vous à Mise à niveau de noeuds gérés vers une version de Kubernetes plus récente.
- Mise à niveau de noeud autogérée : vous mettez à niveau des noeuds autogérés en remplaçant un noeud autogéré existant par un nouveau noeud autogéré hébergé sur une nouvelle instance de calcul. Pour plus d'informations sur la mise à niveau de noeuds autogérés, reportez-vous à Mise à niveau de noeuds autogérés vers une version de plus récente de Kubernetes en remplaçant un noeud autogéré existant.
- Mise à niveau de noeud virtuel : vous mettez à niveau les noeuds virtuels en mettant à niveau les noeuds de plan de contrôle dans un cluster. Lorsque vous mettez à niveau la version de Kubernetes exécutée sur les noeuds de plan de contrôle, les noeuds virtuels de chaque pool de noeuds virtuels du cluster sont également automatiquement mis à niveau vers cette version de Kubernetes. Pour plus d'informations sur la mise à niveau de noeud virtuel, reportez-vous à Mise à niveau de noeuds virtuels vers une version de Kubernetes plus récente.
- Mise à niveau de noeud gérée : vous pouvez mettre à niveau les noeuds de processus actifs de l'une des manières suivantes :
Pour en savoir plus sur les versions de Kubernetes actuellement et précédemment prises en charge par Kubernetes Engine, reportez-vous à Versions de Kubernetes prises en charge.
Remarques sur la mise à niveau des clusters
Tenez compte des éléments suivants lors de la mise à niveau des clusters :
- Le moteur Kubernetes met uniquement à niveau la version de Kubernetes exécutée sur les noeuds de plan de contrôle lorsque vous lancez explicitement l'opération de mise à niveau.
- 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.
- Avant de mettre à niveau la version de Kubernetes exécutée sur les noeuds de plan de contrôle, il vous incombe de vérifier si les applications déployées sur le cluster sont compatibles avec la nouvelle version de Kubernetes. Par exemple, avant de mettre à niveau le cluster existant, vous pouvez créer un cluster distinct comportant la nouvelle version de Kubernetes pour tester vos applications.
- Les versions de Kubernetes exécutées sur les noeuds de plan de contrôle et les noeuds de processus actif doivent être compatibles. En d'autres termes, la version de Kubernetes sur les noeuds de plan de contrôle ne doit pas comporter plus de deux versions mineures (ou trois versions mineures, à partir de la version 1.28 de Kubernetes) avant la version de Kubernetes sur les noeuds de processus actif. Reportez-vous à la stratégie de prise en charge des écarts de version de Kubernetes décrite dans la documentation Kubernetes.
- Si la version de Kubernetes actuellement exécutée sur les noeuds de plan de contrôle a plus d'une version de retard sur la version la plus récente prise en charge, vous avez plusieurs choix de versions vers lesquelles effectuer la mise à niveau. Pour effectuer une mise à niveau vers une version de Kubernetes ayant plus d'une version d'avance sur la version actuellement exécutée sur les noeuds de plan de contrôle, vous devez mettre à niveau les noeuds de plan de contrôle vers chaque version intermédiaire dans l'ordre sans en ignorer aucune (comme décrit dans la documentation Kubernetes).
-
Pour mettre à niveau les noeuds de plan de contrôle dans un cluster, le service de tableau de bord Kubernetes doit être de type ClusterIP. Si le service de tableau de bord Kubernetes n'est pas de type ClusterIP (par exemple, si le service est de type NodePort), la mise à niveau échoue. Dans ce cas, rétablissez le type ClusterIP pour le service de tableau de bord Kubernetes (par exemple, en saisissant
kubectl -n kube-system edit service kubernetes-dashboard
et en modifiant le type). - Avant Kubernetes version 1.14, Kubernetes Engine créait des clusters avec kube-dns en tant que serveur DNS. Cependant, à partir de la version 1.14 de Kubernetes, Kubernetes Engine crée des clusters avec CoreDNS en tant que serveur DNS. Lorsque vous mettez à niveau un cluster créé par Kubernetes Engine à partir d'une version antérieure à Kubernetes 1.14, le serveur kube-dns du cluster est automatiquement remplacé par le serveur CoreDNS. Si vous avez personnalisé le comportement de kube-dns à l'aide de l'objet ConfigMap kube-dns d'origine, les personnalisations ne sont pas transférées vers l'objet ConfigMap CoreDNS. Vous devrez créer et appliquer un objet ConfigMap contenant les personnalisations pour remplacer les paramètres du fichier Corefile CoreDNS. Pour plus d'informations sur la mise à niveau vers CoreDNS, reportez-vous à Configuration des serveurs DNS pour les clusters Kubernetes.