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.

SUSE® Rancher Prime: RKE2 Référence de configuration de cluster

Cette section couvre les options de configuration disponibles dans Rancher pour un cluster Kubernetes RKE2 nouveau ou existant.

Présentation

Vous pouvez configurer les options Kubernetes de l’une des deux manières suivantes :

Interface utilisateur Rancher : Utilisez l’interface utilisateur Rancher pour sélectionner les options qui sont couramment personnalisées lors de la configuration d’un cluster Kubernetes.
Fichier de configuration de cluster : Au lieu d’utiliser l’interface utilisateur Rancher pour choisir les options Kubernetes pour le cluster, les utilisateurs avancés peuvent créer un fichier de configuration RKE2. Utiliser un fichier de configuration vous permet de définir de nombreuses options supplémentaires disponibles pour une installation RKE2.

Modification des clusters dans l’interface utilisateur Rancher

L’interface utilisateur Rancher propose deux façons de modifier un cluster :

Avec un formulaire.
Avec YAML.

Modification des clusters avec un formulaire

Le formulaire couvre les options les plus fréquemment nécessaires pour les clusters.

Pour modifier votre cluster,

Cliquez sur ☰ > Gestion des clusters.
Allez au cluster que vous souhaitez configurer et cliquez sur ⋮ > Modifier la configuration.

Modification des clusters en YAML

Pour une référence complète des options configurables pour les clusters RKE2 en YAML, consultez la documentation RKE2.

Pour modifier votre cluster en YAML :

Cliquez sur ☰ > Gestion des clusters.
Allez au cluster que vous souhaitez configurer et cliquez sur ⋮ > Modifier en YAML.
Modifiez les options RKE sous la directive rkeConfig.

Options de configuration dans l’interface utilisateur de Rancher

Configuration de la réserve de machines

Cette sous-section couvre les configurations génériques de réserves de machines. Pour des configurations spécifiques aux fournisseurs d’infrastructure, référez-vous aux éléments suivants :

Nom de la réserve

Le nom de la réserve de machines.

Nombre de machines

Le nombre de machines dans la réserve.

Rôles

Option pour attribuer des rôles etcd, de plan de contrôle et de travail aux nœuds.

Avancé

Remplacement automatique

La durée pendant laquelle les nœuds peuvent être inaccessibles avant d’être automatiquement supprimés et remplacés.

Vidage avant suppression

Permet de vider les nœuds en évacuant tous les pods avant que le nœud ne soit supprimé.

Étiquettes des nœuds Kubernetes

Ajoutez étiquettes aux nœuds pour aider à l’organisation et à la sélection des objets.

Pour plus de détails sur les exigences de syntaxe des étiquettes, consultez la documentation Kubernetes.

Taints

Ajoutez taints aux nœuds pour empêcher les pods d’être planifiés ou exécutés sur les nœuds, à moins que les pods n’aient des tolérances correspondantes.

Configuration de la grappe

Basiques

Kubernetes Version

La version de Kubernetes installée sur vos nœuds de cluster.

Pour des détails sur la mise à niveau ou le retour en arrière de Kubernetes, reportez-vous à Mise à niveau de Kubernetes.

Fournisseur de réseau de conteneurs

Le Fournisseur de réseau que le cluster utilise.

Après avoir lancé le cluster, vous ne pouvez pas changer votre fournisseur de réseau. Par conséquent, choisissez soigneusement le fournisseur de réseau que vous souhaitez utiliser, car Kubernetes ne permet pas de changer de fournisseur de réseau. Une fois qu’un cluster est créé avec un fournisseur de réseau, changer de fournisseur de réseau nécessiterait de démolir l’ensemble du cluster et toutes ses applications.

Par défaut, Rancher est compatible avec les fournisseurs de réseau suivants :

Canal
Cilium*
Calico
Flannel
Multus
Lors de l’utilisation de l’isolement du réseau de projet dans le Cilium CNI, il est possible d’activer le routage d’entrée entre nœuds. Cliquez sur le documentation du fournisseur CNI pour en savoir plus.

Pour plus de détails sur les différents fournisseurs de réseau et comment les configurer, veuillez consulter notre documentation RKE2.

