Clusters particulares

Autopilot Padrão

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

Um cluster particular é um tipo de cluster nativo de VPC que depende apenas de endereços IP internos. Nós, pods e serviços em um cluster particular exigem intervalos exclusivos de endereços IP de sub-rede.

É possível criar e configurar clusters particulares no Standard ou no Autopilot.

Se você quiser fornecer acesso de saída à Internet para determinados nós particulares, use o Cloud NAT.

Arquitetura

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. Por exemplo, um serviço do tipo NodePort hospedado em um cluster particular fica inacessível para clientes externos porque o nó não tem um endereço IP público roteável pela Internet.

Ao contrário de um cluster público, um cluster particular tem um endpoint particular de plano de controle e um endpoint público de plano de controle. É necessário especificar um intervalo de endereços IP /28 exclusivo para o endpoint particular do plano de controle. Também é possível desativar o endpoint público do plano de controle.

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

Mesmo que os nós usem endereços IP internos, os clientes externos podem se conectar a serviços no cluster. Exemplo:

Um cliente externo com um endereço IP de origem na Internet poderá se conectar a um serviço externo do tipo LoadBalancer se você omitir spec.loadBalancerSourceRanges do manifesto do serviço.
É possível criar um serviço do tipo NodePort ou ClusterIP e expor o serviço a clientes externos usando uma entrada externa.

Como usar o Acesso privado do Google em clusters particulares

Para clusters particulares que usam redes VPC no mesmo projeto do cluster, o GKE garante que o Acesso privado do Google seja ativado na sub-rede usada pelo cluster particular quando você criar o cluster. Um administrador de rede, proprietário de projeto ou editor de um projeto de host de VPC compartilhada precisa ativar manualmente o Acesso privado do Google em sub-redes usadas por clusters particulares, se os clusters particulares forem criados em projetos de serviço de VPC compartilhada.

O Acesso privado do Google é ativado por padrão em clusters particulares, exceto para clusters de VPC compartilhada. É necessário ativar o Acesso privado do Google manualmente para clusters de VPC compartilhada.

O Acesso privado do Google fornece aos nós particulares e às cargas de trabalho acesso a APIs e serviços do Google Cloud pela rede particular do Google. 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 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á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, 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.

Reutilização do peering de rede VPC

Os clusters particulares criados após 15 de janeiro de 2020 usam uma conexão de peering de rede VPC comum se os clusters estiverem no mesmo local e usarem a mesma rede VPC. Nesse contexto, local refere-se exclusivamente a uma região ou zona do Google Cloud.

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ê criar na mesma região e rede VPC usam a mesma conexão de peering.
O GKE não usa um peering comum para clusters zonais e clusters regionais, mesmo quando os clusters zonais pertencem à mesma região que os clusters regionais.

Os exemplos a seguir esclarecem esse comportamento. Cada exemplo usa uma conexão de peering de rede VPC:

Dois ou mais clusters particulares zonais na zona us-east1-b usando a mesma rede VPCVPC.
Dois ou mais clusters particulares regionais na região us-east1 usando a mesma rede VPC.

No entanto, um ou mais clusters particulares zonais em us-east1-b e um ou mais clusters regionais em us-east1 usando a mesma rede VPC exigem duas conexões de peering de rede VPC.

Para mais informações sobre clusters e conexões particulares, consulte Reutilização de peering da rede VPC.

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.

Acesso aos endpoints do cluster

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

Acesso ao endpoint público 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 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. Com essa configuração, as redes autorizadas precisam ser endereços IP internos.

Importante: mesmo se você desativar o acesso ao endpoint público, o Google poderá usar o endpoint público do plano de controle para tarefas de gerenciamento de clusters, como manutenção programada e upgrades automáticos do plano de controle.
Acesso ao endpoint público ativado, redes autorizadas ativadas: nessa configuração, as redes autorizadas se aplicam ao endpoint público 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 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 Google Cloud	Selecione Ativar cluster nativo de VPC. Selecione Cluster particular. Limpar Acessar o plano de controle usando o endereço IP externo dele. A opção ativar redes autorizadas do plano de controle é ativada automaticamente.	Selecione Ativar cluster nativo de VPC. Selecione Cluster particular. Selecionar Acessar o plano de controle usando o endereço IP externo dele. Selecionar Ativar as redes autorizadas do plano de controle.	Selecione Ativar cluster nativo de VPC. Selecione Cluster particular. Selecionar Acessar o plano de controle usando o endereço IP externo dele. Desmarque Ativar redes autorizadas do plano de controle.
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 autorizadas do plano de controle	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. De outras VMs na rede VPC do cluster: outras VMs podem usar `kubectl` para se comunicar com o endpoint particular somente se um dos endereços IP internos delas estão incluídos na lista de redes autorizadas ou estão localizados na mesma sub-rede que os nós do cluster. Por padrão, somente VMs na mesma região podem alcançar o endpoint particular. Se você precisar alcançar o endpoint particular fora da região do cluster, configure o acesso global do endpoint particular do plano de controle. 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. De outras VMs na rede VPC do cluster: outras VMs podem usar `kubectl` para se comunicar com o endpoint particular somente se um dos endereços IP internos delas estão incluídos na lista de redes autorizadas ou estão localizados na mesma sub-rede que os nós do cluster. Por padrão, somente VMs na mesma região podem alcançar o endpoint particular. Se você precisar alcançar o endpoint particular fora da região do cluster, configure o acesso global do endpoint particular do plano de controle. 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: por padrão, somente VMs na mesma região podem alcançar o endpoint particular. Se você precisar alcançar o endpoint particular fora da região do cluster, configure o acesso global do endpoint particular do plano de controle. 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.