Neste guia, você encontra práticas recomendadas, considerações práticas e recomendações para implementar frotas na sua organização.
Antes de ler este guia, você precisa estar familiarizado com os conceitos de Como as frotas funcionam. Recomendamos que você leia este guia antes de conferir nossos exemplos.
Requisitos de componentes
Há algumas limitações a serem consideradas ao implementar frotas com base nos componentes do GKE Enterprise e do Google Cloud que reconhecem as frotas que a organização quer usar. Por exemplo, alguns componentes talvez ainda não sejam compatíveis com clusters que não estão no projeto de host da frota.
A tabela a seguir mostra os requisitos e as limitações atuais de cada componente. A tabela também lista os recursos incluídos no GKE Enterprise, mas que não são configurados usando a API Fleet.
| Componente |
Tipos de cluster |
Requisitos do projeto |
Requisitos de VPC |
|---|---|---|---|
| Config Sync | Todos os clusters compatíveis do GKE Enterprise | Nenhum | Nenhum |
| Controlador de Políticas | Todos os clusters compatíveis do GKE Enterprise | Nenhum | Nenhum |
| Anthos Service Mesh | Consulte Plataformas compatíveis. | O cluster precisa estar registrado em uma frota, e todos os clusters que estão no mesmo projeto precisam estar registrados na mesma frota. Para mais informações, consulte Requisitos da frota do Anthos Service Mesh. | Os clusters do GKE precisam estar na mesma rede VPC. |
| Entrada de vários clusters e gateway de vários clusters | Clusters do GKE no Google Cloud | Os recursos de entrada/gateway, os clusters do GKE e a frota precisam compartilhar o 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 Enterprise, GKE no Google Cloud e GKE no VMware. Com o GKE Enterprise, outros clusters do Kubernetes são compatíveis, mas exigem trabalho de configuração manual. | Nenhum | Nenhum |
| Autorização binária | Clusters do GKE no Google Cloud, GKE em Bare Metal, GKE no VMware | Nenhum | Nenhum |
| Advanced Vulnerability Insights | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Postura de segurança do GKE | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Postura de segurança do GKE | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Postura de Conformidade | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Métricas de utilização de recursos da frota | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Geração de registros de frota | Tudo | Nenhum | Nenhum |
| Conectar gateway | Tudo | Nenhum | Nenhum |
| Gerenciamento de equipes de frota | Tudo | Nenhum | Nenhum |
| Políticas de rede de FQDN do pod | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Criptografia transparente entre nós | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
| Controlador de configuração | Não relevante | Nenhum | Nenhum |
| Sequenciamento de lançamento | Clusters do GKE no Google Cloud | Nenhum | Nenhum |
Como organizar projetos e redes VPC para frotas
Ao fazer a arquitetura para frotas, considere dois recursos fundamentais: projetos do Google Cloud e redes de nuvem privada virtual (VPC, na sigla em inglês).
Conforme observado em Como as frotas funcionam, cada frota é criada em um único projeto. No entanto, com as limitações observadas na tabela acima, as frotas destinam-se a trabalhar com recursos com reconhecimento de frotas do projeto host da frota, outro projeto do Google Cloud, outros provedores de nuvem ou locais.
Embora não seja explicitamente impedido na maioria dos casos, também recomendamos que você adicione recursos cientes da frota no mesmo projeto à mesma frota. Eles não podem ser divididos entre diferentes frotas. A divisão de recursos no mesmo projeto em frotas é considerada um antipadrão porque o limite do projeto oferece proteções mais fortes para fins de política e governança.
Ao decidir como colocar recursos com reconhecimento de frota em vários projetos, adiantamos que muitas organizações terão requisitos de locação diferentes. Considere estes dois extremos:
- Algumas organizações podem escolher colocar todos os recursos na frota em alguns projetos de controle central, alocando namespaces para equipes.
- Outras organizações podem conceder às equipes os próprios clusters dedicados nos próprios projetos.
No primeiro extremo, é mais fácil manter a governança centralizada sobre os recursos, mas pode exigir trabalho adicional para conseguir o isolamento desejado. No segundo extremo, essas compensações são invertidas. Em alguns casos complexos, sua organização pode ter uma combinação de recursos de infraestrutura compartilhada e de recursos dedicados, isolados em projetos separados. Seja qual for seu caso, conforme discutimos em nossa seção Alta confiança, é importante manter o controle mútuo sobre os recursos registrados em um ambiente para manter a integridade da frota.
A organização de rede está intimamente relacionada à organização do projeto. Vários componentes da frota, conforme indicado na tabela de requisitos de componentes, exigem uma conectividade específica entre os recursos registrados na frota. Com o tempo, alguns desses requisitos podem ser flexibilizados. No entanto, hoje, por exemplo, a entrada de vários clusters exige que os pods estejam na mesma rede VPC, com os próprios clusters estando no mesmo projeto que a frota.
Quando os componentes podem acomodar esses requisitos iniciais de projeto e rede VPC, prevemos que a adoção de um modelo de VPC compartilhada se torne uma prática recomendada sempre que você precisar de vários projetos. Nesse modelo, a frota pode ser instanciada no projeto host da rede VPC com recursos registrados nos respectivos projetos de serviço. Se você precisar de várias frotas com uma VPC compartilhada, poderá indicar projetos para serem o projeto host da frota.
Como adicionar/excluir recursos de frota (clusters)
É possível adicionar recursos com reconhecimento de frota a uma frota, mas é preciso tomar um certo cuidado para que os serviços não sejam interrompidos como resultado da adição. Em particular, é importante garantir que as mesmas propriedades de semelhança e confiança sejam consideradas antes de adicionar o recurso à frota. O administrador da frota precisa prestar atenção especial em como os componentes ativos da frota usam a semelhança. Isso pode exigir a migração para práticas de nomenclatura consistentes, estabelecendo a governança do recurso, ou possivelmente executar outras ações antes de adicionar o recurso à frota.
Excluir recursos de uma frota também requer atenção especial. Por exemplo, recursos que fazem parte de uma malha de serviço ou são segmentados como parte de um balanceador de carga de vários clusters serão afetados. Para se preparar para excluir o recurso, recomendamos revisar cada componente que você ativou na frota e tomar as medidas necessárias para diminuir o tráfego ativo da malha de serviço ou tráfego externo.
À medida que as frotas evoluírem, forneceremos mais orientação na banda ao adicionar e excluir recursos de frota.
Como ativar ou reconfigurar componentes de frota
Ativar ou reconfigurar componentes do Google Cloud ou do GKE Enterprise que usam frotas também requer alguns cuidados especiais. Ao permitir novos componentes, preste atenção aos possíveis efeitos colaterais para ativá-lo em todos os clusters. Por exemplo, antes de ativar o Anthos Service Mesh, entenda quais endpoints de serviço estão mesclados em recursos e verifique se este é o resultado desejado.
Forneceremos mais orientações na banda ao configurar os componentes ativados pela frota à medida que o conceito de frota evoluir.
A seguir
- Para alguns cenários hipotéticos que ilustram as considerações descritas neste guia, consulte Exemplos de frota.