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 des clusters Windows

Lors du provisionnement d’un cluster personnalisé, Rancher utilise RKE2 pour installer Kubernetes sur vos nœuds existants.

Dans un cluster Windows provisionné avec Rancher, le cluster doit contenir à la fois des nœuds Linux et Windows. Le plan de contrôle Kubernetes ne peut fonctionner que sur des nœuds Linux, et les nœuds Windows ne peuvent avoir que le rôle de travail. Les nœuds Windows ne peuvent être utilisés que pour déployer des charges de travail.

Pour un résumé des fonctionnalités Kubernetes prises en charge sur Windows, consultez la documentation Kubernetes sur les fonctionnalités et limitations prises en charge pour utiliser Kubernetes avec Windows ou le guide pour la planification des conteneurs Windows dans Kubernetes.

SUSE® Rancher Prime: RKE2 Fonctionnalités pour les clusters Windows

Ci-dessous, les principales fonctionnalités RKE2 pour le provisionnement de clusters Windows :

Conteneurs Windows avec RKE2 alimenté par containerd.
Ajout du provisionnement de clusters personnalisés Windows RKE2 directement depuis l’interface utilisateur de Rancher
Calico et Flannel CNI pour les clusters personnalisés RKE2 sous Windows.
Les versions SAC de Windows Server (2004 et 20H2) sont incluses dans l’aperçu technique

Rancher permettra par défaut aux pods de charges de travail Windows de se déployer à la fois sur des nœuds de travail Windows et Linux. Lors de la création de clusters mixtes dans RKE2, vous devez modifier le nodeSelector dans le graphique pour diriger les pods vers un nœud Windows compatible. Référez-vous à la documentation Kubernetes pour plus d’informations sur la façon d’utiliser nodeSelector pour assigner des pods à des nœuds.

Les conteneurs HostProcess dans Windows RKE2 sont pris en charge dans Kubernetes v1.24.1 et versions ultérieures. Voir la documentation en amont pour plus d’informations.

Exigences générales

Les exigences générales en matière de réseau et de système d’exploitation pour les nœuds Windows sont les mêmes que pour d’autres installations Rancher.

Exigences du système d’exploitation

Notre support pour Windows Server et les conteneurs Windows correspond au cycle de vie officiel de Microsoft pour LTSC (Canal de service à long terme) et SAC (Canal semi-annuel).

Pour les dates de cycle de vie du support pour Windows Server, consultez la documentation Microsoft.

Kubernetes Version

Pour plus d’informations concernant les versions des composants Kubernetes, consultez les matrices de support pour les versions RKE2.

Exigences des nœuds

Les hôtes dans le cluster doivent avoir au moins :

2 noyaux d’UC
5 Go de mémoire
50 Go d’espace disque

Rancher ne provisionnera pas le nœud si celui-ci ne répond pas à ces exigences.

Exigences réseau

Avant de provisionner un nouveau cluster, assurez-vous d’avoir déjà installé Rancher sur un appareil qui accepte le trafic réseau entrant. Ceci est nécessaire pour que les nœuds du cluster puissent communiquer avec Rancher. Si vous n’avez pas encore installé Rancher, veuillez vous référer à la documentation d’installation avant de poursuivre avec ce guide.

Rancher prend en charge Windows en utilisant Calico et Flannel comme fournisseurs de réseau.

Si vous configurez des ensembles d’options DHCP pour un cloud privé virtuel AWS, notez que dans le champ domain-name option, un seul nom de domaine peut être spécifié. Selon les options DHCP documentation :

Certains systèmes d’exploitation Linux acceptent plusieurs noms de domaine séparés par des espaces. Cependant, d’autres systèmes d’exploitation Linux et Windows traitent la valeur comme un seul domaine, ce qui entraîne un comportement inattendu. Si votre ensemble d’options DHCP est associé à un VPC qui a des instances avec plusieurs systèmes d’exploitation, spécifiez uniquement un nom de domaine.

Rancher sur VMware vSphere avec ESXi 6.7u2 et supérieur

