Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Guía de migración de RKE1 a SUSE® Rancher Prime: RKE2 Windows

El contenido de este documento no está cubierto por el SLA de Soporte de Rancher. Por favor, proceda con precaución.

Este documento cubre cómo los usuarios finales pueden migrar sus cargas de trabajo de Windows de RKE1 a RKE2.

Programación de Windows en RKE1

La programación de cargas de trabajo de Windows en RKE1 se basa en taints y tolerations.

Cada nodo Linux en un clúster de Windows RKE1, independientemente del rol asignado, tendrá un taint por defecto que impide que se programen cargas de trabajo en él, a menos que la carga de trabajo tenga configurado un toleration. Estas tolerations se utilizan para varios servicios y cargas de trabajo del kernel de Rancher.

  • Taint por defecto del nodo Linux RKE1 NoSchedule:

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

  • Toleration RKE1 Linux NoSchedule para cargas de trabajo

La siguiente toleration permitiría que una carga de trabajo de un usuario final se programe en cualquier nodo Linux de un clúster de Windows RKE1. Estas tolerations se utilizan para varios servicios y cargas de trabajo del kernel de Rancher.

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

  • Siguiendo las mejores prácticas, cualquier carga de trabajo de usuario final que se ejecute en nodos Linux se programaría solo en aquellos con el rol de trabajador:

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

Programación de SUSE® Rancher Prime: RKE2 Windows

Basado en comentarios y solicitudes para soporte de cargas de trabajo híbridas, RKE2 Windows fue diseñado para soportar tanto cargas de trabajo de Linux como de Windows por defecto. La programación de RKE2 se basa en selectores de nodos por defecto. Este es un cambio notable respecto a RKE1, ya que los taints y tolerations no se incorporaron en RKE2. Los selectores de nodos fueron una parte crítica de los clústeres de Windows RKE1, lo que facilita la migración de tus cargas de trabajo.

Migraciones de ejemplo

RKE1 a SUSE® Rancher Prime: RKE2 Carga de trabajo de Windows

  • Despliegue de Windows RKE1 previo a la migración:

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

  • Despliegue de Windows RKE2 migrado utilizando NodeAffinity:

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

Despliegue de clúster de Windows RKE1 solo en Linux

Al aprovechar los selectores de nodos y la afinidad de nodos, ten en cuenta lo siguiente:

  • Si se especifican tanto nodeSelector como nodeAffinity, ambos deben cumplirse para que el Pod se programe en un nodo.

  • Si especificas múltiples matchExpressions asociados con un solo nodeSelectorTerms, entonces el Pod solo se puede programar en un nodo si se cumplen todos los matchExpressions.

  • Despliegue de clúster de Windows RKE1 solo en Linux previo a la migración, dirigido a nodos de trabajo 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"

  • Despliegue de clúster híbrido de Windows RKE2 solo en Linux migrado, dirigido a nodos de trabajo Linux RKE2 utilizando selectores de nodos:

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

  • Despliegue de clúster híbrido de Windows RKE2 solo en Linux migrado, dirigido a nodos de trabajo Linux RKE2 utilizando afinidad de nodos:

 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

Versiones de Windows Server compatibles con Windows

Canal de servicio a largo plazo (LTSC)

  • Windows Server 2019 LTSC ✅ alcanzará el EOL principal el 9 de enero de 2024 y el EOL extendido el 9 de enero de 2029

Canal semestral (SAC)

  • Windows Server 20H2 SAC ❌ alcanzó el EOL el 9 de agosto de 2022

  • Windows Server 2004 SAC ❌ alcanzó el EOL el 14 de diciembre de 2021

  • Windows Server 1909 SAC ❌ alcanzó el EOL el 11 de mayo de 2021

  • Windows Server 1903 SAC ❌ alcanzó el EOL el 8 de diciembre de 2020

  • Windows Server 1809 SAC ❌ alcanzó el EOL el 10 de noviembre de 2020

SUSE® Rancher Prime: RKE2 Versiones de Windows Server soportadas por Windows

Canal de servicio a largo plazo en SUSE® Rancher Prime: RKE2

  • Windows Server 2019 LTSC ✅ alcanzará el EOL principal el 9 de enero de 2024 y el EOL extendido el 9 de enero de 2029

  • Windows Server 2022 LTSC ✅ alcanzará el EOL principal el 13 de octubre de 2026 y el EOL extendido el 13 de octubre de 2031

