Planejar os recursos da frota

Uma parte importante do planejamento de frotas é decidir quais recursos compatíveis com frotas você quer usar. Principalmente se você estiver trabalhando com clusters e cargas de trabalho de produção, identifique os recursos da frota que podem ser adotados imediatamente com o mínimo de atrito ou risco aos aplicativos atuais e planeje outros recursos que exijam uma adoção mais gradual ou cuidadosa. Este guia descreve os diferentes tipos de recursos ativados pelo uso de frotas e os requisitos deles, além de oferecer algumas orientações práticas sobre a adoção de recursos.

Muitos dos recursos descritos neste guia estão disponíveis apenas como parte do GKE Enterprise. Para mais detalhes, consulte Opções de implantação do GKE Enterprise.

Este guia é destinado a arquitetos de nuvem que querem começar a usar as frotas nas organizações. Antes de ler este guia, confira a Visão geral do gerenciamento de frotas e o Planejamento de recursos de frotas, que discute a organização de clusters novos ou existentes em frotas.

Práticas recomendadas para adoção de recursos

Todos os recursos da frota (exceto a Observabilidade básica da frota) são ativados por opção, ou seja, você precisa especificar que quer usá-los. Apenas adicionar um cluster existente a uma frota não altera sua configuração. Quando você decide usar os atributos da frota, alguns deles podem ser ativados imediatamente com risco mínimo, mas talvez seja necessário abordar alguns deles com mais cuidado. Esta seção fornece algumas orientações para a adoção de recursos.

Principalmente com clusters e cargas de trabalho atuais, é preciso ter muito cuidado quando os recursos usam identidade. Esse é um conceito de frota em que namespaces, serviços ou identidades com o mesmo nome em diferentes clusters são considerados pelo recurso como iguais. Saiba mais sobre o princípio de semelhança e quais recursos o usam em Como as frotas funcionam.

Integração de recursos de baixo risco

O seguinte "ambiente" atributos não pressupõem nenhum tipo de semelhança e não afetam os clusters de forma alguma. Todos eles podem ser usados com segurança, mesmo com cargas de trabalho e clusters atuais, para que você se beneficie imediatamente de insights aprimorados de observabilidade e segurança em toda a frota, além da capacidade de gerenciar a ordem de upgrades de cluster com base na assinatura da frota.

Os recursos a seguir são instalados em clusters individuais. Os recursos podem assumir a mesma semelhança, mas somente ao configurar ou especificar recursos em vários clusters. Isso significa que você pode ativar esses recursos com segurança nos clusters com cargas de trabalho atuais e só precisa considerar a identidade ao criar ou usar configurações que usam esses seletores opcionais.

Como integrar recursos avançados de vários clusters

Os recursos abaixo reduzem a sobrecarga operacional do gerenciamento de vários clusters. No entanto, é preciso ter mais cuidado com esses recursos, já que todos eles exigem uma suposição de um ou mais tipos de igualdade para funcionar. Ativar ou desativar esses recursos pode afetar vários clusters e as cargas de trabalho deles.

Por exemplo, se você tiver namespaces do Kubernetes com o mesmo nome em clusters e aplicativos diferentes (incluindo o namespace padrão), verifique se quer que eles sejam tratados como o mesmo namespace antes de ativar os recursos que fazem essa suposição. Da mesma forma, se você quiser usar o Cloud Service Mesh, entenda quais endpoints de serviço serão mesclados nos clusters e confirme se esse é o comportamento desejado.

Auditar a semelhança de namespace

Se você conhece bem seus aplicativos, pode auditar seus namespaces apenas verificando se nenhum dos aplicativos "diferentes" usa o mesmo namespace. Em particular, observe o uso ad hoc do namespace padrão. Por exemplo, se você tiver um namespace chamado default em um cluster e um namespace chamado default em outro cluster, mas eles forem usados para finalidades diferentes, renomeie um deles.

Para uma abordagem mais rigorosa, tente o seguinte. Para cada conjunto de namespaces com o mesmo nome em clusters diferentes de uma frota, verifique se:

  • em cada cluster, as mesmas regras do RBAC estão presentes e o namespace dos principais tem acesso ao namespace.
  • o conjunto de imagens usadas pelos pods (menos o hash/tag) é o mesmo.
  • o conjunto de Secrets usados pelos pods é idêntico.

Se todas as condições forem verdadeiras, os namespaces serão suficientemente semelhantes para serem tratados como "iguais".

