Frotas

As frotas (anteriormente conhecidas como ambientes) são um conceito do Google Cloud para organizar logicamente clusters e outros recursos, permitindo 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.

Neste guia, apresentamos as frotas: o que queremos dizer com frota, onde em nossos componentes elas são usadas e como configurar seus sistemas para aproveitar os recursos no nível da frota. Também fornecemos alguns exemplos que ilustram como as frotas podem ajudar a simplificar o gerenciamento do cluster e do sistema, além das práticas recomendadas a serem seguidas ao criar e operar sistemas de vários clusters com frotas.

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. 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 Anthos Malha

Se você quiser saber mais sobre o Anthos e os componentes que usam frotas, consulte nossa visão geral técnica do Anthos e o tutorial Explore o Anthos. No entanto, você não precisa estar familiarizado com o Anthos para seguir este guia.

Introdução

Normalmente, conforme as organizações unem as tecnologias nativas da nuvem, como contêineres, orquestração de contêineres e malhas de serviço, elas alcançam um ponto em que a execução de um único cluster não é mais suficiente. Há vários motivos pelos quais as organizações optam por implantar vários clusters para atingir os objetivos técnicos e comerciais. por exemplo, separar a produção de ambientes que não sejam de produção ou separar serviços entre camadas, localidades ou equipes. Saiba mais sobre os benefícios e as desvantagens envolvidas em abordagens de vários clusters em casos de uso de vários clusters.

number medida que o número de clusters aumenta, o gerenciamento e a governança sobre esses clusters e os recursos dentro deles se tornam cada vez mais difíceis. Muitas vezes, as organizações contam para criar ferramentas e políticas operacionais personalizadas para alcançar o nível de controle exigido.

O Google Cloud fornece o conceito de frota para ajudar os administradores a gerenciar vários clusters. Com uma frota, é possível agrupar e normalizar logicamente clusters, facilitando a administração da infraestrutura. As frotas podem ser utilizadas no contexto do Anthos e do GKE. Veja uma lista dos componentes do Anthos e do GKE que podem aproveitar frotas na seção de componentes ativados para frota neste documento.

A adoção de frotas ajuda a organização a gerenciar níveis desde clusters individuais a grupos inteiros de clusters. Além disso, a normalização que as frotas exigem pode ajudar suas equipes a adotar práticas recomendadas semelhantes às usadas no Google. Para fins de comparação, assim como o recurso de organização é o nó raiz da hierarquia de recursos do Google Cloud e é usado para controlar a política e os recursos agrupados, a frota forma a raiz do gerenciamento de vários clusters.

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, somente clusters do Kubernetes podem ser membros de frota, apesar de considerarmos a possibilidade de instâncias de máquina virtual (VM, na sigla em inglês) e, possivelmente, de outros recursos a fazer parte de frotas em futuras iterações de plataforma. O Google Cloud fornece um serviço do Connect para registrar recursos como membros do ambiente.

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 Cloud só pode ter uma única frota (ou nenhuma) associada a ele. Essa restrição reforça o uso de projetos do Cloud para fornecer isolamento mais forte entre recursos que não são regidos ou consumidos em conjunto.

Componentes ativados pela frota

Os seguintes componentes do Anthos e do GKE 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 identidade da carga de trabalho (clusters do Anthos e do GKE)
    Uma frota oferece um pool 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 e para serviços externos.

  • Anthos Service Mesh (Anthos)
    O Anthos Service Mesh é um pacote de ferramentas que ajuda a monitorar e gerenciar uma malha de serviço confiável no Google Na nuvem ou no local. É possível formar uma malha de serviço nos recursos (como clusters e VMs) que fazem parte da mesma frota.

  • Anthos Config Management (Anthos e GKE)
    O Anthos Config Management permite implantar e monitorar políticas declarativas e alterações de configuração no seu sistema armazenadas em um Git central usando os conceitos principais do Kubernetes, como namespaces, rótulos e anotações. Com o Anthos Config Management, a política e a configuração são definidas em toda a frota, mas aplicadas e aplicadas localmente em cada um dos recursos do membro.

  • Entrada de vários clusters (Anthos)
    A Entrada 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.

  • Cloud Run for Anthos (Anthos)
    O Cloud Run for Anthos é uma plataforma para desenvolvedores do Knative gerenciada e compatível com o Google que abstrai a complexidade da infraestrutura subjacente, tornando fácil de criar, implantar e gerenciar aplicativos e serviços nos clusters da frota do Anthos.

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 alguns objetos do Kubernetes, como clusters com o mesmo nome em contextos diferentes, são tratados como a mesma coisa. Essa normalização é feita para tornar a administração de recursos de ambiente mais gerenciável. Ela traz 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.

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 os mesmos de muitos componentes. 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. O namespace é instanciado apenas nos clusters A e B, mas implicitamente reservado no Cluster C. Ele permite que o serviço 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.

Diagrama ilustrando a semelhança de namespace em uma frota
Semelhança de namespace em uma frota

Semelhança de serviços

O Anthos Service Mesh e a Entrada 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 Anthos Service Mesh. Com a Entrada 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 os nomes de serviço 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 rota, o serviço frontend pode acessar um serviço com o mesmo nome no namespace auth presente nos clusters A e C.

Diagrama ilustrando a semelhança de serviço em uma frota
Semelhança de serviço em uma frota

Semelhança de identidade ao acessar recursos externos

Os serviços dentro 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.

Diagrama ilustrando a semelhança de identidade acessando recursos fora de uma frota
Semelhança de identidade acessando recursos fora de uma frota

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 Anthos Service Mesh para criar uma malha de serviço de vários clusters em que frontend tem acesso a backend. Com o Anthos 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.

Diagrama ilustrando a semelhança de identidade dentro de uma frota
Semelhança de identidade dentro de uma frota

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 recursos 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.

A seguir

Quer pensar na aplicação desses conceitos nos seus próprios sistemas? Consulte nossos requisitos e práticas recomendadas para frotas.