Lorsque vous utilisez cilium ou multus,cilium comme fournisseur d’interface de réseau de conteneurs, assurez-vous que l’option Activer le support IPv6 est également activée.

Fournisseur de cloud

Vous pouvez configurer un fournisseur de cloud Kubernetes. Si vous souhaitez utiliser des volumes et stockage provisionnés dynamiquement dans Kubernetes, vous devez généralement sélectionner le fournisseur de cloud spécifique pour l’utiliser. Par exemple, si vous souhaitez utiliser Amazon EBS, vous devrez sélectionner le aws fournisseur de cloud.

Si le fournisseur de cloud que vous souhaitez utiliser n’est pas répertorié comme option, vous devrez utiliser l'option de fichier de configuration pour configurer le fournisseur de cloud. Veuillez vous référer à cette documentation sur la façon de configurer le fournisseur de cloud.

Modèle de configuration d’admission de sécurité des pods

Le modèle de configuration d’admission de sécurité des pods par défaut pour le cluster.

Profil de conformité des travailleurs

Sélectionnez un référentiel de conformité pour valider la configuration du système.

Isolation du réseau de projet

Si votre fournisseur de réseau permet l’isolation du réseau de projet, vous pouvez choisir d’activer ou de désactiver la communication inter-projets.

L’isolement du réseau de projet est disponible si vous utilisez un plugin de réseau RKE2 qui prend en charge l’application des politiques de réseau Kubernetes, comme Canal.

CoreDNS

Par défaut, CoreDNS est installé en tant que fournisseur DNS par défaut. Si CoreDNS n’est pas installé, un autre fournisseur DNS doit être installé par vos soins. Consultez la documentation RKE2 pour des configurations supplémentaires de CoreDNS.

Ingress

Ingress-NGINX
Traefik

Ingress-NGINX EOL: Le contrôleur communautaire ingress-nginx a atteint sa fin du service (EOL) en mars 2026 et sa prise en charge a été cessée dans RKE2 v1.36. Les versions RKE2 provisionnées par SUSE Rancher Prime continueront à recevoir le ingress-nginx support et des correctifs CVE (8+) pour l’ensemble du cycle de vie de RKE2 v1.32, v1.33, v1.34, v1.35 et v1.36. Traefik est le chemin de migration recommandé pour les environnements SUSE Rancher RKE2, il est recommandé de migrer dès que possible. Consultez Migration de l’Ingress NGINX vers Traefik dans un cluster RKE2 provisionné par Rancher pour plus de détails.

C’est l’option d’entrée héritée pour activer Ingress-NGINX au sein du cluster. Consultez la documentation RKE2 pour des options de configuration supplémentaires.

Si vous souhaitez exposer vos applications dans une configuration à haute disponibilité, et que vous hébergez vos nœuds avec un fournisseur de cloud qui n’a pas de fonctionnalité d’équilibrage de la charge native, activez cette option pour utiliser Traefik Ingress au sein du cluster. Consultez la documentation RKE2 pour des options de configuration supplémentaires.

Metrics Server

Option pour activer ou désactiver le Metrics Server.

Chaque fournisseur de cloud capable de lancer un cluster en utilisant RKE2 peut collecter des métriques et surveiller vos nœuds de cluster. Activez cette option pour visualiser les métriques de vos nœuds depuis le portail de votre fournisseur de cloud.

Configuration du produit complémentaire

Manifests Kubernetes supplémentaires, gérés en tant que produit complémentaire, à appliquer au cluster au démarrage. Référez-vous à la documentation RKE2 pour plus de détails.

Variables d’environnement de l’agent

Option pour définir des variables d’environnement pour agents Rancher. Les variables d’environnement peuvent être définies à l’aide de paires clé-valeur. Référez-vous à la documentation RKE2 pour plus de détails.

etcd

Instantanés automatiques

Option pour activer ou désactiver les instantanés etcd récurrents. Si activé, les utilisateurs ont la possibilité de configurer la fréquence des instantanés. Pour plus de détails, référez-vous à la documentation RKE2. Notez qu’avec RKE2, les instantanés sont stockés sur chaque nœud etcd. Cela diffère de RKE1 qui ne stocke qu’un seul instantané par cluster.

Métriques

