Esta página explica mais detalhadamente como as frotas ajudam a gerir implementações de vários clusters, incluindo alguns conceitos e terminologia de frotas importantes. As frotas são um Google Cloud conceito para organizar logicamente clusters e outros recursos, o que lhe permite usar e gerir capacidades de vários clusters e aplicar políticas consistentes nos seus sistemas. As frotas formam uma parte crucial do funcionamento da funcionalidade de vários clusters no Google Cloud.
Este guia destina-se a leitores técnicos, incluindo arquitetos de sistemas, operadores de plataformas e operadores de serviços, que querem tirar partido de vários clusters e infraestruturas relacionadas. Estes conceitos são úteis sempre que a sua organização estiver a executar vários clusters, quer noGoogle Cloud, em vários fornecedores de nuvem ou no local.
Antes de ler esta página, certifique-se de que conhece os conceitos básicos do Kubernetes, como clusters e namespaces. Caso contrário, consulte os básicos do Kubernetes, a documentação do GKE e a secção Preparar uma aplicação para a Cloud Service Mesh.
Terminologia
Seguem-se alguns termos importantes que usamos quando falamos de frotas.
Recursos com reconhecimento da frota
Os recursos com reconhecimento de frotas são Google Cloud recursos de projetos que podem ser agrupados e geridos logicamente como frotas. Atualmente, apenas os clusters do Kubernetes podem ser membros da frota.
Projeto anfitrião da frota
A implementação de frotas, como muitos outros Google Cloud recursos, baseia-se num Google Cloud projeto, que denominamos projeto anfitrião da frota. Um determinado projeto só pode ter uma única frota (ou nenhuma frota) associada. Google Cloud Esta restrição reforça a utilização de projetos Google Cloud para fornecer um isolamento mais forte entre recursos que não são regidos nem consumidos em conjunto.
Infraestrutura de agrupamento
O primeiro conceito importante das frotas é o conceito de agrupamento, ou seja, escolher que partes dos recursos relacionados com reconhecimento de frotas devem fazer parte de uma frota. A decisão sobre o que agrupar requer que responda às seguintes perguntas:
- Os recursos estão relacionados entre si?
- Os recursos com 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 controlo unificado (ou, pelo menos, de confiança mútua) sobre os recursos é fundamental para garantir a integridade da frota.
Para ilustrar este ponto, considere uma organização que tem várias linhas de negócio (LOBs). Neste caso, os serviços raramente comunicam entre limites de LOB, os serviços em diferentes LOBs são geridos de forma diferente (por exemplo, os ciclos de atualização diferem entre LOBs) e podem até ter um conjunto diferente de administradores para cada LOB. Neste caso, pode fazer sentido ter frotas por LOB. Cada LOB também adota provavelmente várias frotas para separar os respetivos serviços de produção e não produção.
À medida que outros conceitos de frotas são explorados nas secções seguintes, pode encontrar outros motivos para criar várias frotas à medida que considera as necessidades organizacionais específicas.
Semelhança
Um conceito importante nas frotas é o conceito de igualdade. Isto significa que, quando usa determinadas funcionalidades ativadas para a frota, alguns objetos do Kubernetes, como os espaços de nomes que têm o mesmo nome em diferentes clusters, são tratados como se fossem a mesma coisa. Esta normalização é feita para facilitar a administração dos recursos da frota. Se estiver a usar funcionalidades que tiram partido da semelhança, esta suposição de semelhança fornece algumas orientações importantes sobre como configurar espaços de nomes, serviços e identidades. No entanto, também segue o que a maioria das organizações já está a implementar.
Os diferentes tipos de semelhança oferecem diferentes vantagens, conforme mostrado na tabela seguinte:
| Propriedade de igualdade | Permite-lhe… |
|---|---|
| Um espaço de nomes é considerado o mesmo em vários clusters. |
|
| Uma combinação de espaço de nomes e nome do serviço é considerada a mesma em vários clusters. Os serviços com o mesmo nome no mesmo espaço de nomes usam o mesmo seletor de etiquetas. |
|
| Uma combinação de espaço de nomes e conta de serviço (identidade) é considerada a mesma em vários clusters. |
|
Como isto sugere, as diferentes funcionalidades da frota baseiam-se em diferentes tipos de semelhança. Um número menor de funcionalidades não usa a semelhança. Pode saber mais sobre isto em Que funcionalidades usam a semelhança?, incluindo que funcionalidades pode usar sem ter de considerar a semelhança ao nível da frota e que funcionalidades podem exigir um planeamento mais cuidadoso.
Identidade do espaço de nomes
O exemplo fundamental de igualdade numa frota é a igualdade do espaço de nomes. Os espaços de nomes com o mesmo nome em clusters diferentes são considerados iguais por muitas funcionalidades da frota. Outra forma de pensar nesta propriedade é que um espaço de nomes é definido logicamente numa frota inteira, mesmo que a instanciação do espaço de nomes exista apenas num subconjunto dos recursos da frota.
Considere o seguinte exemplo de espaço de nomes backend. Embora o espaço de nomes seja instanciado apenas nos clusters A e B, está implicitamente reservado no cluster C (permite que um serviço no espaço de nomes backend também seja agendado no cluster C, se necessário).
Isto significa que os espaços de nomes são atribuídos a toda a frota e não por cluster. Como tal, a igualdade do espaço de nomes requer a propriedade consistente do espaço de nomes em toda a frota.
Semelhança de serviços
O Cloud Service Mesh e o Multi Cluster Ingress usam o conceito de igualdade de serviços num espaço de nomes. Tal como a igualdade do espaço de nomes, isto implica que os serviços com o mesmo espaço de nomes e nome do serviço são considerados o mesmo serviço.
Os pontos finais de serviço podem ser unidos na malha no caso do Cloud Service Mesh. Com o Multi Cluster Ingress, um recurso MultiClusterService (MCS) torna a união de pontos finais mais explícita. No entanto, recomendamos práticas semelhantes no que diz respeito à nomenclatura. Por este motivo, é importante garantir que os serviços com o mesmo nome no mesmo espaço de nomes são efetivamente a mesma coisa.
No exemplo seguinte, o tráfego da Internet é equilibrado entre um serviço com o mesmo nome no espaço de nomes frontend presente nos clusters B e C. Da mesma forma, usando as propriedades da malha de serviço na frota, o serviço no espaço de nomes frontend pode alcançar um serviço com o mesmo nome no espaço de nomes auth presente nos clusters A e C.
Identidade igual quando acede a recursos externos
Com a Federação de identidades de cargas de trabalho da frota, os serviços numa frota podem tirar partido de uma identidade comum à medida que saem para aceder a recursos externos, como Google Cloud serviços, armazenamentos de objetos, etc. Esta identidade comum permite conceder aos serviços numa frota acesso a um recurso externo uma vez, em vez de cluster a cluster.
Para ilustrar melhor este ponto, considere o seguinte exemplo. Os clusters A, B e C estão inscritos na identidade comum na respetiva frota. Quando os serviços no espaço de nomes backendacedem Google Cloud a recursos, as respetivas identidades são mapeadas para uma conta de serviço Google Cloud comum denominada back. AGoogle Cloud conta de serviço back pode ser autorizada em qualquer número de serviços geridos, desde o Cloud Storage ao Cloud SQL. À medida que são adicionados novos recursos da frota, como clusters, no espaço de nomes backend, estes herdam automaticamente as propriedades de igualdade da identidade da carga de trabalho.
Devido à igualdade de identidade, é importante que todos os recursos numa frota sejam fidedignos e bem geridos. Voltando ao exemplo anterior, se o cluster C for propriedade de uma equipa separada e não fidedigna, esta também pode criar um espaço de nomes backend e aceder a serviços geridos como se fosse o backend no cluster A ou B.
Identidade igual numa frota
Na frota, a identidade igual é usada de forma semelhante à identidade igual externa que abordámos anteriormente. Tal como os serviços de frota são autorizados uma vez para um serviço externo, também podem ser autorizados internamente.
No exemplo seguinte, estamos a usar a malha de serviço do Google Cloud
para criar uma malha de serviço com vários clusters em que frontend tem acesso a backend.
Com a malha de serviços na nuvem e os conjuntos de nós, não precisamos de especificar que frontend nos clusters B e C pode aceder a backend nos clusters A e B. Em vez disso, apenas especificamos que frontend
na frota pode aceder a backend na frota. Esta propriedade não só simplifica a autorização, como também torna os limites dos recursos mais flexíveis. Agora, as cargas de trabalho podem ser facilmente movidas de cluster para cluster sem afetar a forma como são autorizadas. Tal como acontece com a igualdade de identidades de cargas de trabalho, a gestão dos recursos da frota é crucial para garantir a integridade da comunicação entre serviços.
Que funcionalidades usam a semelhança?
Várias funcionalidades da frota não dependem de todo da igualdade e podem ser ativadas e usadas sem ter de considerar se quer assumir alguma forma de igualdade na sua frota. Outras funcionalidades (incluindo o Config Sync e o Policy Controller) podem usar a igualdade. Por exemplo, se quiser selecionar um espaço de nomes em vários clusters membros da frota para configuração a partir de uma única fonte de verdade, mas não o exigem para todos os exemplos de utilização. Por último, existem funcionalidades como o Multi Cluster Ingress e a Workload Identity Federation ao nível da frota que pressupõem sempre alguma forma de semelhança entre clusters e que podem ter de ser adotadas com cuidado, consoante as suas necessidades e cargas de trabalho existentes.
Algumas funcionalidades da frota (como a Workload Identity Federation da frota) requerem que toda a frota esteja preparada para as pressuposições de igualdade que usam. Outras funcionalidades, como a gestão de equipas, permitem-lhe ativar gradualmente a semelhança ao nível do espaço de nomes ou do âmbito da equipa.
A tabela seguinte mostra que funcionalidades requerem um ou mais dos conceitos de semelhança descritos nesta secção.
| Funcionalidade | Suporta a adoção gradual da semelhança | Depende da igualdade do espaço de nomes | Depende da semelhança do serviço | Depende da igualdade de identidade |
|---|---|---|---|---|
| Fleets | N/A | Não | Não | Não |
| Autorização binária | N/A | Não | Não | Não |
| Encriptação transparente entre nós | N/A | Não | Não | Não |
| Política de rede baseada no nome do domínio totalmente qualificado | N/A | Não | Não | Não |
| Ligue o 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 |
| Sequenciação da implementação | N/A | Não | Não | Não |
| Gestão de equipas | Sim | Sim | Sim | Não |
| Entrada em vários clusters | Sim | Sim | Sim | Sim |
| Serviços em vários clusters | Sim | Sim | Sim | Sim |
| Federação de identidade de cargas de trabalho da frota | Não | Sim | Sim | Sim |
| Cloud Service Mesh | Não | Sim | Sim | Sim |
Exclusividade
Os recursos com reconhecimento da frota só podem ser membros de uma única frota em qualquer momento, uma restrição aplicada por Google Cloud ferramentas e componentes. Esta restrição garante que existe apenas uma fonte de informação fidedigna a reger um cluster. Sem exclusividade, mesmo os componentes mais simples tornam-se complexos de usar, o que exige que a sua organização raciocine e configure a forma como vários componentes de várias frotas interagem.
Confiança elevada
A igualdade de serviços, a igualdade de identidade da carga de trabalho e a igualdade de identidade da malha baseiam-se num princípio de elevada confiança entre os membros de uma frota. Esta confiança permite elevar a gestão destes recursos para a frota, em vez de gerir recurso a recurso (ou seja, cluster a cluster para recursos do Kubernetes) e, em última análise, torna o limite do cluster menos importante.
Por outras palavras, numa frota, os clusters oferecem proteção contra preocupações com o raio de impacto, disponibilidade (tanto do plano de controlo como da infraestrutura subjacente), vizinhos ruidosos, etc. No entanto, não são um limite de isolamento forte para políticas e governação, porque os administradores de qualquer membro numa frota podem afetar potencialmente as operações dos serviços noutros membros da frota.
Por este motivo, recomendamos que os clusters que não sejam fidedignos para o administrador da frota sejam colocados nas suas próprias frotas para os manter isolados. Em seguida, conforme necessário, os serviços individuais podem ser autorizados no limite da frota.
Âmbitos de equipa
Um âmbito de equipa é um mecanismo para subdividir ainda mais a sua frota em grupos de clusters, o que lhe permite definir os recursos com reconhecimento da frota atribuídos a uma equipa de aplicações específica. Consoante o seu exemplo de utilização, um cluster de membros da frota individual pode não estar associado a nenhuma equipa, estar associado a uma equipa ou a várias equipas, o que permite que várias equipas partilhem clusters. Também pode usar âmbitos de equipa para sequenciar implementações de atualizações de clusters na sua frota, embora isto exija que cada cluster esteja associado apenas a uma única equipa.
Um âmbito de equipa pode ter espaços de nomes de frota definidos explicitamente associados, em que o espaço de nomes é considerado o mesmo em todo o âmbito. Isto dá-lhe um controlo mais detalhado sobre os espaços de nomes do que a igualdade de espaços de nomes predefinida fornecida apenas pelas frotas.
Componentes ativados para frotas
Os seguintes componentes tiram partido dos conceitos de frota, como o espaço de nomes e a identidade, para oferecer uma forma simplificada de trabalhar com os seus clusters e serviços. Para ver os requisitos ou as limitações atuais para usar frotas com cada componente, consulte os requisitos dos componentes.
Workload Identity Pools
Uma frota oferece um Workload Identity Pool comum que pode ser usado para autenticar e autorizar cargas de trabalho de forma uniforme numa malha de serviços e para serviços externos.Cloud Service Mesh
O Cloud Service Mesh é um conjunto de ferramentas que ajuda a monitorizar e gerir uma malha de serviços fiável no Google Cloud, no local e noutros ambientes suportados. Pode formar uma malha de serviços em clusters que fazem parte da mesma frota.Config Sync
O Config Sync permite-lhe implementar e monitorizar pacotes de configuração declarativos para o seu sistema armazenados numa fonte prioritária central, como um repositório Git, tirando partido dos conceitos essenciais do Kubernetes, como espaços de nomes, etiquetas e anotações. Com o Config Sync, as configurações são definidas em toda a frota, mas aplicadas e impostas localmente em cada um dos recursos membros.Controlador de políticas
O Controlador de políticas permite-lhe aplicar e impor políticas declarativas para os seus clusters do Kubernetes. Estas políticas atuam como barreiras de proteção e podem ajudar com as práticas recomendadas, a segurança e a gestão da conformidade dos seus clusters e frota.Entrada em vários clusters
A entrada em vários clusters usa a frota para definir o conjunto de clusters e pontos finais de serviço sobre os quais o tráfego pode ser equilibrado, permitindo serviços de baixa latência e alta disponibilidade.
O que se segue?
- Leia mais sobre quando usar vários clusters para satisfazer as suas necessidades técnicas e empresariais em Exemplos de utilização de vários clusters.
- Tem tudo a postos para pensar em aplicar estes conceitos aos seus próprios sistemas? Consulte o artigo Planeie os recursos da frota.