Nesta página, você confere como as frotas ajudam a gerenciar implantações multicluster, incluindo alguns conceitos e terminologia de frotas. As frotas são um conceito do Google Cloud para organizar logicamente clusters e outros recursos. Elas permitem que você use e gerencie recursos de vários clusters e aplique políticas consistentes nos seus sistemas. As frotas são uma parte essencial de como a funcionalidade corporativa de vários clusters funciona no Google Cloud.
Este guia foi desenvolvido para leitores técnicos, incluindo arquitetos do sistema, operadores de plataforma e operadores de serviço, que querem aproveitar vários clusters e uma infraestrutura relacionada. Esses conceitos são úteis onde sua organização executa vários clusters, seja no Google Cloud, em vários provedores de nuvem ou no local.
Você precisa estar familiarizado com os conceitos básicos do Kubernetes, como clusters e namespaces. Caso contrário, consulte Noções básicas do Kubernetes, a documentação do GKE e Como preparar um aplicativo para o serviço do Cloud Service Mesh
Se você quiser saber mais sobre a plataforma GKE Enterprise e os componentes que usam frotas, consulte a visão geral técnica do GKE Enterprise e Conheça o GKE Enterprise. No entanto, você não precisa conhecer o GKE Enterprise para seguir este guia.
Terminologia
Veja a seguir alguns termos importantes que usamos ao falar sobre frotas.
Recursos com reconhecimento de frota
Os recursos com reconhecimento de frota são recursos do projeto do Google Cloud que podem ser agrupados e gerenciados logicamente como frotas. Atualmente, apenas os clusters do Kubernetes podem ser membros da frota.
Projeto host da frota
A implementação de frotas, como muitos outros recursos do Google Cloud, está enraizada em um projeto do Google Cloud, que chamamos de projeto host da frota. Um determinado projeto do Google Cloud só pode ter uma única frota (ou nenhuma) associada a ele. Essa restrição reforça o uso de projetos do Google Cloud para fornecer maior isolamento entre recursos que não são governados ou consumidos em conjunto.
Como agrupar a infraestrutura
O primeiro conceito importante de frotas é o conceito de agrupamento, ou seja, escolher quais partes dos recursos com reconhecimento de frota relacionados devem fazer parte de uma frota. A decisão sobre o que agrupar deve exigir respostas para as seguintes perguntas:
- 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.
Para ilustrar esse ponto, considere uma organização que tenha várias linhas de negócios (LOBs). Nesse caso, os serviços raramente se comunicam entre os limites LOB, os serviços em diferentes LOBs são gerenciados de maneira diferente (por exemplo, os ciclos de upgrade diferem entre os LOBs) e podem até mesmo ter um conjunto diferente de administradores para cada um. LOB Nesse caso, talvez faça sentido ter frotas por LOB. Cada LOB também adota várias frotas para separar os serviços de produção e não produção.
Como outros conceitos de frota são explorados nas seções a seguir, talvez você descubra outros motivos para criar várias frotas ao considerar suas necessidades organizacionais específicas.
Semelhança
Um conceito importante em frotas é o de semelhança. Isso significa que alguns objetos do Kubernetes, como namespaces com o mesmo nome em clusters diferentes, são tratados como a mesma coisa. Essa normalização é feita para tornar a administração de recursos de ambiente mais gerenciável. Ela traz algumas orientações úteis sobre como configurar namespaces, serviços e identidades. Porém, ela também segue o que descobrimos que a maioria das organizações já implementa.
Semelhança de namespace
O exemplo fundamental de semelhança em uma frota é a semelhança de namespace. Os namespaces com o mesmo nome em clusters diferentes são considerados os mesmos de muitos componentes. Outra maneira de pensar sobre essa propriedade é que um namespace é logicamente definido em um ambiente inteiro, mesmo que a instanciação do namespace exista apenas em um subconjunto dos recursos da frota.
Considere o seguinte exemplo de namespace backend. Embora o namespace seja
instanciado apenas nos clusters A e B, ele é reservado de maneira implícita no cluster C.
Isso permite que um serviço no namespace backend também seja programado no cluster C, se necessário.
Isso significa que os namespaces são alocados para toda a frota e não por
cluster. Assim, a semelhança de namespace requer propriedade consistente de namespace
em toda a frota.
Semelhança de serviços
O Cloud Service Mesh e o Ingress de vários clusters usam o conceito de igualdade de serviços dentro de um namespace. Assim como a semelhança de namespace, isso significa que serviços com o mesmo namespace e nome de serviço são considerados o mesmo serviço.
Os endpoints do serviço podem ser mesclados na malha, no caso do Cloud Service Mesh. Com o Ingress de vários clusters, um recurso MultiClusterService (MCS) torna o endpoint integrado mais explícito. No entanto, recomendamos práticas semelhantes com relação à nomenclatura. Por isso, é importante garantir que serviços com nomes idênticos dentro do mesmo namespace sejam, na verdade, os mesmos.
No exemplo a seguir, o tráfego da Internet tem a carga balanceada em um serviço
com nome igual no namespace frontend presente nos clusters B e C. Da mesma forma,
usando as propriedades da malha de serviço na frota, o serviço no namespace frontend pode
alcançar um serviço com o mesmo nome no namespace auth presente nos clusters A e C.
Semelhança de identidade ao acessar recursos externos
Os serviços dentro de uma frota podem usar uma identidade comum quando saem para acessar recursos externos, como serviços do Google Cloud, armazenamentos de objetos e assim por diante. Essa identidade comum possibilita que os serviços dentro de uma frota acessem um recurso externo uma vez em vez de cluster a cluster.
Para entender melhor esse ponto, considere o exemplo a seguir. Os clusters A, B
e C estão inscritos em uma identidade comum na frota. Quando os serviços no namespace
backend acessam recursos do Google Cloud, as identidades deles são
mapeadas para uma conta de serviço comum do Google Cloud chamada back. A
conta de serviço do Google Cloud back pode ser autorizada em qualquer número
de serviços gerenciados, do Cloud Storage ao Cloud SQL. À medida que novos recursos de frota,
como clusters, são adicionados ao namespace backend, eles herdam
automaticamente as propriedades de semelhança de identidade da carga de trabalho.
Devido à semelhança de identidade, é importante que todos os recursos em uma frota
sejam confiáveis e bem-governados. Se você revisitar o exemplo anterior, se o Cluster C
pertence a uma equipe separada e não confiável, ele também pode criar um namespace backend
e acessar serviços gerenciados como se fossembackend no Cluster A
ou B.
Semelhança de identidade dentro de uma frota
Dentro de uma frota, a mesma identidade é usada de forma semelhante à semelhança de identidade externa que discutimos anteriormente. Assim como os serviços de frota são autorizados uma vez para um serviço externo, eles também podem ser autorizados internamente.
No exemplo a seguir, estamos usando o Cloud Service Mesh
para criar uma malha de serviço de vários clusters em que frontend tem acesso a backend.
Com o Cloud Service Mesh e
as frotas, não é necessário especificar que o frontend nos clusters B e C pode
acessar o backend nos clusters A e B. Especificamos apenas que o frontend
na frota pode acessar o backend na frota. Além de deixar a autorização mais simples,
ela também torna os limites de recursos mais flexíveis. agora
as cargas de trabalho podem ser facilmente movidas do cluster para o cluster sem afetar o modo como
são autorizadas. Assim como na semelhança de identidade de carga de trabalho,
a governança sobre os recursos
do ambiente é fundamental para garantir a integridade da comunicação
de serviço a serviço.
Exclusividade
Os recursos com reconhecimento de frota só podem ser membros de uma única frota em qualquer momento, uma restrição aplicada pelas ferramentas e pelos componentes do Google Cloud. Essa restrição garante que haja apenas uma fonte de verdade que regula um cluster. Sem exclusividade, mesmo os componentes mais simples se tornariam complexos de usar, exigindo que sua organização pensasse e configurasse como seria feita a interação de vários componentes em diversas frotas.
Alta confiança
A semelhança de serviço, carga de trabalho e identidade de malha são criadas com base em um princípio de alta confiança entre os membros de uma frota. Essa confiança possibilita um nível superior de gerenciamento desses recursos para a frota, em vez de gerenciar recurso por recurso (ou seja, cluster por cluster para recursos do Kubernetes) e, por fim, torna o limite de cluster menos importante.
Em outras palavras, os clusters dentro de uma frota oferecem proteção contra preocupações com raios de impacto, disponibilidade (do plano de controle e da infraestrutura subjacente), vizinhos barulhentos e assim por diante. No entanto, eles não são um forte limite de isolamento para políticas e governança porque os administradores de qualquer membro em uma rota podem afetar as operações dos serviços em outros membros.
Por esse motivo, recomendamos que os clusters em que o administrador da frota não confia sejam colocados nas próprias frotas para mantê-los isolados. Em seguida, conforme necessário, serviços individuais poderão ser autorizados no limite da frota.
Escopos da equipe
Um escopo de equipe é um mecanismo para subdividir ainda mais sua frota em grupos de clusters, permitindo definir os recursos com reconhecimento de frota atribuídos a uma equipe de aplicativo específica. Dependendo do caso de uso, um cluster individual de membros da frota pode ser associado a nenhuma, ou a várias equipes, permitindo que várias equipes compartilhem clusters. Também é possível usar escopos de equipe para sequenciar lançamentos de upgrade de cluster na sua frota, embora isso exija que cada cluster seja associado apenas a uma única equipe.
Um escopo de equipe pode ter namespaces da frota definidos explicitamente associados a ele. O namespace é o mesmo em todo o escopo. Isso proporciona um controle mais granular sobre os namespaces do que a semelhança de namespace padrão fornecida apenas pelas frotas.
Componentes ativados por frota
Os seguintes componentes do GKE e do GKE Enterprise aproveitam os conceitos de frota, como semelhança de namespace e identidade, para oferecer uma maneira simplificada de trabalhar com clusters e serviços. Para conhecer os requisitos ou limitações atuais para o uso de frotas com cada componente, consulte os requisitos de componente.
Pools de Identidades da carga de trabalho
Uma frota oferece um conjunto de identidades de carga de trabalho comum que pode ser usado para autenticar e autorizar cargas de trabalho de maneira uniforme em uma malha de serviço. a serviços externos.Cloud Service Mesh
O Cloud Service Mesh é um pacote de ferramentas que ajuda você a monitorar e gerenciar uma malha de serviço confiável no Google Cloud, em e outros ambientes compatíveis. É possível formar uma malha de serviço em clusters que fazem parte da mesma frota.Config Sync
O Config Sync permite implantar e monitorar pacotes de configuração declarativos para seu sistema, armazenados em uma fonte central de informações, como um repositório Git, aproveitando os conceitos principais do Kubernetes, como namespaces, rótulos e anotações. Com o Config Sync, a configuração é definida em toda a frota, mas aplicada localmente em cada um dos recursos membros.Policy Controller
O Policy Controller aplica políticas declarativas nos seus clusters do Kubernetes. Essas políticas funcionam como proteções e podem ajudar nas práticas recomendadas, na segurança e no gerenciamento de conformidade dos clusters e frotas.Ingress de vários clusters
O Ingress de vários clusters usa a frota para definir o conjunto de clusters e endpoints de serviço em que o tráfego pode ser submetido ao balanceamento de carga, propiciando baixa latência e serviços de alta disponibilidade.Knative serving
O Knative serving é uma plataforma de desenvolvedor Knative gerenciada pelo Google e com suporte que abstrai a complexidade da infraestrutura subjacente, facilitando a criação, implantação e gerenciamento de apps e serviços nos clusters da sua frota.
A seguir
- Leia mais sobre quando usar vários clusters para atender às necessidades técnicas e de negócios em Casos de uso com vários clusters.
- Quer pensar na aplicação desses conceitos nos seus próprios sistemas? Consulte nossos requisitos e práticas recomendadas para frotas.