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. Esta página mostra como fazer o seguinte:

  • Verifique em qual modo cgroup os nós do cluster estão em execução e se as cargas de trabalho podem ser afetadas pela transição entre os modos cgroup.
  • Migrar nós de cluster do GKE Autopilot ou pools de nós de cluster padrão 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 possam ser afetadas pela transição entre os modos cgroup.

Você pode pular esta página se souber que as 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 recentes.

Sobre os grupos de controle do Linux

O kubelet e o ambiente de execução do contêiner usam 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 padrão, consulte Opções de configuração do modo cgroup do Linux.

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

Analise o cronograma a seguir para entender como o GKE está fazendo a transição de clusters atuais para o uso de cgroupv2:

  • Nas versões anteriores à 1.26, cgroupv1 era o padrão para nós. Nas 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 cgroup seus clusters do GKE executam por padrão, consulte Verificar o modo cgroup dos nós do cluster.
  • Com a versão secundária 1.31, o GKE descontinua o uso de 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 usa cgroupv1.
  • Com a versão secundária 1.35, o GKE remove o suporte para 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. Com a 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 o provisionamento automático de nós, o modo cgroup é baseado na versão inicial do cluster.
  • Para pools de nós de cluster padrão criados manualmente sem o provisionamento automático de nós, o modo cgroup é baseado na versão inicial do pool de nós.

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

Piloto automático

Execute este comando:

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

Substitua CLUSTER_NAME pelo nome do cluster.

Se a saída for EFFECTIVE_CGROUP_MODE_V2, o cluster está sendo executado em cgroupv2. Se a saída for EFFECTIVE_CGROUP_MODE_V1, o cluster está sendo executado em cgroupv1.

Os clusters do GKE Autopilot que foram criados inicialmente com a versão 1.25 ou anterior do GKE executam cgroupv1 até que você os migre.

Padrão

Com clusters do GKE Standard, o modo cgroup é definido no nível do pool de nós. Para verificar o modo de pools de nós individuais, siga as instruções para Verificar a configuração do cgroup. Se os nós do cluster já estiverem usando cgroupv2, nenhuma outra ação será necessária.

Migrar nós para cgroupv2

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

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

  1. Confira o modo cgroup dos nós. Se os nós do cluster já estiverem usando cgroupv2, nenhuma outra ação será necessária.
  2. Analise as considerações sobre a migração, Migrar para o cgroup v2, para garantir que as 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ê usa o provisionamento automático de nós para o cluster, execute o comando a seguir 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 atuais criados sem o provisionamento automático, 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 do nó, o GKE usa cgroupv2 por padrão.

Desativar temporariamente a migração automática para 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, é necessário definir explicitamente cgroupv1. Você também pode usar essas instruções para reverter temporariamente para cgroupv1 se a migração de nós para cgroupv2 tiver causado um problema nas cargas de trabalho do cluster.

Piloto automático

Execute o comando a seguir para clusters criados originalmente usando a versão 1.25 ou anterior. Se o cluster foi criado com a versão 1.26 ou mais recente, não é possível definir o modo cgroup como cgroupv1.

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

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

Substitua CLUSTER_NAME pelo nome do cluster.

Padrão

Para continuar executando cgroupv1 com um pool de nós de cluster do GKE padrão executando a versão 1.33 ou mais recente, siga estas etapas:

  1. Se você usa o provisionamento automático de nós e o cluster foi criado com a versão 1.25 ou anterior, use o comando a seguir para garantir que os pools de nós atuais e futuros criados com o provisionamento automático de nós usem cgroupv1. Se o cluster foi criado com a versão 1.26 ou mais recente, não é possível definir o modo cgroup como cgroupv1:

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

    Substitua CLUSTER_NAME pelo nome do cluster.

  2. Para pools de nós padrão existentes, atualize o pool de nós para adicionar o seguinte à configuração do sistema de nós:

    linuxConfig:
  cgroupMode: 'CGROUP_MODE_V1'

    Também é necessário definir essa configuração de nó para novos pools de nós criados manualmente sem o provisionamento automático de nós.

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