Si vous utilisez Rancher sur VMware vSphere avec ESXi 6.7u2 ou une version ultérieure avec Red Hat Enterprise Linux 8.3, CentOS 8.3 ou SUSE Enterprise Linux 15 SP2 ou une version ultérieure, il est nécessaire de désactiver la vmxnet3 fonctionnalité de déchargement matériel de l’adaptateur réseau virtuel. Le non-respect de cette consigne entraînera l’échec de toutes les connexions réseau entre les pods sur différents nœuds de cluster avec des erreurs de délai d’attente. Toutes les connexions des pods Windows vers les services critiques fonctionnant sur des nœuds Linux, tels que CoreDNS, échoueront également. Il est également possible que les connexions externes échouent. Ce problème résulte des distributions Linux activant la fonctionnalité de déchargement matériel dans vmxnet3 et d’un bogue dans la fonctionnalité de déchargement matériel vmxnet3 qui entraîne le rejet des paquets pour le trafic de superposition invité. Pour résoudre ce problème, il est nécessaire de désactiver la vmxnet3 fonctionnalité de déchargement matériel. Ce paramètre ne survit pas au redémarrage, il est donc nécessaire de le désactiver à chaque démarrage. La démarche recommandée est de créer un fichier d’unité systemd à /etc/systemd/system/disable_hw_offloading.service, qui désactive la vmxnet3 fonctionnalité de déchargement matériel au démarrage. Un exemple de fichier d’unité systemd qui désactive la vmxnet3 fonctionnalité de déchargement matériel est le suivant. Notez que <VM network interface> doit être personnalisé pour l’interface réseau de l’hôte vmxnet3, par exemple, ens192 :

[Unit]
Description=Disable vmxnet3 hardware offloading feature

[Service]
Type=oneshot
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-segmentation off
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-csum-segmentation off
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Ensuite, définissez les autorisations appropriées sur le fichier d’unité systemd :

chmod 0644 /etc/systemd/system/disable_hw_offloading.service

Enfin, activez le service systemd :

systemctl enable disable_hw_offloading.service

Exigences d’architecture

Les nœuds de gestion du cluster Kubernetes (etcd et controlplane) doivent être exécutés sur des nœuds Linux.

Les nœuds worker, où vos charges de travail seront déployées, seront généralement des nœuds Windows, mais il doit y avoir au moins un nœud worker exécuté sur Linux pour faire fonctionner l’agent de cluster Rancher, DNS, le serveur de métriques et les conteneurs liés à Ingress.

Architecture recommandée

Nous recommandons l’architecture minimale à trois nœuds indiquée dans le tableau ci-dessous, mais vous pouvez toujours ajouter plus de nœuds de travail Linux et Windows pour faire évoluer votre cluster et assurer la redondance :

Noeud	Système d’exploitation	Kubernetes Cluster Role(s)	Fonction
Noeud 1	Linux (Ubuntu Server 18.04 recommandé)	Plan de contrôle, etcd, nœud de travail	Gérer le cluster Kubernetes
Noeud 2	Linux (Ubuntu Server 18.04 recommandé)	Nœud de travail	Assurez le support de l’agent de cluster Rancher, du serveur de métriques, de DNS et d’Ingress pour le cluster
Nœud 3	Windows (version Windows Server core 1809 ou supérieure requise, version 2022 recommandée)	Nœud de travail	Exécutez vos conteneurs Windows

Noeud

Système d’exploitation

Kubernetes Cluster Role(s)

Fonction

Noeud 1

Linux (Ubuntu Server 18.04 recommandé)

Plan de contrôle, etcd, nœud de travail

Gérer le cluster Kubernetes

Noeud 2

Linux (Ubuntu Server 18.04 recommandé)

Nœud de travail

Assurez le support de l’agent de cluster Rancher, du serveur de métriques, de DNS et d’Ingress pour le cluster

Nœud 3

Windows (version Windows Server core 1809 ou supérieure requise, version 2022 recommandée)

Nœud de travail

Exécutez vos conteneurs Windows

Exigences des conteneurs

Windows exige que les conteneurs soient construits sur la même version de Windows Server que celle sur laquelle ils sont déployés. Par conséquent, les conteneurs doivent être construits sur la version Windows Server core 1809 ou supérieure. Si vous avez des conteneurs existants construits pour une version antérieure de Windows Server core, ils doivent être reconstruits sur la version Windows Server core 1809 ou supérieure.

Exigences spécifiques au fournisseur de cloud

Si vous définissez un fournisseur de cloud Kubernetes dans votre cluster, des étapes supplémentaires sont nécessaires. Vous pourriez vouloir définir un fournisseur de cloud si vous souhaitez tirer parti des capacités d’un fournisseur de cloud, par exemple, pour provisionner automatiquement du stockage, des équilibreurs de charge ou d’autres infrastructures pour votre cluster. Référez-vous à cette page pour des détails sur la configuration d’un cluster de nœuds de fournisseur de cloud qui répond aux prérequis.

Si vous utilisez le fournisseur de cloud GCE (Google Compute Engine), vous devez faire ce qui suit :

Activez le fournisseur de cloud GCE dans le cluster.yml en suivant ces étapes.
Lors du provisionnement du cluster dans Rancher, choisissez Fournisseur de cloud personnalisé comme fournisseur de cloud dans l’interface utilisateur de Rancher.

