Modernização do plano de controle gerenciado

<0x0

É necessário modernizar as frotas do Cloud Service Mesh da implementação do plano de controle ISTIOD descontinuada para a implementação TRAFFIC_DIRECTOR antes do prazo de fim do suporte. Você pode iniciar a modernização na sua própria programação ou deixar que o Google faça isso automaticamente quando sua organização estiver compatível.

Há dois caminhos de modernização, e você também pode misturá-los:

  • Modernização iniciada pelo cliente (autoatendimento): você inicia e controla o momento exato da modernização da frota usando a Google Cloud CLI, independente dos cronogramas definidos pelo Google.
  • Modernização orientada pelo Google (padrão): o Google avalia a compatibilidade da frota e agenda automaticamente a modernização em toda a organização de acordo com janelas de manutenção e notificações antecipadas. O Google aguarda que todas as frotas da sua organização sejam compatíveis. Assim, uma única frota incompatível vai bloquear sua modernização.

Independente do caminho escolhido, você precisa concluir as seguintes etapas principais para modernizar seu plano de controle:

  1. Verifique a compatibilidade: ative as verificações de compatibilidade e entenda a compatibilidade das suas frotas com a modernização.
  2. Planejar e configurar sua modernização: escolha seu caminho, configure a ordem de lançamento do cluster e da frota ou adie frotas específicas.
  3. Corrija as lacunas de compatibilidade: verifique se suas frotas atendem a todos os requisitos de compatibilidade antes de iniciar a modernização.
  4. Iniciar a modernização: acione a modernização iniciada pelo cliente na sua programação ou aguarde a programação feita pelo Google.
  5. Modernização ativa do cluster: durante as janelas de manutenção configuradas, os planos de controle duplos são executados lado a lado, e as implantações (cargas de trabalho e gateways) fazem a transição automática para o novo plano de controle. É necessário reiniciar manualmente as cargas de trabalho do StatefulSet e do DaemonSet.
  6. Monitorar status, período de teste e finalização: monitore o progresso da condição, resolva qualquer paralisação, observe as cargas de trabalho durante o período de teste (pelo menos 6 dias úteis), com suporte completo de rollback antes da finalização no nível da frota.

Verificar a compatibilidade da frota e corrigir lacunas

Antes que qualquer frota possa ser modernizada, seja por modernização iniciada pelo cliente ou pelo Google, ela precisa ser verificada como compatível. É necessário ativar os relatórios de compatibilidade para inspecionar possíveis condições de bloqueio e corrigir falhas de configuração. Para mais detalhes, consulte Entender a compatibilidade do Cloud Service Mesh.

  • Para a modernização orientada pelo Google: o Google só agenda organizações em que todas as frotas não adiadas são compatíveis.
  • Para a modernização iniciada pelo cliente: verifique se a frota de destino informa MODERNIZATION_COMPATIBLE antes de iniciar a modernização.

As verificações de compatibilidade avaliam as configurações de CRD do Istio da sua frota, as anotações de pod, as dependências de infraestrutura (como a Identidade da carga de trabalho) e os parâmetros de escalonamento.

Como lidar com recursos incompatíveis

Como parte da descontinuação do plano de controle ISTIOD,o Google Cloud vai encerrar o suporte a recursos incompatíveis com a implementação do plano de controle TRAFFIC_DIRECTOR. Confira detalhes sobre o suporte à API.

Se você estiver usando recursos sem suporte, faça uma das seguintes ações antes do fim do suporte (consulte Descontinuações):

  • Refatore sua configuração (recomendado): remova os campos sem suporte ou substitua-os por alternativas compatíveis do Cloud Service Mesh para que os relatórios da frota sejam MODERNIZATION_COMPATIBLE e, em seguida, modernize para a implementação do plano de controle TRAFFIC_DIRECTOR.
  • Migrar para o Istio de código aberto (OSS): se as cargas de trabalho exigirem recursos que o Cloud Service Mesh gerenciado com TRAFFIC_DIRECTOR não oferece suporte, não será possível modernizar esses clusters para TRAFFIC_DIRECTOR. É necessário migrar essas cargas de trabalho para o Istio de código aberto autogerenciado.
  • Desinstalar o Cloud Service Mesh: é possível desinstalar o Cloud Service Mesh gerenciado.

