Sobre o Private Service Connect

Este documento apresenta uma visão geral do Private Service Connect em clusters do Google Kubernetes Engine (GKE). Antes de continuar a leitura, confira se você conhece as redes VPC e os conceitos básicos de rede, como endereços IP.

Visão geral

O Private Service Connect (PSC) faz parte da infraestrutura de rede do Google Cloud, que permite que seus clusters do GKE consumam de maneira segura e particular serviços hospedados no Google Cloud ou em ambientes locais, sem precisar exibir esses serviços publicamente. Com o PSC, Google Cloud atribui um endereço IP interno ao plano de controle para encaminhar solicitações à API de gerenciamento cluster do GKE, permitindo que você gerencie seus clusters sem que o tráfego passe pela Internet pública. O PSC oferece uma estrutura consistente que ajuda a conectar diferentes redes por meio de uma abordagem de rede de serviço e permite que produtores e consumidores de serviços se comuniquem usando endereços IP internos em uma VPC.

Em um cluster do GKE que usa a infraestrutura PSC, toda a comunicação entre o plano de controle do cluster e os nós ocorre de forma particular. Também é possível isolar o cluster nos níveis do plano de controle e do pool de nós sem precisar gerenciar configurações complexas de peering da VPC.

Benefícios dos clusters ativados com o Private Service Connect

Segurança: o PSC estabelece conexões particulares entre o plano de controle e os nós do cluster do GKE, mantendo o tráfego totalmente na rede do Google e longe da Internet pública. Isso minimiza o risco de acesso não autorizado.

Conectividade simplificada: em clusters de PSC, não é necessário gerenciar sub-redes específicas para o endpoint do plano de controle. O endpoint do PSC fica totalmente dentro da rede do cluster, eliminando a necessidade de configurações de rede complexas.

Escalonabilidade: é possível criar até 1.000 clusters ativados com PSC para atender a requisitos de recursos altos. Em contraste, só é possível criar até 75 clusters por zona ou região para clusters que usam o peering de rede VPC.

Configuração personalizável: o PSC permite controlar de forma independente o isolamento do plano de controle do cluster, dos pools de nós ou das cargas de trabalho, tornando os clusters mais escalonáveis e seguros. É possível configurar uma mistura de pools de nós particulares e públicos no cluster.

Flexibilidade: depois de criar o cluster, você pode mudar as configurações de isolamento a qualquer momento. É possível alternar entre o acesso público e privado ao plano de controle e mudar a acessibilidade do pool de nós e da carga de trabalho pela Internet sem precisar criar um novo cluster.

Limitações

O plano de controle tem um endpoint interno e um externo. O endpoint interno do plano de controle não oferece suporte a endereços IP internos em URLs de webhooks configurados. Se você tiver um webhook com um endereço IP interno no URL, siga estas etapas para reduzir essa incompatibilidade:

  1. Crie um serviço sem comando sem um seletor para gerenciar manualmente os endpoints para os quais esse serviço direciona o tráfego. O exemplo a seguir mostra um serviço com um webhook aguardando na porta 3000:

    apiVersion: v1
kind: Service
metadata:
  name: <service-name>
spec:
  clusterIP: None
  ports:
  - port: 3000
    targetPort: 3000

  2. Crie um endpoint correspondente para o destino necessário. Por exemplo, se o webhook usar o endereço IP interno 10.0.0.1 no URL, crie o seguinte endpoint:

    apiVersion: v1
kind: Endpoints
metadata:
  name: <service-name>
subsets:
- addresses:
  - ip: 10.0.0.1
  ports:
  - port: 3000

  3. Atualizar a configuração do webhook: na configuração do webhook, exclua o URL com o endereço IP interno e adicione o serviço que você criou na primeira etapa. Exemplo:

    ...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    service:
      name: <service-name>
      namespace: <namespace>
      path: "/validate"
      port: 3000

    No exemplo anterior, o webhook tem um caminho de /validate e escuta na porta 3000.

  4. Verificar o webhook: confirme se o webhook pode continuar recebendo solicitações do servidor da API e aprová-las, rejeitá-las ou modificá-las com base na lógica personalizada. Se você receber um erro ao verificar o webhook, talvez seja necessário criar um novo certificado e atualizar a configuração do webhook com os novos detalhes do certificado. Exemplo:

    ...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    ...
    caBundle: <new-certificate>
