Gerenciar upgrades de clusters em ambientes de produção


Nesta página, mostramos como gerenciar upgrades de cluster do GKE usando o sequenciamento de lançamentos. Para saber mais, consulte Sobre upgrades de cluster com sequenciamento de lançamento.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud.

Configurar uma sequência de lançamento

Neste documento, explicamos como usar frotas e escopos de frota para organizar clusters e criar sequências de lançamento.

Com o sequenciamento de lançamento, você escolhe a ordem e o tempo de lançamento das versões em conjuntos de clusters no mesmo canal de lançamento. É possível criar uma sequência de até três escopos.

Para criar uma sequência de lançamento, seus clusters precisam ser organizados em escopos. Para saber como organizar seus clusters em escopos, consulte este exemplo. Depois que eles são organizados em escopos, é possível criar uma sequência de lançamento definindo as relações de escopo upstream e o tempo de imersão de cada escopo. Para saber mais sobre como isso funciona, consulte Como uma sequência de lançamento é criada.

Organizar os clusters em escopos

Em uma sequência de lançamento, todos os clusters em todos os escopos precisam estar registrados no mesmo canal de lançamento e na mesma versão secundária. Se esses requisitos não forem atendidos e houver discrepâncias de versão entre clusters, isso poderá causar problemas com o lançamento da versão. Para mais informações, consulte Qualificação para o lançamento.

Os escopos são uma unidade organizacional em uma frota. Os clusters podem ser registrados em uma frota e um escopo hospedados em um projeto diferente. É possível criar uma sequência de lançamento com escopos em várias frotas.

Se você já tiver organizado os clusters em escopos, pule as etapas a seguir e continue para Criar uma sequência de lançamento.

  1. Para cada cluster na sequência, registre-o em uma frota. O cluster precisa ser registrado na frota no projeto em que você vai criar o escopo. Se você quiser registrar um cluster em uma frota em um projeto host diferente, verifique se definiu as permissões necessárias para o registro entre projetos.
  2. Crie de dois a três escopos para organizar os clusters. Execute o comando no projeto host da respectiva frota do escopo. É possível ter até três escopos em uma sequência de lançamento. Repita o comando para cada escopo que você quer criar.

    Consulte a referência de gcloud alpha container fleet scopes create para ver uma lista completa de sinalizações. Com o comando create, é possível usar as sinalizações nas instruções para criar uma sequência de lançamento.

  3. Adicione cada cluster a um escopo.

Criar uma sequência de lançamento

Uma sequência de lançamento é organizada como uma lista vinculada. Para saber mais, consulte Como uma sequência de lançamento é criada. Ao criar uma sequência de lançamento, você define as seguintes propriedades para cada escopo:

  • Escopo upstream: o caminho do recurso do escopo upstream no formato projects/{project-number}/locations/global/scopes/{scope-name}. Não defina um escopo upstream para o primeiro escopo em uma sequência. O escopo upstream classifica novas versões para o escopo downstream.
  • Tempo de imersão: o tempo de imersão de um escopo é o momento entre o momento em que os upgrades foram concluídos (ou o lançamento levou 30 dias) e o momento em que eles podem começar no escopo downstream. Para saber mais, consulte Como funciona a qualificação de versões em uma sequência de lançamento.

É possível definir essas propriedades ao criar ou atualizar um escopo. As instruções a seguir usam o comando update. No entanto, é possível definir as mesmas propriedades ao criar um escopo com o comando create.

