Some or all of the information on this page might not apply to Trusted Cloud by S3NS. See Differences from Google Cloud for more details.

Esta página foi traduzida pela API Cloud Translation.

Acerca do Private Service Connect

Autopilot Padrão

Esta página oferece uma vista geral do Private Service Connect em clusters do Google Kubernetes Engine (GKE).

Esta página pressupõe que tem conhecimentos sobre o seguinte:

Noções básicas de redes, como o endereçamento IP
Redes VPC

Vista geral

O Private Service Connect (PSC) faz parte da infraestrutura de rede do Trusted Cloud by S3NS, que permite que os seus clusters do GKE consumam de forma segura e privada serviços alojados no Trusted Cloud by S3NS ou em ambientes no local, sem necessidade de expôr esses serviços publicamente. Com o PSC, Trusted Cloud by S3NS é atribuído um endereço IP interno ao plano de controlo para encaminhar pedidos para a API de gestão de clusters do GKE, o que lhe permite gerir os seus clusters sem que o tráfego passe pela Internet pública. O PSC oferece uma estrutura consistente que ajuda a ligar diferentes redes através de uma abordagem de rede de serviços e permite que os produtores e os consumidores de serviços comuniquem através de endereços IP internos a uma VPC.

Num cluster do GKE que usa a infraestrutura do PSC, toda a comunicação entre o plano de controlo do cluster e os nós ocorre de forma privada. Também pode isolar o cluster ao nível do plano de controlo e do conjunto de nós sem ter de gerir configurações complexas de interligação de VPCs.

Vantagens dos clusters ativados com o Private Service Connect

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

Conetividade simplificada: para clusters PSC, não tem de gerir sub-redes específicas para o ponto final do plano de controlo. O ponto final do PSC está localizado totalmente na rede do cluster, o que elimina a necessidade de configurações de rede complexas.

Escalabilidade: pode criar até 1000 clusters ativados com o PSC para cumprir requisitos de recursos elevados. Por outro lado, só pode 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-lhe controlar independentemente o isolamento do painel de controlo do cluster, dos conjuntos de nós ou das cargas de trabalho, tornando os seus clusters mais escaláveis e seguros. Pode configurar uma combinação de pools de nós privados e públicos no seu cluster.

Flexibilidade: depois de criar o cluster, pode alterar as definições de isolamento em qualquer altura. Pode alternar entre o acesso público e privado ao plano de controlo e alterar a acessibilidade do conjunto de nós e da carga de trabalho a partir da Internet sem ter de criar um novo cluster.

Limitações

O plano de controlo tem um ponto final interno e um ponto final externo. O ponto final interno do plano de controlo não suporta endereços IP internos em URLs para webhooks que configurar. Se tiver um webhook com um endereço IP interno no URL, pode mitigar esta incompatibilidade seguindo estes passos:

Crie um serviço sem cabeçalho sem um seletor para gerir manualmente os pontos finais para os quais este serviço direciona o tráfego. O exemplo seguinte mostra um serviço com um webhook a detetar na porta 3000:
```
apiVersion: v1
kind: Service
metadata:
  name: <service-name>
spec:
  clusterIP: None
  ports:
  - port: 3000
    targetPort: 3000
```
Crie um ponto final correspondente para o destino necessário. Por exemplo, se o seu webhook usar o endereço IP interno 10.0.0.1 no URL, pode criar o seguinte ponto final:
```
apiVersion: v1
kind: Endpoints
metadata:
  name: <service-name>
subsets:
- addresses:
  - ip: 10.0.0.1
  ports:
  - port: 3000
```
Atualize a configuração do webhook: na configuração do webhook, elimine o URL com o endereço IP interno e adicione o serviço que criou no primeiro passo. Por 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.
Valide o seu webhook: confirme que o seu webhook pode continuar a receber pedidos do servidor da API e pode aprovar, rejeitar ou modificar o pedido com base na lógica personalizada. Se receber um erro ao validar o webhook, pode ter de criar um novo certificado e, em seguida, atualizar a configuração do webhook com os novos detalhes do certificado. Por exemplo:
```
...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    ...
    caBundle: <new-certificate>
...
```

Arquitetura

