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.

Conseils pour la migration de RKE1 vers SUSE® Rancher Prime: RKE2 Windows

Le contenu de ce document n’est pas couvert par le SLA de Rancher Support. Veuillez procéder avec prudence.

Ce document explique comment les utilisateurs finaux peuvent migrer leurs charges de travail Windows de RKE1 vers RKE2.

Planification Windows RKE1

La planification des charges de travail Windows RKE1 est basée sur les taints et les tolerations.

Chaque nœud Linux d’un cluster Windows RKE1, quel que soit le rôle qui lui est assigné, aura une taint par défaut qui empêche la planification des charges de travail, à moins que celles-ci ne disposent d’une toleration configurée. C’est une caractéristique majeure de conception des clusters Windows RKE1 qui ont été conçus pour ne faire fonctionner que des charges de travail Windows.

Taint par défaut du nœud Linux RKE1 NoSchedule :

apiVersion: v1
kind: Node
spec:
  ...
  taints:
  - effect: NoSchedule
    key: cattle.io/os
    value: linux

Toleration RKE1 Linux NoSchedule pour les charges de travail

La toleration suivante permettrait à une charge de travail d’utilisateur final d’être planifiée sur n’importe quel nœud Linux d’un cluster Windows RKE1. Ces tolerations sont utilisées pour divers services et charges de travail essentiels de Rancher.

apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      tolerations:
      - effect: NoSchedule
        key: cattle.io/os
        operator: Equal
        value: linux

En accord avec les meilleures pratiques, toutes les charges de travail d’utilisateur final exécutées sur des nœuds Linux seraient planifiées uniquement sur ceux ayant le rôle de travailleur :

apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      tolerations:
      - effect: NoSchedule
        key: cattle.io/os
        operator: Equal
        value: linux
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: node-role.kubernetes.io/worker
                operator: In
                values:
                - "true"
            weight: 100
      ...

SUSE® Rancher Prime: RKE2 Planification Windows

Sur la base des retours et des demandes de support pour les charges de travail hybrides, RKE2 Windows a été conçu pour prendre en charge par défaut à la fois les charges de travail Linux et Windows. La planification RKE2 repose par défaut sur des sélecteurs de nœuds. C’est un changement marqué par rapport à RKE1, car les taints et les tolerations n’ont pas été intégrés dans RKE2. Les sélecteurs de nœuds étaient une partie critique des clusters Windows RKE1, ce qui facilite la migration de vos charges de travail.

Exemples de migrations

RKE1 vers SUSE® Rancher Prime: RKE2 Charge de travail Windows

Déploiement RKE1 Windows avant la migration :

apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/os
                operator: NotIn
                values:
                - linux

Déploiement RKE2 Windows migré utilisant NodeAffinity :

apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/os
                    operator: In
                    values:
                      - windows

Déploiement du cluster Windows RKE1 exclusivement sous Linux

Lors de l’utilisation des sélecteurs de nœuds et de l’affinité des nœuds, notez ce qui suit :

Si nodeSelector et nodeAffinity sont tous deux spécifiés, les deux doivent être satisfaits pour que le Pod soit planifié sur un nœud.
Si vous spécifiez plusieurs matchExpressions associés à un seul nodeSelectorTerms, alors le Pod ne peut être planifié sur un nœud que si tous les matchExpressions sont satisfaits.

Déploiement du cluster Windows RKE1 exclusivement Linux avant la migration, ciblant les nœuds de travail Linux RKE1 :

apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      tolerations:
      - effect: NoSchedule
        key: cattle.io/os
        operator: Equal
        value: linux
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: node-role.kubernetes.io/worker
                operator: In
                values:
                - "true"

Déploiement RKE2 cluster hybride uniquement Linux migré ciblant les nœuds de travail Linux RKE2 utilisant des sélecteurs de nœuds :

apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      nodeSelector:
        kubernetes.io/os: "linux"
        node-role.kubernetes.io/worker: "true"

Déploiement RKE2 cluster hybride uniquement Linux migré ciblant les nœuds de travail Linux RKE2 utilisant l’affinité des nœuds :

 apiVersion: apps/v1
kind: Deployment
spec:
  ...
  template:
    ...
    spec:
       affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: node-role.kubernetes.io/worker
                operator: In
                values:
                - "true"
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/os
                    operator: In
                    values:
                      - linux

Versions de Windows Server prises en charge par RKE1 Windows

Canal de service à long terme (LTSC)

Windows Server 2019 LTSC ✅ atteindra l’EOL principale le 9 janvier 2024 et l’EOL prolongée le 9 janvier 2029

Canal semi-annuel (SAC)

Windows Server 20H2 SAC ❌ a atteint l’EOL le 9 août 2022
Windows Server 2004 SAC ❌ a atteint l’EOL le 14 décembre 2021
Windows Server 1909 SAC ❌ a atteint l’EOL le 11 mai 2021
Windows Server 1903 SAC ❌ a atteint l’EOL le 8 décembre 2020
Windows Server 1809 SAC ❌ a atteint l’EOL le 10 novembre 2020

