Documentação do Oracle Cloud Infrastructure

Fazendo Upgrade de Nós Gerenciados para o Kubernetes versão 1.35 (ou posterior)

Descubra como fazer upgrade de nós gerenciados que atualmente usam uma imagem OL7 do OKE, uma imagem de plataforma OL7 ou uma imagem personalizada baseada em uma imagem OL7, para executar o Kubernetes versão 1.35 (ou posterior) e OL8, usando o Kubernetes Engine (OKE).

Observação

Esta seção se aplica somente a nós gerenciados. Para obter informações sobre como fazer upgrade de nós autogerenciados, consulte Fazendo Upgrade de Nós Autogerenciados para uma Versão Mais Nova do Kubernetes Substituindo um Nó Autogerenciado Existente.

A partir do Kubernetes versão 1.35, o Kubernetes requer cgroups v2 para gerenciamento de recursos de contêiner.

Grupos de Controle (cgroups) é uma funcionalidade do kernel do Linux que fornece um mecanismo para gerenciar e controlar a alocação de recursos para processos ou grupos de processos. Os grupos de controle versão 2 (cgroups v2) fornecem uma única hierarquia de grupo de controle na qual todos os controladores de recursos estão montados. Nesta hierarquia, você pode coordenar o uso de recursos entre diferentes controladores de recursos.

O Oracle Linux 7 (OL7) suporta cgroups v1, mas não suporta cgroups v2. O Oracle Linux 8 (OL8) e versões posteriores dão suporte a cgroups v1 e cgroups v2, mas cgroups v2 nem sempre são ativados por padrão na OL8.

Em resumo, o Kubernetes versão 1.35, portanto, requer OL8 (ou mais recente) com cgroups v2 ativados.

Por padrão, os Cgroups v2 são ativados em imagens OL8 do OKE que têm um número de build igual ou superior a 1367. No entanto, em imagens OL8 do OKE que têm um número de build menor que 1367 (e em imagens da plataforma OL8), os cgroups v1 são ativados por padrão.

Para nós de trabalho em clusters que executam o Kubernetes versão 1.35 (e posterior), o Kubernetes Engine suporta as seguintes imagens:

Em clusters que executam o Kubernetes versão 1.35 (e posterior), o uso de imagens de plataforma (imagens de plataforma OL7 e imagens de plataforma OL8) não é recomendado. Recomendamos enfaticamente o uso de imagens do OKE para todas as novas implantações e upgrades. Se quiser continuar usando uma imagem de plataforma, crie uma imagem personalizada com base na imagem da plataforma e especifique o OCID da imagem personalizada ao criar ou atualizar um pool de nós (observe que não recomendamos essa abordagem).

Ao fazer upgrade de nós gerenciados que atualmente usam uma imagem OL8 para o Kubernetes versão 1.35 (e posterior), observe o seguinte:

  • Você pode fazer upgrade de nós gerenciados que atualmente usam uma imagem OL8 do OKE (ou uma imagem personalizada baseada em uma imagem OL8 do OKE) com um número de build inferior a 1367, executando um upgrade no local e especificando uma imagem OL8 do OKE com um número de build igual ou superior a 1367.
  • Você pode fazer upgrade de nós gerenciados que atualmente usam uma imagem de plataforma OL8 executando um upgrade no local e especificando uma imagem OL8 do OKE com um número de build igual ou superior a 1367.
  • Você pode executar upgrades no local de nós gerenciados que atualmente usam uma imagem OL8, independentemente de os kernels Linux das instâncias de computação que hospedam os nós já terem os cgroups v2 ativados.
  • Para obter instruções sobre como executar upgrades no local, consulte Upgrading Managed Nodes to a Newer Kubernetes Version.
  • Para obter mais informações sobre a introdução do suporte para o Kubernetes versão 1.35, consulte OKE Welcomes Kubernetes 1.35: What's new, what's change, and what to do next.

Validar cargas de trabalho para cgroups v2

Antes de atualizar nós de trabalho de produção, verifique se os aplicativos e os agentes de suporte são compatíveis com cgroups v2.

cgroups v2 pode alterar a forma como a memória do contêiner é contabilizada. Um aumento no uso relatado de memória de contêiner por si só não indica necessariamente saturação de memória. Investigue um aumento quando ele for acompanhado por uma ou mais das seguintes condições:

  • Terminações de OOM (contêiner out-of-memory)
  • Reinicializações de contêiner ou pod.
  • Despejos de pod.
  • A condição do nó MemoryPressure.

Para obter informações sobre requisitos de cgroups v2, contabilidade de memória, compatibilidade de runtime e determinação da versão de cgroups usada por um nó, consulte Sobre o cgroup v2 na documentação do Kubernetes.

Runtimes de aplicativos mais antigos podem não detectar corretamente limites de recursos de contêiner em sistemas que usam cgroups v2. Por exemplo, um aplicativo Java pode calcular heap ou outras definições de memória a partir dos recursos do nó de trabalho em vez do limite de memória do contêiner. Como resultado, o contêiner pode exceder seu limite de memória configurado e ser encerrado pelo killer do Linux OOM.