SAC no es compatible en RKE2.

Para más información, consulte las siguientes referencias:

Soporte de versiones de Kubernetes

Todas las versiones listadas a continuación están soportadas por SLA según el Matriz de soporte de Rancher v2.6.7 . Cualquier versión no listada debe asumirse como EOL y no soportada bajo SLA por SUSE.

Rancher 2.5 vs. Matriz de soporte de Rancher 2.6 para clústeres de Windows

RKE1 vs. Versiones de Kubernetes soportadas por clústeres de Windows RKE2:

Versiones de Kubernetes RKE1 RKE2

1.18

✓

1.19

✓

1.20

✓

1.21

✓

1.22

✓

✓

1.23

✓

1.24

✓

1.25+

✓

Rancher 2.5 vs. Versiones de Kubernetes soportadas por Rancher 2.6 para aprovisionar RKE1 y clústeres de Windows SUSE® Rancher Prime: RKE2

Versiones de Rancher Versiones de Kubernetes RKE1 RKE2

2.5 - Aprovisionamiento de RKE1

1.18 1.19 1.20

✓

2.6 - Aprovisionamiento RKE1

1.18 1.19 1.20 1.21 1.22

✓

2.6 - Aprovisionamiento RKE2

1.22 1.23 1.24 1.25+

✓

Guiando las migraciones de cargas de trabajo a SUSE® Rancher Prime: RKE2 Windows

Referenciando las tablas en Rancher 2.5 vs. Matriz de soporte de Rancher 2.6 para clústeres de Windows y Rancher 2.5 vs. Versiones de Kubernetes soportadas por Rancher 2.6 para aprovisionar clústeres de Windows RKE1 y RKE2, encontrarás que la superposición en las versiones de Kubernetes entre RKE1 y RKE2 ocurre en 1.22. Esta será la versión base requerida para migrar cargas de trabajo de Windows RKE1 siguiendo el enfoque recomendado por Rancher.

Actualización in situ de Rancher 2.5

  1. Actualiza la versión de Rancher a v2.6.5+.

  2. Actualiza el/los clúster(es) Windows RKE1 de sentido descendente a RKE1 v1.22 utilizando la última versión de parche disponible.

  3. Aprovisiona un nuevo clúster Windows RKE2 de sentido descendente utilizando RKE2 v1.22 con la versión de parche correspondiente a la que tiene el clúster de Windows RKE1.

  4. Comienza la migración de las cargas de trabajo de Windows de los clústeres RKE1 a RKE2.

  5. Realiza pruebas de validación para asegurar que no ha habido pérdida o cambio de funcionalidad al migrar tu aplicación de RKE1 a RKE2.

  6. Después de que se hayan realizado pruebas de validación exitosas, puedes optar por actualizar tu clúster RKE2 1.22.x a una nueva versión menor como 1.23 o 1.24.

Migrando cargas de trabajo de Windows a un nuevo entorno de Rancher

Realizar cualquiera de las siguientes opciones requiere Rancher v2.6.5 o superior.

Al usar versiones de parche de Kubernetes coincidentes para RKE1 y RKE2:

  1. Aprovisiona un nuevo clúster Windows RKE2 de sentido descendente utilizando RKE2 v1.22 con la versión de parche correspondiente a la que tiene el clúster de Windows RKE1.

  2. Comienza la migración de las cargas de trabajo de Windows de los clústeres RKE1 a RKE2.

  3. Realiza pruebas de validación para asegurar que no ha habido pérdida o cambio de funcionalidad al migrar tu aplicación de RKE1 a RKE2.

  4. Después de que se hayan realizado pruebas de validación exitosas, puedes optar por actualizar tu clúster RKE2 1.22.x a una nueva versión menor como 1.23 o 1.24.

Al utilizar una versión de parche más reciente de Kubernetes para RKE2:

  1. Aprovisiona un nuevo clúster Windows RKE2 de sentido descendente utilizando RKE2 v1.23 o v1.24.

  2. Comienza la migración de las cargas de trabajo de Windows de los clústeres RKE1 a RKE2.

  3. Realiza pruebas de validación para asegurar que no ha habido pérdida o cambio de funcionalidad al migrar tu aplicación de RKE1 a RKE2.