Présentation des extensions de cluster

Extensions indispensables

Les modules complémentaires de cluster essentiels sont des composants de base d'un cluster Kubernetes et sont requis pour qu'un cluster fonctionne correctement. Les principales extensions de cluster sont les suivantes :

• CoreDNS : l'extension CoreDNS est un serveur DNS autorisé à usage général. Il est modulaire et pluggable. Le moteur Kubernetes crée des clusters avec CoreDNS en tant que serveur DNS. Le processus kubelet sur chaque noeud de processus actif dirige les différents conteneurs vers le serveur DNS en vue de la conversion des noms DNS en adresses IP.
• kube-proxy : l'extension kube-proxy est le proxy réseau Kubernetes qui gère les règles réseau et achemine les demandes.
• Module d'extension CNI pour la mise en réseau de pod : l'un des modules d'extension CNI suivants permet d'implémenter la connectivité réseau pour les pods exécutés sur des noeuds de processus actif :
  • Module d'extension CNI OCI VCN-Native Pod Networking
  • plugin flannel CNI

  Les modules d'extension CNI configurent les interfaces réseau, provisionnent les adresses IP et maintiennent la connectivité.

Les modules complémentaires de cluster essentiels sont déployés par défaut dans les nouveaux clusters Kubernetes. Lorsque vous utilisez des clusters améliorés, vous pouvez configurer les modules complémentaires de cluster essentiels à l'aide de Kubernetes Engine.

Extensions facultatives

Les extensions de cluster facultatives sont des composants que vous pouvez choisir de déployer sur un cluster Kubernetes. Des modules complémentaires facultatifs étendent les fonctionnalités de base de Kubernetes afin d'améliorer la facilité de gestion et les performances des clusters. Exemples d'extensions de cluster facultatives :