Se os namespaces não forem suficientemente semelhantes, você poderá migrar apps para novos namespaces. Quando você estiver pronto para presumir a semelhança de namespace, poderá ativar os recursos que a usam.

Uniformidade do serviço de auditoria

Se você quiser adotar o Cloud Service Mesh para gerenciar seus aplicativos baseados em microsserviços, considere a semelhança de serviço. Isso significa que, para qualquer combinação de namespace e nome de serviço, o Cloud Service Mesh vai tratá-los como o mesmo serviço lógico em termos de:

  • Identidade (especificamente para a segurança do Cloud Service Mesh): se namespace1/service1 tiver autorização para fazer algo, as cargas de trabalho com essa identidade de qualquer cluster também terão autorização.
  • Gerenciamento de tráfego: por padrão, o tráfego é balanceado por carga nos serviços do namespace1/service1 de qualquer cluster.
  • Observabilidade: as métricas de namespace1/service1 em todos os clusters são agregadas.

Se você estiver ativando o Cloud Service Mesh com novos clusters e aplicativos, recomendamos reservar combinações exclusivas de namespace/nome de serviço em toda a malha. Para aplicativos existentes, audite seus serviços para garantir que os serviços com o mesmo namespace e nome nos clusters sejam aqueles que você quer que sejam tratados como o mesmo serviço em termos de identidade, gerenciamento de tráfego e observabilidade.

Em particular, verifique se serviços logicamente diferentes (por exemplo, uma API de contabilidade de pagamento e uma API de transação de pagamento) não usam o mesmo par [namespace, name] (por exemplo, payments/api), porque eles serão tratados como o mesmo serviço quando estiverem em uma malha de serviço. Essa união conceitual ocorre mesmo em limites regionais. Além disso, a função dos serviços pode ser afetada.

A semelhança de nome/namespace do serviço também é assumida pelo Ingress de vários clusters e pelo gateway de vários clusters ao direcionar o tráfego para serviços em vários clusters, mas apenas para serviços expostos fora dos clusters.

Considerar a identidade da carga de trabalho

Um recurso importante da frota é a federação de identidade da carga de trabalho em toda a frota. Isso amplia os recursos fornecidos na federação de identidade da carga de trabalho para o GKE, que permite que as cargas de trabalho no cluster sejam autenticadas no Google sem que você precise fazer o download, alternar manualmente e gerenciar as chaves da conta de serviço do Google Cloud. Em vez disso, as cargas de trabalho são autenticadas usando tokens de curta duração gerados pelos clusters, e cada cluster é adicionado como um provedor de identidade a um pool de identidades de carga de trabalho especial. As cargas de trabalho executadas em um namespace específico podem compartilhar a mesma identidade do Identity and Access Management nos clusters.

Embora a federação normal de identidade da carga de trabalho para o GKE use um pool de identidades em todo o projeto, a federação de identidade de carga de trabalho em toda a frota usa um pool de identidades de cargas de trabalho para toda a frota, mesmo que os clusters estejam em projetos diferentes, com semelhança implícita para identidades em toda a frota, assim como semelhança de namespace e serviço. Isso simplifica a configuração da autenticação dos seus aplicativos em vários projetos, mas pode ter considerações de controle de acesso além das considerações para a federação de identidade da carga de trabalho normal para o GKE se você optar por usá-la em frotas de vários projetos, principalmente se o projeto host da frota tiver uma mistura de clusters de frota e não-frota.

Para saber mais sobre a federação de identidade da carga de trabalho da frota e como usá-la para acessar os serviços do Google Cloud, consulte Usar a Identidade da carga de trabalho da frota. Para receber orientações sobre como minimizar os riscos com a federação de identidade da carga de trabalho da frota com alguns exemplos, consulte Práticas recomendadas para usar a Identidade da carga de trabalho da frota.

Padrões da frota

O GKE Enterprise permite definir padrões no nível da frota para determinados recursos corporativos, incluindo o Cloud Service Mesh, o Config Sync e o Policy Controller. Isso ajuda a configurar clusters para usar esses recursos sem precisar configurar cada cluster individualmente. Por exemplo, um administrador pode ativar o Policy Controller para a frota e definir políticas padrão no nível da frota. Isso instala o agente necessário em novos clusters de membros da frota e aplica políticas padrão a eles.

