Planejar recursos da frota

Como você aprendeu na Visão geral do gerenciamento de frotas, as frotas são um mecanismo de agrupamento para gerenciar, configurar e proteger clusters do Kubernetes em grande escala. As frotas são uma ferramenta poderosa que elimina a necessidade de realizar operações repetidas em um ambiente de vários clusters e oferece consistência e observabilidade abrangente em grandes grupos de clusters. Vários recursos do GKE Enterprise estão disponíveis apenas por frota.

A estratégia de agrupamento usada para criar frotas pode variar de acordo com as necessidades técnicas e comerciais da sua organização. Por exemplo, uma organização pode agrupar clusters com base no tipo de aplicativo em execução, enquanto outra pode agrupar por região, ambiente ou outros fatores relevantes. Se todo o restante for igual, é conveniente ter o menor número necessário de frotas dentro da organização.

Este guia é destinado a arquitetos de nuvem que querem começar a usar as frotas nas organizações. Ele oferece algumas orientações práticas sobre como organizar clusters em frotas, incluindo:

  • Quando você quer criar clusters completamente novos.
  • Quando você quer criar frotas com clusters existentes.

Os padrões descritos aqui funcionam para muitas organizações, mas não são a única maneira de planejar frotas. As frotas são flexíveis, e você pode usar um padrão de agrupamento diferente para seus clusters.

Você precisa conhecer os conceitos abordados na Visão geral do gerenciamento de frotas antes de ler este guia. Neste guia, pressupomos que você já conheça os conceitos básicos do Kubernetes e a hierarquia de recursos do Google Cloud.

Limitações de frota e recursos

As seguintes limitações gerais se aplicam ao criar frotas:

  • Um determinado projeto do Google Cloud só pode ter uma única frota (ou nenhuma) associada a ele, embora essa frota possa incluir clusters de vários projetos. O projeto associado a uma frota é conhecido como projeto host da frota.
  • Os clusters só podem ser membros de uma única frota.
  • O limite padrão para o número de clusters em uma frota é de 250, mas você pode solicitar um limite maior, se necessário.

Pode ser conveniente colocar vários clusters no mesmo projeto por vários motivos. No entanto, considere os seguintes limites ao planejar quais clusters incluir em um projeto:

Princípios gerais

Confira a seguir perguntas gerais que você deve fazer ao decidir se vai agrupar clusters em uma frota. Vamos analisar como isso se aplica com mais detalhes nas próximas seções.

  • Os recursos estão relacionados?
    • Recursos com grandes quantidades de comunicação entre serviços beneficiam-se mais de serem gerenciados juntos em uma frota.
    • Recursos no mesmo ambiente de implantação (por exemplo, ambiente de produção) precisam ser gerenciados juntos em uma frota.
  • Quem administra os recursos?
    • Ter um controle unificado (ou pelo menos mutuamente confiável) sobre os recursos é essencial para garantir a integridade da frota.

Planejar frotas para novos clusters

Nesta seção, descrevemos como planejar frotas quando você tem um conjunto conhecido de aplicativos, mas é flexível quanto ao local onde esses aplicativos são implantados. Isso pode ter acontecido porque você ainda não desenvolveu esses aplicativos ou está migrando-os de outra plataforma de contêiner. Como alternativa, talvez você já tenha aplicativos em execução em clusters existentes, mas esteja aberto a migrar aplicativos para novos clusters para alcançar uma arquitetura preferida.

Depois de identificar as frotas, é possível criar um novo projeto por frota, criar uma frota em cada projeto e criar e registrar clusters na frota pretendida.

Auditar suas cargas de trabalho

Comece com uma lista de todas as cargas de trabalho do Kubernetes (por exemplo, implantações) que você quer implantar. Não é necessário que seja uma lista literal. Ela pode ser uma ideia das cargas de trabalho que você vai precisar. Em seguida, siga as etapas no restante desta seção para dividir progressivamente esse conjunto de aplicativos em subconjuntos até ter o conjunto mínimo de agrupamentos necessário. Isso vai definir quais frotas e clusters você precisa.

Considere as unidades de negócios

Sua organização pode ter uma estrutura de TI federada, em que há uma equipe central de TI para a organização e equipes de TI separadas para cada unidade de negócios. Nesse caso, cada equipe de TI federada pode querer gerenciar as próprias frotas. Use frotas separadas se as cargas de trabalho de duas unidades de negócios (por exemplo, auditoria e negociação em um banco) não puderem se comunicar por motivos regulamentares.

Separar cargas de trabalho por ambiente

Um padrão comum que funciona para muitas organizações é agrupar clusters por ambiente. Uma configuração típica é ter três ambientes principais: desenvolvimento, não produção (ou preparo) e produção. As alterações no aplicativo costumam ser implantadas progressivamente (ou promovidas) em cada ambiente na lista. Por isso, você tem implantações separadas em cada ambiente para o mesmo aplicativo, como o mesmo nome de imagem de contêiner base. Consulte o blueprint de bases empresariais para um exemplo de como criar ambientes na sua organização.

Uma frota só pode conter clusters de um ambiente. Três ambientes, com uma frota em cada um, podem ser suficientes para muitas organizações. No Blueprint de aplicativos empresariais, confira um exemplo em que cada ambiente tem uma frota e como os aplicativos podem ser implantados progressivamente.

Combinar instâncias de carga de trabalho redundantes

