Modernização do plano de controle gerenciado

É necessário modernizar suas 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. É possível iniciar a modernização de acordo com sua própria programação ou deixar que o Google a programe automaticamente quando sua organização for compatível.

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

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

Seja qual for o caminho escolhido, você precisa concluir as seguintes etapas principais para modernizar seu plano de controle:

  1. Verificar sua 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 de clusters e frotas ou adie frotas específicas.
  3. Corrigir lacunas de compatibilidade: verifique se as 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 do Google.
  5. Modernização de cluster ativo: 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. Será necessário reiniciar manualmente as cargas de trabalho StatefulSet e DaemonSet.
  6. Monitorar o status, o soak e a finalização: monitore o progresso da condição, resolva as interrupções, observe as cargas de trabalho durante o período de soak (pelo menos seis dias úteis), com suporte total para reversão 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 iniciativa do cliente ou do Google, ela precisa ser verificada como compatível. Ative os relatórios de compatibilidade para inspecionar possíveis condições de bloqueio e corrigir lacunas de configuração. Para mais detalhes, consulte Noções básicas sobre a compatibilidade do Cloud Service Mesh.

  • Para a modernização orientada pelo Google: o Google só vai programar organizações em que todas as frotas não adiadas sejam compatíveis.
  • Para modernização acionada 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 do ISTIOD, o Google Cloud está encerrando o suporte a recursos incompatíveis com a implementação do plano de controle do TRAFFIC_DIRECTOR. Confira os detalhes do suporte à API.

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

  • Refatorar a configuração (recomendado): remova os campos não compatíveis ou substitua-os por alternativas compatíveis do Cloud Service Mesh para que sua frota informe 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 estritamente recursos que o Cloud Service Mesh gerenciado com TRAFFIC_DIRECTOR não oferece, não será possível modernizar esses clusters para o 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 para modernizar suas frotas. Se você não fizer isso, a modernização do Google será aplicada de maneira padrão. É preciso entrar em ação para garantir que as frotas que não são de produção sejam modernizadas primeiro e as frotas críticas sejam modernizadas por último. Além disso, a modernização do 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, sua modernização pode ser bloqueada por incompatibilidades locais.

Antes de iniciar a modernização, analise as opções e defina as configurações de lançamento nas frotas e nos clusters da sua organização.

