Programa de aprendizado: dimensionar aplicativos - considerações sobre produção
Neste conjunto de tutoriais, algumas das considerações de planejamento são simplificadas para que você possa se concentrar no aprendizado dos principais recursos e serviços da edição Enterprise do Google Kubernetes Engine (GKE). Antes de começar a criar seu próprio ambiente da edição Google Kubernetes Engine (GKE) Enterprise semelhante ao descrito neste conjunto de tutoriais, há algumas considerações de planejamento adicionais a serem consideradas. Essas considerações incluem o nível de gerenciamento de cluster, a rede e os tipos de disponibilidade.
Rede
Os clusters do GKE exigem um planejamento cuidadoso do endereço IP. As opções de rede escolhidas afetam a arquitetura dos clusters do GKE. Algumas dessas opções não podem ser alteradas depois de configuradas, sem recriar o cluster.
Neste conjunto de tutoriais, você vai usar clusters do modo Autopilot que sempre usam rede do modo nativo da VPC. Eles usam intervalos de endereços IP do alias nos nós do GKE e são necessários para criar clusters em VPCs compartilhadas. Os clusters nativos de VPC são escalonados com mais facilidade que os clusters baseados em roteamento, sem consumir rotas do Google Cloud. Por isso, são menos suscetíveis a atingir limites de roteamento.
Antes de criar seu próprio ambiente do GKE Enterprise e implantar cargas de trabalho, revise as seguintes orientações de rede:
Modos de cluster
Neste conjunto de tutoriais, você cria um cluster regional do GKE Enterprise que usa o modo Autopilot. Os clusters do Autopilot são pré-configurados com uma configuração de cluster otimizada pronta para cargas de trabalho de produção. Outra opção é usar clusters do modo Standard para ter flexibilidade de configuração mais avançada em relação à infraestrutura subjacente.
Para uma visão geral mais abrangente, revise os documentos de planejamento que começam com as opções de configuração de cluster.
Namespaces
Os namespaces permitem organizar os aplicativos e isolar os componentes uns dos outros. Cada namespace tem o próprio conjunto de recursos, como pods, serviços e implantações. Por exemplo, é possível criar um namespace para todos os serviços de front-end e um namespace para os serviços de back-end. Esse agrupamento facilita o gerenciamento e o controle do acesso aos serviços.
Neste conjunto de tutoriais, você vai implantar os pods e os serviços do aplicativo de exemplo do Cymbal Bank em um único namespace. Essa abordagem reduz a complexidade da implantação, mas não permite que você use namespaces para atribuir recursos a diferentes equipes e usuários, como seria feito em um ambiente de produção. Ele também não permite que você aproveite os recursos de gerenciamento de equipe do GKE Enterprise, que ajudam a estruturar frotas, namespaces e permissões para que as equipes atuem de maneira independente como "locatários" separados na frota com os próprios recursos. Para conferir um exemplo mais seguro e pronto para produção do aplicativo de amostra Cymbal Bank que usa vários namespaces, consulte Arquitetura de aplicativos do Cymbal Bank.
orçamentos de interrupção do pod
As políticas de orçamento de interrupção de pod (PDB, na sigla em inglês) ajudam a garantir o desempenho do app impedindo que os pods sejam desativados ao mesmo tempo quando você faz uma alteração no sistema e limitam o número de pods indisponíveis simultaneamente em um aplicativo replicado.
Neste conjunto de tutoriais, você não vai configurar e usar PDBs. Quando você concluir o tutorial para simular falhas, todos os serviços e nós precisarão responder conforme o esperado. Quando você implanta suas próprias cargas de trabalho, os PDBs em nós podem bloquear a drenagem de nós.
Se você usa PDBs, revise sua configuração antes de tentar restringir e drenar os nós. Se não for possível drenar os nós, você poderá ter problemas com eventos de manutenção programada.
A seguir
Comece concluindo o primeiro tutorial para implantar um único cluster do GKE que executa um aplicativo baseado em microsserviços.