Planejar e configurar sua modernização

Crie um plano de modernização para suas frotas. Se você não fizer isso, a modernização impulsionada pelo Google será aplicada de maneira padrão. É necessário tomar medidas para garantir que as frotas de não produção sejam modernizadas primeiro e as frotas críticas por último. Além disso, a modernização impulsionada pelo Google não vai programar a modernização da sua organização até que 100% das frotas não adiadas em toda a organização sejam compatíveis. Portanto, a modernização pode ser bloqueada por incompatibilidades locais.

Antes de iniciar a modernização, revise suas opções e configure as configurações de lançamento em todas as frotas e clusters da sua organização.

Programas disponíveis

Abordagem Descrição Ideal para Escopo Pré-requisitos Aviso com antecedência Capacidade de reversão
Modernização acionada pelo cliente Você inicia a modernização frota por frota no seu próprio cronograma. Controle granular sobre o tempo de modernização da frota: você decide quando iniciar e quando reverter no nível da frota. Aproveitar o monitoramento de aplicativos atual para alertar você se uma reversão for necessária. Frota por frota (FLEET_PROJECT_ID). A frota de destino precisa ser compatível com a modernização. N/A. Reversão imediata de autoatendimento usando a Google Cloud CLI.
Modernização orientada pelo Google (padrão) O Google programa automaticamente a modernização em toda a organização. Modernização automatizada quando todas as frotas da organização estiverem compatíveis. Toda a organização Google Cloud (todas as frotas não adiadas). Todas as frotas não adiadas na organização precisam ser compatíveis com a modernização. Notificação da frota com mais de 14 dias e notificação do cluster com mais de 24 horas antes do início. O Google vai reverter se o monitoramento padronizado mostrar um erro. Entre em contato com o Cloud Customer Care se o monitoramento de aplicativos mostrar um erro.

Gerenciar várias frotas em uma organização

Se a sua Google Cloud organização gerencia várias frotas, não é necessário escolher uma única abordagem para todas elas. É possível combinar estratégias, por exemplo:

  • Adie frotas complexas ou críticas: fixe frotas específicas na implementação legada usando --modernization-strategy deferred para que elas sejam excluídas do agendamento controlado pelo Google enquanto você corrige dependências ou planeja a execução acionada pelo cliente.
  • Comece com a modernização acionada pelo cliente em frotas selecionadas: modernize primeiro as frotas de teste, desenvolvimento ou avaliação para validar o comportamento na sua própria linha do tempo.
  • Permitir que o Google modernize as frotas restantes: todas as frotas compatíveis e não adiadas permanecem ativadas para o agendamento feito pelo Google.

Adiar a modernização da frota (desativação)

Para desativar uma frota individual da modernização orientada pelo Google, defina a estratégia dela como DEFERRED:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota.

Definir --modernization-strategy deferred é a maneira recomendada de:

  • Exclua frotas específicas do agendamento feito pelo Google porque você pretende modernizá-las no seu próprio cronograma usando a modernização acionada pelo cliente.
  • Adie temporariamente a modernização em frotas complexas ou críticas enquanto você corrige dependências, permitindo que outras frotas compatíveis na sua organização prossigam com o agendamento orientado pelo Google.

Observe que o rótulo do projeto legado mesh-modernization-mode=manual continua sendo respeitado, mas --modernization-strategy deferred é recomendado. Outras frotas não adiadas na sua organização ainda se qualificam para o agendamento do Google quando estiverem todas compatíveis.

Configurar a ordem de lançamento

É possível controlar a ordem de lançamento sequencial em clusters e frotas usando o rótulo mesh-modernization-order (inicial, padrão ou tardio).

Ordem de lançamento do cluster (válida para os dois caminhos)

Se uma frota tiver vários clusters, você poderá controlar a ordem em que eles são modernizados aplicando o rótulo mesh-modernization-order a cada cluster. Quando você ou o Google aciona a modernização de uma frota, cada grupo de clusters é modernizado sequencialmente, aguardando a conclusão das etapas de modernização automatizada no grupo atual antes de iniciar o próximo:

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