Caminhos 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 de acordo com sua própria programação. Controle granular sobre o momento da modernização da frota (você decide quando iniciar e quando reverter no nível da frota). Aproveitar o monitoramento de aplicativos 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 forem compatíveis. Toda a Google Cloud organização (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 de frota com mais de 14 dias + notificação de 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 do aplicativo mostrar um erro.

Gerenciar várias frotas em uma organização

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

  • Adiar frotas complexas ou críticas: fixe frotas específicas na implementação legada usando --modernization-strategy deferred para que elas sejam excluídas da programação orientada 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: primeiro, modernize as frotas de teste, desenvolvimento ou avaliação para validar o comportamento no seu próprio cronograma.
  • Permitir que o Google modernize as frotas restantes: todas as frotas compatíveis e não adiadas permanecem ativadas para a programação orientada pelo Google.

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

Para desativar a modernização do Google em uma frota individual, defina a estratégia 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 da programação do Google porque você pretende modernizá-las no seu próprio cronograma usando a modernização acionada pelo cliente.
  • Suspenda 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 a programação orientada pelo Google.

O rótulo de projeto legado mesh-modernization-mode=manual ainda é respeitado, mas recomendamos usar --modernization-strategy deferred. Outras frotas não adiadas na sua organização continuam qualificadas para o agendamento do Google quando todas forem compatíveis.

Como configurar a ordem de lançamento

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

Ordem de lançamento do cluster (aplica-se aos dois caminhos)

Se uma frota tiver vários clusters, será possível controlar a ordem em que eles são modernizados aplicando o rótulo mesh-modernization-order a cada cluster. Quando você ou o Google acionam a modernização de uma frota, cada grupo de clusters é modernizado sequencialmente, aguardando a conclusão das etapas de modernização automatizadas 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 uma das seguintes opções:

  • 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 frotas (somente para o Google)

Em organizações com várias frotas passando por modernização gerenciada pelo Google, é possível controlar a ordem em que o Google moderniza as frotas definindo o rótulo para envolvidos no 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 uma das seguintes opções:

  • early: a frota é modernizada na primeira onda de modernização.
  • default: a frota é 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, primeiro o nível antecipado, depois o padrão (e sem rótulo) e, por fim, o tardio. As frotas marcadas como adiadas não são incluídas nessa ordem.

Por exemplo, é possível definir as frotas que não são de produção 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 acionada pelo cliente (autoatendimento)

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

Como acionar a modernização da frota

Depois que 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 de manutenção e as exclusões configuradas do cluster. A modernização do cluster começa durante a próxima janela de manutenção aberta do cluster.
  • Ordenação de clusters: se você configurou rótulos mesh-modernization-order nos clusters, o Google vai respeitar 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. Observe o monitoramento do aplicativo para determinar se você precisa de uma reversão, especialmente durante os status MODERNIZATION_PREPARING e MODERNIZATION_MIGRATING_WORKLOADS.

Como reverter uma modernização acionada pelo cliente

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

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 orientada pelo Google. Quando estiver tudo pronto para tentar novamente, execute o comando para acionar a modernização da frota.

Modernização orientada 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 com malha ativada na sua organização (exceto as frotas adiadas) forem compatíveis com a modernização, o Google vai programar a modernização da sua organização.

Notificações e programação com antecedência

O Google envia dois avisos com antecedência 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 orientada pelo Google no futuro.

  • A modernização do cluster pode começar até 14 dias após o primeiro dia útil nos EUA 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 as 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 para a modernização do cluster pelo Google, pelo menos um dia (24 horas) antes do início da modernização.

Após a notificação no nível da frota, você tem um tempo muito mais preciso para a 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).

Como solicitar a reversão para a modernização orientada pelo Google

Se surgirem problemas durante a modernização ativa ou a imersão em uma frota de modernização orientada pelo Google, entre em contato com o Cloud Customer Care para solicitar uma reversão.

O que acontece durante a modernização ativa

Nesta seção, descrevemos o que acontece durante a modernização ativa de frotas e clusters.

Modernização de frotas

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

Depois que o plano de controle é ativado para todos os clusters, mudamos o tráfego para a nova implementação do plano de controle para todos os clusters com base na ordem (antecipado → padrão → tardio).

Consulte Verificar o status de 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 todos os clusters concluírem a modernização antes da transição para MODERNIZATION_FINALIZED. A capacidade de reversão total é preservada durante todo o período de imersão. Depois que a modernização for finalizada, não será mais possível fazer a reversão, e os componentes do ISTIOD poderão ser desprovisionados.

Como 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 e, 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, essa etapa vai começar durante uma janela de manutenção e continuar até ser concluída. Observe os seguintes detalhes:
    • Os pods gerenciados pela implantação do Kubernetes que têm proxies do Cloud Service Mesh são reiniciados para que se reconectem 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 pelas implantações do Kubernetes. As cargas de trabalho gerenciadas por outros tipos de recursos do Kubernetes, como StatefulSets e DaemonSets, precisam ser reiniciadas manualmente.
    • Depois que as cargas de trabalho de Deployment forem reiniciadas, se alguma carga de trabalho no cluster ainda tiver proxies do Cloud Service Mesh conectados a ISTIOD, o cluster vai informar MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART com MODERNIZATION_MIGRATING_WORKLOADS.
    • Reinicie as cargas de trabalho restantes manualmente para que os proxies se conectem à implementação do plano de controle TRAFFIC_DIRECTOR. O Google aguarda pelo menos 60 dias para que você reinicie todas as cargas de trabalho antes de prosseguir para os clusters subsequentes (em uma frota de vários clusters) ou iniciar o período de imersão da frota.
    • Para verificar quais proxies ainda estão conectados ao ISTIOD, execute o comando gcloud beta container fleet mesh debug proxy-status, conforme descrito em Ver o status do plano de controle. Os proxies com um ID de instância do Istiod na coluna ISTIOD da resposta ao comando ainda se conectam a ISTIOD e exigem uma reinicialização manual.
    • Depois que todas as cargas de trabalho da malha no cluster se conectarem a TRAFFIC_DIRECTOR, MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART será limpo automaticamente e o status do cluster será alterado para MODERNIZATION_COMPLETED.

  4. Depois que todas as cargas de trabalho em um cluster forem transferidas, o cluster vai aguardar o período de permanência da frota.