Para cada um dos comandos a seguir, substitua SOAK_TIME pelo tempo de imersão do escopo que você está atualizando.

  1. Defina o tempo de imersão do primeiro cluster na sequência:

    gcloud alpha container fleet scopes update FIRST_SCOPE \
        --default-upgrade-soaking=SOAK_TIME \
        --project=FIRST_SCOPE_PROJECT_ID
    

    Substitua FIRST_SCOPE pelo caminho completo do primeiro escopo e FIRST_SCOPE_PROJECT_ID pelo ID do projeto em que o primeiro escopo está hospedado.

  2. Defina o escopo upstream e o tempo de imersão para o segundo escopo na sequência:

    gcloud alpha container fleet scopes update SECOND_SCOPE \
        --upstream-scope=projects/FIRST_SCOPE_PROJECT_NUMBER/locations/global/scopes/FIRST_SCOPE \
        --default-upgrade-soaking=SOAK_TIME \
        --project=SECOND_SCOPE_PROJECT_ID
    

    Substitua SECOND_SCOPE pelo caminho completo do primeiro escopo e SECOND_SCOPE_PROJECT_ID pelo ID do projeto em que o segundo escopo está hospedado.

  3. Opcional: se você quiser ter três escopos em uma sequência de lançamento, defina o escopo upstream para o terceiro escopo na sequência:

    gcloud alpha container fleet scopes update THIRD_SCOPE \
        --upstream-scope=projects/SECOND_SCOPE_PROJECT/locations/global/scopes/SECOND_SCOPE \
        --default-upgrade-soaking=SOAK_TIME \
        --project=THIRD_SCOPE_PROJECT_ID
    

    Substitua THIRD_SCOPE pelo caminho completo do primeiro escopo e THIRD_SCOPE_PROJECT_ID pelo ID do projeto em que o terceiro escopo está hospedado.

Verificar a sequência de lançamento

Descreva o primeiro escopo na sequência para confirmar as configurações. Para cada um, ao descrever o escopo, você pode ver o escopo upstream e o escopo downstream.

Controlar o processo de lançamento de versão

Os upgrades de cluster com o GKE oferecem vários mecanismos para controle manual do processo. Além desses controles, há outras maneiras de controlar os upgrades de cluster com o sequenciamento de lançamento. Nesta seção, veja como é possível exercer o controle sobre os upgrades.

Verificar o status de uma sequência de lançamento

Verifique o status de uma sequência de lançamento:

gcloud alpha container fleet scopes describe SCOPE_NAME \
    --show-linked-cluster-upgrade
    --project=SCOPE_PROJECT_ID

Substitua SCOPE_NAME pelo nome de qualquer escopo na sequência de lançamento e SCOPE_PROJECT_ID pelo ID do projeto desse escopo. Se a sequência de lançamento tiver escopos entre projetos em diferentes frotas, você precisará ter as permissões necessárias para executar este comando.

Na saída, os atributos clusterUpgrade(s).spec e clusterUpgrade(s).state contêm mais informações sobre o upgrade do cluster, como tempo de imersão, substituições de upgrade de cluster e status do upgrade. Para mais informações sobre quais informações são fornecidas com esse comando, consulte Verificar o status do lançamento da versão em uma sequência.

Se você precisar apenas de informações sobre um escopo na sequência, substitua a sinalização --show-linked-cluster-upgrade por --show-cluster-upgrade.

Consulte a referência de gcloud alpha container fleet scopes describe para ver uma lista completa de sinalizações.

Para ver o status de clusters individuais em um escopo, execute o comando a seguir no projeto da frota em que o escopo está:

gcloud alpha container fleet features describe clusterupgrade

Resolver problemas de qualificação para o lançamento

Se todos os clusters em uma sequência de lançamento não tiverem o mesmo destino de upgrade, o GKE talvez não consiga continuar com os upgrades de cluster, porque os clusters no escopo upstream não validam o destino de upgrade necessário para clusters no escopo downstream.

Para verificar se a sequência de lançamento tem problemas de qualificação, confira o status da sequência de lançamento. Se um escopo não estiver qualificado, siga as instruções para ver o status de clusters individuais em um escopo.

Se um cluster não estiver qualificado porque está em uma versão anterior (por exemplo, a maioria dos clusters no escopo está sendo atualizada de 1.23 para 1.24 e um cluster está na versão 1.22), é possível fazer upgrade manual da a versão 1.24 para resolver a discrepância.