No entanto, esses padrões são aplicados automaticamente apenas a novos clusters que você adiciona à frota no momento da criação. Os clusters e as cargas de trabalho atuais não são afetados, mesmo que você já os tenha adicionado à frota ou adicionado os clusters depois de configurar os padrões do recurso. Isso significa que você pode configurar com segurança os padrões no nível da frota sem correr o risco de ativar ou configurar recursos em clusters em que você não está pronto para isso. Você sempre pode aplicar as configurações padrão aos clusters existentes mais tarde.

Requisitos de atributos

Há algumas limitações a serem consideradas ao implementar frotas com base nos atributos da frota que seu que a organização quer usar. Por exemplo, alguns recursos não oferecem suporte trabalhar com clusters que não estão no projeto host da frota, enquanto outros não têm suporte em clusters fora do Google Cloud.

A tabela a seguir mostra os requisitos e as limitações atuais de cada componente, com algumas diretrizes específicas nas seções a seguir.

Recurso
 Tipos de cluster
 Requisitos do projeto
 Requisitos de VPC
Config Sync Todos os clusters compatíveis do GKE Enterprise Nenhum Nenhum
Policy Controller Todos os clusters compatíveis do GKE Enterprise Nenhum Nenhum
Cloud Service Mesh Veja as limitações Todos os clusters usados com o Cloud Service Mesh que estão no mesmo projeto precisam ser registrados na mesma frota. Para mais informações, consulte Requisitos da frota do Cloud Service Mesh. Os clusters do GKE precisam estar na mesma rede VPC.
Serviços de vários clusters (MCS) GKE no Google Cloud Nenhum Consulte MCS na VPC compartilhada.
Entrada de vários clusters e gateway de vários clusters GKE no Google Cloud Os recursos de entrada/gateway, os clusters do GKE e a frota precisam estar no mesmo projeto. Os recursos de entrada/gateway e os clusters do GKE precisam estar na mesma rede VPC.
Pools de identidade da carga de trabalho Otimizado para GKE no Google Cloud e Google Distributed Cloud no VMware. Outros recursos do Kubernetes os clusters são compatíveis, mas exigem configuração extra. Nenhum Nenhum
Autorização binária GKE no Google Cloud, Google Distributed Cloud no VMware, Google Distributed Cloud em 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
Geração de registros de frota Todos Nenhum Nenhum
Conectar gateway Todos Nenhum Nenhum
Gerenciamento de equipes de frota Todos Nenhum Nenhum
Políticas de rede de FQDN do pod GKE no Google Cloud Nenhum Nenhum
Criptografia transparente entre nós GKE no Google Cloud Nenhum Nenhum
Controlador de configuração Não relevante Nenhum Nenhum
Sequenciamento de lançamento GKE no Google Cloud Nenhum Nenhum

Considerar os requisitos da nuvem privada virtual

Se você planeja usar um recurso como o Cloud Service Mesh, que exige que os clusters estejam em uma única rede de nuvem privada virtual (VPC), conforme mostrado na tabela anterior, crie uma frota para cada VPC. Se você não planeja usar esses recursos, várias VPCs podem ser colocadas em uma frota.

Por exemplo, um padrão comum é que uma organização tenha vários projetos, cada um com a própria VPC padrão. Eles podem ter conexões de peering entre si. Se você não estiver usando um atributo com requisitos de VPC única, todos eles poderão ser colocados em uma única frota. Outro padrão comum segue um modelo que usa várias VPCs. Se você não estiver usando um recurso com requisitos de VPC única, poderá colocar clusters de todas as VPCs em uma frota. Em alguns casos, seguir essas diretrizes pode resultar em frotas com apenas um cluster. Nesse caso, talvez seja necessário abandonar o uso de recursos com restrições de VPC e criar frotas com vários projetos ou reconsiderar sua arquitetura e mover as cargas de trabalho, conforme apropriado.

Requisitos para a rede de vários clusters

Se você quiser usar a Entrada de vários clusters ou os gateways de vários clusters para o gerenciamento de tráfego, saiba que, em ambos os casos, o controlador de gateway não pode abranger projetos. Isso significa que todos os clusters que você quer usar com esses recursos precisam estar no mesmo projeto e na mesma frota. Se você precisar criar frotas que incluam clusters de vários projetos, use gateways de cluster único e direcione o tráfego para o gateway certo de outra maneira (por exemplo, usando DNS). Os clusters que usam esses recursos também precisam estar na mesma rede VPC.

A seguir