Substitua CLUSTER_NAME pelo nome do cluster, LOCATION pelo local do cluster e VALUE por um dos seguintes:

  • early: o cluster é modernizado na primeira onda de modernização.
  • default: o cluster é modernizado na segunda onda de modernização.
  • late: o cluster é modernizado na terceira e última onda de modernização.

Ordenação de lançamento de frota (somente pelo Google)

Em organizações com várias frotas passando por modernização impulsionada pelo Google, é possível controlar a ordem em que o Google moderniza as frotas definindo o rótulo no nível do projeto no projeto host da frota:

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota e VALUE por um dos seguintes:

  • early: a frota é modernizada na primeira onda de modernização.
  • default: a frota será modernizada na segunda onda de modernização.
  • late: a frota é modernizada na terceira e última onda de modernização.

O Google conclui a modernização de cada nível da frota antes de iniciar o próximo: antecipado, padrão (e sem rótulo) e tardio. As frotas marcadas como adiadas não são incluídas nessa ordenação.

Por exemplo, é possível definir as frotas não produtivas como early, uma frota especialmente crítica como late e deixar as outras no padrão.

Se você não usar organizações do Google Cloud , suas frotas serão programadas e modernizadas de forma independente, e não será possível controlar a ordem.

Modernização iniciada pelo cliente (autoatendimento)

A modernização iniciada pelo cliente oferece controle direto sobre quando a modernização começa para uma frota individual.

Acionamento da modernização da frota

Quando a frota de destino informar MODERNIZATION_COMPATIBLE, acione a modernização usando o seguinte comando:

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota.

  • Janelas de manutenção: o Google respeita as janelas e exclusões de manutenção configuradas para o cluster. A modernização do cluster começa durante a próxima janela de manutenção aberta.
  • Ordenação de cluster: se você configurou rótulos mesh-modernization-order nos clusters, o Google respeita essa ordenação.

Monitorar o progresso

Siga as instruções em Verificar o status da modernização para monitorar o progresso da modernização da frota e do cluster. Monitore o monitoramento do aplicativo para determinar se é necessário uma reversão, especialmente durante os status MODERNIZATION_PREPARING e MODERNIZATION_MIGRATING_WORKLOADS.

Reverter uma modernização iniciada pelo cliente

Se você detectar problemas durante a modernização ativa do cluster ou durante o período de imersão da frota (antes da finalização no nível da frota), poderá acionar um rollback imediato:

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota.

Isso vai deixar sua frota no estado adiado, ou seja, ela não será considerada para a modernização impulsionada pelo Google. Quando estiver tudo pronto para tentar de novo, execute o comando para acionar a modernização da frota.

Modernização impulsionada pelo Google (padrão automatizado)

Se você não iniciar a modernização acionada pelo cliente, o Google vai gerenciar a modernização em toda a organização automaticamente.

Programação em toda a organização

O Google monitora continuamente suas frotas. Depois que todas as frotas compatíveis com malha na sua organização (exceto as adiadas) estiverem prontas para modernização, o Google vai agendar a modernização da sua organização.

Notificações e programação antecipadas

O Google oferece dois níveis de notificação antecipada antes de iniciar a modernização:

Notificação no nível da frota

Primeiro, você vai receber uma notificação quando suas frotas forem identificadas como compatíveis com a modernização e selecionadas para a modernização impulsionada pelo Google no futuro.

  • A modernização do cluster pode começar 14 dias após o primeiro dia útil do mês seguinte à notificação. Por exemplo, se o Google determinar que sua organização está pronta em 10 de janeiro de 2027, vamos notificar você até 31 de janeiro de 2027 que a data de início mais próxima possível da modernização é 15 de fevereiro de 2027.

  • Você vai receber uma notificação simultânea para cada uma das frotas na sua organização (exceto aquelas que você adiou). Essa notificação está disponível nas condições de estado do recurso no nível da frota (MODERNIZATION_WILL_BE_SCHEDULED).

Notificação no nível do cluster

Você vai receber uma notificação no nível do cluster sobre a data de início estimada da modernização do cluster pelo Google, pelo menos um dia (24 horas) antes do início da modernização.

