Neste conjunto de tutoriais, algumas das considerações de planeamento são simplificadas para que se possa concentrar na aprendizagem das principais funcionalidades e serviços do Google Kubernetes Engine (GKE). Antes de começar a criar o seu próprio ambiente do Google Kubernetes Engine semelhante ao descrito neste conjunto de tutoriais, existem algumas considerações de planeamento adicionais a ter em conta. Estas considerações incluem o nível de gestão do cluster, a rede e os tipos de disponibilidade.
Trabalhar em rede
Os clusters do GKE requerem um planeamento cuidadoso dos endereços IP. As opções de rede que escolher afetam a arquitetura dos seus clusters do GKE. Não é possível alterar algumas destas opções depois de configuradas sem recriar o cluster.
Neste conjunto de tutoriais, usa clusters do modo Autopilot que usam sempre a rede no modo nativo da VPC. Os clusters nativos da VPC usam intervalos de endereços IP de alias em nós do GKE e são necessários para criar clusters em VPCs partilhadas. Os clusters nativos de VPC são dimensionados mais facilmente do que os clusters baseados em rotas sem consumirGoogle Cloud rotas e, por isso, são menos suscetíveis de atingir os limites de encaminhamento.
Antes de criar o seu próprio ambiente do GKE e implementar cargas de trabalho, reveja as seguintes orientações de rede:
Modos de cluster
Neste conjunto de tutoriais, cria um cluster do GKE regional que usa o modo Autopilot. Os clusters do Autopilot são pré-configurados com uma configuração de cluster otimizada que está pronta para cargas de trabalho de produção. Em alternativa, pode usar clusters do modo padrão para uma flexibilidade de configuração mais avançada na infraestrutura subjacente.
Para uma vista geral mais abrangente, reveja os documentos de planeamento que começam com as opções de configuração do cluster.
Espaços de nomes
Os espaços de nomes permitem-lhe organizar as suas aplicações e isolar os componentes uns dos outros. Cada espaço de nomes tem o seu próprio conjunto de recursos, como Pods, Services e Deployments. Por exemplo, pode criar um espaço de nomes para todos os seus serviços de front-end e um espaço de nomes para os seus serviços de back-end. Este agrupamento facilita a gestão dos seus serviços e o controlo do acesso aos mesmos.
Neste conjunto de tutoriais, implementa os pods e os serviços para a aplicação de exemplo do Cymbal Bank num único espaço de nomes. Esta abordagem reduz a complexidade da implementação, mas não lhe permite usar espaços de nomes para atribuir recursos a diferentes equipas e utilizadores, como faria num ambiente de produção. Para ver um exemplo mais seguro e pronto para produção da aplicação de exemplo do Cymbal Bank que usa vários espaços de nomes, consulte o artigo Arquitetura da aplicação Cymbal Bank.
Orçamentos de interrupção de pods
As políticas de orçamento de interrupção de pods (PDB) ajudam a garantir o desempenho da app, impedindo que os pods fiquem inativos ao mesmo tempo quando faz uma alteração ao sistema e limitam o número de pods indisponíveis em simultâneo numa aplicação replicada.
Neste conjunto de tutoriais, não configura nem usa PDBs. Quando concluir o tutorial para simular a falha, todos os seus serviços e nós devem responder conforme esperado. Quando implementa as suas próprias cargas de trabalho, os PDBs nos nós podem bloquear a drenagem dos nós.
Se usar PDBs, reveja a sua configuração antes de tentar isolar e esvaziar os nós. Se os nós não puderem ser esvaziados com êxito, pode ter problemas com eventos de manutenção agendados.
O que se segue?
Comece por concluir o primeiro tutorial para implementar um único cluster do GKE que execute uma aplicação baseada em microsserviços.