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: K3sRéférence de configuration de cluster

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

Présentation

Vous pouvez configurer les options Kubernetes de deux manières :

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 K3s. L’utilisation d’un fichier de configuration vous permet de définir n’importe laquelle des options disponibles lors d’une installation K3s.

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 K3s en YAML, consultez la documentation K3s.

Pour modifier votre cluster avec 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.

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.

Chiffrer les secrets

Option pour activer ou désactiver le chiffrement des secrets. Lorsqu’il est activé, les secrets sont chiffrés à l’aide d’une clé AES-CBC. S’il est désactivé, les secrets précédemment chiffrés ne sont pas lisibles tant que le chiffrement n’est pas réactivé. Pour plus de détails, reportez-vous à la documentation K3s.

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.

SELinux

Option pour activer ou désactiver le support de SELinux.

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. Référez-vous à la documentation K3s pour plus de détails.

Service LB Klipper

Option pour activer ou désactiver le répartiteur de charge du service Klipper. Référez-vous à la documentation K3s pour plus de détails.

Traefik Ingress

Option pour activer ou désactiver le proxy inverse HTTP et le répartiteur de charge Traefik. Pour plus de détails et d’options de configuration, consultez la documentation K3s.

Stockage local

Option pour activer ou désactiver le stockage local sur le(s) nœud(s).

Metrics Server

Option pour activer ou désactiver le serveur de métriques. Si activé, assurez-vous que le port 10250 est ouvert pour le trafic TCP entrant.

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 K3s pour plus de détails.

Variables d’environnement de l’agent

Option pour définir des variables d’environnement pour les agents K3s. Les variables d’environnement peuvent être définies à l’aide de paires clé-valeur. Référez-vous à la documentation K3 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, consultez la documentation K3s.

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/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.

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.

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.

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 K3s.

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 des configurations déjà listées dans Options de configuration dans l’interface Rancher, ainsi que de définir des paramètres spécifiques à Rancher.

Cliquez pour développer Exemple d’extrait de fichier de configuration de cluster

apiVersion: provisioning.cattle.io/v1 kind: Cluster spec: cloudCredentialSecretName: cattle-global-data:cc-fllv6 clusterAgentDeploymentCustomization: {} fleetAgentDeploymentCustomization: {} kubernetesVersion: v1.26.7+k3s1 localClusterAuthEndpoint: {} rkeConfig: additionalManifest: "" chartValues: {} etcd: snapshotRetention: 5 snapshotScheduleCron: 0 */5 * * * machineGlobalConfig: disable-apiserver: false disable-cloud-controller: false disable-controller-manager: false disable-etcd: false disable-kube-proxy: false disable-network-policy: false disable-scheduler: false etcd-expose-metrics: false kube-apiserver-arg: - audit-policy-file=/etc/rancher/k3s/user-audit-policy.yaml - audit-log-path=/etc/rancher/k3s/user-audit.logs profile: null secrets-encryption: false machinePools: - controlPlaneRole: true etcdRole: true machineConfigRef: kind: Amazonec2Config name: nc-test-pool1-pwl5h name: pool1 quantity: 1 unhealthyNodeTimeout: 0s workerRole: true machineSelectorConfig: - config: docker: false protect-kernel-defaults: false selinux: false machineSelectorFiles: - fileSources: - configMap: name: '' secret: name: audit-policy items: - key: audit-policy path: /etc/rancher/k3s/user-audit-policy.yaml machineLabelSelector: matchLabels: rke.cattle.io/control-plane-role: 'true' registries: {} upgradeStrategy: controlPlaneConcurrency: '1' controlPlaneDrainOptions: deleteEmptyDirData: true disableEviction: false enabled: false force: false gracePeriod: -1 ignoreDaemonSets: true ignoreErrors: false postDrainHooks: null preDrainHooks: null skipWaitForDeleteTimeoutSeconds: 0 timeout: 120 workerConcurrency: '1' workerDrainOptions: deleteEmptyDirData: true disableEviction: false enabled: false force: false gracePeriod: -1 ignoreDaemonSets: true ignoreErrors: false postDrainHooks: null preDrainHooks: null skipWaitForDeleteTimeoutSeconds: 0 timeout: 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 au chemin /var/lib/rancher/k3s/server/manifests/rancher/addons.yaml sur les 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 graphiques du système installés par K3s.

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

Exemple :

chartValues:
    chart-name:
        key: value

machineGlobalConfig

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

Exemple :

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

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 K3s s’attend à ce que les valeurs soient saisies sous forme de chemins de fichiers :

registre-privé
flannel-conf

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

Exemple :

apiVersion: provisioning.cattle.io/v1
kind: Cluster
spec:
  rkeConfig:
    machineGlobalConfig:
      private-registry: |
        mirrors:
          docker.io:
            endpoint:
              - "http://mycustomreg.com:5000"
        configs:
          "mycustomreg:5000":
            auth:
              username: xxxxxx # this is the registry username
              password: xxxxxx # this is the registry password

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 K3s. 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