Documentação do Oracle Cloud Infrastructure

Upgrade de Clusters para Versões Mais Recentes do Kubernetes

Descubra as diferentes maneiras de fazer upgrade dos nós de plano de controle e dos nós de trabalho para versões mais recentes do Kubernetes usando o Kubernetes Engine (OKE).

Após a liberação de uma nova versão do Kubernetes e quando o Kubernetes Engine suporta a nova versão, você pode fazer upgrade da versão do Kubernetes em execução nos nós de plano de controle e nos nós de trabalho de um cluster.

Os nós do plano de controle e os nós de trabalho que formam o cluster poderão executar diferentes versões do Kubernetes, desde que você siga a política de suporte a skew de versão do Kubernetes descrita na documentação do Kubernetes.

Você faz upgrade dos nós do plano de controle e dos nós de trabalho de formas diferentes:

  • Upgrade do nó do plano de controle: Você faz upgrade dos nós do plano de controle fazendo upgrade do cluster e especificando uma versão mais recente do Kubernetes para o cluster. É feito o upgrade dos nós do plano de controle que executam versões mais antigas do Kubernetes. Como o Serviço Kubernetes Engine distribui o Plano de Controle do Kubernetes em vários nós de plano de controle gerenciados pela Oracle para garantir a alta disponibilidade (distribuídos entre diferentes domínios de disponibilidade em uma região na qual é suportado), você poderá fazer upgrade da versão do Kubernetes em execução nos nós de plano de controle com indisponibilidade zero.

    Tendo feito upgrade dos nós do plano de controle para uma nova versão do Kubernetes, você poderá criar subsequentemente novos pools de nós com os nós de trabalho que executam a versão mais recente. Por outro lado, você poderá continuar criando novos pools de nós com os nós de trabalho que executarão as versões mais antigas do Kubernetes (desde que essas versões mais antigas sejam compatíveis com a versão do Kubernetes em execução nos nós do plano de controle).

    Para obter mais informações sobre o upgrade do nó do plano de controle, consulte Fazendo Upgrade da Versão do Kubernetes nos Nós do Plano de Controle em um Cluster.

  • Upgrade do nó de trabalho: você faz upgrade dos nós gerenciados, autogerenciados e virtuais de maneira diferente:
    • Upgrade do nó gerenciado: Você faz upgrade dos nós de trabalho de uma das seguintes maneiras:
      • Executando um upgrade 'in-place' de um pool de nós no cluster, especificando uma versão mais recente do Kubernetes para o pool de nós existente e, em seguida, reiniciando os nós para substituir os volumes de inicialização das instâncias que hospedam nós de trabalho existentes ou para encerrar e substituir os nós de trabalho existentes.
      • Executando um upgrade 'no local' de um pool de nós no cluster, especificando uma versão mais recente do Kubernetes para o pool de nós existente e, em seguida, substituindo manualmente cada nó de trabalho existente por um novo nó de trabalho.
      • Executando um upgrade 'fora do local' de um pool de nós no cluster, substituindo o pool de nós original por um novo para o qual você especificou uma versão mais recente do Kubernetes.

      Para obter mais informações sobre upgrade de nó gerenciado, consulte Fazendo Upgrade de Nós Gerenciados para uma Versão Mais Recente do Kubernetes.

    • Upgrade de nós autogerenciados: Você faz upgrade de nós autogerenciados substituindo um nó autogerenciado existente por um novo nó autogerenciado hospedado em uma nova instância de computação. Para obter mais informações sobre o upgrade do nó autogerenciado, consulte Atualizando Nós Autogerenciados para uma Versão Mais Nova do Kubernetes Substituindo um Nó Autogerenciado Existente.
    • Upgrade do nó virtual: Você faz upgrade dos nós virtuais fazendo upgrade dos nós do plano de controle em um cluster. Quando você faz upgrade da versão do Kubernetes em execução nos nós de plano de controle, os nós virtuais em cada pool de nós virtuais no cluster também são submetidos a upgrade automaticamente para essa versão do Kubernetes. Para obter mais informações sobre o upgrade do nó virtual, consulte Fazendo Upgrade de Nós Virtuais para uma Versão Mais Recente do Kubernetes.

Para obter mais informações sobre as versões do Kubernetes suportadas no momento e anteriormente pelo Kubernetes Engine, consulte Versões Suportadas do Kubernetes.

Observações sobre o Upgrade de Clusters

Observe o seguinte ao fazer upgrade de clusters:

  • O Kubernetes Engine só faz upgrade da versão do Kubernetes em execução nos nós do plano de controle quando você inicia explicitamente a operação de upgrade.
  • Depois de fazer upgrade dos nós do plano de controle para uma versão mais recente do Kubernetes, você não poderá fazer o downgrade deles para uma versão anterior do Kubernetes.
  • Antes de fazer upgrade da versão do Kubernetes em execução nos nós do plano de controle, é de sua responsabilidade testar se os aplicativos implantados no cluster são compatíveis com a nova versão do Kubernetes. Por exemplo, antes de fazer upgrade do cluster existente, você pode criar um novo cluster separado com a nova versão do Kubernetes para testar seus aplicativos.
  • As versões do Kubernetes que estão sendo executadas nos nós do plano de controle e nos nós de trabalho devem ser compatíveis. Ou seja, a versão do Kubernetes nos nós do plano de controle deve ser de no máximo duas versões secundárias (ou três versões secundárias, a partir do Kubernetes versão 1.28) antes da versão do Kubernetes nos nós de trabalho. Consulte a política de suporte a skew de versão do Kubernetes descrita na documentação do Kubernetes.
  • Se a versão do Kubernetes que está sendo executada no momento nos nós do plano de controle for mais de uma versão anterior à versão mais recente suportada, você terá a opção de fazer upgrade para ela. Se você quiser fazer upgrade para uma versão do Kubernetes que esteja mais de uma versão acima da versão que está sendo executada nos nós do plano de controle, faça upgrade para cada versão intermediária em sequência sem ignorar versões (conforme descrito na documentação do Kubernetes).

  • Para fazer upgrade dos nós do plano de controle com sucesso em um cluster, o serviço de Painel de Controle do Kubernetes deve ser do tipo ClusterIP. Se o serviço do Painel de Controle do Kubernetes não for do tipo ClusterIP (por exemplo, se o serviço for do tipo NodePort), o upgrade falhará. Nesse caso, altere o tipo de serviço do Painel de Controle do Kubernetes de volta para ClusterIP (por exemplo, informando kubectl -n kube-system edit service kubernetes-dashboard e alterando o tipo).

  • Antes do Kubernetes versão 1.14, o Kubernetes Engine criava clusters com kube-dns como servidor DNS. No entanto, a partir do Kubernetes versão 1.14 em diante, o Kubernetes Engine cria clusters com CoreDNS como o servidor DNS. Quando você faz upgrade de um cluster criado pelo Kubernetes Engine de uma versão anterior para o Kubernetes 1.14 ou mais recente, o servidor kube-dns do cluster é substituído automaticamente pelo servidor CoreDNS. Observe que se você personalizou o comportamento do kube-dns usando o ConfigMap do kube-dns original, essas personalizações não serão transportadas para o ConfigMap do CoreDNS. Você terá de criar e aplicar um novo ConfigMap contendo as personalizações para substituir as definições no Corefile do CoreDNS. Para obter mais informações sobre o upgrade para o CoreDNS, consulte Configurando Servidores DNS para Clusters do Kubernetes.