Este guia destina-se a arquitetos da nuvem que querem começar a usar frotas nas respetivas organizações. Antes de ler este guia, certifique-se de que conhece a nossa vista geral da gestão de frotas e o artigo Planeie recursos da frota, que aborda a organização de clusters novos ou existentes em frotas.
Práticas recomendadas para a adoção de funcionalidades
Todas as funcionalidades de frotas (exceto a observabilidade básica de frotas) são opcionais, ou seja, tem de especificar que quer usá-las. Apenas adicionar um cluster existente a uma frota não altera a respetiva configuração. Quando decidir usar as funcionalidades de frota, algumas funcionalidades podem ser ativadas imediatamente com um risco mínimo, mas pode ter de abordar algumas funcionalidades com mais cuidado. Esta secção fornece algumas orientações para a adoção de funcionalidades.
Em particular, com clusters e cargas de trabalho existentes, tem de ter especial cuidado quando as funcionalidades usam a semelhança. Este é um conceito de frota em que os espaços de nomes, os serviços ou as identidades com o mesmo nome em diferentes clusters são assumidos pela funcionalidade como sendo a mesma coisa. Pode ler mais acerca do princípio da igualdade e das funcionalidades que o usam no artigo Como funcionam as frotas.
Integração de funcionalidades de baixo risco
As seguintes funcionalidades "ambientais" não pressupõem qualquer tipo de semelhança e não afetam os clusters de forma alguma. Podem ser usadas em segurança, mesmo com cargas de trabalho e clusters existentes, o que lhe permite beneficiar imediatamente de uma observabilidade melhorada e de estatísticas de segurança em toda a sua frota, bem como da capacidade de gerir a ordem das atualizações de clusters com base na associação à frota.
As seguintes funcionalidades estão instaladas em clusters individuais. As funcionalidades podem assumir a igualdade, mas apenas quando configuram ou especificam recursos em vários clusters. Isto significa que pode ativar estas funcionalidades em segurança nos seus clusters com cargas de trabalho existentes e só tem de considerar a igualdade quando criar ou usar configurações para as mesmas que usam estes seletores opcionais.
- Config Sync. Pode ter de considerar a igualdade se quiser usar os seletores opcionais namespace e team scope.
- Autorização binária. Pode ter de considerar o espaço de nomes, a identidade ou a semelhança de serviços se quiser usar regras com âmbito opcionais.
- Policy Controller. Pode ter de considerar a igualdade do espaço de nomes se quiser excluir espaços de nomes da aplicação.
Integração de funcionalidades avançadas de vários clusters
As seguintes funcionalidades avançadas reduzem os custos operacionais da gestão de vários clusters. No entanto, é preciso ter mais cuidado com estas funcionalidades, uma vez que todas requerem a pressuposição de um ou mais tipos de semelhança para funcionar, e ativá-las ou desativá-las pode afetar vários clusters e as respetivas cargas de trabalho.
- Federação de identidades da carga de trabalho da frota
- Cloud Service Mesh
- Gateway de vários clusters
- Entrada em vários clusters
- Gestão da equipa de frota
Por exemplo, se tiver espaços de nomes do Kubernetes existentes com o mesmo nome em diferentes clusters e aplicações (incluindo o espaço de nomes predefinido), deve verificar se quer que sejam tratados como o mesmo espaço de nomes antes de ativar quaisquer funcionalidades que façam esta suposição. Da mesma forma, se quiser usar o Cloud Service Mesh, deve compreender que os pontos finais de serviço vão ser unidos nos seus clusters e confirmar que este é o comportamento pretendido.
Auditoria da igualdade do espaço de nomes
Se conhecer bem as suas aplicações, pode auditar os seus espaços de nomes apenas verificando que não existem duas aplicações "diferentes" a usar o mesmo espaço de nomes. Em particular, procure a utilização ad hoc do espaço de nomes predefinido. Por exemplo, se tiver um espaço de nomes denominado default num cluster e um espaço de nomes denominado default noutro cluster, mas forem usados para fins diferentes, deve mudar o nome de um deles.
Para uma abordagem mais rigorosa, experimente o seguinte. Para cada conjunto de namespaces com o mesmo nome em diferentes clusters de uma frota, verifique se:
- Em todos os clusters, as mesmas regras de RBAC estão no cluster e o namespace de diretores tem acesso permitido ao namespace.
- O conjunto de imagens usado pelos Pods (exceto o hash/etiqueta) é o mesmo.
- O conjunto de segredos usado pelos pods é idêntico.
Se todas estas condições forem verdadeiras, os espaços de nomes são suficientemente semelhantes para serem tratados como "iguais".
Se os seus espaços de nomes não forem suficientemente semelhantes, pode migrar as apps para novos espaços de nomes. Quando tiver a certeza de que os espaços de nomes são iguais, pode ativar as funcionalidades que os usam.
Audite a igualdade do serviço
Se quiser adotar o Cloud Service Mesh para gerir as suas aplicações baseadas em microsserviços, outro aspeto a considerar é a igualdade dos serviços. Isto significa que, para qualquer combinação de namespace e nome do serviço, o Cloud Service Mesh trata-os como o mesmo serviço lógico em termos de:
- Identidade (especificamente para a segurança da Cloud Service Mesh): se
namespace1/service1tiver autorização para fazer algo, as cargas de trabalho com essa identidade de qualquer cluster têm autorização. - Gestão de tráfego: por predefinição, o tráfego é equilibrado entre a carga de
namespace1/service1serviços em qualquer cluster. - Observabilidade: as métricas para
namespace1/service1em todos os clusters são agregadas.
Se estiver a ativar a Cloud Service Mesh com novos clusters e aplicações, recomendamos que reserve combinações únicas de namespace/nome do serviço em toda a malha. Para aplicações existentes, audite os seus serviços para garantir que os serviços com o mesmo espaço de nomes e nome nos seus clusters são aqueles que quer que sejam tratados como o mesmo serviço em termos de identidade, gestão de tráfego e observabilidade.
Em particular, certifique-se de que os serviços logicamente diferentes (por exemplo, uma API de contabilidade de pagamentos e uma API de transações de pagamentos) não usam o mesmo par [namespace, name] (por exemplo, payments/api), porque são tratados como o mesmo serviço assim que estiverem numa malha de serviços. Esta união conceptual ocorre mesmo entre limites regionais. Além disso, o funcionamento dos serviços pode ser afetado.
A igualdade do nome/espaço de nomes do serviço também é assumida pelo Multi Cluster Ingress e pelo gateway de vários clusters quando direcionam o tráfego para serviços em vários clusters, embora apenas para serviços que são expostos fora dos clusters.
Considere o Workload Identity
Uma funcionalidade poderosa da frota é a federação de identidade da carga de trabalho ao nível da frota. Isto expande as capacidades fornecidas na Workload Identity Federation para o GKE, que permite que as cargas de trabalho no seu cluster sejam autenticadas no Google sem ter de transferir, rodar manualmente e, geralmente, gerir Google Cloud chaves de contas de serviço. Em alternativa, as cargas de trabalho são autenticadas através de tokens de curta duração gerados pelos clusters, com cada cluster adicionado como um fornecedor de identidade a um Workload Identity Pool especial. As cargas de trabalho executadas num espaço de nomes específico podem partilhar a mesma identidade de gestão de identidade e de acesso entre clusters.
Embora a federação de identidade da carga de trabalho normal para o GKE use um conjunto de identidades ao nível do projeto, a federação de identidade da carga de trabalho ao nível da frota usa um conjunto de identidades da carga de trabalho para toda a frota, mesmo que os clusters estejam em projetos diferentes, com igualdade implícita para identidades em toda a frota, bem como igualdade de espaço de nomes e serviços. Isto simplifica a configuração da autenticação para as suas aplicações em vários projetos, mas pode ter considerações de controlo de acesso além das da Workload Identity Federation normal para o GKE se optar por usá-la em frotas com vários projetos, especialmente se o projeto anfitrião da frota tiver uma combinação de clusters de frotas e não de frotas.
Para saber mais sobre a federação de identidades da carga de trabalho da frota e como a usar para aceder a Google Cloud serviços, consulte o artigo Use o Workload Identity da frota. Para ver orientações sobre como minimizar o risco com a federação de identidades da carga de trabalho da frota, juntamente com alguns exemplos, consulte o artigo Práticas recomendadas para usar o Workload Identity da frota.
Predefinições ao nível da frota
O GKE oferece a capacidade de definir predefinições ao nível da frota para determinadas funcionalidades empresariais, incluindo o Cloud Service Mesh, o Config Sync e o Policy Controller. Isto ajuda a configurar clusters para usar estas funcionalidades sem ter de configurar cada cluster individualmente. Por exemplo, um administrador pode ativar o Policy Controller para a sua frota e definir políticas predefinidas ao nível da frota. Isto instala o agente necessário em novos clusters de membros da frota e aplica-lhes as políticas predefinidas.
No entanto, estas predefinições só se aplicam automaticamente a novos clusters que adicionar à frota no momento da criação do cluster. Os clusters existentes e as respetivas cargas de trabalho não são afetados, mesmo que já os tenha adicionado à frota ou se adicionar os clusters depois de configurar as predefinições das funcionalidades. Isto significa que pode configurar em segurança predefinições ao nível da frota sem correr o risco de ativar ou configurar funcionalidades em clusters onde não está pronto para o fazer. Pode sempre optar por aplicar as predefinições aos clusters existentes mais tarde.
Requisitos de funcionalidades
Existem algumas limitações a ter em conta ao implementar frotas com base nas funcionalidades de frotas que a sua organização quer usar. Por exemplo, algumas funcionalidades não suportam o trabalho com clusters que não estão no projeto anfitrião da frota, enquanto outras não são suportadas em clusters fora Google Cloud.
A tabela seguinte mostra os requisitos e as limitações atuais de cada componente, com algumas diretrizes específicas nas secções seguintes.
| Funcionalidade |
Tipos de clusters |
Requisitos do projeto |
Requisitos da VPC |
|---|---|---|---|
| Config Sync | Todos os clusters suportados do GKE | Nenhum | Nenhum |
| Controlador de políticas | Todos os clusters suportados do GKE | Nenhum | Nenhum |
| Cloud Service Mesh | Veja as limitações | Todos os clusters usados com a Cloud Service Mesh que estejam no mesmo projeto têm de estar registados na mesma frota. Para mais informações, consulte os requisitos da frota da Cloud Service Mesh. | Os clusters do GKE têm de estar na mesma rede de VPC. |
| Serviços em vários clusters (MCS) | GKE no Google Cloud | Nenhum | Consulte MCS na VPC partilhada |
| Entrada em vários clusters e gateway em vários clusters | GKE no Google Cloud | Os recursos de entrada/gateway, os clusters do GKE e a frota têm de estar no mesmo projeto. | Os recursos de entrada/gateway e os clusters do GKE têm de estar na mesma rede de VPC. |
| Workload Identity Pools | Otimizado para o GKE no Google Cloud e no Google Distributed Cloud no VMware. Outros clusters do Kubernetes são suportados, mas requerem trabalho de configuração adicional. | Nenhum | Nenhum |
| Autorização binária | GKE on Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on bare metal | Nenhum | Nenhum |
| Advanced Vulnerability Insights | GKE no Google Cloud | Nenhum | Nenhum |
| Postura de segurança | GKE no Google Cloud | Nenhum | Nenhum |
| Postura de conformidade | GKE no Google Cloud | Nenhum | Nenhum |
| Métricas de utilização de recursos da frota | GKE no Google Cloud | Nenhum | Nenhum |
| Registo de frotas | Tudo | Nenhum | Nenhum |
| Ligue o gateway | Tudo | Nenhum | Nenhum |
| Gestão da equipa de frotas | Tudo | Nenhum | Nenhum |
| Políticas de rede FQDN de pods | GKE no Google Cloud | Nenhum | Nenhum |
| Encriptação transparente entre nós | GKE no Google Cloud | Nenhum | Nenhum |
| Config Controller | Não aplicável | Nenhum | Nenhum |
| Sequenciação da implementação | GKE no Google Cloud | Nenhum | Nenhum |
Considere os requisitos da nuvem privada virtual
Se planeia usar uma funcionalidade, como a Cloud Service Mesh, que requer que os clusters estejam numa única rede de nuvem virtual privada (VPC), conforme mostrado na tabela anterior, deve criar uma frota para cada VPC. Se não planeia usar essas funcionalidades, pode colocar várias VPCs numa frota.
Por exemplo, um padrão comum é uma organização ter vários projetos, cada um com a sua própria VPC predefinida. Estes podem ter ligações de peering existentes entre si. Se não estiver a usar uma funcionalidade com requisitos de VPC única, pode colocar tudo numa única frota. Outro padrão comum segue uma topologia de "hub and spoke", que usa várias VPCs. Se não estiver a usar uma funcionalidade com requisitos de VPC única, pode colocar clusters de todas essas VPCs numa única frota. Tenha em atenção que, em alguns casos, seguir estas diretrizes pode resultar em frotas com apenas um cluster. Nesse caso, pode ter de renunciar à utilização de funcionalidades com restrições de VPC e criar frotas de vários projetos ou reconsiderar a sua arquitetura e mover cargas de trabalho, conforme adequado.
Requisitos para a rede de vários clusters
Se quiser usar o Multi Cluster Ingress ou gateways de vários clusters para a gestão de tráfego, tenha em atenção que, em ambos os casos, o controlador de gateway não pode abranger projetos. Isto significa que todos os clusters que quer usar com estas funcionalidades também têm de estar no mesmo projeto e na mesma frota. Se precisar de criar frotas que incluam clusters de vários projetos, pode usar gateways de cluster único e direcionar o tráfego para o gateway certo de outra forma (por exemplo, através de DNS). Os clusters que usam estas funcionalidades também têm de estar na mesma rede VPC.
O que se segue?
- Saiba como gerir funcionalidades da frota em Gerir funcionalidades ao nível da frota.
- Saiba mais sobre como funcionam as frotas no artigo Como funcionam as frotas.