Para cargas de trabalho Java, use uma das seguintes releases do JDK ou uma release posterior:

  • JDK 15
  • JDK 11.0.16
  • JDK 8u381

O JDK 8u372 introduziu o reconhecimento cgroups v2. O JDK 8u381 inclui melhorias adicionais na detecção de limites de recursos cgroups v1 e cgroups v2, métricas de contêiner e estabilidade de aplicativos. Para outras distribuições JDK e tempos de execução de aplicativos, consulte a documentação do fornecedor para identificar uma versão que suporte cgroups v2.

Verifique também a compatibilidade de monitoramento, segurança e outros agentes que acessam diretamente o /sys/fs/cgroup. Atualize agentes incompatíveis para versões que suportem cgroups v2.

Antes de fazer upgrade dos nós de trabalho de produção, execute a seguinte validação em um ambiente de não produção:

  1. Teste cargas de trabalho representativas e agentes de suporte em nós que usam cgroups v2.
  2. Compare as seguintes informações antes e depois de ativar os cgroups v2:
    • Uso de memória de contêiner reportado
    • Eventos OOM do contêiner
    • Reinicializações de contêiner e pod
    • Despejos de pod
    • A condição do nó MemoryPressure
    • O limite de memória detectado pelo runtime do aplicativo

  3. Para cargas de trabalho Java:

    • Grave a versão do JDK digitando:

      java -version

    • Revise as definições do sistema e do contêiner detectadas pela JVM digitando: 

      java -XshowSettings:system -version

    • Configure valores -Xms e -Xmx explícitos quando apropriado para a carga de trabalho.

Fazer upgrade dos nós gerenciados do OL7 para executar o Kubernetes versão 1.35 (ou posterior)

Para fazer upgrade de nós gerenciados que atualmente usam uma imagem do OKE OL7, uma imagem da plataforma OL7 ou uma imagem personalizada baseada em uma imagem do OL7, para executar o Kubernetes versão 1.35 (ou posterior), execute um upgrade fora do local para substituir o pool de nós existente por um novo pool de nós:

  1. Identifique os pools de nós existentes que usam OL7, usando a Console ou a CLI da seguinte forma:

    • Usando a Console:

      1. Na página da lista Clusters, selecione o nome do cluster que contém os pools de nós que você deseja ver. Se precisar de ajuda para localizar a página de lista ou o cluster, consulte Listando Clusters.
      2. Selecione a guia Pools de nós.
      3. Use a coluna Nome da imagem para identificar pools de nós que usam imagens Oracle-Linux-7.9.x.

    • Usando a CLI: Identifique pools de nós existentes que usam OL7 digitando um comando semelhante ao seguinte:

      oci ce node-pool list --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --query 'data[*].{name:"name", image:"node-source"."image-id"}'

  2. Crie um pool de nós de substituição que use uma imagem OL8, usando a Console ou a CLI da seguinte forma:

    • Usando a Console:

      1. Na guia Pools de nós, selecione Adicionar pool de nós e informe detalhes para o novo pool de nós.
      2. Selecione uma Imagem do Nó de Trabalho do OKE com base em uma imagem Oracle Linux 8.x.
      3. Configure o novo pool de nós com a mesma forma, tamanho e posicionamento do pool de nós OL7.
      4. Selecione Criar.

    • Usando a CLI: Crie um pool de nós de substituição que use uma imagem OL8 informando um comando semelhante ao seguinte:

      oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name "nodepool-ol8-workers" --node-shape "VM.Standard.E4.Flex" --kubernetes-version "v1.35.0" --node-image-id <ol8-image-ocid> --size 3 --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"<subnet-ocid>"}]'

  3. Conecte os nós OL7:

    1. Obtenha os nomes dos nós OL7 digitando:

      kubectl get nodes -l node.kubernetes.io/os=ol7

    2. Cordon cada nó inserindo:

      kubectl cordon <node-name>

  4. Escorra os nós OL7 para migrar cargas de trabalho normalmente:

    1. Escorra cada nó OL7 digitando:
      kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force
    2. Verifique se as cargas de trabalho foram reprogramadas nos novos nós digitando:
      kubectl get pods -A -o wide | grep <node-name>

  5. Exclua o pool de nós OL7 usando a Console ou a CLI, da seguinte forma:

    • Usando a Console:

      1. Na guia Pools de nós, selecione Excluir pool de nós no menu Ações (três pontos) ao lado do pool de nós OL7.
      2. Clique em Excluir.
      3. Confirme se deseja excluir o pool de nós e selecione Excluir.

    • Usando a CLI: Exclua o pool de nós OL7:

      oci ce node-pool delete --node-pool-id <ol7-nodepool-ocid>

  6. Faça upgrade do cluster (por exemplo, para o Kubernetes versão 1.35):

    oci ce cluster update --cluster-id <cluster-ocid> --kubernetes-version "v1.35.0"

Para obter mais informações, consulte Executando um Upgrade do Kubernetes do Nó Gerenciado Fora do Lugar Substituindo um Pool do Nó Existente por um Novo Pool do Nó.