Esta página apresenta considerações e recomendações que ajudam a migrar cargas de trabalho de clusters do Google Kubernetes Engine (GKE) padrão para clusters do Autopilot com a mínima interrupção dos seus serviços. Esta página destina-se a administradores de clusters que já decidiram migrar para o Autopilot. Se precisar de mais informações antes de decidir migrar, consulte Escolha um modo de funcionamento do GKE e Compare o GKE Autopilot e o GKE Standard.
Como funciona a migração
Os clusters do Autopilot automatizam muitas das funcionalidades opcionais e da funcionalidade que requerem configuração manual em clusters Standard. Além disso, os clusters do Autopilot aplicam configurações predefinidas mais seguras para as aplicações, de modo a oferecer um ambiente mais pronto para produção e reduzir a sobrecarga de gestão necessária em comparação com o modo Standard. Os clusters do Autopilot aplicam muitas práticas recomendadas e recomendações do GKE por predefinição. O Autopilot usa um modelo de configuração centrado na carga de trabalho, em que pede o que precisa nos seus manifestos do Kubernetes e o GKE aprovisiona a infraestrutura correspondente.
Quando migrar as suas cargas de trabalho padrão para o Autopilot, deve preparar os manifestos das cargas de trabalho para garantir que são compatíveis com os clusters do Autopilot. Por exemplo, deve garantir que os manifestos pedem infraestrutura que, normalmente, teria de aprovisionar por si.
Para preparar e executar uma migração bem-sucedida, vai realizar as seguintes tarefas de alto nível:
- Execute uma verificação prévia no cluster padrão existente para confirmar a compatibilidade com o modo automático.
- Se aplicável, modifique os manifestos da carga de trabalho para se tornarem compatíveis com o Autopilot.
- Faça um teste de funcionamento em vazio para verificar se as cargas de trabalho funcionam corretamente no Autopilot.
- Planeie e crie o cluster do Autopilot.
- Se aplicável, atualize as ferramentas de infraestrutura como código.
- Faça a migração.
Antes de começar
Antes de começar, certifique-se de que realizou as seguintes tarefas:
- Ative a API Google Kubernetes Engine. Ative a API Google Kubernetes Engine
- Se quiser usar a CLI gcloud para esta tarefa,
instale-a e, em seguida,
inicialize-a. Se instalou anteriormente a CLI gcloud, execute
gcloud components updatepara obter a versão mais recente.
- Certifique-se de que tem um cluster padrão existente com cargas de trabalho em execução.
- Certifique-se de que tem um cluster do Autopilot sem cargas de trabalho para fazer testes de execução. Para criar um novo cluster do Autopilot, consulte o artigo Crie um cluster do Autopilot.
Ative o componente de verificação prévia no seu cluster
Na versão 1.31.6-gke.1027000 e posteriores do GKE, o componente de verificação prévia do Autopilot está desativado por predefinição. Tem de ativar o componente de verificação pré-voo antes de poder executar a verificação num cluster. Se o seu cluster executar uma versão do GKE anterior a 1.31.6-gke.1027000, avance para a secção seguinte.
Ative o componente de verificação pré-voo no seu cluster:
gcloud container clusters update CLUSTER_NAME \ --location=LOCATION \ --enable-autopilot-compatibility-auditingSubstitua o seguinte:
CLUSTER_NAME: o nome do seu cluster padrão.LOCATION: a localização do seu cluster padrão, comous-central1.
A operação de atualização demora até 30 minutos a ser concluída.
Execute uma verificação pré-voo no cluster padrão
A CLI do Google Cloud e a API Google Kubernetes Engine oferecem uma ferramenta de verificação prévia que valida as especificações das suas cargas de trabalho padrão em execução para identificar incompatibilidades com clusters do Autopilot. Esta ferramenta está disponível na versão 1.26 e posteriores do GKE.
- Para usar esta ferramenta na linha de comandos, execute o seguinte comando:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Substitua CLUSTER_NAME pelo nome do seu cluster Standard. Opcionalmente, adicione --format=json a este comando para obter o resultado num ficheiro JSON.
O resultado contém conclusões para todas as suas cargas de trabalho padrão em execução, categorizadas e com recomendações acionáveis para garantir a compatibilidade com o Autopilot, quando aplicável. A tabela seguinte descreve as categorias:
| Resultados da ferramenta de pré-publicação | |
|---|---|
Passed |
A carga de trabalho é executada conforme esperado sem necessidade de configuração para o Autopilot. |
Passed with optional configuration |
A carga de trabalho é executada no Autopilot, mas pode fazer alterações de configuração opcionais para otimizar a experiência. Se não fizer alterações à configuração, o Autopilot aplica uma configuração predefinida por si. Por exemplo, se a sua carga de trabalho estivesse a ser executada em máquinas N2 no modo padrão, o GKE aplica a classe de computação de uso geral para o Autopilot. Opcionalmente, pode modificar a carga de trabalho para pedir a classe de computação equilibrada, que é suportada por máquinas N2. |
Additional configuration required |
A carga de trabalho não é executada no Autopilot, a menos que faça uma alteração de configuração. Por exemplo, considere um contentor que usa a capacidade NET_ADMIN no padrão. O Autopilot desativa esta capacidade por predefinição para melhorar a segurança, pelo que tem de ativar o NET_ADMIN no cluster antes de implementar a carga de trabalho. |
Incompatibility |
A carga de trabalho não é executada no Autopilot porque usa funcionalidades que o Autopilot não suporta. Por exemplo, os clusters do Autopilot rejeitam pods privilegiados
( |
Modifique as especificações da carga de trabalho com base nos resultados da pré-publicação
Depois de executar a verificação prévia, percorra a saída JSON e identifique as cargas de trabalho que têm de ser alteradas. Recomendamos que implemente mesmo as recomendações de configuração opcionais. Cada descoberta também fornece um link para a documentação que mostra o aspeto da especificação da carga de trabalho.
A diferença mais importante entre o Autopilot e o Standard é que a configuração da infraestrutura no Autopilot é automatizada com base na especificação da carga de trabalho. Os controlos de agendamento do Kubernetes, como as manchas e as tolerâncias dos nós, são adicionados automaticamente às suas cargas de trabalho em execução. Se necessário, também deve modificar as configurações de infraestrutura como código, como gráficos Helm ou sobreposições Kustomize, para corresponderem.
Seguem-se algumas alterações de configuração comuns que tem de fazer:
| Alterações de configuração comuns para o Autopilot | |
|---|---|
| Configuração de computação e arquitetura | Os clusters do Autopilot usam o tipo de máquina da série E por predefinição. Se precisar de outros tipos de máquinas, a especificação da carga de trabalho tem de pedir uma classe de computação, que indica ao Autopilot para colocar esses pods em nós que usam tipos de máquinas ou arquiteturas específicos. Para obter detalhes, consulte o artigo Calcule as classes no modo de condução autónoma. |
| Aceleradores | As cargas de trabalho baseadas em GPU têm de pedir GPUs na especificação da carga de trabalho. O Autopilot aprovisiona automaticamente nós com o tipo de máquina e os aceleradores necessários. Para mais detalhes, consulte o artigo Implemente cargas de trabalho de GPU no Autopilot. |
| Pedidos de recursos | Todas as cargas de trabalho do Autopilot têm de especificar valores para
Para ver detalhes, consulte o artigo Pedidos de recursos no Autopilot. |
| Cargas de trabalho com tolerância a falhas em VMs do Spot | Se as suas cargas de trabalho forem executadas em VMs do Spot no Standard,
peça pods do Spot na configuração da carga de trabalho definindo um seletor de nós para Para obter detalhes, consulte o artigo Spot Pods. |
Faça um teste de execução num cluster de preparação do Autopilot
Depois de modificar cada manifesto da carga de trabalho, faça uma implementação de teste num novo cluster do Autopilot de preparação para garantir que a carga de trabalho é executada conforme esperado.
Linha de comandos
Execute o seguinte comando:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Substitua PATH_TO_MANIFEST pelo caminho para o manifesto da carga de trabalho modificado.
IDE
Se usar o editor do Cloud Shell, o comando de teste é incorporado e executado em todos os manifestos abertos. Se usar os IDEs Visual Studio Code ou Intellij, instale a extensão Cloud Code para executar automaticamente o teste de execução em qualquer manifesto aberto.
O painel Problemas no IDE mostra quaisquer problemas de teste de execução, como na imagem seguinte, que mostra um teste de execução falhado para um manifesto que especificou privileged: true.
Planeie o cluster do Autopilot de destino
Quando a execução de teste deixar de apresentar problemas, planeie e crie o novo cluster do Autopilot para as suas cargas de trabalho. Este cluster é diferente do cluster do Autopilot que usou para testar as modificações do manifesto na secção anterior.
Use as práticas recomendadas para a integração no GKE para requisitos de configuração básicos. Em seguida, leia a vista geral do Autopilot, que fornece informações específicas do seu exemplo de utilização em diferentes camadas.
Além disso, considere o seguinte:
- Os clusters do Autopilot são nativos da VPC, pelo que não recomendamos a migração para o Autopilot a partir de clusters padrão baseados em rotas.
- Use a mesma VPC ou uma VPC semelhante para o cluster do Autopilot e o cluster Standard, incluindo quaisquer regras de firewall personalizadas e definições de VPC.
- Os clusters do Autopilot usam o GKE Dataplane V2 e só suportam Cilium NetworkPolicies. As NetworkPolicies do Calico não são suportadas.
- Se quiser usar o mascaramento de IP no Autopilot, use uma política de NAT de saída.
- Especifique o intervalo IPv4 principal para o cluster durante a criação do cluster, com o mesmo tamanho do intervalo que o cluster padrão.
- Saiba mais sobre as diferenças de quota entre modos, especialmente se tiver clusters grandes.
- Saiba mais sobre os máximos de pods por nó para o Autopilot, que são diferentes do Standard. Isto é mais importante se usar frequentemente a afinidade de nós ou pods.
- Todos os clusters do Autopilot usam o Cloud DNS.
Crie o cluster do Autopilot
Quando estiver pronto para criar o cluster, use a opção Criar um cluster do Autopilot. Todos os clusters do Autopilot são regionais e estão automaticamente inscritos num canal de lançamento, embora possa especificar o canal e a versão do cluster. Recomendamos que implemente uma pequena carga de trabalho de exemplo no cluster para acionar o aprovisionamento automático de nós, de modo que as suas cargas de trabalho de produção possam ser agendadas imediatamente.
Atualize as ferramentas de infraestrutura como código
Os seguintes fornecedores de infraestrutura como código suportam o Autopilot:
Leia a documentação do seu fornecedor preferencial e modifique as configurações.
Escolha uma abordagem de migração
O método de migração que usa depende da sua carga de trabalho individual e do seu nível de familiaridade com conceitos de rede, como serviços de vários clusters e entrada de vários clusters, bem como da forma como gere o estado dos objetos Kubernetes no seu cluster.
| Tipo de carga de trabalho | Resultados da ferramenta de pré-publicação | Abordagem de migração |
|---|---|---|
| Sem estado |
|
Para cargas de trabalho |
| Com estado |
|
Use um dos seguintes métodos:
|
| Configuração adicional necessária | Atualize os manifestos do Kubernetes e volte a implementar no Autopilot durante o tempo de inatividade agendado. Para ver os passos de alto nível, consulte o artigo Migre manualmente cargas de trabalho com estado. |
Passos de migração de alto nível
Antes de iniciar uma migração, certifique-se de que resolveu todos os resultados Incompatible ou Additional configuration required da verificação prévia. Se implementar cargas de trabalho com esses resultados no Autopilot sem modificações, as cargas de trabalho vão falhar.
As secções seguintes apresentam uma vista geral de nível superior de uma migração hipotética. Os passos reais variam consoante o seu ambiente e cada uma das suas cargas de trabalho. Planeie, teste e volte a testar as cargas de trabalho para detetar problemas antes de migrar um ambiente de produção. As considerações incluem o seguinte:
- A duração do processo de migração depende do número de cargas de trabalho que está a migrar.
- O tempo de inatividade é necessário enquanto migra as cargas de trabalho com estado.
- A migração manual permite-lhe focar-se em cargas de trabalho individuais durante a migração, para que possa resolver problemas em tempo real caso a caso.
- Em todos os casos, certifique-se de que migra os serviços, as entradas e outros objetos do Kubernetes que facilitam a funcionalidade das suas cargas de trabalho sem estado e com estado.
Migre todas as cargas de trabalho com a Cópia de segurança do GKE
Se todas as cargas de trabalho (com e sem estado) em execução no seu cluster Standard forem compatíveis com o Autopilot e a ferramenta de pré-implementação devolver Passed ou Passed with optional configuration para cada carga de trabalho, pode usar o Backup for GKE para fazer uma cópia de segurança de todo o estado do seu cluster Standard e cargas de trabalho e restaurar a cópia de segurança no cluster do Autopilot.
Esta abordagem tem as seguintes vantagens:
- Pode mover todas as cargas de trabalho do modo padrão para o modo de funcionamento do Autopilot com uma configuração mínima.
- Pode mover cargas de trabalho sem estado e com estado, e manter as relações entre cargas de trabalho, bem como os PersistentVolumes associados.
- As reversões são intuitivas e geridas pela Google. Pode reverter toda a migração ou reverter seletivamente cargas de trabalho específicas.
- Pode migrar cargas de trabalho com estado entre Google Cloud regiões. A migração manual de cargas de trabalho com estado só pode ocorrer na mesma região.
Quando usa este método, o GKE aplica as configurações predefinidas do Autopilot a cargas de trabalho que receberam um resultado da ferramenta de pré-implementação.Passed with optional configuration Antes de migrar estas cargas de trabalho, certifique-se de que
concorda com essas predefinições.
Migre manualmente cargas de trabalho sem estado sem tempo de inatividade
Para migrar cargas de trabalho sem estado sem tempo de inatividade para os seus serviços, regista os clusters de origem e destino numa GKE Fleet e usa serviços de vários clusters e o Ingress de vários clusters para garantir que as suas cargas de trabalho permanecem disponíveis durante a migração.
- Ative os serviços em vários clusters e a entrada em vários clusters para o cluster de origem e o cluster de destino. Para ver instruções, consulte os artigos Configurar serviços de vários clusters e Configurar a entrada de vários clusters.
- Se tiver dependências de back-end, como uma carga de trabalho de base de dados, exporte esses serviços do cluster Standard através de serviços de vários clusters. Isto permite que as cargas de trabalho no cluster do Autopilot acedam às dependências no cluster Standard. Para ver instruções, consulte o artigo Registar um serviço para exportação.
- Implemente um Ingress em vários clusters e um serviço em vários clusters para controlar o tráfego de entrada entre clusters. Configure o serviço em vários clusters para enviar tráfego apenas para o cluster padrão. Para ver instruções, consulte o artigo Implementar o Ingress em vários clusters.
- Implemente as suas cargas de trabalho sem estado com manifestos atualizados no cluster do Autopilot. Os serviços em vários clusters exportados correspondem automaticamente e enviam tráfego para as cargas de trabalho com estado correspondentes.
- Atualize o serviço em vários clusters para direcionar o tráfego de entrada para o cluster do Autopilot. Para ver instruções, consulte a secção Seleção de clusters.
Agora, está a publicar as suas cargas de trabalho sem estado a partir do cluster do Autopilot. Se só tinha cargas de trabalho sem estado no cluster de origem e não restam dependências, avance para Concluir a migração. Se tiver cargas de trabalho com estado, avance para a secção Migre manualmente cargas de trabalho com estado.
Migre manualmente cargas de trabalho com estado
Depois de migrar as cargas de trabalho sem estado, tem de suspender e migrar as cargas de trabalho com estado do cluster padrão. Este passo requer tempo de inatividade para o cluster.
- Inicie o tempo de inatividade do ambiente.
- Suspenda as suas cargas de trabalho com estado.
- Certifique-se de que modificou os manifestos da carga de trabalho para compatibilidade com o Autopilot. Para ver detalhes, consulte o artigo Modifique as especificações da carga de trabalho com base nos resultados da pré-validação.
Implemente as cargas de trabalho no cluster do Autopilot.
Implemente os serviços para as suas cargas de trabalho com estado no cluster do Autopilot.
Atualize a rede no cluster para permitir que as cargas de trabalho sem estado continuem a comunicar com as respetivas cargas de trabalho de back-end:
- Se usou um endereço IP estático nos serviços de back-end do cluster Standard, reutilize esse endereço IP no Autopilot.
- Se permitir que o Kubernetes atribua um endereço IP, implemente os seus serviços de back-end, obtenha o novo endereço IP e atualize o seu DNS para usar o novo endereço IP.
Nesta fase, o seguinte deve ser verdadeiro:
- Está a executar todas as suas cargas de trabalho sem estado no Autopilot.
- Todas as cargas de trabalho com estado do back-end também estão a ser executadas no Autopilot.
- As suas cargas de trabalho sem estado e com estado podem comunicar entre si.
- O serviço em vários clusters direciona todo o tráfego de entrada para o seu cluster do Autopilot.
Quando tiver migrado todas as cargas de trabalho e objetos do Kubernetes para o novo cluster, avance para Concluir a migração.
Alternativa: migre manualmente todas as cargas de trabalho durante o tempo de inatividade
Se não quiser usar serviços de vários clusters e o Ingress de vários clusters para migrar cargas de trabalho com um tempo de inatividade mínimo, migre todas as cargas de trabalho durante o tempo de inatividade. Este método resulta num tempo de inatividade mais longo para os seus serviços, mas não requer o uso de funcionalidades de vários clusters.
- Inicie o tempo de lazer.
- Implemente os seus manifestos sem estado no cluster do Autopilot.
- Migre manualmente as suas cargas de trabalho com estado. Para ver instruções, consulte a secção Migre manualmente cargas de trabalho com estado.
- Modifique os registos de DNS para o tráfego externo de entrada e intra-cluster para usar os novos endereços IP dos serviços.
- Termine o tempo de lazer.
Conclua a migração
Depois de mover todas as cargas de trabalho e serviços para o novo cluster do Autopilot, termine o tempo de inatividade e permita que o seu ambiente seja absorvido durante um período predeterminado. Quando estiver satisfeito com o estado da migração e tiver a certeza de que não vai precisar de reverter a migração, pode limpar os artefactos de migração e concluir a migração.
Opcional: limpe as funcionalidades de vários clusters
Se usou o Ingress de vários clusters e os serviços de vários clusters para migrar e não quiser que o cluster do Autopilot permaneça registado numa frota, faça o seguinte:
- Para o tráfego externo de entrada, implemente uma entrada e defina-a para o endereço IP dos serviços que expõem as suas cargas de trabalho. Para obter instruções, consulte o artigo Entrada para balanceadores de carga de aplicações externos.
- Para o tráfego intra-cluster, como de cargas de trabalho de front-end para dependências com estado, atualize os registos DNS do cluster para usar os endereços IP desses serviços.
- Elimine os recursos de entrada em vários clusters e de serviço em vários clusters que criou durante a migração.
- Desative a entrada em vários clusters e os serviços em vários clusters.
- Anule o registo do cluster do Autopilot na frota.
Elimine o cluster Standard
Depois de decorrido tempo suficiente após a conclusão da migração e se estiver satisfeito com o estado do novo cluster, elimine o cluster padrão. Recomendamos que mantenha os seus manifestos padrão com cópia de segurança.
Reverta uma migração com falhas
Se tiver problemas e quiser reverter para o cluster padrão, faça uma das seguintes ações, consoante a forma como fez a migração:
Se usou a Cópia de segurança do GKE para criar cópias de segurança durante a migração, restaure as cópias de segurança no cluster Standard original. Para ver instruções, consulte Restaurar uma cópia de segurança.
Se migrou manualmente as cargas de trabalho, repita os passos de migração nas secções anteriores com o cluster Standard como destino e o cluster Autopilot como origem. A um nível elevado, isto envolve os seguintes passos:
- Inicie o período de descanso.
- Migrar manualmente cargas de trabalho com estado para o cluster Standard. Para ver instruções, consulte a secção Migre manualmente cargas de trabalho com estado.
- Mova as cargas de trabalho sem estado para o cluster Standard através dos manifestos originais dos quais fez uma cópia de segurança antes da migração.
- Implemente o Ingress no cluster Standard e transfira o seu DNS para os novos endereços IP dos serviços.
- Elimine o cluster do Autopilot.
O que se segue?
- Plan Autopilot resource requests
- Configure a monitorização
- Configure e use o painel de controlo da postura de segurança