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.

Exigences des nœuds pour les clusters gérés par SUSE Rancher Prime

Cette page décrit les exigences pour les clusters Kubernetes gérés par Rancher où vos applications et services seront installés. Ces clusters en aval doivent être séparés du cluster à trois nœuds exécutant Rancher.

Si Rancher est installé sur un cluster Kubernetes à haute disponibilité, le cluster à trois nœuds de Rancher et les clusters en aval ont des exigences différentes. Pour les exigences d’installation de Rancher, consultez les exigences des nœuds dans la section d’installation.

Exigences des systèmes d’exploitation et de l’environnement d’exécution de conteneur

Rancher devrait fonctionner avec n’importe quelle distribution Linux moderne et n’importe quelle version moderne de Docker. Linux est requis pour les nœuds etcd et controlplane de tous les clusters en aval. Les nœuds de travail peuvent exécuter Linux ou Windows Server.

Pour des détails sur les versions de système d’exploitation et de Docker qui ont été testées avec chaque version de Rancher, consultez les conditions de maintenance du support.

Tous les systèmes d’exploitation pris en charge sont en 64 bits x86.

Si vous prévoyez d’utiliser ARM64, consultez Exécution sur ARM64 (Expérimental).

Pour des informations sur la façon d’installer Docker, consultez la documentation officielle de Docker.

Nœuds Linux dérivés d’Oracle Linux et de RHEL

Certaines distributions de Linux dérivées de RHEL, y compris Oracle Linux, peuvent avoir des règles de passerelle de périmètre de sécurité par défaut qui bloquent la communication avec Helm. Nous recommandons de désactiver firewalld. Pour Kubernetes 1.19, firewalld doit être désactivé.

Dans RHEL 8.4, deux services supplémentaires sont inclus dans le NetworkManager : nm-cloud-setup.service et nm-cloud-setup.timer. Ces services ajoutent une table de routage qui interfère avec la configuration du plugin CNI. Si ces services sont activés, vous devez les désactiver en utilisant la commande ci-dessous, puis redémarrer le nœud pour rétablir la connectivité :

   systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
   reboot

Nœuds SUSE Linux

SUSE Linux peut avoir une passerelle de périmètre de sécurité qui bloque tous les ports par défaut. Dans cette situation, suivez ces étapes pour ouvrir les ports nécessaires à l’ajout d’un hôte à un cluster personnalisé.

Nœuds Flatcar Container Linux

Lorsque Lancement de Kubernetes avec Rancher en utilisant des nœuds Flatcar Container Linux, il est nécessaire d’utiliser la configuration suivante dans le fichier de configuration du cluster.

  • Canal

  • Calico

rancher_kubernetes_engine_config:
  network:
    plugin: canal
    options:
      canal_flex_volume_plugin_dir: /opt/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
      flannel_backend_type: vxlan

  services:
    kube-controller:
      extra_args:
        flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
rancher_kubernetes_engine_config:
  network:
    plugin: calico
    options:
      calico_flex_volume_plugin_dir: /opt/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
      flannel_backend_type: vxlan

  services:
    kube-controller:
      extra_args:
        flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/

Il est également nécessaire d’activer le service Docker, vous pouvez activer le service Docker en utilisant la commande suivante :

systemctl enable docker.service

Le service Docker est activé automatiquement lors de l’utilisation de Node Drivers.

Nœuds Windows

Les nœuds avec Windows Server doivent exécuter Docker Enterprise Edition.

Les nœuds Windows ne peuvent être utilisés que comme nœuds de travail. Consultez Configuration des clusters personnalisés pour Windows

Configuration matérielle requise

Les exigences matérielles pour les nœuds avec le rôle worker dépendent principalement de vos charges de travail. Le minimum pour exécuter les composants de nœud Kubernetes est de 1 UC (noyau) et 1 Go de mémoire.

Concernant l’UC et la mémoire, il est recommandé que les différents plans des clusters Kubernetes (etcd, controlplane et nœuds de travail) soient hébergés sur des nœuds différents afin qu’ils puissent évoluer séparément les uns des autres.

Pour des recommandations matérielles pour de grands clusters Kubernetes, consultez la documentation officielle de Kubernetes sur la construction de grands clusters.

Pour des recommandations matérielles pour les clusters etcd en production, consultez la documentation officielle de etcd.

Exigences réseau

Pour un cluster de production, nous vous recommandons de restreindre le trafic en n’ouvrant que les ports définis dans les exigences de port ci-dessous.

Les ports requis à ouvrir varient en fonction de la manière dont le cluster utilisateur est lancé. Chacune des sections ci-dessous répertorie les ports qui doivent être ouverts pour différentes options de création de cluster.

Pour un aperçu des exigences en matière de ports pour les nœuds etcd, les nœuds de plan de contrôle et les nœuds de travail dans un cluster Kubernetes, reportez-vous aux exigences en matière de ports pour le Rancher Kubernetes Engine.

Les détails sur les ports utilisés dans chaque situation se trouvent sous Exigences en matière de ports pour le cluster en aval.

Exigences en matière d’adresses IPv6

Rancher prend en charge les clusters configurés avec un réseau IPv4 uniquement, un réseau IPv6 uniquement ou un réseau à double pile.

Vous devez provisionner chaque nœud avec au moins une adresse IPv4 valide, une adresse IPv6, ou les deux, selon la configuration du réseau du cluster.

Pour les environnements uniquement IPv6, assurez-vous de configurer correctement le système d’exploitation et que le fichier /etc/hosts inclut une entrée localhost valide, par exemple :

::1       localhost

Vous ne devez jamais enregistrer un nœud avec le même nom d’hôte ou la même adresse IP qu’un nœud existant. Cela empêche RKE de permettre au nœud de rejoindre, et le provisionnement reste bloqué. Cela peut se produire pour les clusters utilisant un pilote de nœud et pour les clusters personnalisés. Si un nœud doit réutiliser un nom d’hôte ou une adresse IP d’un nœud existant, vous devez définir l’option hostname_override RKE option avant d’enregistrer le nœud, afin qu’il puisse rejoindre correctement.

Facultatives : Considérations relatives à la sécurité

Si vous souhaitez provisionner un cluster Kubernetes conforme au CIS (Center for Internet Security) Kubernetes Benchmark, nous vous recommandons de suivre notre guide de renforcement de la sécurité pour configurer vos nœuds avant d’installer Kubernetes.

Pour plus d’informations sur le guide de renforcement de la sécurité et les détails sur la version du guide correspondant à vos versions de Rancher et Kubernetes, reportez-vous à la section de sécurité.