Option permettant de choisir si les métriques etcd doivent être exposées au public ou uniquement au sein du cluster.

Réseautique

CIDR de cluster

CIDR de réseau IPv4 et/ou IPv6 à utiliser pour les IP des pods (par défaut : 10.42.0.0/16).

Exemples de valeurs :

IPv4 uniquement : 10.42.0.0/16
IPv6 uniquement : 2001:cafe:42::/56
Double pile : 10.42.0.0/16,2001:cafe:42::/56

Pour des exigences et des limitations supplémentaires liées à la double pile ou à la mise en réseau IPv6 à pile unique, consultez les ressources suivantes :

Vous devez configurer le CIDR de service lors de la création initiale du cluster. Vous ne pouvez pas activer le CIDR de service sur un cluster existant après son démarrage.
Lorsque vous utilisez cilium ou multus,cilium comme fournisseur d’interface réseau de conteneurs, assurez-vous que l’option Activer le support IPv6 est également activée.

CIDR de service

CIDR de réseau IPv4/IPv6 à utiliser pour les IP des services (par défaut : 10.43.0.0/16).

Exemples de valeurs :

IPv4 uniquement : 10.43.0.0/16
IPv6 uniquement : 2001:cafe:43::/112
Double pile : 10.43.0.0/16,2001:cafe:43::/112

Pour des exigences et des limitations supplémentaires liées à la double pile ou à la mise en réseau IPv6 à pile unique, consultez les ressources suivantes :

Vous devez configurer le CIDR de service lors de la création initiale du cluster. Vous ne pouvez pas activer le CIDR de service sur un cluster existant après son démarrage.
Lorsque vous utilisez cilium ou multus,cilium comme fournisseur d’interface réseau de conteneurs, assurez-vous que l’option Activer le support IPv6 est également activée.

DNS de cluster

IP Cluster IPv4 pour le service coredns. Doit être dans votre plage de service-cidr (par défaut : 10.43.0.10).

Domaine de cluster

Sélectionnez le domaine pour le cluster. La valeur par défaut est cluster.local.

Plage de ports de service NodePort

Option pour changer la plage de ports pouvant être utilisés pour NodePort services. La valeur par défaut est 30000-32767.

Tronquer les noms d’hôtes

Option pour tronquer les noms d’hôtes à 15 caractères ou moins. Vous ne pouvez définir ce champ que lors de la création initiale du cluster. Vous ne pouvez pas activer ou désactiver la limite de 15 caractères après la création du cluster.

Ce paramètre n’affecte que les clusters provisionnés par machine. Étant donné que les clusters personnalisés définissent les noms d’hôtes lors de leur propre processus de création de nœuds, qui se déroule en dehors de Rancher, ce champ ne limite pas la longueur des noms d’hôtes des clusters personnalisés.

Tronquer les noms d’hôtes dans un cluster améliore la compatibilité avec les systèmes basés sur Windows. Bien que Kubernetes autorise des noms d’hôtes jusqu’à 63 caractères, les systèmes utilisant NetBIOS limitent les noms d’hôtes à 15 caractères ou moins.

Noms alternatifs TLS

Ajouter des noms d’hôtes ou des adresses IPv4/IPv6 en tant que noms alternatifs de sujet sur le certificat TLS du serveur.

Préférence de pile

Choisissez la pile réseau pour le cluster. Cette option affecte :

L’adresse utilisée pour les sondes de santé et de disponibilité des composants tels que Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager et kubelet.
L’URL du serveur dans le authentication-token-webhook-config-file pour le point de terminaison de cluster autorisé.
Le paramètre advertise-client-urls pour etcd lors de la restauration de l’instantané.

Les options sont ipv4, ipv6, dual :

Lorsqu’il est défini sur ipv4, le cluster utilise 127.0.0.1
Lorsqu’il est défini sur ipv6, le cluster utilise [::1]
Lorsqu’il est défini sur dual, le cluster utilise localhost

La préférence de pile doit correspondre à la configuration réseau du cluster :

Définir sur ipv4 pour des clusters uniquement IPv4
Définir sur ipv6 pour des clusters uniquement IPv6
Définir sur dual pour des clusters à double pile

S’assurer que la configuration de l’adresse de boucle est correcte est essentiel pour un approvisionnement réussi du cluster. Pour plus d’informations, consultez la page Exigences des nœuds.

