Nos exemplos desta página, você verá alguns cenários hipotéticos com frotas que ilustram alguns dos conceitos e práticas recomendadas dos nossos guias. Antes de ler este guia, você precisa conhecer os conceitos em Introdução às frotas e Requisitos e práticas recomendadas para frotas.
Exemplo 1: frotas com recursos de produção, preparo e desenvolvimento
Neste primeiro exemplo, há quatro clusters. Dois clusters são para produção
(em duas regiões para redundância), um para preparo e teste e o último
para desenvolvimento. Todos os clusters pertencem e são administrados
centralmente pela equipe da plataforma. Neste exemplo simples, há dois serviços:
frontend
e backend
. No entanto, cenários mais complexos podem ter um
número maior de serviços e clusters.
![Diagrama ilustrando um sistema com recursos de produção, preparação e desenvolvimento](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-one.png?authuser=4&hl=pt-br)
Abordagem 1: frotas separadas para produção, preparo e desenvolvimento
Uma abordagem possível para aproveitar frotas é criar frotas separadas para recursos de produção, preparo e desenvolvimento.
Para fazer isso, criamos três projetos de host de frota separada e colocamos
recursos neles ou, no caso do nosso cluster
de desenvolvimento local, registramos o cluster no projeto example-dev
. Não foi preciso
resolver muitos dos problemas de semelhança de namespace e de serviço devido à
granularidade no exemplo, mas garantimos que os namespaces dos clusters prod-east
e
prod-west
foram normalizados.
A vantagem dessa abordagem é que temos um isolamento muito forte entre cada uma das frotas. A principal desvantagem dessa abordagem é que precisamos administrar três frotas diferentes, o que dificulta a consistência entre produção, preparo e desenvolvimento. Para equipes de desenvolvimento, também é mais difícil desenvolver com serviços preparados.
![Diagrama ilustrando rotas separadas para recursos de produção, preparo e desenvolvimento](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-one-separate-environs.png?authuser=4&hl=pt-br)
Abordagem 2: uma frota para todos os recursos
Nessa abordagem, criamos uma única rota para todos os recursos.
Para fazer isso, podemos deixar os recursos no projeto example
e criar a
frota nesse projeto. Poderíamos ter separado nossos recursos
de produção e preparo colocando-os em outros projetos de host de frota e aproveitando a
VPC compartilhada, mas optamos por não fazer isso para simplificar
este exemplo.
Nessa abordagem, precisamos garantir que nossos namespaces e serviços estejam
normalizados em todo a frota. Por exemplo, renomeamos nosso frontend
genérico como frontend-prod
e frontend-staging
nos clusters de produção e preparo,
respectivamente. Por fim, embora possamos manter os nomes originais dos nossos
namespaces de desenvolvimento, fornecemos nomes mais claros (como frontend-dev-alice
) para
indicar que eles são namespaces de desenvolvimento.
Com essa abordagem, estamos trocando o isolamento por uma maior facilidade de gerenciamento. Contamos com a autorização da malha de serviço para evitar comunicações indesejadas entre serviços, mas podemos administrar facilmente o sistema geral com uma única frota. Isso nos permite aplicar políticas em todos os recursos, o que nos dá a certeza de que o desenvolvimento parece muito próximo à produção.
![Diagrama ilustrando uma única frota com recursos de produção, preparo e desenvolvimento](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-one-single-environ.png?authuser=4&hl=pt-br)
Abordagem 3: frotas separadas para produção e não produção
Nessa abordagem, usamos uma configuração intermediária que combina os recursos de preparo e desenvolvimento em uma frota de não produção e coloca a produção em uma frota separada.
Para isso, criamos dois projetos de host de frota, um para produção e outro para
não produção. Também colocaremos nossos recursos diretamente nesses projetos, com o
cluster dev
no local registrado na nossa frota de não produção. Precisamos
normalizar os namespaces e serviços entre nossos recursos de
preparo e desenvolvimento para oferecer mais clareza. Por exemplo, renomeamos frontend
como
frontend-staging
no cluster de preparo.
A vantagem é que a produção é bem isolada da não produção. Por
exemplo, podemos permitir que os serviços de desenvolvimento conversem com os serviços de preparo para
que o frontend
da desenvolvedora Alice possa se comunicar com um backend
de preparo enquanto
ela estiver desenvolvendo o serviço.
![Diagrama ilustrando frotas de produção e não produção](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-one-two-environs.png?authuser=4&hl=pt-br)
Resumo
Cada uma das abordagens descritas no exemplo 1 é válida. A escolha da sua organização depende do isolamento em relação à consistência (e facilidade de gerenciamento). Em outras palavras, é preciso definir o isolamento necessário entre diferentes tipos de recursos em relação à consistência necessária entre eles. É mais fácil conseguir uma consistência maior com menos frotas. A terceira abordagem é oferecida como um possível meio-termo, mantendo a produção completamente isolada e, ao mesmo tempo, oferecendo aos desenvolvedores a capacidade de trabalhar com serviços preparados.
Exemplo 2: frotas com diferentes proprietários de recursos
Para este exemplo, temos duas equipes: team-a e team-b. Essas equipes têm e
administram os próprios clusters, e ambas usaram namespaces frontend
e
backend
para os serviços que produzem. No entanto,
frontend
e backend
da equipe team-a não são iguais aos da equipe team-b. As duas equipes querem
criar uma malha de serviço para que os serviços possam interagir.
![Diagrama ilustrando um sistema com os recursos de duas equipes](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-two.png?authuser=4&hl=pt-br)
Sem intervenção, não há como tornar esses clusters parte da
mesma malha. Um bom ponto de partida é transferir a propriedade dos clusters para uma
equipe centralizada de plataforma para estabelecer a confiança entre eles. Como alternativa, se
as equipes team-a e team-b confiarem uma na outra, elas também podem se coordenar para estabelecer essa confiança.
A próxima etapa é normalizar o uso do namespace para que o frontend
e
backend
não fiquem mais sobrecarregados nos clusters dessas duas equipes. Depois disso,
elas podem estabelecer uma única frota para todos os recursos e criar
a malha de serviço deles.
![Diagrama ilustrando os recursos de duas equipes em uma única frota](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-two-single-environ.png?authuser=4&hl=pt-br)
Se esse nível de confiança não puder ser estabelecido, team-a e team-b precisam formar duas frotas separadas que usam dois projetos de host de frotas diferentes. A desvantagem dessa abordagem é que agora elas precisam usar a federação de malha, que é mais difícil de administrar do que uma única malha. A vantagem é que nenhuma equipe precisa normalizar os namespaces e serviços implantados, e somente a comunicação explícita e especificamente autorizada é possível.
![Diagrama ilustrando os recursos de duas equipes em frotas separadas](https://cloud.google.com/static/kubernetes-engine/fleet-management/images/example-two-separate-environs.png?authuser=4&hl=pt-br)