Didacticiel : Comment créer un cluster avec support Windows

Ce tutoriel décrit comment créer un cluster provisionné par Rancher avec les trois nœuds dans l'architecture recommandée.

Pour configurer un cluster avec support pour les nœuds et conteneurs Windows, vous devrez compléter les tâches ci-dessous.

1. Provisionner des hôtes

Pour commencer à provisionner un cluster sur des nœuds existants avec un support Windows, préparez vos hôtes.

Vos hôtes peuvent être :

VMs hébergées dans le cloud
VMs provenant de clusters de virtualisation
Serveurs bare-metal

Vous allez provisionner trois nœuds :

Un nœud Linux, qui gère le plan de contrôle Kubernetes, stocke votre etcd, et peut optionnellement être un nœud de travail
Un deuxième nœud Linux, qui sera un autre nœud de travail
Le nœud Windows, qui exécutera vos conteneurs Windows en tant que nœud de travail

Noeud	Système d’exploitation
Noeud 1	Linux (Ubuntu Server 18.04 recommandé)
Noeud 2	Linux (Ubuntu Server 18.04 recommandé)
Nœud 3	Windows (version Windows Server core 1809 ou supérieure requise, version 2022 recommandée)

Noeud

Système d’exploitation

Noeud 1

Linux (Ubuntu Server 18.04 recommandé)

Noeud 2

Linux (Ubuntu Server 18.04 recommandé)

Nœud 3

Windows (version Windows Server core 1809 ou supérieure requise, version 2022 recommandée)

Si vos nœuds sont hébergés par un Fournisseur de Cloud et que vous souhaitez un support d’automatisation tel que des équilibreurs de charge ou des dispositifs de stockage persistants, vos nœuds ont des exigences de configuration supplémentaires. Pour plus de détails, voir Sélection des fournisseurs de cloud.

2. Créer le cluster sur des nœuds existants

Les instructions pour créer un cluster Windows sur des nœuds existants sont très similaires aux instructions générales pour créer un cluster personnalisé avec quelques exigences spécifiques à Windows.

Dans le coin supérieur gauche, cliquez sur ☰ > Gestion des clusters.
Sur la page Clusters, cliquez sur Créer.
Cliquez sur Personnaliser.
Entrez un nom pour votre cluster dans le champ Nom du cluster.
Dans le menu déroulant Version de Kubernetes, sélectionnez une version de Kubernetes prise en charge.
Dans le champ Réseau de conteneurs, sélectionnez soit Calico soit Flannel.
Cliquez sur Create.

3. Ajouter des nœuds au cluster

Cette section décrit comment enregistrer vos nœuds Linux et vos nœuds de travail dans votre cluster. Vous exécuterez une commande sur chaque nœud, qui installera le rancher-system-agent et permettra à Rancher de gérer chaque nœud.

Ajouter un nœud maître Linux

Dans cette section, nous remplissons un formulaire sur l’interface utilisateur de Rancher pour obtenir une commande personnalisée afin d’installer l’agent Rancher sur le nœud maître Linux. Ensuite, nous copierons la commande et l’exécuterons sur notre nœud maître Linux pour enregistrer le nœud dans le cluster.

Le premier nœud de votre cluster doit être un hôte Linux ayant à la fois les rôles Plan de contrôle et etcd. Au minimum, ces deux rôles doivent être activés pour ce nœud, et ce nœud doit être ajouté à votre cluster avant que vous puissiez ajouter des hôtes Windows.

Après la création du cluster, accédez à l’onglet Inscription.
Dans Étape 1, sous la section Rôle du nœud, sélectionnez les trois rôles. Bien que vous puissiez choisir uniquement les rôles etcd et Plan de contrôle, nous recommandons de sélectionner les trois.
Facultatives : Si vous cliquez sur Afficher les options avancées, vous pouvez configurer des paramètres supplémentaires tels que spécifier l’adresse IP, remplacer le nom d’hôte du nœud ou ajouter étiquettes ou taints au nœud.
Dans Étape 2, sous la section Inscription, copiez la commande affichée à l’écran dans votre presse-papiers.
Connectez-vous en SSH à votre hôte Linux et exécutez la commande que vous avez copiée dans votre presse-papiers.

Résultat :

Votre cluster est créé et a un état de Mise à jour. Rancher est en train de mettre en place votre cluster.

Il peut falloir quelques minutes pour que le nœud s’enregistre et apparaisse sous l’onglet Machines.

Vous pourrez accéder au cluster une fois que son état changera en Actif.