Para monitorar o status de modernização ativa dos clusters, consulte Verificar o status de modernização.

Verificar o status da modernização e entrar em ação

É possível monitorar o progresso da modernização das frotas e dos 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 de 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 de frota bem-sucedida, o status da frota começa como MODERNIZATION_MODERNIZING.

Cada cluster passaria pelos status:

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • (opcionalmente) MODERNIZATION_MIGRATING_WORKLOADS com MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART
  • 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 acionamos automaticamente uma reversão se detectarmos problemas. Se você detectar um problema, entre em contato com o Cloud Customer Care para solicitar uma reversão.

Para modernizações acionadas pelo cliente, é possível acionar uma reversão a qualquer momento.

Durante uma reversão, a frota mostra o status MODERNIZATION_ROLLING_BACK_FLEET e o cluster mostra o status MODERNIZATION_ROLLING_BACK_CLUSTER.

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

Como lidar com erros e travamentos (somente acionados pelo cliente)

Durante a modernização acionada pelo cliente, se um cluster encontrar um problema que impeça o progresso, a condição dele vai mudar para MODERNIZATION_STALLED. O Google não vai acionar reversões para modernizações acionadas pelo cliente. Você precisa fazer a triagem do problema e decidir se quer corrigir ou acionar uma reversão.

Quando um cluster relatar MODERNIZATION_STALLED, inspecione os detalhes da condição para encontrar um link direto para a seção de erro relevante:

Erros que podem ser resolvidos pelo usuário

Se detectarmos uma configuração de malha ou cluster incompatível, 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 em busca de lacunas, conforme descrito em Noções básicas sobre a compatibilidade do Cloud Service Mesh.

  • Nova tentativa imediata: assim que o bloqueador é resolvido, detectamos a mudança e retomamos a modernização imediatamente, sem esperar pela 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 ocorre com erros que podem ser resolvidos pelo usuário. Para evitar isso, acionar uma reversão.

Se a modernização estiver travada por mais de 24 horas e não houver lacunas de compatibilidade, entre em contato com o Cloud Customer Care para mais detalhes ou acionar uma reversão se as cargas de trabalho de produção forem afetadas.

Referência de 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 imersão.
MODERNIZATION_FINALIZED A modernização foi concluída e finalizada. Os componentes legados do Istiod serão removidos. Não é mais possível fazer a reversão.
MODERNIZATION_ROLLING_BACK_FLEET Uma reversão no nível da frota está em andamento.

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

Condição Descrição
MODERNIZATION_SCHEDULED A modernização do cluster está programada para a data especificada na condição ou depois dela. Se as janelas/exclusões de manutenção estiverem configuradas para o 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 cargas de trabalho para a nova implementação do plano de controle.
MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART A migração automatizada de cargas de trabalho foi concluída. Reinicie as cargas de trabalho de malha que não sejam Deployment, como StatefulSets, DaemonSets ou Jobs, para que os proxies se conectem à implementação do plano de controle TRAFFIC_DIRECTOR.
MODERNIZATION_COMPLETED O cluster concluiu a modernização e está no período de imersão.
MODERNIZATION_STALLED A modernização está travada devido a um erro (somente acionada pelo cliente). Consulte os detalhes da condição para resolver o problema.
MODERNIZATION_ROLLING_BACK_CLUSTER O cluster está sendo revertido.
MODERNIZATION_ABORTED O cluster foi revertido para o plano de controle legado. Informado por um curto período.