O diagrama seguinte apresenta uma vista geral da arquitetura de um cluster que usa o PSC:

Seguem-se os componentes principais de um cluster ativado com PSC:

Plano de controlo: todos os clusters do GKE têm um servidor da API Kubernetes gerido pelo plano de controlo. O plano de controlo é executado numa máquina virtual (VM) que se encontra numa rede VPC num projeto gerido pela Google. Um cluster regional tem várias réplicas do plano de controlo, cada uma das quais é executada na sua própria VM.

O plano de controlo tem um ponto final interno (ponto final do Private Service Connect) para a comunicação interna do cluster e um ponto final externo. Pode optar por desativar o ponto final externo. O tráfego entre os nós e o plano de controlo é encaminhado inteiramente através de endereços IP internos. Para saber mais sobre a configuração do cluster, consulte o artigo Verifique a configuração do plano de controlo.

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

Ponto final do Private Service Connect: este é o ponto final interno no plano de controlo do cluster que reside na rede VPC do seu projeto. O ponto final do PSC funciona como o ponto de entrada para aceder ao plano de controlo do cluster.

Anexo de serviço: o anexo de serviço é um recurso que estabelece uma ligação segura e privada entre a sua rede da VPC e a rede da VPC do produtor. Conforme mostrado no diagrama anterior, o ponto final do PSC acede à associação de serviço através de uma ligação privada e permite o fluxo de tráfego entre os nós e o plano de controlo.

Configurar o acesso ao cluster

Tem várias opções para configurar o acesso ao plano de controlo e o acesso aos nós em clusters com PSC ativado. Pode alterar estas configurações em qualquer altura após a criação do cluster. Para configurar o acesso ao cluster, consulte o artigo Personalize o isolamento da rede.

Acesso ao plano de controlo

Aceder ao plano de controlo apenas através do ponto final baseado em DNS (recomendado). Pode autorizar pedidos de acesso ao plano de controlo criando políticas de autorização da IAM.
Aceder ao plano de controlo apenas através de pontos finais baseados em IP. Pode optar por usar os pontos finais externos e internos do plano de controlo ou desativar o ponto final externo para permitir apenas o acesso a partir de endereços IP reservados pela Google (para fins de gestão de clusters) e endereços IP internos de clusters do GKE.

Se estiver a usar endereços IP, recomendamos que use redes autorizadas para restringir o acesso ao plano de controlo do seu cluster. Com as redes autorizadas, também pode bloquear o acesso ao seu plano de controlo a partir de Trusted Cloud by S3NS VMs, do Cloud Run ou das funções do Cloud Run com origem em Trusted Cloud by S3NS IPs externos.
Aceda ao plano de controlo com o ponto final baseado em DNS e pontos finais baseados em IP.

Acesso ao nó do cluster

Com clusters ativados para PSC, pode configurar clusters de modo misto. Pode configurar o cluster para ter nós com acesso interno ou externo. Também pode alterar a configuração de rede do nó consoante o tipo de cluster que usa:

Para clusters do Autopilot, pode configurar algumas cargas de trabalho para serem executadas em nós privados e outras cargas de trabalho para serem executadas em nós públicos. Por exemplo, pode estar a executar uma combinação de cargas de trabalho no seu cluster em que algumas requerem acesso à Internet e outras não. Pode implementar uma carga de trabalho num nó com endereçamento IP externo para garantir que apenas essas cargas de trabalho são acessíveis publicamente.
Para clusters padrão, pode aprovisionar alguns dos seus nós com endereços IP internos, enquanto outros nós podem usar endereços IP externos.

Clusters com Private Service Connect

Para verificar se o cluster usa o Private Service Connect, execute o comando gcloud container clusters describe. Se o seu cluster usar o Private Service Connect, o recurso privateClusterConfig tem os seguintes valores:

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

Para ativar o cluster com o PSC, crie o cluster na versão 1.29 ou posterior. Caso contrário, para as versões 1.28 e anteriores, crie o cluster sem ativar os nós privados. Pode sempre atualizar esta definição e ativar os nós privados após a criação do cluster.

O que se segue?

Saiba como personalizar o isolamento da rede no GKE.