• Tableau de bord Kubernetes : l'extension facultative Tableau de bord Kubernetes est une interface de gestion Web qui vous permet de déployer, de modifier, d'observer et de dépanner des applications en conteneur. En raison du manque de prise en charge de l'authentification extensible, nous déconseillons de déployer le tableau de bord Kubernetes sur les clusters de production. Pour plus d'informations, reportez-vous à Accès à un cluster à l'aide du tableau de bord Kubernetes.
• Tiller (non recommandé) : l'extension Tiller facultative est la partie serveur de Helm. Lorsque Tiller est exécuté dans le cluster, vous pouvez utiliser Helm pour gérer les ressources Kubernetes. Tiller a été supprimé de Helm dans la version 3 (et les versions ultérieures) en raison de risques de sécurité connus. En raison de ces risques de sécurité, nous vous recommandons vivement de ne pas déployer Tiller sur des clusters de production. Pour la même raison, le module complémentaire Tiller n'est pas affiché dans la console. Si vous décidez de déployer l'extension Tiller malgré les risques de sécurité, utilisez l'interface de ligne de commande ou l'API OCI.
• Opérateur de base de données : l'extension facultative Oracle Database Operator for Kubernetes étend l'API Kubernetes avec des ressources et des contrôleurs personnalisés pour automatiser la gestion du cycle de vie d'Oracle Database. Oracle Database Operator prend en charge diverses configurations de base de données et opérations de cycle de vie. Pour utiliser Oracle Database Operator en tant qu'extension de cluster, vous devez également déployer le gestionnaire de certificats (en mode autonome ou en tant qu'extension de cluster). Pour plus d'informations, reportez-vous à la documentation sur Oracle Database Operator for Kubernetes sur GitHub.
• Opérateur Weblogic : l'extension d'opérateur Kubernetes WebLogic facultative prend en charge l'exécution de domaines d'infrastructure Fusion Middleware et serveur WebLogic sur Kubernetes. Pour plus d'informations, reportez-vous à la documentation de l'opérateur Kubernetes WebLogic sur GitHub.
• Gestionnaire de certificats : l'extension facultative Gestionnaire de certificats, également appelée gestionnaire de certificats, ajoute des certificats et des émetteurs de certificats aux clusters Kubernetes en tant que types de ressource. Le gestionnaire de certificats simplifie également le processus d'obtention, d'utilisation et de renouvellement de ces certificats. Pour plus d'informations, reportez-vous à la documentation du gestionnaire de certificats sur GitHub.
• Outil de redimensionnement automatique de cluster : l'extension facultative de l'outil de redimensionnement automatique de cluster redimensionne automatiquement les pools de noeuds gérés d'un cluster en fonction des demandes de charge globale d'application à l'aide de l'outil de redimensionnement automatique de cluster Kubernetes. Le déploiement de l'outil de redimensionnement automatique de cluster Kubernetes en tant qu'extension de cluster plutôt qu'en tant que programme autonome simplifie la configuration et la maintenance continue. Vous pouvez également indiquer qu'Oracle doit mettre à jour l'outil de redimensionnement automatique de cluster Kubernetes automatiquement. Pour plus d'informations, reportez-vous à Utilisation de l'outil de redimensionnement automatique de cluster en tant qu'extension de cluster.
• Istio : l'extension Istio facultative fournit une résilience de trafic de référence automatisée, une collecte de mesures de service, un suivi distribué, le cryptage du trafic, des mises à niveau de protocole et des fonctionnalités de routage avancées pour toutes les communications entre services. Pour plus d'informations, reportez-vous à Utilisation d'Istio en tant qu'extension de cluster.
• Contrôleur d'entrée natif : le contrôleur d'entrée natif OCI facultatif équilibre la charge et achemine le trafic entrant vers des pods de service exécutés sur des noeuds de processus actif dans un cluster Kubernetes. Pour plus d'informations, reportez-vous à Utilisation du contrôleur d'entrée natif OCI en tant qu'extension de cluster.
• Serveur de mesures Kubernetes : le serveur facultatif de mesures Kubernetes est un agrégateur de données d'utilisation des ressources à l'ensemble du cluster. Le serveur de mesures Kubernetes collecte des mesures de ressource à partir du kubelet exécuté sur chaque noeud de processus actif et les expose dans le serveur d'API Kubernetes via l'API de mesures Kubernetes. Pour utiliser le serveur de mesures Kubernetes en tant qu'extension de cluster, vous devez également déployer un gestionnaire de certificats (autonome ou en tant qu'extension de cluster). Pour plus d'informations, reportez-vous à Utilisation du serveur de mesures Kubernetes en tant qu'extension de cluster.
• Module d'extension de GPU NVIDIA : l'extension de module d'extension de GPU NVIDIA facultative est un moyen pratique de gérer le module d'extension de périphérique NVIDIA pour Kubernetes. Le plug-in de périphérique NVIDIA pour Kubernetes est l'implémentation NVIDIA de la structure de plug-in de périphérique Kubernetes pour exposer le nombre de GPU NVIDIA sur chaque noeud de processus actif et suivre l'état de ces GPU. Pour plus d'informations sur le module d'extension de périphérique NVIDIA pour Kubernetes, reportez-vous à la documentation NVIDIA/k8s-device-plugin sur github.

Les modules complémentaires facultatifs du cluster ne sont pas déployés par défaut. Lorsque vous utilisez des clusters améliorés, vous pouvez choisir de déployer et de configurer un nombre croissant d'extensions de cluster facultatives à l'aide de Kubernetes Engine.

Mise à jour des versions de module

Lorsque vous activez un module complémentaire de cluster, vous pouvez indiquer qu'Oracle doit le mettre à jour automatiquement lorsque de nouvelles versions sont disponibles, ou que vous voulez choisir une version particulière du module à déployer.

