Présentation des modules complémentaires de grappe

Modules complémentaires essentiels

Les modules complémentaires de grappe essentiels sont des composants de base d'une grappe Kubernetes et sont requis pour qu'une grappe fonctionne correctement. Les modules complémentaires essentiels incluent :

• CoreDNS : Le module complémentaire CoreDNS est un serveur DNS faisant autorité, universel, modulaire et enfichable. Le moteur Kubernetes crée des grappes avec CoreDNS comme serveur DNS. Le processus kubelet de chaque noeud de travail dirige les conteneurs individuels vers le serveur DNS pour convertir les noms DNS en adresses IP.
• kube-proxy : Le module complémentaire kube-proxy est le mandataire de réseau Kubernetes qui gère les règles de réseau et achemine les demandes.
• un plugiciel CNI pour le service de réseau de pods : Un des modules complémentaires de plugiciel CNI suivants pour mettre en oeuvre la connectivité réseau pour les pods exécutés sur les noeuds de travail :
  • VCN OCI - Plugiciel CNI de réseau de pods natif
  • plugin flannel CNI

  Les plugiciels CNI configurent les interfaces réseau, provisionnent les adresses IP et assurent la connectivité.

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

Modules complémentaires facultatifs

Les modules complémentaires de grappe facultatifs sont des composants que vous pouvez choisir de déployer sur une grappe Kubernetes. Des modules complémentaires facultatifs étendent la fonctionnalité de base de Kubernetes pour améliorer la gérabilité et la performance des grappes. Exemples de modules complémentaires de cluster facultatifs :

• Tableau de bord Kubernetes : Le module complémentaire facultatif Kubernetes Dashboard est une interface de gestion basée sur le Web qui vous permet de déployer, de modifier, d'observer et de dépanner des applications conteneurisées. Nous ne recommandons pas de déployer le tableau de bord Kubernetes sur des grappes de production en raison du manque de prise en charge de l'authentification extensible. Pour plus d'informations, voir Accès à une grappe à l'aide du tableau de bord Kubernetes.
• Tiller (non recommandé) : Le module complémentaire Tiller facultatif est la partie serveur de Helm. Lorsque Tiller s'exécute dans la grappe, 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 fortement de ne pas déployer Tiller sur les grappes 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 le module complémentaire 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 : Le module complémentaire facultatif Opérateur d'Oracle Database pour Kubernetes enrichit l'API Kubernetes avec des ressources personnalisées et des contrôleurs pour automatiser la gestion du cycle de vie d'Oracle Database. L'opérateur Oracle Database prend en charge une variété de configurations de base de données et d'opérations de cycle de vie. Notez que pour utiliser l'opérateur Oracle Database en tant que module complémentaire de grappe, vous devez également déployer cert-manager (autonome ou en tant que module complémentaire de grappe). Pour plus d'informations, consultez la documentation relative aux opérateurs Oracle Database pour Kubernetes sur GitHub.
• Opérateur Weblogic : Le module complémentaire d'opérateur Kubernetes facultatif WebLogic prend en charge l'exécution des domaines WebLogic Server et Fusion Middleware sur Kubernetes. Pour plus d'informations, voir la documentation de l'opérateur WebLogic Kubernetes sur GitHub.
• Gestionnaire de certificats : Le module complémentaire Gestionnaire de certificats facultatif, également appelé gestionnaire de certificats, ajoute des certificats et des émetteurs de certificats aux grappes 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, voir la documentation sur le gestionnaire de certificats sur GitHub.
• Ajustement automatique de grappe : Le module complémentaire d'ajustement automatique de grappe facultatif redimensionne automatiquement les groupes de noeuds gérés d'une grappe en fonction des demandes de charge de travail d'application à l'aide du composant d'ajustement automatique de grappe de Kubernetes. Le déploiement du composant d'ajustement automatique de grappe de Kubernetes en tant que module complémentaire de grappe plutôt qu'en tant que programme autonome simplifie la configuration et la maintenance continue, et vous permet de spécifier qu'Oracle doit mettre à jour automatiquement le composant d'ajustement automatique de grappe de Kubernetes. Pour plus d'informations, voir Utilisation du composant d'ajustement automatique de grappe en tant que module complémentaire de grappe.
• Istio : Le module complémentaire Istio facultatif fournit une résilience du trafic de base automatisée, une collecte de mesures de service, un traçage distribué, un chiffrement du trafic, des mises à niveau de protocole et une fonctionnalité de routage avancée pour toutes les communications entre les services. Pour plus d'informations, voir Utilisation d'Istio en tant que module complémentaire de grappe.
• Contrôleur de trafic entrant natif : Équilibreurs de charge supplémentaires natifs du contrôleur de trafic entrant OCI facultatifs et achemine le trafic entrant vers les pods de service s'exécutant sur les noeuds de travail d'une grappe Kubernetes. Pour plus d'informations, voir Utilisation du contrôleur de trafic entrant natif OCI en tant que module complémentaire de grappe.
• Serveur de mesures Kubernetes : Le serveur de mesures Kubernetes facultatif permet d'agréger les données sur l'utilisation des ressources à l'échelle de la grappe. Le serveur de mesures Kubernetes collecte des mesures de ressources à partir du kubelet en cours d'exécution sur chaque noeud de travail et les expose dans le serveur d'API Kubernetes à l'aide de l'API de mesures Kubernetes. Notez que pour utiliser le serveur de mesures Kubernetes en tant que module complémentaire de grappe, vous devez également déployer cert-manager (autonome ou en tant que module complémentaire de grappe). Pour plus d'informations, voir Utilisation du serveur de mesures Kubernetes en tant que module complémentaire de grappe.
• Plugiciel GPU NVIDIA : Le plugiciel de GPU NVIDIA facultatif est un moyen pratique de gérer le plugiciel de périphérique NVIDIA pour Kubernetes. Le plugiciel de périphérique NVIDIA pour Kubernetes est la mise en oeuvre NVIDIA de la structure de plugiciel de périphérique Kubernetes permettant d'exposer le nombre de processeurs graphiques NVIDIA sur chaque noeud de travail et de suivre l'état de ces processeurs graphiques. Pour plus d'informations sur le plugiciel de périphérique NVIDIA pour Kubernetes, consultez la documentation sur le plugiciel de périphérique NVIDIA/k8s sur github.