SUSE® Rancher Prime: RKE2 Versions de Windows Server prises en charge par Windows

Canal de service à long terme dans SUSE® Rancher Prime: RKE2

Windows Server 2019 LTSC ✅ atteindra l’EOL principale le 9 janvier 2024 et l’EOL prolongée le 9 janvier 2029
Windows Server 2022 LTSC ✅ atteindra l’EOL principale le 13 octobre 2026 et l’EOL prolongée le 13 octobre 2031

SAC n’est pas pris en charge dans RKE2.

Pour plus d’informations, veuillez consulter les références suivantes :

Support des versions de Kubernetes

Toutes les versions énumérées ci-dessous sont prises en charge par SLA selon le Tableau de support Rancher v2.6.7. Toute version non listée doit être considérée comme étant en fin de vie et non prise en charge par SLA par SUSE.

Rancher 2.5 contre. Tableau de support Rancher 2.6 pour les clusters Windows

RKE1 contre. Versions de Kubernetes prises en charge par le cluster Windows RKE2 :

Kubernetes Versions	RKE1	RKE2
1.18	✓
1.19	✓
1.20	✓
1.21	✓
1.22	✓	✓
1.23		✓
1.24		✓
1.25+		✓

Rancher 2.5 contre. Versions de Kubernetes prises en charge par Rancher 2.6 pour le provisionnement de RKE1 et SUSE® Rancher Prime: RKE2 des clusters Windows

Versions de Rancher	Kubernetes Versions	RKE1	RKE2
2.5 - Provisionnement RKE1	1.18 1.19 1.20	✓
2.6 - Provisionnement RKE1	1.18 1.19 1.20 1.21 1.22	✓
2.6 - Provisionnement RKE2	1.22 1.23 1.24 1.25+		✓

Versions de Rancher

Kubernetes Versions

RKE1

RKE2

2.5 - Provisionnement RKE1

1.18 1.19 1.20

✓

2.6 - Provisionnement RKE1

1.18 1.19 1.20 1.21 1.22

✓

2.6 - Provisionnement RKE2

1.22 1.23 1.24 1.25+

✓

Orientation pour la migration des charges de travail vers SUSE® Rancher Prime: RKE2 Windows

Reportez-vous aux tableaux dans Rancher 2.5 vs. Matrice de support Rancher 2.6 pour les clusters Windows et Rancher 2.5 vs. Versions Kubernetes prises en charge par Rancher 2.6 pour le provisionnement des clusters Windows RKE1 et RKE2, vous trouverez le chevauchement des versions Kubernetes entre RKE1 et RKE2 qui se produit dans 1.22. Ceci sera la version de base requise pour migrer les charges de travail Windows RKE1 en suivant l’approche recommandée par Rancher.

Mise à niveau sur place de Rancher 2.5

Mettre à niveau la version de Rancher vers v2.6.5+.
Mettre à niveau le(s) cluster(s) en aval Windows RKE1 vers RKE1 v1.22 en utilisant la dernière version de correctif disponible.
Provisionner un nouveau cluster en aval Windows RKE2 en utilisant RKE2 v1.22 avec la version de correctif correspondante à celle du cluster Windows RKE1.
Commencer la migration des charges de travail Windows des clusters RKE1 vers RKE2.
Effectuer des tests de validation pour s’assurer qu’il n’y a eu aucune perte ou changement de fonctionnalité lors de la migration de votre application de RKE1 vers RKE2.
Après que des tests de validation réussis aient eu lieu, vous pouvez choisir de mettre à niveau votre cluster RKE2 1.22.x vers une nouvelle version mineure telle que 1.23 ou 1.24.

Migration des charges de travail Windows vers un nouvel environnement Rancher

Pour effectuer l’une des options suivantes, il faut Rancher v2.6.5 ou supérieur.

Lors de l’utilisation de versions de correctif Kubernetes correspondantes pour RKE1 et RKE2 :

Provisionner un nouveau cluster en aval Windows RKE2 en utilisant RKE2 v1.22 avec la version de correctif correspondante à celle du cluster Windows RKE1.
Commencer la migration des charges de travail Windows des clusters RKE1 vers RKE2.
Effectuer des tests de validation pour s’assurer qu’il n’y a eu aucune perte ou changement de fonctionnalité lors de la migration de votre application de RKE1 vers RKE2.
Après que des tests de validation réussis aient eu lieu, vous pouvez choisir de mettre à niveau votre cluster RKE2 1.22.x vers une nouvelle version mineure telle que 1.23 ou 1.24.

Lors de l’utilisation d’une version de correctif Kubernetes plus récente pour RKE2 :

Provisionner un nouveau cluster en aval Windows RKE2 en utilisant RKE2 v1.23 ou v1.24.
Commencer la migration des charges de travail Windows des clusters RKE1 vers RKE2.
Effectuer des tests de validation pour s’assurer qu’il n’y a eu aucune perte ou changement de fonctionnalité lors de la migration de votre application de RKE1 vers RKE2.