Atualizações Automatizadas

Visão Geral

Você pode gerenciar os upgrades do cluster RKE2 usando o system-upgrade-controller do Rancher. Esta é uma abordagem nativa do Kubernetes para atualizações de cluster. Ele aproveita um Plan Recurso Personalizado para descrever de forma declarativa quais nós fazer upgrade e para qual versão.

O plano define políticas de upgrade e requisitos. Ele também define quais nós devem ser atualizados através de um seletor de rótulos. Veja abaixo os planos com padrões apropriados para fazer upgrade de um cluster RKE2. Para opções de configuração de plano mais avançadas, consulte a documentação do Plano vinculada acima.

O Upgrade Controller agenda upgrades monitorando planos e selecionando nós para executar upgrade Jobs. Quando um Job é concluído com sucesso, o controlador rotulará o nó em que foi executado de acordo.

Se o cluster RKE2 for gerenciado pelo Rancher, você deve usar a interface do Rancher para gerenciar os upgrades.

Se o cluster RKE2 foi importado (registrado) no Rancher, o Rancher gerenciará por padrão a implantação do system-upgrade-controller e os planos. Não siga os passos nesta página a menos que você tenha desativado o gerenciamento de versão no Rancher. Veja Configuring Version Management for SUSE® Rancher Prime: RKE2 and SUSE® Rancher Prime: K3s Clusters para mais informações.
Se o cluster RKE2 foi provisionado pelo Rancher, o Rancher usará o system agent para gerenciar os upgrades de versão. Não siga os passos nesta página.
Se o cluster RKE2 não for gerenciado pelo Rancher, você pode seguir os passos abaixo.

Usando o Upgrade Controller

Para automatizar os upgrades, você deve fazer o seguinte:

Instale o system-upgrade-controller em seu cluster.
Crie planos descrevendo quais grupos de nós fazer upgrade e como.

Para mais detalhes sobre o design e a arquitetura do system-upgrade-controller ou sua integração com o RKE2, consulte os seguintes repositórios Git:

Ao tentar fazer upgrade para uma nova versão do RKE2, aplica-se a política de desvio de versão do Kubernetes. Certifique-se de que seu plano não pule versões menores intermediárias ao fazer upgrade. O Upgrade Controller em si não protegerá contra mudanças não suportadas na versão do Kubernetes.

Instalação

O manifesto do Upgrade Controller instala uma definição de recurso personalizado, implantação, conta de serviço, vinculação de função de cluster e configmap. Para instalar esses componentes, execute o seguinte comando:

kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/crd.yaml -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml

O Upgrade Controller pode ser configurado e personalizado através do configmap mencionado anteriormente, mas o pod do Upgrade Controller deve ser excluído para que as mudanças sejam aplicadas.

Configuração

Os nós do servidor devem sempre ser atualizados antes dos nós agentes.

Por essa razão, é recomendado que você crie pelo menos dois planos: um plano para fazer upgrade dos nós do servidor (plano de controle) e um plano para fazer upgrade dos nós agentes.

Você pode criar planos adicionais conforme necessário para controlar o rollout do upgrade entre os nós. Uma vez criados os planos, o controlador os capturará e começará a fazer upgrade do seu cluster.

Os seguintes dois planos de exemplo manterão continuamente o seu cluster com upgrade para a versão estável atual, direcionando-se para o release channel:

# Server plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: server-plan
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
    - key: node-role.kubernetes.io/control-plane
      operator: In
      values:
      - "true"
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/rke2-upgrade
  channel: https://update.rke2.io/v1-release/channels/stable
# Agent plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: agent-plan
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
    - key: node-role.kubernetes.io/control-plane
      operator: DoesNotExist
  prepare:
    args:
    - prepare
    - server-plan
    image: rancher/rke2-upgrade
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/rke2-upgrade
  channel: https://update.rke2.io/v1-release/channels/stable

Há algumas coisas importantes a serem destacadas em relação a esses planos:

Os planos devem ser criados no mesmo namespace onde o controlador foi implantado.
O campo concurrency indica quantos nós podem fazer upgrade ao mesmo tempo.
O plano do servidor visa os nós do servidor especificando um seletor de rótulos que seleciona nós com o rótulo node-role.kubernetes.io/control-plane. O plano do agente direciona os nós do agente especificando um seletor de rótulo que seleciona nós sem esse rótulo.
A etapa prepare no plano do agente fará com que os trabalhos de fazer upgrade para esse plano aguardem a conclusão do plano do servidor antes de serem executados. Essa lógica está incorporada na imagem usada para a etapa de preparação e não faz parte do Upgrade Controller em si.
Ambos os planos têm o campo channel definido para a URL do canal de lançamento estável. Isso fará com que o controlador monitore essa URL e faça upgrade do cluster sempre que ela resolver para um novo lançamento. Isso funciona bem com os release channels. Assim, você pode configurar seus planos com o seguinte canal para garantir que seu cluster seja sempre atualizado automaticamente para a versão estável mais recente do RKE2. Alternativamente, você pode omitir o campo channel e definir o campo version para um lançamento específico do RKE2:
```
apiVersion: upgrade.cattle.io/v1
kind: Plan
# ...
spec:
  # ...
  version: v1.33.4+rke2r1
```

A atualização começará assim que o controlador detectar que a versão alvo para um plano foi resolvida, seja pelo campo de versão ou por meio da consulta ao servidor do canal.

Modificar um plano fará com que o controlador reavalie o plano e determine se outra atualização é necessária.

Se um canal foi configurado, a URL também é consultada periodicamente para verificar novas versões.

Você pode monitorar o progresso de um upgrade visualizando o plano e os trabalhos via kubectl:

kubectl -n system-upgrade get plans -o wide
kubectl -n system-upgrade get jobs

Agendando Atualizações

Os planos podem ser restritos a ocorrer dentro de uma janela de tempo específica definindo o campo window dentro da especificação do plano.

Os campos da janela de tempo são compatíveis e seguem o mesmo formato que opções de agendamento do kured.

Por exemplo:

apiVersion: upgrade.cattle.io/v1
kind: Plan
# ...
spec:
  # ...
  window:
    days:
      - monday
      - tuesday
      - wednesday
      - thursday
      - friday
    startTime: 19:00
    endTime: 21:00
    timeZone: UTC

Trabalhos para executar atualizações de um plano não serão criados fora da janela de tempo. Uma vez que os trabalhos são criados, eles podem continuar em execução uma vez que a janela tenha fechado.

Prevenção de Rebaixamento

O Kubernetes não suporta downgrade dos componentes do plano de controle. A imagem rke2-upgrade usada pelos planos de atualização atualmente não inclui verificações para impedir que um plano faça downgrade da versão do Kubernetes.

Clusters provisionados pelo Rancher podem ser revertidos juntamente com a restauração de um instantâneo do etcd que contém dados garantidos para serem utilizáveis pela versão alvo do Kubernetes. Para mais informações, consulte a documentação do Rancher.

Clusters não provisionados pelo Rancher podem ser revertidos manualmente para uma versão anterior acompanhados pela restauração de um instantâneo do etcd. Para mais informações, consulte Rolling Back RKE2.

Segurança

O trabalho de fazer upgrade que é iniciado deve ter privilégios elevados para efetuar mudanças nos nós subjacentes. Por padrão, ele é configurado com o seguinte:

Host IPC, NET e PID namespaces
O recurso CAP_SYS_BOOT
Host root montado em /host com permissões de leitura e escrita