Planeie os recursos da frota

Conforme aprendeu na vista geral da gestão de frotas, as frotas são um mecanismo de agrupamento para gerir, configurar e proteger clusters do Kubernetes em grande escala. Os fleets são uma ferramenta poderosa que elimina a necessidade de realizar operações repetidas num ambiente de vários clusters e oferece consistência e observabilidade abrangente em grandes grupos de clusters. Várias funcionalidades do GKE só estão disponíveis através de uma frota.

A estratégia de agrupamento que usa para criar frotas pode variar consoante as necessidades técnicas e empresariais da sua organização. Por exemplo, uma organização pode agrupar clusters com base no tipo de aplicações em execução nos mesmos, enquanto outra pode agrupá-los por região, ambiente ou outros fatores relevantes. Em tudo o resto, é conveniente ter o menor número possível de frotas na sua organização.

Este guia destina-se a arquitetos da nuvem que querem começar a usar frotas nas respetivas organizações. Oferece algumas orientações práticas sobre como organizar os seus clusters em frotas, incluindo:

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

Os padrões descritos aqui funcionam para muitas organizações, mas não são a única forma de planear frotas. Os frotas são flexíveis e pode decidir usar um padrão de agrupamento diferente para os seus clusters.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Limitações de recursos e frota

Aplicam-se as seguintes limitações gerais quando cria frotas:

  • Um determinado Google Cloud projeto só pode ter uma única frota (ou nenhuma) associada, embora essa frota possa incluir clusters de vários projetos. O projeto associado a uma frota é conhecido como o projeto anfitrião da frota.
  • Os clusters só podem ser membros de uma única frota em qualquer altura.
  • Todos os clusters num determinado projeto têm de estar na mesma frota ou não estar numa frota. Se um projeto já contiver membros da frota, não pode registar um cluster desse projeto numa frota diferente.
  • O limite predefinido para o número de clusters numa frota é 250, embora possa pedir um limite superior, se necessário.

Pode ser conveniente colocar vários clusters no mesmo projeto por vários motivos. No entanto, considere os seguintes limites ao planear que clusters agrupar num projeto:

Princípios gerais

Seguem-se perguntas gerais que deve fazer ao decidir se deve agrupar clusters numa frota. Vamos ver como estas se aplicam mais detalhadamente nas secções seguintes.

  • Os recursos estão relacionados entre si?
    • Os recursos que têm grandes quantidades de comunicação entre serviços beneficiam mais da gestão conjunta numa frota.
    • Os recursos no mesmo ambiente de implementação (por exemplo, o seu ambiente de produção) devem ser geridos em conjunto numa frota.
  • Quem administra os recursos?
    • Ter um controlo unificado (ou, pelo menos, mutuamente fidedigno) sobre os recursos é fundamental para garantir a integridade da frota.

Planeie frotas para novos clusters

Esta secção descreve como planear frotas quando tem um conjunto conhecido de aplicações, mas é flexível quanto ao local onde essas aplicações são implementadas. Isto pode dever-se ao facto de ainda não ter desenvolvido essas aplicações ou de as estar a migrar de uma plataforma de contentores diferente. Em alternativa, pode já ter aplicações em execução em clusters existentes, mas estar disponível para mover aplicações para novos clusters para alcançar uma arquitetura preferencial.

Depois de identificar as frotas, pode criar um novo projeto por frota, criar uma frota em cada projeto e criar e registar clusters na frota pretendida.

Audite as suas cargas de trabalho

Comece com uma lista de todas as cargas de trabalho do Kubernetes (por exemplo, implementações) que quer implementar. Não tem de ser uma lista literal. Pode ser apenas uma ideia das cargas de trabalho de que vai precisar. Em seguida, siga os passos no resto desta secção para dividir progressivamente esse conjunto de aplicações em subconjuntos até ter o conjunto mínimo de agrupamentos necessário. Isto define as frotas e os clusters de que precisa.

Considere as unidades de negócio

A sua organização pode ter uma estrutura de TI federada, em que existe uma equipa de TI central para a organização, bem como equipas de TI separadas para cada unidade de negócio. Neste caso, cada equipa de TI federada pode querer gerir as suas próprias frotas. Use frotas separadas se as cargas de trabalho de duas unidades empresariais (por exemplo, auditoria e negociação num banco) não puderem comunicar entre si por motivos regulamentares.

Separe as cargas de trabalho por ambiente

Um padrão comum que funciona para muitas organizações é agrupar os clusters por ambiente. Uma configuração típica consiste em ter três ambientes principais: desenvolvimento, não produção (ou teste) e produção. Normalmente, as alterações à aplicação são implementadas progressivamente (ou promovidas) em cada ambiente da lista. Por este motivo, tem implementações separadas em cada ambiente para a mesma aplicação subjacente, como o mesmo nome de imagem do contentor base. Consulte o projeto de base empresarial para ver um exemplo de como criar ambientes na sua organização.

Uma frota só deve conter clusters de um ambiente. Três ambientes, com uma frota em cada ambiente, podem ser suficientes para muitas organizações. Consulte o projeto de aplicação empresarial para ver um exemplo em que cada ambiente tem uma frota e como as aplicações podem ser implementadas progressivamente.

Combine instâncias de cargas de trabalho redundantes