• Si vous indiquez que vous souhaitez que l'extension soit automatiquement mise à jour (comportement par défaut), Oracle déploie la version la plus récente de l'extension qui prend en charge la version de Kubernetes indiquée pour le cluster. Si une nouvelle version du module est ensuite publiée, Oracle la met automatiquement à jour, à condition que le module mis à jour soit compatible avec les versions de Kubernetes actuellement prises en charge par Kubernetes Engine.

  Si vous configurez un module complémentaire à l'aide d'un ou de plusieurs des arguments de configuration de paire clé/valeur approuvés (reportez-vous à Arguments de configuration du module Cluster Add-on), la configuration est conservée lorsque le module complémentaire est mis à jour automatiquement. Cependant, notez que toutes les autres personnalisations que vous avez apportées au module sont ignorées lors de la mise à jour automatique.

  Gardez à l'esprit qu'il est de votre responsabilité de mettre à niveau les clusters pour exécuter des versions de Kubernetes prises en charge par Kubernetes Engine. Pour tirer parti des mises à jour automatiques des modules complémentaires, nous vous recommandons de mettre à niveau les clusters en temps opportun afin de garantir que les clusters exécutent toujours les versions prises en charge de Kubernetes. Les mises à jour d'un module complémentaire de cluster peuvent ne pas être compatibles avec les anciennes versions de Kubernetes que Kubernetes Engine ne prend plus en charge. Si un cluster exécute une version de Kubernetes non prise en charge qui est incompatible avec les mises à jour d'un module complémentaire de cluster, le module complémentaire n'est pas mis à jour automatiquement.

• Si vous spécifiez que vous souhaitez choisir la version du module à déployer, Oracle déploie la version du module que vous choisissez. Il vous incombe de vérifier que la version du module complémentaire est compatible avec la version de Kubernetes exécutée sur le cluster.

  Gardez à l'esprit qu'il vous incombe de mettre à niveau les clusters pour exécuter les versions de Kubernetes prises en charge par Kubernetes Engine. Lorsqu'Oracle annonce que Kubernetes Engine doit cesser la prise en charge d'une ancienne version de Kubernetes, il est de votre responsabilité de mettre à niveau tout cluster exécutant cette ancienne version de Kubernetes, ainsi que (si nécessaire) de mettre à jour l'extension vers une version compatible avec la nouvelle version de Kubernetes.

Après avoir activé un module de cluster et spécifié qu'Oracle doit le mettre à jour automatiquement, vous pouvez spécifier ensuite que vous voulez déployer une version particulière du module. De même, si vous avez indiqué qu'il fallait choisir la version du module à déployer, vous pouvez indiquer par la suite à la place qu'Oracle doit le mettre à jour automatiquement.

Notez que dans le cas de l'extension de module d'extension CNI OCI VCN-Native Pod Networking, que vous choisissiez Oracle de mettre à jour le module automatiquement ou que vous choisissiez de mettre à jour le module vous-même, les mises à jour ne sont appliquées que lorsque les noeuds de processus actif sont redémarrés à la prochaine étape. Reportez-vous à Mise à jour du module d'extension CNI OCI VCN-Native Pod Networking.

Remarques concernant les modules pour clusters

Lors de la configuration des extensions de cluster, tenez compte des points suivants :

