Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

RKE1 zu SUSE® Rancher Prime: RKE2 Windows Migrationsanleitung

Der Inhalt dieses Dokuments ist nicht durch den SLA von Rancher Support abgedeckt. Bitte gehen Sie vorsichtig vor.

Dieses Dokument beschreibt, wie Endbenutzer ihre Windows-Workloads von RKE1 auf RKE2 migrieren können.

RKE1 Windows Planung

Die Planung von RKE1 Windows-Workloads basiert auf Taints und Toleranzen.

Jeder Linux-Knoten in einem RKE1 Windows-Cluster, unabhängig von der ihm zugewiesenen Rolle, hat einen standardmäßigen Taint, der verhindert, dass Workloads auf ihm geplant werden, es sei denn, der Workload hat eine konfigurierte Toleranz. Dies ist ein wichtiges Designelement für RKE1 Windows-Cluster, die nur Windows-Workloads ausführen sollten.

  • Standardmäßiger RKE1 Linux-Knoten NoSchedule Taint:

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

  • RKE1 Linux NoSchedule Toleranz für Workloads

Die folgende Toleranz würde es einem Endbenutzer-Workload ermöglichen, auf jedem Linux-Knoten eines RKE1 Windows-Clusters geplant zu werden. Diese Toleranzen werden für verschiedene Kern-Rancher-Dienste und Workloads verwendet.

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

  • In Übereinstimmung mit den Best Practices würden alle Endbenutzer-Workloads, die auf Linux-Knoten ausgeführt werden, nur auf solchen mit der Worker-Rolle geplant werden:

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 Windows Planung

Basierend auf Feedback und Anfragen nach Unterstützung für hybride Workloads wurde RKE2 Windows so konzipiert, dass es standardmäßig sowohl Linux- als auch Windows-Workloads unterstützt. Die Planung in RKE2 basiert standardmäßig auf Knotenauswahlen. Dies ist eine deutliche Änderung gegenüber RKE1, da Taints und Toleranzen nicht in RKE2 integriert wurden. Knotenauswahlen waren ein kritischer Bestandteil von RKE1 Windows-Clustern, was eine einfache Migration Ihrer Workloads ermöglicht.

Beispielmigrationen

RKE1 zu SUSE® Rancher Prime: RKE2 Windows-Workload

  • Vor der Migration RKE1 Windows-Bereitstellung:

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

  • Migrierte RKE2 Windows-Bereitstellung unter Verwendung von NodeAffinity:

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

RKE1 Windows-Cluster Linux-Only-Bereitstellung

Bei der Verwendung von Knotenauswahlen und Knotenaffinität beachten Sie Folgendes:

  • Wenn sowohl nodeSelector als auch nodeAffinity angegeben sind, müssen beide erfüllt sein, damit die Pod auf einem Knoten geplant werden kann.

  • Wenn Sie mehrere matchExpressions an einem einzelnen nodeSelectorTerms zuordnen, kann die Pod nur dann auf einem Knoten geplant werden, wenn alle matchExpressions erfüllt sind.

  • Vor der Migration RKE1 Windows-Cluster Linux-Only-Bereitstellung, die auf RKE1 Linux-Worker-Knoten abzielt:

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"

  • Migrierte RKE2 hybride Cluster Linux-Only-Bereitstellung, die auf RKE2 Linux-Worker-Knoten abzielt und Knotenauswahlen verwendet:

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

  • Migrierte RKE2 hybride Cluster Linux-Only-Bereitstellung, die auf RKE2 Linux-Worker-Knoten abzielt und Knotenaffinität verwendet:

 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

RKE1 Windows-unterstützte Windows Server-Versionen

Long-Term Servicing Channel (LTSC)

  • Windows Server 2019 LTSC ✅ erreicht am 9. Januar 2024 das Ende des Mainstream-Supports und am 9. Januar 2029 das Ende des Extended-Supports.

Semi-Annual Channel (SAC)

  • Windows Server 20H2 SAC ❌ hat am 9. August 2022 das Ende des Supports erreicht.

  • Windows Server 2004 SAC ❌ hat am 14. Dezember 2021 das Ende des Supports erreicht.

  • Windows Server 1909 SAC ❌ hat am 11. Mai 2021 das Ende des Supports erreicht.

  • Windows Server 1903 SAC ❌ hat am 8. Dezember 2020 das Ende des Supports erreicht.

  • Windows Server 1809 SAC ❌ hat am 10. November 2020 das Ende des Supports erreicht.

SUSE® Rancher Prime: RKE2 Windows-unterstützte Windows Server-Versionen

Long-Term Servicing Channel (LTSC) in SUSE® Rancher Prime: RKE2

  • Windows Server 2019 LTSC ✅ erreicht am 9. Januar 2024 das Ende des Mainstream-Supports und am 9. Januar 2029 das Ende des Extended-Supports.

  • Windows Server 2022 LTSC ✅ erreicht am 13. Oktober 2026 das Mainstream-EOL und am 13. Oktober 2031 das Extended-EOL.