Point de terminaison de cluster autorisé

Le point de terminaison de cluster autorisé peut être utilisé pour accéder directement au serveur API Kubernetes, sans nécessiter de communication via Rancher.

Ceci est activé par défaut dans les clusters Kubernetes lancés par Rancher, utilisant l’adresse IP du nœud avec le rôle controlplane et les certificats auto-signés Kubernetes par défaut.

Pour plus de détails sur le fonctionnement d’un point de terminaison de cluster autorisé et pourquoi il est utilisé, consultez la section architecture.

Nous recommandons d’utiliser un équilibreur de charge avec le point de terminaison de cluster autorisé. Pour plus de détails, consultez la section architecture recommandée.

Registres

Sélectionnez le dépôt d’images à partir duquel tirer les images de Rancher. Pour plus de détails et d’options de configuration, consultez la Documentation RKE2.

Stratégie de mise à niveau

Concurrence du plan de contrôle

Sélectionnez combien de nœuds peuvent être mis à niveau en même temps. Peut être un nombre fixe ou un pourcentage.

Concurrence des travailleurs

Sélectionnez combien de nœuds peuvent être mis à niveau en même temps. Peut être un nombre fixe ou un pourcentage.

Vider les nœuds (plan de contrôle)

Option pour supprimer tous les pods du nœud avant la mise à niveau.

Vider les nœuds (nœuds de travail)

Option pour supprimer tous les pods du nœud avant la mise à niveau.

Avancé

Option pour définir des options kubelet pour différents nœuds. Pour les options disponibles, consultez la documentation Kubernetes.

Référence du fichier de configuration du cluster

Modifier les clusters en YAML vous permet de définir les options disponibles dans une installation RKE2, y compris celles déjà listées dans Options de configuration dans l’interface utilisateur Rancher, ainsi que de définir des paramètres spécifiques à Rancher.

Exemple d’extrait de fichier de configuration de cluster

yaml apiVersion: provisioning.cattle.io/v1 kind: Spécification du cluster : cloudCredentialSecretName : cattle-global-data:cc-s879v kubernetesVersion : v1.25.12+rke2r1 localClusterAuthEndpoint : {} rkeConfig : additionalManifest : "" chartValues : rke2-calico : {} etcd : snapshotRetention : 5 planification des instantanés : 0 */5 * * * machineGlobalConfig : cni : calico disable-kube-proxy : false etcd-expose-metrics : false profil : null kube-apiserver-arg : - audit-policy-file=/etc/rancher/rke2/user-audit-policy.yaml - audit-log-path=/etc/rancher/rke2/user-audit.logs machinePools : - controlPlaneRole : true etcdRole : true machineConfigRef : kind: Amazonec2Config nom : nc-test-pool1-pwl5h nom : pool1 quantité : 1 délai d’attente pour les nœuds non sains : 0s rôle de travailleur : vrai configuration du sélecteur de machine : - config : protéger-les-défauts-du-noyau : faux fichiers du sélecteur de machine : - sources de fichiers : - configMap : nom : '' secret : nom : audit-policy éléments : - clé : audit-policy chemin : /etc/rancher/rke2/user-audit-policy.yaml sélecteur d’étiquettes de machine : correspondre aux étiquettes : rke.cattle.io/control-plane-role : 'true' registres : {} stratégie de mise à niveau : concurrence du plan de contrôle : "1" options de drainage du plan de contrôle : supprimer les données de répertoire vide : vrai activé : vrai période de grâce : -1 ignorer les ensembles de démons : vrai délai d’attente : 120 concurrence des travailleurs : "1" options de drainage des travailleurs : supprimer les données de répertoire vide : vrai activé : vrai période de grâce : -1 ignorer les ensembles de démons : vrai délai d’attente : 120

additionalManifest

Spécifiez des manifestes supplémentaires à livrer aux nœuds du plan de contrôle.

La valeur est une chaîne de caractères et sera placée sur le chemin /var/lib/rancher/rke2/server/manifests/rancher/addons.yaml des nœuds cibles.

Exemple :

additionalManifest: |-
  apiVersion: v1
  kind: Namespace
  metadata:
    name: name-xxxx