Quando um aplicativo precisa de alta disponibilidade, um padrão é executá-lo em duas ou mais regiões. Isso envolve dois ou mais clusters que executam implantações configuradas de maneira muito semelhante que são gerenciadas como uma unidade. Muitas vezes, eles têm um balanceador de carga que abrange instâncias de aplicativos em todos os clusters ou usam o balanceamento de carga DNS.

Nesses cenários, coloque todos os clusters na mesma frota. Clusters em regiões diferentes geralmente não precisam estar em frotas separadas, a menos que seja necessário por motivos regulatórios ou outros.

Planejar frotas com clusters

Esta seção descreve como planejar frotas quando você tem cargas de trabalho em execução em clusters existentes e não planeja realocá-las. Esses clusters podem estar no Google Cloud ou fora dele. Neste cenário, o objetivo é criar um conjunto de frotas na sua organização e atribuir clusters a elas.

Depois de identificar as frotas, crie um novo projeto por frota, crie uma frota em cada projeto e registre clusters na frota pretendida.

Auditar seus clusters

Comece com uma lista de todos os clusters do Kubernetes na sua organização. O Inventário de recursos do Cloud é uma maneira de pesquisar recursos de cluster do Kubernetes na sua organização.

Em seguida, siga as etapas no restante desta seção para dividir progressivamente esse conjunto de aplicativos em subconjuntos até ter o conjunto mínimo de agrupamentos necessários. Isso vai definir quais frotas você precisa.

Considere as unidades de negócios

Sua organização pode ter uma estrutura de TI federada, em que há uma equipe central de TI para a organização e equipes de TI separadas para cada unidade de negócios. Esses times de TI por unidade de negócios podem ter criado os clusters atuais. Nesse caso, normalmente você particiona o conjunto de clusters por unidade de negócios. Um exemplo é quando as cargas de trabalho de determinadas unidades de negócios (por exemplo, auditoria e negociação em um banco) não podem se comunicar por motivos regulamentares.

Se as unidades de negócios existem apenas para fins de contabilidade de custos, mas usam uma equipe de TI comum, considere combinar os clusters em uma única frota, especialmente se houver dependências interserviços significativas entre as unidades de negócios.

Agrupar clusters por ambiente

Identifique quais ambientes são usados na sua organização. Os nomes de ambiente típicos são "dev", "não produção" (ou "preparação") e "prod".

Se cada cluster estiver claramente em apenas um dos ambientes, separe a lista de clusters por ambiente. No entanto, se alguns clusters tiverem cargas de trabalho que pertencem logicamente a ambientes diferentes, recomendamos reimplantar os aplicativos em clusters que contenham apenas aplicativos que pertençam a um único ambiente lógico.

Minimizar o número de proprietários de cluster

Ao combinar projetos atuais em uma frota, pode haver diferentes conjuntos de usuários autorizados a atuar como administradores nesses clusters, considerando as políticas do IAM (container.admin) e o RBAC (admin ClusterRoleBinding). Se você planeja usar recursos que exigem a mesma configuração, o objetivo deve ser fazer com que todos os clusters tenham o mesmo conjunto de administradores e que haja um pequeno conjunto de administradores para a frota. Se os clusters precisam ter administradores diferentes e o objetivo é usar os recursos que exigem a mesma configuração, provavelmente eles não pertencem à mesma frota.

Por exemplo, se os clusters C1 e C2 tiverem administradores diferentes que não confiam uns nos outros e não quiserem compartilhar as permissões de administrador com uma equipe central da plataforma que gerencia as frotas, eles não poderão ser agrupados em uma frota.

Saiba mais sobre a semelhança e quais recursos exigem isso em Como as frotas funcionam.

Considerar os recursos da frota

Independentemente de você estar trabalhando com clusters novos ou existentes, os recursos de frota que você escolher também podem afetar a organização ideal da frota. Por exemplo, se você usar a federação de identidade da carga de trabalho em toda a frota, talvez queira organizar suas frotas de maneira que minimize o risco ao configurar a autenticação da carga de trabalho em toda a frota. Se você quiser usar o Cloud Service Mesh, talvez precise que determinados clusters estejam na mesma frota. Se você usa a nuvem privada virtual (VPC), alguns recursos exigem o uso de uma única VPC por frota.

Você pode saber mais sobre como adotar recursos da frota e os requisitos e limitações no próximo guia desta série, Planejar recursos da frota.

Considerar os perímetros da VPC

Outro problema a considerar para clusters novos e existentes é se você escolheu ou quer criar suas próprias redes privadas no Google Cloud com a nuvem privada virtual (VPC). Os clusters em um perímetro da VPC (por exemplo, em uma VPC compartilhada com o VPC Service Controls) podem estar em uma frota. Se você tem VPCs compartilhadas restritas e não restritas, uma prática recomendada é colocá-las em frotas separadas.

Se você pretende usar os perímetros do VPC Service Controls, alguns workloads geralmente estão dentro do perímetro e outros, fora dele. Você precisa ter versões do VPC Service Controls e que não são do VPC Service Controls de cada frota em cada ambiente (ou pelo menos a produção e o ambiente imediatamente antes da produção).

Ao planejar frotas com VPCs, saiba que alguns recursos têm requisitos de VPC específicos, como exigir que todos os clusters que as usam estejam na mesma rede VPC.

A seguir