Depois da notificação no nível da frota, isso oferece um cronograma muito mais preciso de modernização de clusters individuais. Essa notificação está disponível nas condições de estado do recurso no nível do cluster (MODERNIZATION_SCHEDULED).

Solicitar o rollback da modernização feita pelo Google

Se surgirem problemas durante a modernização ativa ou o soaking em uma frota de modernização controlada pelo Google, entre em contato com o Cloud Customer Care para solicitar um rollback.

O que acontece durante a modernização ativa

Esta seção descreve o que acontece durante a modernização ativa de frotas e clusters.

Modernização de frotas

Para cada frota em modernização (seja por iniciativa do Google ou do cliente), ativamos a nova implementação do plano de controle para todos os clusters com base na ordenação (inicial → padrão → tardia).

Depois que o plano de controle for ativado para todos os clusters, vamos transferir o tráfego para a nova implementação do plano de controle para todos os clusters com base na ordenação (inicial → padrão → tardio).

Consulte Verificar o status da modernização da frota para conferir o status atual.

Período de imersão da frota

Depois que o tráfego é transferido para todos os clusters, a frota entra em um período de imersão. A frota permanece no período de imersão (MODERNIZATION_MODERNIZED) por pelo menos seis dias úteis após a conclusão da modernização de todos os clusters antes da transição para MODERNIZATION_FINALIZED. A capacidade de reversão total é preservada durante todo o período de teste. Depois que a modernização é concluída, não é mais possível fazer o rollback, e os componentes do ISTIOD podem ser desprovisionados.

Modernizar um cluster

Durante a modernização ativa de um cluster, as duas implementações do plano de controle são executadas temporariamente lado a lado. De maneira segura e controlada, as seguintes tarefas são processadas:

  1. Ative a nova implementação do plano de controle. Se você configurou janelas de manutenção para o cluster, essa etapa vai começar durante uma janela de manutenção e continuar até ser concluída. Observe os seguintes detalhes:
  2. Mude o tráfego para a nova implementação do plano de controle. Se você configurou janelas de manutenção para o cluster, esta etapa vai começar durante uma janela de manutenção e continuar até a conclusão. Observe os seguintes detalhes:
    • Os pods gerenciados pela implantação do Kubernetes que têm proxies do Cloud Service Mesh são reiniciados para se reconectarem ao novo plano de controle.
    • Os pods são reiniciados em ondas progressivamente maiores com tempo de imersão após cada onda para monitoramento.

  3. Reinicializações manuais de cargas de trabalho para não implantações (ação do cliente necessária).

    • O Google reinicia automaticamente as cargas de trabalho gerenciadas por implantações do Kubernetes. As cargas de trabalho gerenciadas por outros tipos de recursos do Kubernetes, como StatefulSets e DaemonSets, precisam ser reiniciadas manualmente.
    • Reinicie essas cargas de trabalho depois que o status do cluster informar MODERNIZATION_COMPLETED (ou seja, quando o cluster estiver no período de absorção).
    • É necessário reiniciar essas cargas de trabalho antes da conclusão da modernização da frota. Caso contrário, esses proxies vão permanecer conectados ao plano de controle legado do Istiod, que está programado para desprovisionamento.
    • Reinicie cargas de trabalho usando abordagens padrão do Kubernetes, como kubectl rollout restart ...

  4. Depois que todas as cargas de trabalho em um cluster são transferidas, o cluster aguarda o período de permanência da frota.

Para monitorar o status ativo da modernização dos seus clusters, consulte Verificar o status da modernização.

Verificar o status da modernização e tomar medidas

É possível monitorar o progresso da modernização das suas frotas e clusters usando a Google Cloud CLI:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota.

A saída é semelhante a:

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

O status da modernização é informado nos campos state.servicemesh.conditions (nível da frota) e membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (nível do cluster):

Status de uma modernização de frota bem-sucedida

Em uma modernização bem-sucedida, o status da frota começa como MODERNIZATION_MODERNIZING.

Cada cluster passaria pelos seguintes status:

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • MODERNIZATION_COMPLETED