...

Arquitetura

O diagrama a seguir fornece uma visão geral da arquitetura de um cluster que usa PSC:

Arquitetura do Private Service Connect no GKE.
Figura Arquitetura do Private Service Connect

Confira a seguir os principais componentes de um cluster ativado com PSC:

Plano de controle: todos os cluster do GKE têm um servidor da API Kubernetes gerenciado pelo plano de controle. O plano de controle é executado em uma máquina virtual (VM) que está em uma rede VPC em um projeto gerenciado pelo Google. Um cluster regional tem várias réplicas do plano de controle, e cada uma delas é executada na própria VM.

O plano de controle tem um endpoint interno (endpoint do Private Service Connect) para comunicação interna do cluster e um endpoint externo. É possível desativar o endpoint externo. O tráfego entre os nós e o plano de controle é totalmente roteado usando endereços IP internos. Para saber mais sobre a configuração do cluster, consulte Verificar a configuração do plano de controle.

Rede VPC: é uma rede virtual em que você cria sub-redes com intervalos de endereços IP internos especificamente para os nós e pods do cluster.

Endpoint do Private Service Connect: é o endpoint interno no plano de controle do cluster que fica na rede VPC do seu projeto. O endpoint do PSC funciona como o ponto de entrada para acessar o plano de controle do cluster.

Anexo de serviço: é um recurso que estabelece uma conexão segura e particular entre sua rede VPC e a rede VPC do produtor. Como mostrado no diagrama anterior, o endpoint do PSC acessa o anexo de serviço por uma conexão privada e permite que o tráfego flua entre os nós e o plano de controle.

Como configurar o acesso ao cluster

Você tem várias opções para configurar o acesso ao plano de controle e ao nó em clusters com PSC. É possível mudar essas configurações a qualquer momento após a criação do cluster. Para configurar o acesso ao cluster, consulte Personalizar o isolamento de rede.

Controle o acesso ao plano de controle

  • Acesse o plano de controle usando apenas o endpoint baseado em DNS (recomendado). É possível autorizar solicitações para acessar o plano de controle criando políticas de permissão do IAM.

  • Acesse o plano de controle usando apenas endpoints baseados em IP. É possível usar os endpoints externos e internos do plano de controle ou desativar o endpoint externo para permitir apenas o acesso de endereços IP reservados pelo Google (para gerenciamento de clusters) e endereços IP internos do cluster do GKE.

    Se você estiver usando endereços IP, recomendamos o uso de redes autorizadas para restringir o acesso ao plano de controle do cluster. Com as redes autorizadas, também é possível bloquear o acesso ao plano de controle de Google Cloud VMs, Cloud Run ou funções do Cloud Run com IPs externos Google Cloud .

  • Acesse o plano de controle com endpoints baseados em DNS e IP.

Acesso ao nó do cluster

Com clusters com PSC ativado, é possível configurar clusters de modo misto. É possível configurar o cluster para ter nós com acesso interno ou externo. Você também pode mudar a configuração da rede de nós, dependendo do tipo de cluster usado:

  • Para clusters do Autopilot, é possível configurar algumas cargas de trabalho para serem executadas em nós particulares e outras em nós públicos. Por exemplo, você pode executar um conjunto de cargas de trabalho no cluster, em que algumas exigem acesso à Internet e outras não. É possível implantar uma carga de trabalho em um nó com endereçamento IP externo para garantir que apenas essas cargas de trabalho sejam acessíveis publicamente.

  • Para clusters padrão, é possível provisionar alguns dos nós com endereços IP internos, enquanto outros podem usar endereços IP externo.

Clusters com o Private Service Connect

Para verificar se o cluster usa o Private Service Connect, execute o comando gcloud container clusters describe. Se o cluster usar o Private Service Connect, o recurso privateClusterConfig terá estes valores:

  • O campo peeringName está vazio ou não existe.
  • O campo privateEndpoint tem um valor atribuído.

Para ativar o cluster com PSC, crie-o na versão 1.29 ou mais recente. Caso contrário, para as versões 1.28 e anteriores, crie o cluster sem ativar nós privados. É possível atualizar essa configuração e ativar nós privados após a criação do cluster.

A seguir