Nesta página, fornecemos considerações e recomendações que ajudarão você a migrar cargas de trabalho de clusters padrão do Google Kubernetes Engine (GKE) para clusters do Autopilot com o mínimo de interrupção nos serviços. Esta página é destinada a administradores de cluster que já decidiram migrar para o Autopilot. Se você precisar de mais informações antes de decidir migrar, consulte Escolher um modo de operação do GKE e Comparar o Autopilot do GKE e o Standard.
Como funciona a migração
Os clusters do Autopilot automatizam muitos dos recursos e funcionalidades opcionais que exigem configuração manual em clusters padrão. Além disso, os clusters do Autopilot impõem configurações padrão mais seguras aos aplicativos para fornecer um ambiente mais pronto para produção e reduzir a sobrecarga de gerenciamento necessária em comparação com o modo padrão. Os clusters do Autopilot aplicam muitas práticas recomendadas e recomendações do GKE por padrão. O Autopilot usa um modelo de configuração centrado na carga de trabalho em que você solicita o que precisa nos manifestos do Kubernetes e o GKE provisiona a infraestrutura correspondente.
Ao migrar suas cargas de trabalho padrão para o Autopilot, você precisa preparar os manifestos de cargas de trabalho para garantir que sejam compatíveis com os clusters do Autopilot, por exemplo, garantindo que seus manifestos solicitem a infraestrutura que você normalmente teria que provisionar.
Para preparar e executar uma migração bem-sucedida, você fará as seguintes tarefas gerais:
- Execute uma verificação de pré-renderização no cluster padrão para confirmar a compatibilidade com o Autopilot.
- Modifique os manifestos da carga de trabalho para que sejam compatíveis com o Autopilot, se aplicável.
- Faça uma simulação para verificar se suas cargas de trabalho funcionam corretamente no Autopilot.
- Planeje e crie o cluster do Autopilot.
- Se aplicável, atualize as ferramentas de infraestrutura como código.
- Execute a migração.
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. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update.
- Verifique se você tem um cluster padrão atual com cargas de trabalho em execução.
- Verifique se você tem um cluster do Autopilot sem cargas de trabalho para realizar simulações. Para criar um novo cluster do Autopilot, consulte Criar um cluster do Autopilot.
Executar uma verificação de simulação no cluster padrão
A Google Cloud CLI e a API Google Kubernetes Engine fornecem uma ferramenta de verificação de simulação que valida as especificações das cargas de trabalho padrão em execução para identificar incompatibilidades com os clusters do Autopilot. Essa ferramenta está disponível nas versões 1.26 e posteriores do GKE.
- Para usar essa ferramenta na linha de comando, execute o seguinte comando:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Substitua CLUSTER_NAME pelo nome do cluster padrão. Se quiser, adicione --format=json a esse comando para receber a saída em um
arquivo JSON.
A saída contém descobertas 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 a seguir descreve as categorias:
| Resultados da ferramenta de simulação | |
|---|---|
Passed |
A carga de trabalho será executada conforme o esperado, sem a necessidade de configuração para o Autopilot. |
Passed with optional configuration |
A carga de trabalho será executada no Autopilot, mas é possível fazer alterações de configuração opcionais para otimizar a experiência. Se você não fizer alterações, o Autopilot aplicará uma configuração padrão. Por exemplo, se a carga de trabalho estava sendo executada em máquinas N2 no modo padrão, o GKE aplica a classe de computação de uso geral para o Autopilot. Opcionalmente, é possível modificar a carga de trabalho para solicitar a classe de computação equilibrada, que é apoiada por máquinas N2. |
Additional configuration required |
A carga de trabalho não será executada no Autopilot, a menos que você faça uma alteração de configuração. Por exemplo, pense em um contêiner que usa o recurso NET_ADMIN na classe Standard. O Autopilot descarta esse recurso por padrão para maior segurança. Portanto, é necessário ativar NET_ADMIN no cluster antes de implantar a carga de trabalho. |
Incompatibility |
A carga de trabalho não será executada no Autopilot porque ele usa uma funcionalidade que não é compatível com o Autopilot. Por exemplo, os clusters do Autopilot rejeitam os pods com privilégios ( |
Modificar suas especificações de carga de trabalho com base nos resultados de simulação
Depois de executar a verificação de simulação, percorra a saída JSON e identifique as cargas de trabalho que precisam ser alteradas. Recomendamos a implementação até mesmo das recomendações de configuração opcionais. Cada descoberta também fornece um link para a documentação que mostra como a especificação da carga de trabalho deve ser.
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 controles de programação do Kubernetes, como tolerâncias e taints de nós, são adicionados automaticamente às cargas de trabalho em execução. Se necessário, modifique também as configurações de infraestrutura como código, como gráficos do Helm ou sobreposições do Kustomize.
Algumas alterações comuns de configuração que precisam ser feitas incluem:
| Mudanças comuns na configuração do Autopilot | |
|---|---|
| Configuração de computação e arquitetura | Os clusters do Autopilot usam o tipo de máquina da série E por padrão. Se você precisar de outros tipos de máquina, sua especificação da carga de trabalho precisará solicitar uma classe de computação, que instrui o Autopilot a colocar esses pods em nós que usam arquiteturas ou tipos de máquina específicos. Para mais detalhes, consulte Classes de computação no Autopilot. |
| Aceleradores | As cargas de trabalho baseadas em GPU precisam solicitar GPUs na especificação. O Autopilot provisiona automaticamente os nós com o tipo de máquina e aceleradores necessários. Para mais detalhes, consulte Implantar cargas de trabalho da GPU no Autopilot. |
| Solicitações de recursos | Todas as cargas de trabalho do Autopilot precisam especificar valores para
Para mais detalhes, consulte Solicitações de recursos no Autopilot. |
| Cargas de trabalho tolerantes a falhas em VMs do Spot | Se as cargas de trabalho forem executadas em VMs do Spot no padrão,
solicite pods do Spot na configuração da carga de trabalho definindo um
seletor de nó para Para mais detalhes, consulte Pods do Spot. |
Executar uma simulação em um cluster de teste do Autopilot
Depois de modificar cada manifesto de carga de trabalho, faça uma implantação de simulação em um novo cluster de teste do Autopilot para garantir que a carga de trabalho seja executada conforme o esperado.
Linha de comando
Execute este comando:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Substitua PATH_TO_MANIFEST pelo caminho para o manifesto de carga de trabalho modificado.
Ambiente de desenvolvimento integrado
Se você usar o editor do Cloud Shell, o comando de simulação será integrado e executado em manifestos abertos. Se você usar o Visual Studio Code ou os ambientes de desenvolvimento integrado Intellij, instale a extensão do Cloud Code para executar automaticamente a simulação em qualquer manifesto aberto.
O painel Problems no ambiente de desenvolvimento integrado mostra todos os problemas de simulação, como na imagem a seguir, que mostra uma simulação de falha de um manifesto que especificou privileged: true.
Planejar o cluster de destino do Autopilot
Quando a simulação não exibir mais problemas, planeje e crie o novo cluster do Autopilot para suas cargas de trabalho. Esse cluster é diferente do cluster do Autopilot que você usou para testar as modificações do manifesto na seção anterior.
Use as Práticas recomendadas para integração com o GKE para requisitos básicos de configuração. Em seguida, leia a Visão geral do Autopilot, que fornece informações específicas para seu caso de uso em camadas diferentes.
Além disso, considere o seguinte:
- Os clusters do Autopilot são nativos de VPC. Por isso, não recomendamos migrar para o Autopilot de clusters padrão baseados em rotas.
- Use a mesma VPC ou uma semelhante para o cluster do Autopilot e o cluster padrão, incluindo regras de firewall personalizadas e configurações de VPC.
- Os clusters do Autopilot usam o GKE Dataplane V2 e são compatíveis apenas com Cilium NetworkPolicies. NetworkPolicies do Calico não são compatíveis.
- Se você quiser usar o mascaramento de IP no Autopilot, use uma política NAT de saída.
- Se você tiver um cluster particular padrão, crie um cluster particular do Autopilot com configurações de isolamento semelhantes.
- Especifique o intervalo IPv4 principal do cluster durante a criação dele com o mesmo tamanho do cluster padrão.
- Saiba mais sobre as diferenças de cota entre os modos, especialmente se você tiver clusters grandes.
- Saiba mais sobre os máximos de pods por nó para o Autopilot, que são diferentes do padrão. Isso será mais importante se você usar a afinidade de nós ou pods com frequência.
- Todos os clusters do Autopilot usam o Cloud DNS.
Criar o cluster do Autopilot
Quando estiver pronto para criar o cluster, use Criar um cluster do Autopilot. Todos os clusters do Autopilot são regionais e registrados automaticamente em um canal de lançamento, embora seja possível especificar o canal e a versão do cluster. Recomendamos implantar uma pequena carga de trabalho de amostra no cluster para acionar o provisionamento automático de nós para que as cargas de trabalho de produção possam ser programadas imediatamente.
Atualizar as ferramentas de infraestrutura como código
Os seguintes provedores de infraestrutura como código são compatíveis com o Autopilot:
Leia a documentação do provedor de sua preferência e modifique suas configurações.
Escolher uma abordagem de migração
O método de migração usado depende da sua carga de trabalho individual e da sua familiaridade com conceitos de rede, como serviços de vários clusters e Ingress de vários clusters e como gerenciar o estado dos objetos do Kubernetes no cluster.
| Tipo de carga de trabalho | Resultados da ferramenta de simulaçã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 reimplante no Autopilot durante o tempo de inatividade programado. Para etapas de alto nível, consulte Migrar manualmente cargas de trabalho com estado. |
Etapas 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 de simulação. Se você implantar cargas de trabalho com esses resultados no Autopilot sem modificações, elas falharão.
As seções a seguir são uma visão geral de alto nível sobre uma migração hipotética. As etapas reais variam de acordo com o ambiente e cada uma das cargas de trabalho. Planeje, teste e teste novamente as cargas de trabalho em busca de problemas antes de migrar um ambiente de produção. Inclui as seguintes considerações:
- A duração do processo de migração depende de quantas cargas de trabalho você está migrando.
- A inatividade é obrigatória enquanto você migra cargas de trabalho com estado.
- A migração manual permite que você se concentre 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 migrar serviços, entradas e outros objetos do Kubernetes que facilitem a funcionalidade das cargas de trabalho sem estado e com estado.
Migrar todas as cargas de trabalho usando o Backup para GKE
Se todas as cargas de trabalho (com e sem estado) em execução no cluster
padrão forem compatíveis com o Autopilot e a ferramenta de simulação retornar
Passed ou Passed with optional configuration para cada carga de trabalho, você
poderá usar Fazer backup do GKE
para fazer backup de todo o estado do cluster e das cargas de trabalho padrão e
restaurar o backup no cluster do Autopilot.
Essa abordagem tem os seguintes benefícios:
- É possível mover todas as cargas de trabalho da operação Padrão para o Autopilot com a configuração mínima necessária.
- É possível mover cargas de trabalho sem estado e com estado e manter as relações entre as cargas de trabalho e os PersistentVolumes associados.
- As reversões são intuitivas e gerenciadas pelo Google. É possível reverter toda a migração ou reverter seletivamente cargas de trabalho específicas.
- É possível migrar cargas de trabalho com estado nas regiões do Google Cloud. A migração manual de cargas de trabalho com estado só pode acontecer na mesma região.
Quando você usa esse método, o GKE aplica configurações padrão do Autopilot a cargas de trabalho que receberam um resultado Passed with optional configuration da ferramenta de simulação. Antes de migrar essas cargas de trabalho, verifique se você está confortável com esses padrões.
Migrar manualmente cargas de trabalho sem estado sem inatividade
Para migrar cargas de trabalho sem estado sem inatividade para seus serviços, registre os clusters de origem e destino em uma frota do GKE e use os serviços de vários clusters e a Entrada de vários clusters para manter as cargas de trabalho disponíveis durante a migração.
- Ative os serviços de vários clusters e a Entrada de vários clusters no cluster de origem e de destino. Para instruções, consulte Como configurar serviços de vários clusters e Como configurar a Entrada de vários clusters.
- Se você tiver dependências de back-end, como uma carga de trabalho de banco de dados, exporte esses serviços do cluster padrão usando serviços de vários clusters. Isso permite que as cargas de trabalho no cluster do Autopilot acessem as dependências no cluster padrão. Para mais instruções, consulte Como registrar um serviço para exportação.
- Implante uma Entrada de vários clusters e um Serviço de vários clusters para controlar o tráfego de entrada entre os clusters. Configure o serviço de vários clusters para enviar apenas tráfego para o cluster padrão. Para mais instruções, consulte Como implantar o Ingress em clusters.
- Implante suas cargas de trabalho sem estado com manifestos atualizados no cluster do Autopilot. Os serviços de vários clusters exportados automaticamente correspondem e enviam tráfego para as cargas de trabalho com estado correspondentes.
- Atualize o serviço de vários clusters para direcionar o tráfego de entrada para o cluster do Autopilot. Para mais instruções, consulte Seleção de cluster.
Agora você está disponibilizando suas cargas de trabalho sem estado no cluster do Autopilot. Se você tiver apenas cargas de trabalho sem estado no cluster de origem e nenhuma dependência permanecer, prossiga para Concluir a migração. Se você tiver cargas de trabalho com estado, prossiga para Migrar manualmente cargas de trabalho com estado.
Migrar manualmente cargas de trabalho com estado
Depois de migrar as cargas de trabalho sem estado, será necessário desativar e migrar as cargas de trabalho com estado do cluster padrão. Esta etapa requer inatividade para o cluster.
- Inicie o tempo de inatividade do seu ambiente.
- Reduza as cargas de trabalho com estado.
- Verifique se você modificou os manifestos de carga de trabalho para compatibilidade com o Autopilot. Para detalhes, consulte Modificar as especificações da carga de trabalho com base nos resultados de simulação.
Implante as cargas de trabalho no cluster do Autopilot.
Implante os serviços das cargas de trabalho com estado no cluster do Autopilot.
Atualize a rede no cluster para permitir que as cargas de trabalho sem estado continuem se comunicando com as cargas de trabalho de back-end:
- Se você usou um endereço IP estático nos serviços de back-end do cluster padrão, reutilize esse endereço IP no Autopilot.
- Se você permitir que o Kubernetes atribua um endereço IP, implante os serviços de back-end, consiga o novo endereço IP e atualize o DNS para usar o novo endereço IP.
Nesta etapa, as seguintes condições são verdadeiras:
- Você está executando todas as cargas de trabalho sem estado no Autopilot.
- Todas as cargas de trabalho com estado de back-end também estão em execução no Autopilot.
- As cargas de trabalho sem estado e com estado podem se comunicar entre si.
- O serviço de vários clusters direciona todo o tráfego de entrada para o cluster do Autopilot.
Depois de migrar todas as cargas de trabalho e objetos do Kubernetes para o novo cluster, siga para Concluir a migração.
Alternativa: migrar manualmente todas as cargas de trabalho durante o tempo de inatividade
Se você não quiser usar os serviços e a Entrada de vários clusters para migrar cargas de trabalho com tempo de inatividade mínimo, migre todas as cargas de trabalho durante o tempo de inatividade. Esse método resulta em um tempo de inatividade mais longo para seus serviços, mas não exige o trabalho com recursos de vários clusters.
- Comece o intervalo.
- Implante seus manifestos sem estado no cluster do Autopilot.
- Migre manualmente suas cargas de trabalho com estado. Para mais instruções, consulte a seção Migrar cargas de trabalho com estado manualmente.
- Modifique os registros DNS de tráfego interno e de cluster dentro do cluster para usar os novos endereços IP dos serviços.
- Encerre seu tempo de inatividade.
Conclua a migração
Depois de mover todas as cargas de trabalho e os serviços para o novo cluster do Autopilot, encerre o tempo de inatividade e deixe o ambienteem imersão por um período predeterminado. Quando estiver satisfeito com o estado da migração e tiver certeza de que não precisará reverter a migração, será possível limpar os artefatos e concluir a migração.
Opcional: limpar recursos de vários clusters
Se você usou a Entrada de vários clusters e os Serviços de vários clusters para migrar e não quer que o cluster do Autopilot permaneça registrado em uma frota, faça o seguinte:
- Para o tráfego externo de entrada, implante um Ingress e defina-o como o endereço IP dos serviços que expõem suas cargas de trabalho. Para mais instruções, consulte Entrada para balanceadores de carga de aplicativo externos.
- Para o tráfego dentro do cluster, como cargas de trabalho de front-end para dependências com estado, atualize os registros DNS do cluster para usar os endereços IP desses serviços.
- Exclua a Entrada de vários clusters e os recursos de Serviço de vários clusters que você criou durante a migração.
- Desative a Entrada de vários clusters e os Serviços de vários clusters.
- Cancelar o registro do cluster do Autopilot na frota.
Excluir o cluster padrão
Depois de tempo suficiente após a conclusão da migração e quando você estiver satisfeito com o estado do novo cluster, exclua o cluster padrão. Recomendamos que você mantenha os manifestos padrão salvos em backup.
Reverter uma migração com falha
Se você tiver problemas e quiser reverter para o cluster padrão, siga um dos procedimentos a seguir, dependendo de como realizou a migração:
Se você usou o Backup para GKE para criar backups durante a migração, restaure os backups no cluster padrão original. Para instruções, consulte Restaurar um backup.
Se você migrou manualmente as cargas de trabalho, repita as etapas de migração nas seções anteriores, com o cluster padrão como destino e o cluster do Autopilot como origem. Em geral, isso envolve as seguintes etapas:
- Iniciar inatividade.
- Migre manualmente as cargas de trabalho com estado para o cluster padrão. Para instruções, consulte a seção Migrar cargas de trabalho com estado manualmente.
- Mova as cargas de trabalho sem estado para o cluster padrão usando os manifestos originais que você armazenou em backup antes da migração.
- Implante a entrada no cluster padrão e faça a transição do DNS para os novos endereços IP dos serviços.
- Exclua o cluster do Autopilot.
A seguir
- Planejar solicitações de recursos do Autopilot
- Configurar o monitoramento
- Configurar e usar o painel de postura de segurança