SAC wird in RKE2 nicht unterstützt.

Weitere Informationen finden Sie in den folgenden Referenzen:

Kubernetes Version Support

Alle unten aufgeführten Versionen sind SLA-unterstützt gemäß der Rancher v2.6.7 Supportmatrix. Jede nicht aufgeführte Version sollte als EOL und nicht unter SLA von SUSE unterstützt angesehen werden.

Rancher 2.5 vs. Rancher 2.6 Supportmatrix für Windows-Cluster

RKE1 vs. RKE2 Windows-Cluster-unterstützte Kubernetes-Versionen:

Kubernetes Versions RKE1 RKE2

1.18

✓

1.19

✓

1.20

✓

1.21

✓

1.22

✓

✓

1.23

✓

1.24

✓

1.25+

✓

Rancher 2.5 vs. Rancher 2.6 unterstützte Kubernetes-Versionen für die Bereitstellung von RKE1 und SUSE® Rancher Prime: RKE2 Windows-Clustern

Rancher-Versionen Kubernetes Versions RKE1 RKE2

2.5 - RKE1-Bereitstellung

1.18 1.19 1.20

✓

2.6 - RKE1-Bereitstellung

1.18 1.19 1.20 1.21 1.22

✓

2.6 - RKE2-Bereitstellung

1.22 1.23 1.24 1.25+

✓

Leitfaden für Migrationen von Workloads zu SUSE® Rancher Prime: RKE2 Windows

Verweis auf die Tabellen in Rancher 2.5 vs. Rancher 2.6 Supportmatrix für Windows-Cluster und Rancher 2.5 vs. Die unterstützten Kubernetes-Versionen von Rancher 2.6 für die Bereitstellung von RKE1- und RKE2-Windows-Clustern zeigen, dass die Überlappung der Kubernetes-Versionen zwischen RKE1 und RKE2 in 1.22 auftritt. Dies wird die Basisversion sein, die erforderlich ist, um RKE1 Windows-Workloads gemäß dem empfohlenen Ansatz von Rancher zu migrieren.

In-Place-Upgrade von Rancher 2.5

  1. Upgrade der Rancher-Version auf v2.6.5+.

  2. Upgrade der RKE1 Windows-Downstream-Cluster auf RKE1 v1.22 unter Verwendung der neuesten verfügbaren Patch-Version.

  3. Provisionieren eines neuen RKE2 Windows-Downstream-Clusters mit RKE2 v1.22 unter Verwendung der passenden Patch-Version, die der RKE1 Windows-Cluster hat.

  4. Beginnen Sie mit der Migration der Windows-Workloads von RKE1 zu RKE2-Clustern.

  5. Führen Sie Validierungstests durch, um sicherzustellen, dass es beim Migrieren Ihrer Anwendung von RKE1 zu RKE2 keinen Funktionsverlust oder keine Änderung gegeben hat.

  6. Nach erfolgreichen Validierungstests können Sie sich entscheiden, Ihr RKE2 1.22.x-Cluster auf eine neue Minor-Version wie 1.23 oder 1.24 zu aktualisieren.

Migration von Windows-Workloads in eine neue Rancher-Umgebung

Um eine der folgenden Optionen auszuführen, ist Rancher v2.6.5 oder höher erforderlich.

Bei Verwendung passender Kubernetes-Patch-Versionen für RKE1 und RKE2:

  1. Provisionieren eines neuen RKE2 Windows-Downstream-Clusters mit RKE2 v1.22 unter Verwendung der passenden Patch-Version, die der RKE1 Windows-Cluster hat.

  2. Beginnen Sie mit der Migration der Windows-Workloads von RKE1 zu RKE2-Clustern.

  3. Führen Sie Validierungstests durch, um sicherzustellen, dass es beim Migrieren Ihrer Anwendung von RKE1 zu RKE2 keinen Funktionsverlust oder keine Änderung gegeben hat.

  4. Nach erfolgreichen Validierungstests können Sie sich entscheiden, Ihr RKE2 1.22.x-Cluster auf eine neue Minor-Version wie 1.23 oder 1.24 zu aktualisieren.

Wenn Sie eine neuere Kubernetes-Patch-Version für RKE2 verwenden:

  1. Stellen Sie einen neuen RKE2 Windows-Downstream-Cluster mit RKE2 v1.23 oder v1.24 bereit.

  2. Beginnen Sie mit der Migration der Windows-Workloads von RKE1 zu RKE2-Clustern.

  3. Führen Sie Validierungstests durch, um sicherzustellen, dass es beim Migrieren Ihrer Anwendung von RKE1 zu RKE2 keinen Funktionsverlust oder keine Änderung gegeben hat.