Ajouter un nœud de travail Linux

Dans cette section, nous exécutons une commande pour enregistrer le nœud de travail Linux dans le cluster.

Après le provisionnement initial de votre cluster, votre cluster ne dispose que d’un seul hôte Linux. Ensuite, nous ajoutons un autre hôte Linux worker, qui sera utilisé pour prendre en charge l’agent du cluster Rancher, le serveur de métriques, DNS et Ingress pour votre cluster.

Après la création du cluster, accédez à l’onglet Inscription.
Dans Étape 1, sous la section Rôle du nœud, sélectionnez nœud de travail.
Facultatives : Si vous cliquez sur Afficher les options avancées, vous pouvez configurer des paramètres supplémentaires tels que spécifier l’adresse IP, remplacer le nom d’hôte du nœud ou ajouter étiquettes ou taints au nœud.
Dans Étape 2, sous la section Inscription, copiez la commande affichée à l’écran dans votre presse-papiers.
Connectez-vous en SSH à votre hôte Linux et exécutez la commande que vous avez copiée dans votre presse-papiers.

Résultat :

Le rôle nœud de travail est installé sur votre hôte Linux, et le nœud s’enregistre auprès de Rancher. Il peut falloir quelques minutes pour que le nœud soit enregistré dans votre cluster.

Taints sur les nœuds de travail Linux

Pour chaque nœud de travail Linux ajouté au cluster, les taints suivants seront ajoutés au nœud de travail Linux. En ajoutant ce taint au nœud de travail Linux, toutes les charges de travail ajoutées au cluster Windows seront automatiquement planifiées sur le nœud de travail Windows. Si vous souhaitez planifier des charges de travail spécifiquement sur le nœud de travail Linux, vous devrez ajouter des tolérances à ces charges de travail.

Clé de taint Valeur du taint Effet du taint

cattle.io/os

linux

NoSchedule

Ajouter un nœud de travail Windows

Dans cette section, nous exécutons une commande pour enregistrer le nœud de travail Windows dans le cluster.

La commande d’enregistrement pour ajouter les nœuds de travail Windows n’apparaît qu’après que le cluster fonctionne avec Linux etcd, le plan de contrôle et les nœuds de travail.

Après la création du cluster, accédez à l’onglet Inscription.
Dans Étape 1, sous la section Rôle du nœud, sélectionnez nœud de travail.
Facultatives : Si vous cliquez sur Afficher les options avancées, vous pouvez configurer des paramètres supplémentaires tels que spécifier l’adresse IP, remplacer le nom d’hôte du nœud ou ajouter étiquettes ou taints au nœud.
Dans Étape 2, sous la section Inscription, copiez la commande pour les nœuds de travail Windows affichée à l’écran dans votre presse-papiers.
Connectez-vous à votre hôte Windows en utilisant votre outil préféré, tel que Microsoft Remote Desktop. Exécutez la commande copiée dans votre presse-papiers dans la Console PowerShell en tant qu’administrateur.
Facultatives : Répétez ces instructions si vous souhaitez ajouter d’autres nœuds Windows à votre cluster.

Résultat :

Le rôle nœud de travail est installé sur votre hôte Windows, et le nœud s’enregistre auprès de Rancher. Il peut falloir quelques minutes pour que le nœud soit enregistré dans votre cluster.

Vous avez maintenant un cluster Kubernetes Windows.

Étapes suivantes optionnelles

Après avoir créé votre cluster, vous pouvez y accéder via l’interface utilisateur de Rancher. En tant que meilleure pratique, nous recommandons de mettre en place ces méthodes alternatives pour accéder à votre cluster :

Accédez à votre cluster avec la CLI kubectl : Suivez ces étapes pour accéder aux clusters avec kubectl sur votre station de travail. Dans ce cas, vous serez authentifié via le proxy d’authentification du serveur Rancher, puis Rancher vous connectera au cluster en aval. Cette méthode vous permet de gérer le cluster sans l’interface utilisateur de Rancher.
Accédez à votre cluster avec la CLI kubectl, en utilisant le point de terminaison de cluster autorisé : Suivez ces étapes pour accéder à votre cluster en aval avec kubectl directement, sans vous authentifier via le serveur Rancher. Nous recommandons de mettre en place cette méthode alternative pour accéder à votre cluster afin que, dans le cas où vous ne pouvez pas vous connecter à Rancher, vous puissiez toujours accéder au cluster.

Configuration des classes de stockage dans Azure

Si vous utilisez des machines virtuelles Azure pour vos nœuds, vous pouvez utiliser Fichiers Azure comme classe de stockage pour le cluster. Pour plus de détails, reportez-vous à cette section.