Se um cluster não estiver qualificado porque está em uma versão posterior (por exemplo, a maioria dos clusters no escopo está sendo atualizada de 1.23 para 1.24 e um cluster está na versão 1.25), não é possível fazer upgrade manual da cluster para resolver a discrepância entre as versões.

Para avançar imediatamente os upgrades de cluster, remova todos os clusters com status INELIGIBLE seguindo as instruções para Promover lançamentos parcialmente qualificados.

Mudar o tempo de imersão

Se você quiser que o tempo de imersão de um lançamento de versão específico seja diferente do tempo de imersão configurado para a sequência, é possível alterar isso usando a sinalização --add-upgrade-soaking-override com o seguinte comando:

gcloud alpha container fleet scopes update SCOPE_NAME \
    --add-upgrade-soaking-override=SOAK_TIME \
    --upgrade-selector=name=UPGRADE_NAME,version=VERSION

Substitua:

  • SCOPE_NAME: o nome do escopo para o qual você quer substituir o tempo de imersão usado para o lançamento de uma versão específica.
  • SOAK_TIME: o tempo de imersão a ser usado além do padrão. Por exemplo, "0d" se você quiser pular o tempo de imersão para um lançamento de versão.
  • UPGRADE_NAME: o nome do upgrade, pode ser k8s_control_plane ou k8s_node.
  • VERSION: a versão do GKE em que você quer o tempo de imersão após o lançamento neste escopo, por exemplo, 1.25.2-gke.400.

Por exemplo, se você já tiver qualificado uma nova versão e estiver pronto para upgrades para o próximo escopo, defina o tempo de imersão como zero. Também é possível usá-lo se quiser mais tempo do que o padrão de imersão para qualificar uma versão específica.

Mudar a ordem de uma sequência

Se você quiser alterar a ordem de uma sequência, use os comandos das instruções para Criar uma sequência de lançamento para atualizar os escopos upstream.

Atrasar a conclusão do lançamento da versão do escopo

Se você precisar impedir temporariamente que um escopo conclua o lançamento de uma nova versão para os clusters, adicione uma exclusão de manutenção a qualquer um dos clusters que não foi feito o upgrade para a versão de destino. Isso pode pausar um escopo, que pode continuar até o momento da imersão ou escopo downstream, por até 30 dias. Depois de 30 dias, o escopo começa a imersão.

É possível também alterar o tempo de imersão desse escopo para 30 dias a fim de maximizar o tempo que a sequência de lançamento aguarda antes de prosseguir para o próximo escopo.

Se você precisar atrasar ainda mais os upgrades a partir do próximo escopo, use exclusões de manutenção para os clusters do próximo escopo.

Destacar lançamentos parcialmente qualificados

Se os upgrades de cluster em um escopo ainda não tiverem atingido o limite de 30 dias e não terminarem devido a problemas de qualificação para a implantação (por exemplo, discrepâncias de versão em um escopo), será possível remover um cluster de um escopo para concluir o lançamento da versão e iniciar o tempo de imersão ou avançar para o próximo escopo na sequência de lançamento; Também é possível remover um cluster de um escopo por outros motivos, por exemplo, se o uso dele não estiver mais relacionado aos outros clusters no escopo.

Siga as instruções para remover clusters dos escopos.

Depois que você remover todos os clusters que estão impedindo a conclusão da implementação da versão de um escopo, o lançamento da versão do escopo será concluído. Confirme seguindo as instruções para verificar o status do lançamento de uma versão.

Excluir uma sequência

Para excluir uma sequência, use o comando a seguir para remover a associação do escopo upstream para o segundo escopo (e terceiro escopo, se a sequência de lançamento incluir três escopos):

gcloud alpha container fleet scopes update SCOPE_NAME --reset-upstream-scope

Substitua SCOPE_NAME pelo nome do escopo que você quer excluir.

Limpar

Para evitar cobranças inesperadas de faturamento, se você se inscreveu em um teste gratuito da API Anthos para testar o recurso de lançamento de lançamento, desative a API depois de terminar o teste na visualização particular. Desative a API antes que o projeto host da frota seja removido da lista de permissões desse recurso.

A seguir