Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Lancement de Kubernetes sur de nouveaux nœuds dans un fournisseur d’infrastructure

Lorsque vous créez un cluster RKE2 en utilisant une configuration de machine dans Rancher, chaque pool de nœuds résultant est affiché dans un nouvel onglet Pools de machines. Vous pouvez voir les pools de machines en procédant comme suit :

  1. Cliquez sur ☰ > Gestion des clusters.

  2. Cliquez sur le nom du cluster RKE2.

SUSE® Rancher Prime: RKE2 Clusters

Rancher v2.6 introduit le provisionnement pour les clusters RKE2 directement depuis l’interface utilisateur de Rancher. RKE2, également connu sous le nom de RKE Government, est une distribution Kubernetes entièrement conforme axée sur la sécurité et la conformité aux États-Unis. secteur du gouvernement fédéral américain.

Pour les modèles de cluster RKE2, veuillez vous référer à cette page pour des informations supplémentaires.

Rôles de nœud

La CLI RKE2 expose deux rôles, server et agent, qui représentent les rôles de nœud Kubernetes etcd + controlplane et worker respectivement. Avec l’intégration de RKE2 dans Rancher v2.6, les pools de nœuds RKE2 peuvent représenter des attributions de rôles plus détaillées de sorte que les rôles etcd et controlplane peuvent être représentés.

La même fonctionnalité d’utilisation des nœuds etcd, controlplane et worker est possible dans la CLI RKE2 en utilisant des options et le marquage des nœuds pour contrôler où les charges de travail et le nœud maître Kubernetes étaient programmés. La raison pour laquelle ces rôles n’ont pas été implémentés en tant que rôles de première classe dans le RKE2 CLI est que RKE2 est conceptualisé comme un ensemble de blocs de construction bruts qui sont mieux exploités par un système d’orchestration tel que Rancher.

Dans notre architecture de cluster recommandée, nous décrivons combien de nœuds de chaque rôle les clusters devraient avoir :

  • Au moins trois nœuds avec le rôle etcd pour survivre à la perte d’un nœud.

  • Au moins deux nœuds avec le rôle controlplane pour une haute disponibilité du composant maître.

  • Au moins deux nœuds avec le rôle worker pour la replanification des charges de travail en cas d’échec d’un nœud.