Quando uma aplicação precisa de alta disponibilidade, um padrão é executá-la em duas ou mais regiões. Isto envolve dois ou mais clusters que executam implementações configuradas de forma muito semelhante e que são geridas como uma unidade. Muitas vezes, têm um balanceador de carga que abrange instâncias de aplicações em todos os clusters ou usam o balanceamento de carga de DNS.

Nestes cenários, coloque todos esses clusters na mesma frota. Geralmente, os clusters em regiões diferentes não precisam de estar em frotas separadas, a menos que seja necessário por motivos regulamentares ou outros.

Planeie frotas com clusters existentes

Esta secção descreve como planear frotas quando tem cargas de trabalho em execução em clusters existentes e não planeia relocá-las. Esses clusters podem estar no interior ou no exterior Google Cloud. Neste cenário, o objetivo é criar um conjunto de fleets na sua organização e atribuir-lhes clusters existentes.

Depois de identificar as frotas, pode criar um novo projeto por frota, criar uma frota em cada projeto e registar clusters na frota pretendida.

Audite os seus clusters

Comece com uma lista de todos os clusters do Kubernetes na sua organização. O Cloud Asset Inventory é uma forma de pesquisar recursos de clusters do Kubernetes na sua organização.

Em seguida, pode seguir os passos no resto desta secção para dividir progressivamente esse conjunto de aplicações em subconjuntos até ter o conjunto mínimo de agrupamentos necessário. Isto define as frotas de que precisa.

Considere as unidades de negócio

A sua organização pode ter uma estrutura de TI federada, em que existe uma equipa de TI central para a organização, bem como equipas de TI separadas para cada unidade de negócio. Estas equipas de TI por unidade de negócio podem ter criado os seus clusters existentes. Normalmente, neste caso, particiona o conjunto de clusters por unidade de negócio. Um exemplo é quando as cargas de trabalho de determinadas unidades de negócio (por exemplo, auditoria e negociação num banco) não podem comunicar entre si por motivos regulamentares.

Se as unidades empresariais existirem apenas para fins de contabilidade de custos, mas usarem uma equipa de TI comum, considere combinar os respetivos clusters numa única frota, especialmente se existirem dependências significativas entre serviços nas unidades empresariais.

Agrupe clusters por ambiente

Identifique os ambientes usados na sua organização. Os nomes de ambientes típicos são dev, non-production (ou staging) e prod.

Se cada cluster estiver claramente apenas num dos seus ambientes, separe a lista de clusters por ambiente. No entanto, se alguns clusters contiverem cargas de trabalho que pertencem logicamente a ambientes diferentes, recomendamos que volte a implementar as aplicações em clusters que contenham apenas aplicações pertencentes a um único ambiente lógico.

Minimize o número de proprietários de clusters

Quando combina projetos existentes numa frota, pode haver diferentes conjuntos de utilizadores autorizados a agir como administradores nesses clusters, tendo em conta as políticas IAM (container.admin) e o RBAC (admin ClusterRoleBinding). Se planeia usar funcionalidades que requerem igualdade, o objetivo deve ser que todos os clusters tenham o mesmo conjunto de administradores e que exista um pequeno conjunto de administradores para a frota. Se os clusters tiverem de ter administradores diferentes e o objetivo for usar essas funcionalidades que requerem igualdade, provavelmente 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 partilhar autorizações de administrador com uma equipa de plataforma central que gere frotas, não devem ser agrupados numa frota.

Pode saber mais sobre a semelhança e que funcionalidades a requerem no artigo Como funcionam as frotas.

Considere as funcionalidades de frota

Independentemente de estar a trabalhar com clusters novos ou existentes, as funcionalidades da frota que escolher também podem afetar a organização ideal da frota. Por exemplo, se optar por usar a Workload Identity Federation ao nível da frota, pode querer organizar as suas frotas de uma forma que minimize o risco ao configurar a autenticação de cargas de trabalho ao nível da frota ou, se quiser usar o Cloud Service Mesh, pode precisar que determinados clusters estejam na mesma frota. Se usar a nuvem virtual privada (VPC), algumas funcionalidades requerem a utilização de uma única VPC por frota.

Pode saber mais sobre a adoção de funcionalidades de frotas, bem como os respetivos requisitos e limitações, no próximo guia desta série, Planeie funcionalidades de frotas.

Considere os perímetros da VPC

Outro aspeto a considerar para clusters novos e existentes é se optou por criar ou quer criar as suas próprias redes privadas Google Cloud com a nuvem privada virtual (VPC). Os clusters num perímetro da VPC (por exemplo, numa VPC partilhada que tenha os VPC Service Controls) podem estar numa frota em conjunto. Se tiver VPCs partilhadas restritas e não restritas, uma boa prática é colocá-las em frotas separadas.

Se planeia usar perímetros dos VPC Service Controls, normalmente, algumas cargas de trabalho estão no perímetro e outras estão fora dele. Deve planear ter versões do VPC Service Controls e não do VPC Service Controls de cada frota em cada ambiente (ou, pelo menos, no ambiente de produção e no ambiente imediatamente anterior ao de produção).

Tenha em atenção que, ao planear frotas com VPCs, algumas funcionalidades de frotas têm requisitos de VPC específicos, como exigir que todos os clusters que as usam estejam na mesma rede VPC.

O que se segue?