Les modules complémentaires de grappe facultatifs ne sont pas déployés par défaut. Lors de l'utilisation de grappes améliorées, vous pouvez choisir de déployer et de configurer un nombre croissant d'extensions de grappe facultatives à l'aide de Kubernetes Engine.

Mise à jour des versions de module complémentaire

Lorsque vous activez un module complémentaire de grappe, vous pouvez indiquer soit que vous souhaitez qu'Oracle le mette à jour automatiquement lorsque de nouvelles versions deviennent disponibles, soit que vous souhaitez choisir une version particulière du module complémentaire à déployer.

• Si vous indiquez que vous voulez que le module complémentaire soit mis à jour automatiquement (comportement par défaut), Oracle déploie la version la plus récente du module complémentaire qui prend en charge la version de Kubernetes spécifiée pour la grappe. Si une nouvelle version du module complémentaire est publiée par la suite, Oracle le met automatiquement à jour, à condition que le module complémentaire 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 (voir Arguments de configuration du module complémentaire de grappe), la configuration est conservée lorsque le module complémentaire est mis à jour automatiquement. Toutefois, notez que toute autre personnalisation que vous avez peut-être apportée au module complémentaire est abandonnée lorsque celui-ci est mis à jour automatiquement.

  Gardez à l'esprit qu'il vous incombe de mettre à niveau des grappes 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 grappes en temps opportun afin de vous assurer qu'elles exécutent toujours les versions de Kubernetes prises en charge. Les mises à jour d'un module complémentaire de grappe peuvent ne pas être compatibles avec les anciennes versions de Kubernetes que Kubernetes Engine ne prend plus en charge. Si une grappe exécute une version de Kubernetes non prise en charge incompatible avec les mises à jour d'un module complémentaire de grappe, ce dernier n'est pas mis à jour automatiquement.

• Si vous indiquez que vous souhaitez choisir la version du module complémentaire à déployer, Oracle déploie la version du module complémentaire 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 la grappe.

  Gardez à l'esprit qu'il est de votre responsabilité de mettre à niveau les grappes pour exécuter les versions de Kubernetes prises en charge par Kubernetes Engine. Lorsque Oracle annonce que Kubernetes Engine doit cesser de prendre en charge une ancienne version de Kubernetes, il vous incombe à la fois de mettre à niveau toute grappe exécutant cette ancienne version de Kubernetes et (si nécessaire) de mettre à jour le module complémentaire à une version compatible avec la version la plus récente de Kubernetes.

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

