Modernização do plano de controle gerenciado
É possível modernizar suas frotas do Cloud Service Mesh da implementação do plano de controle ISTIOD para a implementação TRAFFIC_DIRECTOR no seu próprio cronograma ou deixar que o Google faça isso automaticamente.
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. Por isso, 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:
- Verifique a compatibilidade: ative as verificações de compatibilidade e entenda a compatibilidade das suas frotas com a modernização.
- Planejar e configurar sua modernização: escolha seu caminho, configure a ordem de implantação do cluster e da frota ou adie frotas específicas.
- Corrija as lacunas de compatibilidade: verifique se suas frotas atendem a todos os requisitos de compatibilidade antes de iniciar a modernização.
- Iniciar a modernização: acione a modernização iniciada pelo cliente na sua programação ou aguarde a programação feita pelo Google.
- 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.
- Monitorar status, teste de resistência e finalização: monitore o progresso da condição, resolva qualquer paralisação, observe as cargas de trabalho durante o período de teste de resistência (pelo menos seis dias úteis), com suporte completo de rollback antes da finalização no nível da frota.
Verificar a compatibilidade da frota e corrigir falhas
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 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 sua frota de destino informa
MODERNIZATION_COMPATIBLEantes 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.
Planejar e configurar sua modernização
Crie um plano de como suas frotas devem ser modernizadas. 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 as opções e configure as definições de lançamento nas 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 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 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 da frota com mais de 14 dias e notificação do cluster com mais de 24 horas antes do início. | O Google 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 deferredpara 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 (por exemplo, para
realizar uma modernização acionada pelo cliente mais tarde ou corrigir dependências
complexas), 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.
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 continuam qualificadas para o agendamento do Google quando forem 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 é 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 estão incluídas nessa ordenação.
Por exemplo, você pode definir suas frotas de não produção como early, uma frota especialmente
crítica como late e deixar outras no padrão.
Se você não usar organizações do Google Cloud , as frotas serão programadas e modernizadas de forma independente, e não será possível controlar a ordem.
Modernização iniciada pelo cliente (autoatendimento)
Com a modernização iniciada pelo cliente, você tem controle direto sobre quando a modernização começa para uma frota individual.
Acionamento da modernização da frota
Quando sua 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 do cluster configuradas. 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-ordernos 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.
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 automático)
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 para 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 aviso prévio 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 até 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 período de teste em uma frota de modernização gerenciada 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 em 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 completa é 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:
- 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:
- Para ativar a verificação de integridade, o daemonset
snké criado no namespacekube-systemdo cluster, e uma regra de firewall por cluster é criada. - Para ativar a ingestão de grupo de endpoints de rede (NEG), a anotação
cloud.google.com/negé adicionada a todos os serviços do Kubernetes. - Novos recursos do Google Cloud , como mesh, routes, serviços de back-end e verificações de integridade, são criados no cluster.
- Alguns dos novos recursos têm limite de cota. É possível conferir cotas e pedir mais se necessário.
- O cluster é monitorado durante o tempo de imersão antes de passar para a próxima etapa.
- Para ativar a verificação de integridade, o daemonset
- 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é 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.
Reinicializações manuais de carga 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 imersã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 as cargas de trabalho usando abordagens padrão do Kubernetes, como
kubectl rollout restart ...
Depois que todas as cargas de trabalho em um cluster são migradas, 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 de frota bem-sucedida, o status da frota começa como
MODERNIZATION_MODERNIZING.
Cada cluster passaria pelos seguintes status:
MODERNIZATION_SCHEDULEDMODERNIZATION_PREPARINGMODERNIZATION_PREPAREDMODERNIZATION_MIGRATING_WORKLOADSMODERNIZATION_COMPLETED
Depois que todos os clusters da frota concluírem a modernização, a frota vai passar pelos seguintes status:
MODERNIZATION_MODERNIZEDMODERNIZATION_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 um rollback de cluster é concluído, ele 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 acionáveis 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 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 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 para erros que podem ser resolvidos pelo usuário. Para evitar isso, faça um rollback.
Se a modernização estiver parada há mais de 24 horas e não houver lacunas 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 |
Ativando a nova implementação do plano de controle. |
MODERNIZATION_PREPARED |
A nova implementação do plano de controle é 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. Relatado por um curto período. |