• Lors de la création d'un cluster, vous ne pouvez pas désactiver les modules complémentaires de cluster essentiels. Cependant, lorsque vous modifiez un cluster existant, vous pouvez choisir de désactiver un module complémentaire essentiel. Si vous désactivez un module complémentaire de cluster essentiel, vous êtes responsable du déploiement et de la configuration d'un autre module pour fournir des fonctionnalités équivalentes.
• Lors de la création d'un cluster, les extensions de cluster essentielles sont configurées pour se mettre à jour automatiquement. Cependant, vous pouvez choisir de ne pas avoir un module essentiel automatiquement mis à jour. Si vous le faites, vous assumez la responsabilité de maintenir le module à jour.
• Lorsque vous activez un module complémentaire de cluster, vous pouvez le configurer en spécifiant une ou plusieurs paires clé/valeur à transmettre en tant qu'arguments au module complémentaire de cluster. Par exemple, pour le tableau de bord Kubernetes, vous indiquez la valeur 3 pour la clé numOfReplicas.
• Lorsque vous désactivez un module complémentaire de cluster à l'aide de la console, le module complémentaire n'est pas supprimé du cluster mais n'est tout simplement pas utilisé. Pour supprimer complètement le module, utilisez l'interface de ligne de commande ou l'API.
• Kubernetes Engine rapproche régulièrement la configuration des extensions de cluster déployées sur des clusters de base et améliorés avec les configurations d'extension de cluster par défaut correspondantes. Si vous configurez un module complémentaire de cluster déployé sur un cluster amélioré à l'aide d'un ou de plusieurs des arguments de configuration de paire clé/valeur approuvés (reportez-vous à Arguments de configuration d'extension de cluster), Kubernetes Engine fusionne vos personnalisations avec la configuration par défaut. Cependant, Kubernetes Engine supprime toutes les autres personnalisations apportées aux configurations d'extension de cluster et restaure les configurations par défaut.

  Dans le cas des clusters de base, la persistance des personnalisations vers les modules complémentaires de cluster essentiels n'est pas garantie. Si vous effectuez une personnalisation vers un module complémentaire de cluster essentiel qui provoque un conflit lors du processus de rapprochement, la personnalisation est rétablie. Pour conserver les personnalisations d'extension de cluster essentielles, mettez à niveau les clusters de base vers des clusters améliorés.

• Il est possible de déployer, mettre à jour et gérer des modules complémentaires de cluster sur un cluster exécutant une ancienne version de Kubernetes que Kubernetes Engine ne prend plus en charge. Cependant, Oracle ne prend pas en charge les clusters exécutant des versions de Kubernetes au-delà de ceux répertoriés dans Versions Kubernetes actuellement prises en charge. Si vous demandez la prise en charge d'un cluster exécutant une version non prise en charge de Kubernetes, vous serez invité à mettre à niveau le cluster vers une version prise en charge de Kubernetes.

  Si vous déployez un module sur un cluster exécutant une version de Kubernetes non prise en charge, et que vous indiquez que le module doit être mis à jour automatiquement (comportement par défaut), Oracle déploie initialement la version la plus récente du module compatible avec la version de Kubernetes non prise en charge. Dans le cas peu probable où une nouvelle version du module serait par la suite disponible et compatible avec la version non prise en charge de Kubernetes, Oracle met automatiquement à jour le module.

  Sachez que, dans le cas de clusters exécutant des versions de Kubernetes non prises en charge, Kubernetes Engine ne concilie pas la configuration des extensions de cluster en fusionnant les personnalisations avec les configurations par défaut. Si Kubernetes Engine détecte des différences entre la configuration actuelle d'un module complémentaire de cluster et sa configuration par défaut, le module complémentaire de cluster est affiché avec le statut Attention requise. Dans ce cas, vérifiez le message de demande de travail associé :

  • Si le message associé est Addon out of sync, envisagez de mettre à niveau la version de Kubernetes non prise en charge vers une version prise en charge.
  • Si le message associé indique une erreur de configuration, supprimez les modifications apportées aux valeurs des arguments de configuration de paire clé/valeur approuvés, afin que les arguments reprennent leurs valeurs par défaut.

• Vous pouvez utiliser l'API et l'interface de ligne de commande pour afficher la liste de toutes les versions d'un module de cluster particulier (y compris les numéros de version à construire). Les versions de module de cluster actuellement prises en charge ont le statut ACTIVE. Les versions de modules complémentaires du cluster qui ne sont plus prises en charge ont le statut EN PHASE D'ABANDON. Notez que les versions d'extension de cluster en phase d'abandon ne sont fournies que dans des circonstances exceptionnelles (par exemple, pour effectuer une annulation). Nous vous recommandons de ne pas utiliser une version de module de cluster obsolète, ni spécifier une version particulière d'un module pris en charge, pour un fonctionnement normal.