Sobre clusters privados

Nesta página, você vê como os clusters particulares funcionam no Google Kubernetes Engine (GKE). Você também aprende a criar clusters particulares.

Os clusters particulares usam nós que não têm endereços IP externos. Isso significa que os clientes na Internet não podem se conectar aos endereços IP dos nós. Clusters particulares são ideais para cargas de trabalho que, por exemplo, exigem acesso controlado devido a regulamentos de privacidade e segurança de dados.

Os clusters particulares estão disponíveis nos modos Standard ou Autopilot.

Arquitetura de clusters particulares

Ao contrário de um cluster público, um cluster particular tem um endpoint interno do plano de controle e um endpoint externo do plano de controle.

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

Arquitetura de cluster particular

Confira a seguir os principais componentes de um cluster particular:

  • Plano de controle: o plano de controle tem um endpoint interno para comunicação interna do cluster e um externo. É possível desativar o endpoint externo.

  • Nós: os nós usam apenas endereços IP internos, isolando-os da Internet pública.

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

  • Acesso privado do Google: é ativado na sub-rede do cluster e permite que os nós com endereços IP internos alcancem APIs e serviços essenciais do Google Cloud sem precisar de endereços IP públicos. Por exemplo, o Acesso privado do Google é necessário para que clusters particulares acessem imagens de contêiner pelo Artifact Registry e enviem registros para o Cloud Logging. O Acesso privado do Google é ativado por padrão em clusters particulares, exceto nos clusters de VPC compartilhada, que exigem ativação manual.

O plano de controle em clusters particulares

Todos os clusters 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 do Google. Um cluster regional tem várias réplicas do plano de controle, cada uma executada na própria VM.

Em clusters particulares, a rede VPC do plano de controle está conectada à rede VPC do cluster com o Peering de rede VPC. A rede VPC contém os nós do cluster, e a rede VPC do Google Cloud gerenciada pelo Google contém o plano de controle do cluster.

O tráfego entre os nós e o plano de controle é totalmente roteado usando endereços IP internos. Se você usar o peering de rede VPC para conectar a rede VPC do cluster a uma terceira rede, a terceira rede não alcançará recursos na rede VPC do plano de controle. Isso ocorre porque o peering de rede VPC é compatível apenas com a comunicação entre redes com peering direto, e a terceira rede não pode fazer peering com a rede do plano de controle. Para mais informações, consulte Restrições de peering de rede VPC.

Endpoints em clusters particulares

O plano de controle de um cluster particular tem um endpoint interno e um externo.

O endpoint interno é um endereço IP interno na rede VPC do plano de controle. Em um cluster particular, os nós sempre se comunicam com o endpoint particular do plano de controle. Dependendo da sua configuração, é possível gerenciar o cluster com ferramentas que também se conectam ao endpoint particular, como a kubectl. Qualquer VM que use a mesma sub-rede que seu cluster particular também pode acessar o endpoint interno.

O endpoint externo é o endereço IP externo do plano de controle. Por padrão, ferramentas como kubectl se comunicam com o plano de controle no endpoint externo.

Opções de acesso aos endpoints do cluster

É possível controlar o acesso aos endpoints usando uma das seguintes configurações:

  • Acesso ao endpoint externo desativado: essa é a opção mais segura, porque evita todo o acesso de Internet ao plano de controle. Ela é mais adequada se você configurou a rede local para se conectar ao Google Cloud usando o Cloud Interconnect ou o Cloud VPN.

    Se você desativar o acesso ao endpoint externo, será preciso configurar as redes autorizadas para o endpoint interno. Quando você não faz isso, só é possível se conectar ao endpoint interno pelos nós do cluster ou das VMs na mesma sub-rede que o cluster. Com essa configuração, as redes autorizadas precisam ser endereços IP internos.

  • Acesso ao endpoint externo ativado, redes autorizadas ativadas: nessa configuração, as redes autorizadas se aplicam ao endpoint externo do plano de controle. Essa é uma ótima opção se você precisa administrar o cluster por redes de origem que não estão conectadas à rede VPC do cluster usando o Cloud Interconnect ou o Cloud VPN.

  • Acesso ao endpoint externo ativado, redes autorizadas desativadas: é a opção padrão e também a menos restritiva. Como as redes autorizadas não estão ativadas, é possível administrar o cluster de qualquer endereço IP de origem, desde que faça a autenticação.

Reutilização do peering de rede VPC

Os clusters particulares criados após 15 de janeiro de 2020 usam uma conexão comum de peering de rede VPC se estiverem na mesma zona ou região do Google Cloud e usarem a mesma rede VPC.

  • Para clusters zonais: o primeiro cluster particular criado em uma zona gera uma nova conexão de peering de rede VPC com a rede VPC do cluster. Os clusters particulares zonais adicionais criados na mesma zona e rede VPC usam a mesma conexão de peering.

  • Para clusters regionais: o primeiro cluster particular criado em uma região gera uma nova conexão de peering de rede VPC com a rede VPC do cluster. Os clusters particulares regionais adicionais que você cria na mesma região e rede VPC usam a mesma conexão de peering.

Os clusters zonais e regionais usam as próprias conexões de peering, mesmo que estejam na mesma região. Exemplo:

  • Você cria dois ou mais clusters particulares zonais na zona us-east1-b e os configura para usar a mesma rede VPC. Os dois clusters usam a mesma conexão de peering.

  • Você cria dois ou mais clusters particulares regionais na região us-east1 e os configura para usar a mesma rede VPC dos clusters zonais. Esses clusters regionais usam a mesma conexão de peering de rede VPC entre si, mas precisarão de uma conexão de peering diferente para se comunicar com os clusters zonais.

Todos os clusters particulares criados antes de 15 de janeiro de 2020 usam uma conexão exclusiva de peering da rede VPC. Em outras palavras, esses clusters não usam a mesma conexão de peering com outros clusters zonais ou regionais. Para ativar a reutilização do peering de rede VPC nesses clusters, basta excluí-los e recriá-los. Fazer o upgrade de um cluster não faz com que ele reutilize uma conexão atual do peering da rede VPC.

Para verificar se o cluster particular está usando uma conexão comum de peering de rede VPC, consulte Verificar a reutilização do peering de VPC.

Restrições

  • Cada zona ou região aceitará no máximo 75 clusters particulares se a reutilização do peering de rede VPC estiver ativada.

    Por exemplo, é possível criar até 75 clusters particulares zonais em us-east1-b e outros 75 clusters particulares regionais em us-east1. Isso também se aplica se você estiver usando clusters particulares em uma rede VPC compartilhada.

  • O número máximo de conexões com uma rede VPC é 25, o que significa que só é possível criar clusters particulares usando 25 locais únicos.

  • A reutilização do peering de rede VPC se aplica somente a clusters no mesmo local. Por exemplo, clusters regionais na mesma região ou clusters zonais na mesma zona. No máximo, é possível ter quatro peerings de rede VPC por região se criar clusters regionais e clusters por zona em todas as zonas dessa região.

  • Para clusters criados antes de 15 de janeiro de 2020, cada rede VPC pode fazer peering com até 25 outras redes VPC, o que significa que para esses clusters há um limite de no máximo 25 clusters particulares por rede (supondo que peerings não são usados para outros fins).

A seguir