Notez que dans le cas du module complémentaire du plugiciel CNI de réseau de pods natif du VCN OCI, que vous choisissiez de faire mettre à jour le module complémentaire automatiquement par Oracle ou que vous choisissiez de le mettre à jour vous-même, les mises à jour ne sont appliquées que lors du prochain redémarrage des noeuds de travail. Voir Mise à jour du plugiciel CNI de réseau de pods natif du VCN pour OCI.

Notes sur les modules complémentaires de grappe

Notez les points suivants lors de la configuration des modules complémentaires de grappe :

• Lors de la création d'une grappe, vous ne pouvez pas désactiver les modules complémentaires de grappe essentiels. Toutefois, lors de la modification d'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 module complémentaire de remplacement pour fournir des fonctionnalités équivalentes.
• Lors de la création d'une grappe, les modules complémentaires de grappe essentiels sont configurés pour être mis à jour automatiquement. Cependant, vous pouvez choisir de ne pas avoir un module complémentaire essentiel mis à jour automatiquement. Si vous le faites, vous assumez la responsabilité de maintenir le module complémentaire à 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 spécifiez la valeur 3 pour la clé numOfReplicas.
• Lorsque vous désactivez un module complémentaire de grappe à l'aide de la console, il n'est pas supprimé de la grappe mais n'est tout simplement pas utilisé. Pour supprimer complètement le module complémentaire, utilisez l'interface de ligne de commande ou l'API.
• Kubernetes Engine rapproche régulièrement la configuration des modules complémentaires de grappes déployés sur des grappes de base et améliorées avec les configurations de modules complémentaires de grappes par défaut correspondantes. Si vous configurez un module complémentaire de grappe déployé sur une grappe améliorée à l'aide d'un ou de plusieurs des arguments de configuration de paire clé/valeur approuvés (voir Arguments de configuration du module complémentaire de grappe), Kubernetes Engine fusionne vos personnalisations avec la configuration par défaut. Toutefois, Kubernetes Engine rejette toutes les autres personnalisations apportées aux configurations de modules complémentaires de grappes et restaure les configurations par défaut.

  Dans le cas des grappes de base, il est à noter que la persistance des personnalisations apportées aux modules complémentaires de grappe essentiels n'est pas garantie. Si vous effectuez une personnalisation vers un module complémentaire de cluster essentiel qui provoque un conflit au cours du processus de rapprochement, la personnalisation est annulée. Pour conserver les personnalisations essentielles du module complémentaire de grappe, mettez à niveau les grappes de base vers des grappes améliorées.

• Il est possible de déployer, de mettre à jour et de gérer les modules complémentaires de grappes sur une grappe exécutant une ancienne version de Kubernetes que Kubernetes Engine ne prend plus en charge. Toutefois, notez qu'Oracle ne fournit pas de prise en charge pour les grappes exécutant des versions de Kubernetes supérieures à celles répertoriées dans les versions Kubernetes actuellement prises en charge. Si vous demandez la prise en charge d'une grappe exécutant une version non prise en charge de Kubernetes, vous serez invité à mettre à niveau la grappe vers une version prise en charge de Kubernetes.

  Si vous déployez un module complémentaire sur une grappe qui exécute une version de Kubernetes non prise en charge et que vous spécifiez que le module complémentaire doit être mis à jour automatiquement (comportement par défaut), Oracle déploie initialement la version la plus récente du module complémentaire compatible avec la version de Kubernetes non prise en charge. Dans l'éventualité peu probable qu'une nouvelle version du module complémentaire soit ultérieurement publiée et compatible avec la version de Kubernetes non prise en charge, Oracle met automatiquement à jour le module complémentaire.

  Sachez que, dans le cas de grappes exécutant des versions de Kubernetes non prises en charge, Kubernetes Engine ne rapproche pas la configuration des modules complémentaires de grappes en fusionnant les personnalisations avec les configurations par défaut. Si Kubernetes Engine détecte les différences entre la configuration courante d'un module complémentaire de grappe et sa configuration par défaut, le module complémentaire de grappe s'affiche 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.