Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Orientações de Migração do RKE1 para SUSE® Rancher Prime: RKE2 Windows

O conteúdo deste documento não está coberto pelo SLA do Suporte Rancher. Por favor, prossiga com cautela.

Este documento aborda como os usuários finais podem migrar suas cargas de trabalho do Windows do RKE1 para o RKE2.

RKE1 Windows Scheduling

O agendamento de cargas de trabalho do Windows no RKE1 é baseado em taints e tolerâncias.

Cada nó Linux em um cluster Windows RKE1, independentemente do papel atribuído a ele, terá uma taint padrão que impede que cargas de trabalho sejam agendadas nele, a menos que a carga de trabalho tenha uma tolerância configurada. Este é um recurso de design importante para clusters Windows RKE1, que foram projetados para executar apenas cargas de trabalho do Windows.

Taint padrão do nó Linux RKE1 NoSchedule:

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

Tolerância do Linux RKE1 NoSchedule para cargas de trabalho

A seguinte tolerância permitiria que uma carga de trabalho de um usuário final fosse agendada em qualquer nó Linux de um cluster Windows RKE1. Essas tolerâncias são usadas para vários serviços e cargas de trabalho essenciais do Rancher.

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

Alinhando-se às melhores práticas, quaisquer cargas de trabalho de usuários finais executadas em nós Linux seriam agendadas apenas nos que têm o papel de trabalhador:

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 Agendamento do Windows

Com base no feedback e nas solicitações de suporte a cargas de trabalho híbridas, o RKE2 Windows foi projetado para suportar tanto cargas de trabalho Linux quanto Windows por padrão. O agendamento do RKE2 depende de seletores de nós por padrão. Esta é uma mudança significativa em relação ao RKE1, pois taints e tolerâncias não foram incorporados ao RKE2. Seletores de nós foram uma parte crítica dos clusters Windows RKE1, o que facilita a migração de suas cargas de trabalho.

Exemplos de Migrações

RKE1 para SUSE® Rancher Prime: RKE2 Carga de Trabalho do Windows

Implantação do Windows RKE1 antes da migração:

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

Implantação do Windows RKE2 migrada usando NodeAffinity:

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

Implantação do Cluster Windows RKE1 somente para Linux

Ao utilizar seletores de nó e afinidade de nó, observe o seguinte:

Se tanto nodeSelector quanto nodeAffinity forem especificados, ambos devem ser atendidos para que o Pod seja agendado em um nó.
Se você especificar múltiplos matchExpressions associados a um único nodeSelectorTerms, então o Pod pode ser agendado em um nó apenas se todos os matchExpressions forem atendidos.

Implantação do cluster Windows RKE1 somente para Linux antes da migração, visando nós de trabalho 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"

Implantação do cluster híbrido RKE2 somente para Linux migrada, visando nós de trabalhador Linux RKE2 usando seletores de nó:

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

Implantação do cluster híbrido RKE2 somente para Linux migrada, visando nós de trabalhador Linux RKE2 usando afinidade de nó:

 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

Versões do Windows Server suportadas pelo Windows RKE1

Canal de Manutenção de Longo Prazo (LTSC)

O Windows Server 2019 LTSC ✅ atingirá o EOL principal em 9 de janeiro de 2024 e o EOL estendido em 9 de janeiro de 2029

Canal Semestral (SAC)

O Windows Server 20H2 SAC ❌ atingiu o EOL em 9 de agosto de 2022
O Windows Server 2004 SAC ❌ atingiu o EOL em 14 de dezembro de 2021
O Windows Server 1909 SAC ❌ atingiu o EOL em 11 de maio de 2021
O Windows Server 1903 SAC ❌ atingiu o EOL em 8 de dezembro de 2020
O Windows Server 1809 SAC ❌ atingiu o EOL em 10 de novembro de 2020

SUSE® Rancher Prime: RKE2 Versões do Windows Server Suportadas pelo Windows

Canal de Manutenção de Longo Prazo em SUSE® Rancher Prime: RKE2

O Windows Server 2019 LTSC ✅ atingirá o EOL principal em 9 de janeiro de 2024 e o EOL estendido em 9 de janeiro de 2029
O Windows Server 2022 LTSC ✅ atingirá o EOL principal em 13 de outubro de 2026 e o EOL estendido em 13 de outubro de 2031

