Como se conectar a clusters registrados com o gateway do Connect

As frotas no Google Cloud são grupos lógicos de clusters do Kubernetes e outros recursos que podem ser gerenciados juntos, criados ao registrar clusters no Google Cloud. O gateway do Connect foi desenvolvido com base na eficiência das frotas para que os usuários do Anthos possam se conectar e executar comandos nos clusters registrados de frota de maneira simples, consistente e segura, estejam eles no Google Cloud, em outras nuvens públicas ou no local, além de facilitar a automatização de processos de DevOps em todos os clusters.

Neste guia, pressupomos que você já conheça alguns conceitos básicos da frota e saiba como registrar clusters em frotas. Saiba mais na Visão geral do gerenciamento de frota, na Visão geral de criação de frota e nos guias vinculados. Você também precisa conhecer as ferramentas e conceitos do Kubernetes, incluindo kubectl, client-go (se quiser usar o gateway para fins de automação), controle de acesso baseado em papéis (RBAC) e recursos principais do Kubernetes.

Por padrão, o gateway do Connect usa seu ID do Google para se autenticar em clusters, com compatibilidade com provedores de identidade de terceiros que usam a federação de identidade de colaboradores e com compatibilidade com a autenticação baseada em grupo pelo serviço de identidade do GKE. Se você quiser saber mais sobre o serviço de identidade do GKE ou usá-lo como uma opção autônoma de autenticação de terceiros, consulte Introdução ao serviço de identidade do GKE.

Por que usar o gateway do Connect?

Há muitos desafios no gerenciamento das cargas de trabalho quando os clusters são executados em várias nuvens e ambientes híbridos. Os clusters podem estar sendo executados em nuvens privadas virtuais (VPCs) diferentes e aproveitar diferentes provedores de identidade, o que torna a conectividade, autenticação e autorização mais complicadas. As vezes, é difícil descobrir quais clusters existem nesses ambientes.

O gateway do Connect facilita:

  • Descubra quais clusters existem (no Google Cloud, em outra nuvem pública ou no local) e estão registrados na sua frota por fazendo uma consulta simples.
  • Conecte-se a um cluster usando a mesma infraestrutura que usamos para exibir os clusters do GKE registrados no console do Google Cloud.
  • Faça a autenticação com as mesmas identidades que você usa com os serviços do Google Cloud.
  • Autorize de maneira consistente em todos os clusters registrados em uma frota.

O gateway autentica sua identidade do Google Cloud e fornece a conexão com o servidor da API do cluster por meio do serviço Connect.

É possível interagir com os clusters diretamente pelo gateway usando ferramentas de linha de comando que aceitam um kubeconfig, como kubectl. Também é fácil aproveitar o gateway com seus pipelines de versão e outras automações de DevOps. Veja um exemplo de como fazer isso no nosso tutorial Como integrar ao Cloud Build.

Também é possível usar o serviço Connect para se conectar a clusters registrados fora do Google Cloud com sua identidade do Google Cloud no Console do Google Cloud. Para fazer isso, siga as instruções em Como fazer login em um cluster no Console do Google Cloud.

Como funciona

Veja o fluxo que um usuário ou serviço típico (como um pipeline de CI/CD) cumpre para usar o gateway do Connect depois que a autenticação e a autorização apropriadas são configuradas. Para instruções mais detalhadas sobre os usuários, consulte nosso guia de uso.

  1. O usuário ou serviço descobre clusters listando recursos de assinatura da frota com a Google Cloud CLI.

    gcloud container fleet memberships list

  2. O usuário ou serviço busca o kubeconfig específico do gateway do Connect necessário para alcançar o cluster selecionado usando a Google Cloud CLI.

    gcloud container fleet memberships get-credentials membership-name

    Se você já sabe usar a CLI gcloud com o GKE, é semelhante à execução de gcloud container clusters get-credentials usando a conta do Google Cloud. Isso permite, se houver autorização, acessar qualquer cluster registrado e se conectar na frota do projeto.

  3. O usuário ou serviço executa os comandos como faria normalmente com kubectl ou client-go, usando o arquivo kubeconfig baixado.

    1. O usuário/serviço é autenticado pelo gateway do Connect e a autorização é verificada para garantir que tenha permissão para usar o gateway.
    2. A solicitação é encaminhada por meio do serviço do Connect e do agente do Connect para o servidor correspondente da API Kubernetes.
    3. O servidor da API Kubernetes autoriza a solicitação, que exige que o agente do Connect esteja autorizado a personificar o usuário ou serviço e que o usuário ou serviço esteja autorizado a executar a solicitação desejada.

Suporte do Grupo do Google

No fluxo padrão descrito na seção anterior, a solicitação do usuário é autorizada com base no ID individual. No entanto, em muitos casos é útil autorizar os usuários com base na assinatura do Grupos do Google. Autorizar com base na associação ao grupo significa que você não precisa configurar uma autorização separada para cada conta, simplificando o gerenciamento das políticas e facilitando a auditoria. Por exemplo, é fácil compartilhar o acesso ao cluster para uma equipe, eliminando a necessidade de adicionar/remover manualmente usuários individuais dos clusters quando eles ingressam ou saem da equipe. Em algumas configurações adicionais usando o GKE Identity Service, é possível configurar o gateway do Connect para receber as informações de assinatura do grupo do Google para o usuário.

Saiba mais sobre como esse recurso funciona e como configurá-lo em Configurar o gateway do Connect com o Grupos do Google.

Se você quiser usar esse recurso com clusters anexados ou outros ambientes de clusters do GKE, entre em contato com o Cloud Customer Care ou com a equipe de gateway do Connect.

Compatibilidade com identidade de terceiros

Além de trabalhar com usuários e grupos do Google Workspace, o gateway do Connect oferece compatibilidade com a autorização usando identidades de terceiros, como o Azure Active Directory e Okta. Usando a federação de identidade de colaboradores , é possível usar um provedor de identidade externo para autenticar e autorizar uma força de trabalho (um grupo de usuários, como funcionários, parceiros e prestadores de serviço) usando o Identity and Access Management para que os usuários possam acessar serviços do Google Cloud, como o gateway do Connect. Com algumas configurações adicionais usando o serviço de identidade do GKE, é possível configurar o gateway do Connect para receber informações de associação a grupos de terceiros para usuários.

O recurso de identidade de terceiros do gateway do Connect é compatível com o GKE no VMware e o GKE em Bare Metal a partir do Anthos 1.13 em diante. Para clusters anexados, esse recurso está disponível no GKE Enterprise 1.16 e nas versões mais recentes.

Saiba mais sobre como esse recurso funciona e como fazer a configuração dele em Configurar o gateway do Connect com identidades de terceiros.

Se preferir, configure a autenticação de terceiros usando o serviço de identidade do GKE, seguindo as instruções na documentação.

Latência

A latência total de uma solicitação por meio do gateway pode ser dividida em duas partes: o RTT (tempo de retorno) do serviço de gateway do Connect para o agente do Connect e o tempo de execução da solicitação dentro do cluster. A latência extra trazida pelo RTT é de p95<500 ms e p99<1s. Observe que a maioria dos comandos kubectl executa uma série de solicitações diferentes, cada uma exigindo uma ida e volta, antes de renderizar uma resposta para o usuário.

A seguir