Si vous souhaitez personnaliser les graphiques du système, vous devez utiliser le champ chartValues comme décrit ci-dessous.

Des alternatives, telles que l’utilisation d’un HelmChartConfig pour personnaliser les graphiques du système via additionalManifest, peuvent entraîner un comportement inattendu, en raison de la présence de plusieurs HelmChartConfigs pour le même graphique.

chartValues

Spécifiez les valeurs pour les charts système installés par RKE2.

Pour plus d’informations sur la façon dont RKE2 gère les composants empaquetés, veuillez vous référer à la documentation RKE2.

Exemple :

chartValues:
    chart-name:
        key: value

machineGlobalConfig

Spécifiez les configurations RKE2. Tout changement de configuration effectué ici s’appliquera à chaque nœud. Les options de configuration disponibles dans la version autonome de RKE2 peuvent être appliquées ici.

Exemple :

machineGlobalConfig:
    etcd-arg:
        - key1=value1
        - key2=value2

Il existe certaines options de configuration qui ne peuvent pas être modifiées lors de la provision via Rancher :

data-dir (dossier pour conserver l’état), dont la valeur par défaut est /var/lib/rancher/rke2.

Pour faciliter la mise en place des fichiers sur les nœuds à l’avance, Rancher s’attend à ce que les valeurs suivantes soient incluses dans la configuration, tandis que RKE2 s’attend à ce que les valeurs soient saisies sous forme de chemins de fichiers :

fichier-de-politique-d’audit
configuration-du-fournisseur-de-cloud
registre-privé

Rancher livre les fichiers au chemin /var/lib/rancher/rke2/etc/config-files/<option> dans les nœuds cibles et définit les options appropriées dans le serveur RKE2.

Exemple :

apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
  rkeConfig:
    machineGlobalConfig:
      audit-policy-file:
        apiVersion: audit.k8s.io/v1
        kind: Policy
        rules:
        - level: RequestResponse
          resources:
          - group: ""
            resources:
            - pods

machineSelectorConfig

machineSelectorConfig est identique à machineGlobalConfig sauf qu’un sélecteur label peut être spécifié avec la configuration. La configuration ne sera appliquée qu’aux nœuds qui correspondent au sélecteur d’étiquettes fourni.

Plusieurs entrées config sont autorisées, chacune spécifiant son propre machineLabelSelector. Un utilisateur peut spécifier matchExpressions, matchLabels, les deux ou aucun. Omettre la section machineLabelSelector de ce champ a le même effet que de mettre la configuration dans la section machineGlobalConfig.

Exemple :

machineSelectorConfig
  - config:
      config-key: config-value
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

machineSelectorFiles

Cette fonctionnalité est disponible dans Rancher v2.7.2 et versions ultérieures.

Livrer des fichiers aux nœuds, afin que les fichiers puissent être en place avant de lancer les processus du serveur ou de l’agent RKE2. Le contenu du fichier est récupéré soit d’un secret, soit d’un configmap. Les nœuds cibles sont filtrés par le machineLabelSelector.

Exemple :

machineSelectorFiles:
  - fileSources:
      - secret:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-secret-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2
  - fileSources:
      - configMap:
          items:
            - key: example-key
              path: path-to-put-the-file-on-nodes
              permissions: 644 (optional)
              hash: base64-encoded-hash-of-the-content (optional)
          name: example-configmap-name
    machineLabelSelector:
      matchExpressions:
        - key: example-key
          operator: string # Valid operators are In, NotIn, Exists and DoesNotExist.
          values:
            - example-value1
            - example-value2
      matchLabels:
        key1: value1
        key2: value2

Le secret ou le configmap doit répondre aux exigences suivantes :

Il doit se trouver dans l’espace de noms fleet-default où l’objet Cluster existe.
Il doit avoir l’annotation rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2, qui permet aux clusters cibles de l’utiliser.

Le tableau de bord Rancher fournit un formulaire facile à utiliser pour créer le secret ou le configmap.

Exemple :

apiVersion: v1
data:
  audit-policy: >-
    IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
kind: Secret
metadata:
  annotations:
    rke.cattle.io/object-authorized-for-clusters: cluster1
  name: name1
  namespace: fleet-default