SAC não é suportado no RKE2.

Para mais informações, consulte as seguintes referências:

Suporte a Versões do Kubernetes

Todas as versões listadas abaixo são suportadas por SLA de acordo com Matriz de Suporte do Rancher v2.6.7. Qualquer versão não listada deve ser considerada como EOL e não suportada sob SLA pela SUSE.

Rancher 2.5 vs. Matriz de Suporte do Rancher 2.6 para Clusters Windows

RKE1 vs. Versões do Kubernetes suportadas por clusters 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 vs. Versões do Kubernetes suportadas pelo Rancher 2.6 para Provisionamento de Clusters RKE1 e SUSE® Rancher Prime: RKE2 Windows

Versões do Rancher	Kubernetes Versions	RKE1	RKE2
2.5 - Aprovisionamento RKE1	1.18 1.19 1.20	✓
2.6 - Aprovisionamento RKE1	1.18 1.19 1.20 1.21 1.22	✓
2.6 - Aprovisionamento RKE2	1.22 1.23 1.24 1.25+		✓

Versões do Rancher

Kubernetes Versions

RKE1

RKE2

2.5 - Aprovisionamento RKE1

1.18 1.19 1.20

✓

2.6 - Aprovisionamento RKE1

1.18 1.19 1.20 1.21 1.22

✓

2.6 - Aprovisionamento RKE2

1.22 1.23 1.24 1.25+

✓

Orientando Migrações de Cargas de Trabalho para SUSE® Rancher Prime: RKE2 Windows

Referenciando as tabelas em Rancher 2.5 vs. Matriz de Suporte do Rancher 2.6 para Clusters Windows e Rancher 2.5 vs. Versões do Kubernetes Suportadas pelo Rancher 2.6 para Aprovisionamento de Clusters Windows RKE1 e RKE2, você encontrará a sobreposição nas versões do Kubernetes entre RKE1 e RKE2 que ocorre em 1.22. Esta será a versão base necessária para migrar cargas de trabalho do Windows RKE1 ao seguir a abordagem recomendada pelo Rancher.

Atualização In-Place do Rancher 2.5

Atualize a versão do Rancher para v2.6.5+.
Atualize o(s) cluster(s) downstream do Windows RKE1 para RKE1 v1.22 usando a versão de patch mais recente disponível.
Provisione um novo cluster downstream do Windows RKE2 usando RKE2 v1.22 com a versão de patch correspondente à qual o cluster Windows RKE1 se encontra.
Inicie a migração das cargas de trabalho do Windows dos clusters RKE1 para RKE2.
Realize testes de validação para garantir que não houve perda ou alteração de funcionalidade ao migrar seu aplicativo de RKE1 para RKE2.
Após a realização bem-sucedida dos testes de validação, você pode optar por atualizar seu cluster RKE2 1.22.x para uma nova versão menor, como 1.23 ou 1.24.

Migrando Cargas de Trabalho do Windows para um Novo Ambiente Rancher

Para realizar qualquer uma das opções a seguir, é necessário o Rancher v2.6.5 ou superior.

Ao usar versões de patch do Kubernetes correspondentes para RKE1 e RKE2:

Provisione um novo cluster downstream do Windows RKE2 usando RKE2 v1.22 com a versão de patch correspondente à qual o cluster Windows RKE1 se encontra.
Inicie a migração das cargas de trabalho do Windows dos clusters RKE1 para RKE2.
Realize testes de validação para garantir que não houve perda ou alteração de funcionalidade ao migrar seu aplicativo de RKE1 para RKE2.
Após a realização bem-sucedida dos testes de validação, você pode optar por atualizar seu cluster RKE2 1.22.x para uma nova versão menor, como 1.23 ou 1.24.

Ao usar uma versão de patch mais recente do Kubernetes para RKE2:

Provisione um novo cluster downstream do Windows RKE2 usando RKE2 v1.23 ou v1.24.
Inicie a migração das cargas de trabalho do Windows dos clusters RKE1 para RKE2.
Realize testes de validação para garantir que não houve perda ou alteração de funcionalidade ao migrar seu aplicativo de RKE1 para RKE2.