Clusters particulares

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

Com os clusters particulares, você isola os nós, evitando a conectividade de entrada e de saída com a Internet pública. Esse isolamento é alcançado já que os nós têm apenas endereços IP internos.

Para fornecer acesso de saída à Internet para determinados nós particulares, use o Cloud NAT ou gerencie seu próprio gateway NAT.

Mesmo que os endereços IP do nó sejam particulares, os clientes externos podem acessar Serviços no cluster. Por exemplo, é possível criar um Serviço do tipo LoadBalancer em que os clientes externos chamam o endereço IP do balanceador de carga. Se preferir, é possível criar um Serviço do tipo NodePort e gerar uma Entrada. O GKE usa informações do Serviço e da Entrada para configurar um balanceador de carga HTTP(S). Depois, os clientes externos podem chamar o endereço IP externo do balanceador de carga HTTP(S).

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

Arquitetura de cluster particular

Como usar o Acesso privado do Google em clusters particulares

Por padrão, o Acesso privado do Google está ativado. Ele fornece aos nós particulares e às cargas de trabalho acesso de saída limitado a serviços e APIs do Google Cloud por meio da rede particular do Google. Por exemplo, com o acesso privado do Google, os nós particulares podem extrair imagens de contêiner do Container Registry e enviar registros ao Cloud Logging.

O plano de controle em clusters particulares

Todos os clusters do GKE têm um servidor da API Kubernetes gerenciado pelo plano de controle (mestre). O plano de controle é executado em uma VM que está em uma rede VPC em um projeto do Google. Um cluster regional tem vários planos de controle, e cada um deles é executado 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, enquanto outra rede VPC do Google Cloud inclui o plano de controle do seu cluster. A rede VPC do plano de controle está localizada em um projeto controlado pelo Google. O tráfego entre os nós e o plano de controle é totalmente roteado com endereços IP internos.

Reutilização do peering de rede VPC

Todos os clusters particulares recém-criados reutilizam automaticamente as conexões existentes de peering de rede VPC. O primeiro cluster particular zonal ou regional que você cria gera uma nova conexão de peering de rede VPC. Novos clusters particulares na mesma zona, região e rede podem usar o mesmo peering, sem a necessidade de criar mais conexões de peering de rede VPC. Por exemplo, se você criar dois clusters particulares de zona única na us-east1-b e três clusters particulares regionais na asia-east1, apenas duas conexões de peering serão geradas. No entanto, se você criar um cluster regional e um zonal na mesma região, como asia-east1 e asia-east1-a, duas diferentes conexões de peering serão geradas. É possível verificar se o cluster particular reutiliza as conexões.

Endpoints em clusters particulares

O plano de controle de um cluster particular tem um endpoint particular e outro público. O plano de controle de um cluster não particular tem apenas um endpoint público.

Endpoint particular
O endpoint particular é 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 configuração, é possível gerenciar o seu cluster com ferramentas como o kubectl, que também se conecta ao endpoint particular. Qualquer VM que use a mesma sub-rede que seu cluster particular também podem acessar o endpoint particular.
Endpoint público
Este é o endereço IP externo do plano de controle. Por padrão, ferramentas como kubectl se comunicam com o plano de controle no endpoint público. É possível controlar o acesso a esse endpoint usando redes autorizadas ou desativando o acesso ao endpoint público.

Por padrão, os clusters particulares padrão e de Autopilot usam endpoints do plano de controle público. É possível modificar essa configuração e especificar um endpoint particular.

Acesso aos endpoints do cluster

Use uma das configurações a seguir para controlar o nível de acesso aos endpoints:

  • Acesso ao endpoint público desativado: essa é a opção mais segura, porque evita todo o acesso de Internet ao plano de controle. É a escolha mais adequada se você configurou sua rede no local para se conectar ao Google Cloud usando o Cloud Interconnect e o Cloud VPN. Essas tecnologias conectam a rede da empresa à sua VPC sem que o tráfego tenha de passar pela Internet pública.

    Se você desativar o acesso ao endpoint público, será necessário configurar redes autorizadas no endpoint particular. Quando não faz isso, você só pode se conectar ao endpoint particular a partir dos nós do cluster ou das VMs que estejam na mesma sub-rede que o cluster. Além disso, as redes autorizadas precisam ser endereços IP internos.

  • Acesso ao endpoint público ativado, redes autorizadas ativadas: o uso de clusters particulares com redes autorizadas ativadas dá acesso restrito ao plano de controle a partir dos endereços IP de origem definidos por você. Essa é uma ótima opção se você não tem uma infraestrutura de VPN ou se tem usuários remotos ou filiais que se conectam pela Internet pública em vez da VPN corporativa, do Cloud Interconnect ou do Cloud VPN.

  • Acesso ao endpoint público ativado, redes autorizadas desativadas: é o padrão e também é a opção 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.

Veja na tabela a seguir um resumo das diferentes maneiras de acessar os endpoints:

Acesso ao endpoint público desativado Acesso ao endpoint público ativado,
redes autorizadas ativadas
Acesso ao endpoint público ativado,
redes autorizadas desativadas
Segurança Maior nível de acesso restrito ao plano de controle. O acesso de cliente ao endpoint público do plano de controle está bloqueado. O acesso ao plano de controle precisa partir de endereços IP internos. Os endereços IP internos e externos definidos por você têm acesso restrito ao plano de controle. Qualquer endereço IP tem acesso ao plano de controle.
Etapas de configuração detalhadas Como criar um cluster particular sem acesso de cliente ao endpoint público. Como criar um cluster particular com acesso limitado ao endpoint público. Como criar um cluster particular com acesso irrestrito ao endpoint público.
Opções de configuração do Console do Cloud
  1. Selecione Ativar cluster nativo de VPC.
  2. Selecione Cluster particular.
  3. Desmarque Acessar mestre usando o endereço IP externo.
    A opção Ativar redes mestres autorizadas é ativada automaticamente.
  1. Selecione Ativar cluster nativo de VPC.
  2. Selecione Cluster particular.
  3. Selecione Acessar mestre usando o endereço IP externo.
  4. Selecione Ativar redes mestres autorizadas.
  1. Selecione Ativar cluster nativo de VPC.
  2. Selecione Cluster particular.
  3. Selecione Acessar mestre usando o endereço IP externo.
  4. Desmarque Ativar redes mestres autorizadas.
Sinalizações gcloud de criação de cluster --enable-ip-alias
--enable-private-nodes
--enable-private-endpoint
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--no-enable-master-authorized-networks
Comunicação entre nós e o plano de controle

Os nós sempre entram em contato com o plano de controle usando o endpoint particular.

Comunicação de webhook entre nós e o servidor da API

Os webhooks que usam um serviço com um targetPort diferente de 443 precisam de uma regra de firewall para permitir o processo. Para mais informações, consulte Como adicionar regras de firewall para casos de uso específicos.

Redes mestres autorizadas

Necessárias para acessar o plano de controle a partir de endereços IP internos que não sejam nós e pods.

Não é necessário autorizar explicitamente o intervalo de nós do endereço IP interno. Os endereços no intervalo principal de endereços IP da sub-rede do cluster estão sempre autorizados a se comunicar com o endpoint particular.

Use --master-authorized-networks para especificar outros endereços IP internos que podem acessar o plano de controle. Não é possível incluir endereços IP externos na lista de redes autorizadas, porque o acesso ao endpoint público está desativado.

Necessárias para acessar o plano de controle a partir de endereços IP externos e internos que não sejam nós e pods.

Use --master-authorized-networks para especificar endereços IP externos e internos que não sejam nós e pods, mas que possam acessar o plano de controle.

Não utilizado.

Se você ativar o acesso ao endpoint público do plano de controle sem ativar as redes autorizadas, o acesso ao endpoint público do plano de controle não será restrito.

Acesso usando a kubectl

Pelos nós: sempre usa o endpoint particular. A kubectl precisa ser configurada para usar o endpoint particular.

A partir de outras VMs na rede VPC do cluster: outras VMs só poderão usar kubectl para se comunicar com o endpoint particular se estiverem na mesma região do cluster e os respectivos endereços IP internos estiverem incluídos na lista de redes autorizadas ou se estiverem localizados na mesma sub-rede que os nós do cluster. A kubectl precisa ser configurada para usar o endpoint particular.

A partir de endereços IP públicos: nunca.

Pelos nós: sempre usa o endpoint particular. A kubectl precisa ser configurada para usar o endpoint particular.

A partir de outras VMs na rede VPC do cluster: outras VMs só poderão usar kubectl para se comunicar com o endpoint particular se estiverem na mesma região do cluster e os respectivos endereços IP internos estiverem incluídos na lista de redes autorizadas ou se estiverem localizados na mesma sub-rede que os nós do cluster. A kubectl precisa ser configurada para usar o endpoint particular.

A partir de endereços IP públicos: máquinas com endereços IP públicos poderão usar kubectl para se comunicar com o endpoint público somente se os respectivos endereços IP públicos estiverem incluídos na lista de redes autorizadas. Isso inclui máquinas fora do Google Cloud e das VMs do Google Cloud com endereços IP externos.

Pelos nós: sempre usa o endpoint particular. A kubectl precisa ser configurada para usar o endpoint particular.

De outras VMs na rede VPC do cluster: outras VMs só poderão usar a kubectl para se comunicar com o endpoint particular se estiverem na mesma região do cluster. A kubectl precisa ser configurada para usar o endpoint particular.

A partir de endereços IP públicos: qualquer máquina com um endereço IP público pode usar a kubectl para se comunicar com o endpoint público. Isso inclui máquinas fora do Google Cloud e das VMs do Google Cloud com endereços IP externos.

A seguir