Depois que todos os clusters da frota concluírem a modernização, a frota vai passar pelos seguintes status:

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

Reversões

A modernização orientada pelo Google monitora a prontidão e a integridade da implantação durante todo o processo de modernização, e vamos acionar automaticamente um rollback se detectarmos problemas. Se você detectar um problema, entre em contato com o Cloud Customer Care para solicitar um rollback.

Para modernização iniciada pelo cliente, é possível acionar um rollback a qualquer momento.

Durante um rollback, a frota mostra o status MODERNIZATION_ROLLING_BACK_FLEET e o cluster mostra o status MODERNIZATION_ROLLING_BACK_CLUSTER.

Quando uma reversão de cluster é concluída, ela mostra temporariamente o status MODERNIZATION_ABORTED.

Como lidar com erros e interrupções (somente iniciados pelo cliente)

Durante a modernização iniciada pelo cliente, se um cluster encontrar um problema que impede o progresso, a condição dele vai mudar para MODERNIZATION_STALLED. O Google não vai acionar rollbacks para modernização iniciada pelo cliente. Você precisa analisar o problema e decidir se vai corrigir ou acionar um rollback.

Quando um cluster informa MODERNIZATION_STALLED, inspecione os detalhes da condição para um link direto à seção de erros relevante:

Erros que exigem ação do usuário

Se detectarmos uma configuração incompatível de malha ou cluster, vamos interromper a modernização. Verifique se os relatórios de compatibilidade estão ativados e analise as condições no nível da frota e do cluster para identificar lacunas, conforme descrito em Entender a compatibilidade do Cloud Service Mesh.

  • Nova tentativa imediata: assim que o bloqueio é resolvido, detectamos a mudança e retomamos a modernização imediatamente, sem esperar a próxima janela de manutenção.

Erros internos

Os problemas internos do serviço do Google são analisados por engenheiros do Google, que vão retomar a modernização, se possível. A modernização pode ser retomada fora de uma janela de manutenção, assim como para erros que exigem ação do usuário. Para evitar isso, faça um rollback.

Se a modernização estiver parada há mais de 24 horas e não houver falhas de compatibilidade, entre em contato com o Cloud Customer Care para mais detalhes ou faça um rollback se as cargas de trabalho de produção forem afetadas.

Referência das condições no nível da frota

Condição Descrição
MODERNIZATION_COMPATIBLE A frota é compatível com a nova implementação do plano de controle.
MODERNIZATION_WILL_BE_SCHEDULED Modernização impulsionada pelo Google: todas as frotas não adiadas na organização são compatíveis e foram colocadas na fila para programação.
MODERNIZATION_MODERNIZING A modernização está em andamento para um ou mais clusters na frota.
MODERNIZATION_MODERNIZED Todos os clusters concluíram a modernização ativa. A frota está no período de teste.
MODERNIZATION_FINALIZED A modernização foi concluída e finalizada. Os componentes legados do Istiod serão removidos. Não é mais possível fazer o rollback.
MODERNIZATION_ROLLING_BACK_FLEET Um rollback no nível da frota está em andamento.

Referência de condições no nível do cluster

Condição Descrição
MODERNIZATION_SCHEDULED O cluster está programado para modernização na data especificada na condição ou após ela. Se janelas/exclusões de manutenção estiverem configuradas para seu cluster, a data vai indicar a janela de manutenção de destino.
MODERNIZATION_PREPARING Ativar a nova implementação do plano de controle.
MODERNIZATION_PREPARED A nova implementação do plano de controle está ativada. A migração da carga de trabalho ainda não começou.
MODERNIZATION_MIGRATING_WORKLOADS O cluster está migrando ativamente as cargas de trabalho para a nova implementação do plano de controle.
MODERNIZATION_COMPLETED O cluster concluiu a modernização e está no período de imersão.
MODERNIZATION_STALLED A modernização está paralisada devido a um erro (somente acionado pelo cliente). Consulte os detalhes da condição para saber como resolver.
MODERNIZATION_ROLLING_BACK_CLUSTER O cluster está sendo revertido.
MODERNIZATION_ABORTED O cluster foi revertido para o plano de controle legado. Denunciado por um curto período.