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, ao usar determinados recursos ativados para a frota, alguns objetos do Kubernetes, como namespaces com o mesmo nome em clusters diferentes, são tratados como se fossem iguais. Essa normalização é feita para facilitar a administração de recursos da frota. Se estiver usando recursos que aproveitam a uniformidade, essa suposição oferece 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.
Diferentes tipos de igualdade oferecem benefícios diferentes, conforme mostrado na tabela a seguir:
| Propriedade semelhante | Você pode... |
|---|---|
| Um namespace é considerado o mesmo em vários clusters. |
|
| Uma combinação de namespace e nome de serviço é considerada igual em vários clusters. Serviços com o mesmo nome no mesmo namespace usam o mesmo seletor de rótulos. |
|
| Uma combinação de namespace e conta de serviço (identidade) é considerada igual em vários clusters. |
|
Como isso sugere, diferentes recursos da frota dependem de diferentes tipos de semelhança Um número menor de recursos não usa a semelhantes. Saiba mais sobre isso em Quais recursos usam a semelhança?, incluindo quais recursos você pode usar sem considerar a semelhança em toda a frota e quais recursos podem exigir um planejamento mais cuidadoso.
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 iguais por muitos recursos da frota. 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
Com a federação de identidade da carga de trabalho da frota, os serviços 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.
Quais recursos usam a mesma coisa?
Vários recursos da frota não dependem da igualdade e podem ser ativados e usados sem precisar considerar se você quer assumir qualquer forma de igualdade na frota. Outros recursos (incluindo o Config Sync e o Controlador de Políticas) podem usar a mesma configuração como, por exemplo, para selecionar um namespace em vários clusters de membros da frota para configuração de uma única fonte de verdade, mas não é necessário para todos os casos de uso. Por fim, há recursos como o Ingress de vários clusters e a federação de identidade da carga de trabalho em toda a frota que sempre assumem alguma forma de igualdade entre os clusters e podem precisar ser adotados com cuidado, dependendo das necessidades e dos workloads atuais.
Alguns recursos da frota, como a federação de identidade da carga de trabalho, exigem que toda a frota esteja pronta para as suposições de semelhança usadas por eles. Outros recursos, como o gerenciamento de equipe, permitem ativar gradualmente a semelhança no nível do namespace ou do escopo da equipe.
A tabela a seguir mostra quais recursos exigem um ou mais conceitos de identidade descritos nesta seção.
| Recurso | Oferece suporte à adoção gradual da semelhança | Depende da semelhança de namespace | Depende da identidade do serviço | Depende da semelhança de identidade |
|---|---|---|---|---|
| Frotas | N/A | Não | Não | Não |
| Autorização binária | N/A | Não | Não | Não |
| Criptografia transparente entre nós | N/A | Não | Não | Não |
| Política de rede baseada em nome de domínio totalmente qualificado | N/A | Não | Não | Não |
| Conectar gateway | N/A | Não | Não | Não |
| Config Sync | N/A | Não | Não | Não |
| Controlador de Políticas | N/A | Não | Não | Não |
| Postura de segurança do GKE | N/A | Não | Não | Não |
| Advanced Vulnerability Insights | N/A | Não | Não | Não |
| Postura de Conformidade | N/A | Não | Não | Não |
| Sequenciamento de lançamento | N/A | Não | Não | Não |
| Gerenciamento de equipes | Sim | Sim | Sim | Não |
| Ingress de vários clusters | Sim | Sim | Sim | Sim |
| Serviços de vários clusters | Sim | Sim | Sim | Sim |
| Federação de identidade da carga de trabalho da frota | Não | Sim | Sim | Sim |
| Cloud Service Mesh | Não | Sim | Sim | Sim |
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 Planejar recursos da frota.