Migrar nós para o cgroupv2 do Linux

A partir da versão 1.33, o Google Kubernetes Engine (GKE) migra clusters que executam cgroupv1 para cgroupv2. Nesta página, você aprende a fazer o seguinte:

• Verifique em qual modo de cgroup os nós do cluster estão sendo executados e se as cargas de trabalho podem ser afetadas pela transição entre os modos de cgroup.
• Migre nós de cluster do GKE Autopilot ou pools de nós de cluster Standard para cgroupv2.
• Desative temporariamente a migração automática de nós do GKE usando cgroupv1 para cgroupv2. Siga estas instruções se o cluster executar cargas de trabalho que podem ser afetadas pela transição entre modos de cgroup.

Você pode pular a leitura desta página se souber que suas cargas de trabalho são executadas conforme o esperado no cgroupv2 ou não são afetadas pela configuração do modo cgroup. O GKE migra automaticamente clusters que executam cgroupv1 para cgroupv2 com a versão 1.33 e mais recente.

Sobre os grupos de controle do Linux

O kubelet e o ambiente de execução do contêiner usam os grupos de controle (cgroups) do kernel do Linux para gerenciar recursos, como limitar a quantidade de CPU ou memória que cada contêiner em um pod pode acessar. Há dois modos do subsistema cgroup no kernel: cgroupv1 e cgroupv2. O suporte do Kubernetes para cgroupv2 foi introduzido como Alfa na versão 1.18 do Kubernetes, Beta na versão 1.22 e disponível para todos os usuários na versão 1.25. Para saber mais, consulte a documentação do Kubernetes cgroups v2.

Para saber como configurar um modo cgroup para clusters Standard, consulte Opções de configuração do modo cgroup do Linux.

Como o GKE está fazendo a transição para cgroupv2

Confira a linha do tempo a seguir para entender como o GKE está fazendo a transição dos clusters atuais para usar o cgroupv2:

• Em versões anteriores à 1.26, cgroupv1 era o padrão para nós. Para versões 1.26 ou mais recentes, cgroupv2 é o padrão para novos nós. Não há mudanças nos nós atuais. Para saber mais sobre qual modo de cgroup seus clusters do GKE executam por padrão, consulte Verificar o modo de cgroup dos nós do cluster.
• Com a versão secundária 1.31, o GKE descontinua cgroupv1.
• A partir da versão 1.33, o GKE migra clusters que executam cgroupv1 para cgroupv2. É possível impedir temporariamente essa migração automática especificando explicitamente que um pool de nós use cgroupv1.
• Com a versão secundária 1.35, o GKE remove a compatibilidade com cgroupv1.

Para saber o tempo aproximado dos upgrades automáticos para versões secundárias mais recentes, como 1.31 e 1.33, consulte a Programação estimada para canais de lançamento.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.

Verificar o modo cgroup dos nós do cluster

O modo cgroup padrão depende do tipo de cluster ou pool de nós e da versão. Na versão 1.26 ou mais recente, o padrão é cgroupv2. Com a versão 1.25 ou anterior, o padrão é cgroupv1:

• Para clusters do Autopilot e novos pools de nós de cluster padrão criados com provisionamento automático de nós, o modo cgroup é baseado na versão inicial do cluster. Não é possível definir o modo cgroup durante a criação do cluster do Autopilot. Para novos nós provisionados automaticamente, não é possível definir o modo de maneira diferente do modo cgroup padrão com base na versão secundária.
• Para pools de nós do cluster Standard criados manualmente sem provisionamento automático de nós, o modo cgroup se baseia na versão inicial do pool de nós ou na configuração personalizada do sistema de nós.

Para verificar o modo cgroup, siga as instruções com base no modo do cluster.

gcloud container clusters describe CLUSTER_NAME \
    --format='value(nodePools[0].config.effectiveCgroupMode)'

Migrar nós para cgroupv2

Recomendamos que você migre os nós atuais antes que o GKE faça isso automaticamente na versão 1.33 ou mais recente.

Siga estas etapas para migrar nós que executam o cgroupv1:

1. Verifique o modo cgroup dos nós. Se os nós do cluster já estiverem usando cgroupv2, nenhuma outra ação será necessária.
2. Leia as considerações sobre a migração, Migrar para cgroup v2, para garantir que suas cargas de trabalho estejam preparadas para usar a nova versão da API.

3. Migre os nós do cluster.

   Piloto automático

   Defina explicitamente os nós do cluster para usar cgroupv2:

   gcloud container clusters update CLUSTER_NAME \
       --autoprovisioning-cgroup-mode=v2
   

   Substitua CLUSTER_NAME pelo nome do cluster.

   Padrão

   1. Se você usar o provisionamento automático de nós para o cluster, execute o seguinte comando para garantir que os pools de nós atuais e futuros criados com o provisionamento automático de nós usem cgroupv2:

      gcloud container clusters update CLUSTER_NAME \
          --autoprovisioning-cgroup-mode=v2
      

      Substitua CLUSTER_NAME pelo nome do cluster.

   2. Para pools de nós criados sem o provisionamento automático de nós, atualize o pool de nós para adicionar o seguinte à configuração do sistema de nós:

      linuxConfig:
        cgroupMode: 'CGROUP_MODE_V2'
      

      Para saber mais, consulte Como personalizar a configuração do sistema de nós.

      Quando você cria manualmente novos pools de nós sem o provisionamento automático de nós, o GKE usa cgroupv2 por padrão.

Desativar temporariamente a migração automática para o cgroupv2

Para evitar temporariamente a migração automática de nós que executam cgroupv1 para cgroupv2 com versões secundárias 1.33 e mais recentes, defina explicitamente cgroupv1. Você também pode usar essas instruções para reverter temporariamente para cgroupv1 se a migração de nós para cgroupv2 causar um problema nas cargas de trabalho do cluster.

gcloud container clusters update CLUSTER_NAME \
    --autoprovisioning-cgroup-mode=v1