Nesta página, você aprende a criar um cluster particular do Google Kubernetes Engine (GKE), que é um tipo de cluster nativo de VPC. Em um cluster particular, os nós têm apenas endereços IP internos, o que significa que os nós e os pods estão isolados da Internet por padrão.
Os endereços IP internos para nós vêm do intervalo de endereços IP primário da sub-rede escolhida para o cluster. Os endereços IP do pod e os endereços IP de serviço vêm de dois intervalos de endereços IP secundários da mesma sub-rede. Consulte Intervalos de IP para clusters nativos de VPC para mais detalhes.
As versões 1.14.2 e posteriores do GKE são compatíveis com quaisquer intervalos de endereços IP internos, incluindo intervalos particulares (RFC 1918 e outros intervalos particulares) e intervalos particulares de endereços IP públicos. Consulte a documentação da VPC para ver uma lista de intervalos de endereços IP internos válidos.
Para mais informações sobre como os clusters particulares funcionam, consulte esta página.
Antes de começar
Familiarize-se com os requisitos, restrições e limitações antes de passar para a próxima etapa.
Antes de começar, veja se você realizou as seguintes tarefas:
- Verifique se você ativou a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Verifique se o SDK do Cloud está instalado.
Defina as configurações padrão da gcloud
usando um dos métodos a seguir:
- Use
gcloud init
se quiser orientações para definir os padrões. - Use
gcloud config
para definir individualmente a região, a zona e o ID do projeto.
Como usar o gcloud init
Se você receber o erro One of [--zone, --region] must be supplied: Please specify
location
, conclua esta seção.
-
Execute
gcloud init
e siga as instruções:gcloud init
Se você estiver usando SSH em um servidor remoto, utilize a sinalização
--console-only
para impedir que o comando inicie um navegador:gcloud init --console-only
-
Siga as instruções para autorizar a
gcloud
a usar sua conta do Google Cloud. - Crie uma nova configuração ou selecione uma atual.
- Escolha um projeto do Google Cloud.
- Escolha uma zona padrão do Compute Engine para clusters zonais ou uma região para clusters regionais ou do Autopilot.
Como usar o gcloud config
- Defina o ID do projeto padrão:
gcloud config set project PROJECT_ID
- Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
gcloud config set compute/zone COMPUTE_ZONE
- Se você estiver trabalhando com clusters do Autopilot ou regionais, defina a região do Compute padrão:
gcloud config set compute/region COMPUTE_REGION
- Atualize
gcloud
para a versão mais recente:gcloud components update
- Verifique se você tem a permissão correta para criar clusters. Você precisa ser, no mínimo, um Administrador de clusters do Kubernetes Engine.
Acesso ao plano de controle
Em clusters particulares, o plano de controle (mestre) tem um endpoint particular e público. Há três combinações de configuração para controlar o acesso aos endpoints do cluster.
- Acesso ao endpoint público desativado: cria um cluster privado sem acesso de cliente ao endpoint público.
- Acesso ao endpoint público ativado, redes autorizadas ativadas: cria um cluster particular com acesso limitado ao endpoint público.
- Acesso ao endpoint público ativado, redes autorizadas desativadas: cria um cluster particular com acesso irrestrito ao endpoint público.
Consulte Acesso aos endpoints do cluster para obter uma visão geral das diferenças entre as opções de configuração acima.
Como criar um cluster privado sem acesso de cliente ao endpoint público
Nesta seção, você cria um cluster particular chamado private-cluster-0
que tem nós particulares e que não tem acesso de cliente ao endpoint público.
gcloud
Para clusters padrão, execute o seguinte comando:
gcloud container clusters create private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --enable-private-endpoint \ --master-ipv4-cidr 172.16.0.32/28
Para clusters do Autopilot, execute o seguinte comando:
gcloud container clusters create-auto private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-private-nodes \ --enable-private-endpoint
onde:
--create-subnetwork name=my-subnet-0
faz com que o GKE crie automaticamente uma sub-rede denominadamy-subnet-0
;--enable-master-authorized-networks
especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;--enable-ip-alias
torna o cluster nativo da VPC (não necessário para o Autopilot).--enable-private-nodes
indica que os nós do cluster não têm endereços IP externos;--enable-private-endpoint
indica que o cluster é gerenciado usando o endereço IP privado do endpoint da API do plano de controle.--master-ipv4-cidr 172.16.0.32/28
especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster. O uso de endereços IP internos não RFC 1918 é compatível.
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Clique em add_box Criar.
Na seção Padrão ou Autopilot, clique em Configurar.
Em Nome, insira
my-subnet-0
.Para clusters padrão, no painel de navegação, em Cluster, clique em Rede.
Selecione o botão de opção Cluster particular.
Desmarque a caixa de seleção Acessar mestre usando o endereço IP externo.
Opcional para o Autopilot: defina o Intervalo de IP principal como
172.16.0.32/28
.Deixe Rede e sub-rede do nó definidas como
default
. Dessa forma, o GKE gera uma sub-rede para o cluster.Clique em Criar.
API
Para criar um cluster com um plano de controle acessível publicamente, especifique o
campo enablePrivateEndpoint: true
no recurso privateClusterConfig
.
Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:
- O intervalo principal de
my-subnet-0
- O intervalo secundário usado para os pods
Por exemplo, suponha que você tenha criado uma VM no intervalo principal de my-subnet-0
.
Então, nessa VM, seria possível
configurar kubectl
para usar o endereço IP interno
do plano de controle.
Se você quiser acessar o plano de controle de fora do my-subnet-0
, precisará
autorizar pelo menos um intervalo de endereços a ter acesso ao endpoint particular.
Suponha que você tenha uma VM na rede padrão, na mesma região que seu cluster, mas não em my-subnet-0
.
Exemplo:
my-subnet-0
:10.0.0.0/22
- intervalo secundário de pods:
10.52.0.0/14
- endereço da VM:
10.128.0.3
Use o comando a seguir para autorizar a VM a acessar o plano de controle:
gcloud container clusters update private-cluster-0 \ --enable-master-authorized-networks \ --master-authorized-networks 10.128.0.3/32
Como criar um cluster privado com acesso limitado ao endpoint público
Ao criar um cluster privado usando essa configuração, é possível optar por usar uma sub-rede gerada automaticamente ou uma sub-rede personalizada.
Como usar uma sub-rede gerada automaticamente
Nesta seção, você cria um cluster particular chamado private-cluster-1
em que o GKE gerar automaticamente uma sub-rede para os nós do cluster.
Ela já tem o recurso “Acesso privado do Google” ativado. Na sub-rede, o GKE cria automaticamente dois intervalos secundários: um para os pods e outro para os serviços.
gcloud
Para clusters padrão, execute o seguinte comando:
gcloud container clusters create private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.0/28
Para clusters do Autopilot, execute o seguinte comando:
gcloud container clusters create-auto private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-private-nodes
onde:
--create-subnetwork name=my-subnet-1
faz com que o GKE crie automaticamente uma sub-rede denominadamy-subnet-1
;--enable-master-authorized-networks
especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;--enable-ip-alias
torna o cluster nativo da VPC (não necessário para o Autopilot).--enable-private-nodes
indica que os nós do cluster não têm endereços IP externos;--master-ipv4-cidr 172.16.0.0/28
especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster. O uso de endereços IP internos não RFC 1918 é compatível.
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Clique em add_box Criar.
Na seção Padrão ou Autopilot, clique em Configurar.
Em Nome, insira
my-subnet-1
.Para clusters padrão, no painel de navegação, em Cluster, clique em Rede.
Selecione o botão de opção Cluster particular.
Para criar um plano de controle que possa ser acessado por intervalos de IP externos autorizados, mantenha marcada a caixa de seleção Acessar mestre usando o endereço IP externo.
(Opcional para o Autopilot) defina o Intervalo de IP principal como
172.16.0.0/28
. Verifique se o intervalo não se sobrepõe a uma sub-rede que já existe na VPC ou no local.Deixe Rede e sub-rede do nó definidas como
default
. Dessa forma, o GKE gera uma sub-rede para o cluster.Marque a caixa de seleção Ativar redes mestres autorizadas.
Clique em Criar.
API
Especifique o campo privateClusterConfig
no recurso da API Cluster
:
{ "name": "private-cluster-1", ... "ipAllocationPolicy": { "createSubnetwork": true, }, ... "privateClusterConfig" { "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint "masterIpv4CidrBlock": string # CIDR block for the cluster control plane "privateEndpoint": string # Output only "publicEndpoint": string # Output only } }
Nesse momento, os únicos endereços IP que têm acesso ao plano de controle do cluster são estes:
- O intervalo principal de
my-subnet-1
- O intervalo secundário usado para os pods.
Imagine que você tem um grupo de máquinas fora da sua rede VPC, com endereços no intervalo 203.0.113.0/29
. Digite o comando abaixo para autorizar que essas máquinas acessem o endpoint público:
gcloud container clusters update private-cluster-1 \ --enable-master-authorized-networks \ --master-authorized-networks 203.0.113.0/29
Agora, estes são os únicos endereços IP que têm acesso ao plano de controle:
- O intervalo principal de
my-subnet-1
- O intervalo secundário usado para os pods
- Os intervalos autorizados, como
203.0.113.0/29
Como usar uma sub-rede personalizada
Nesta seção, você criará um cluster privado chamado private-cluster-2
, uma rede denominada my-net-0
, além de uma sub-rede chamada my-subnet-2
com o intervalo principal 192.168.0.0/20
para os nós do cluster. Sua sub-rede tem dois intervalos de endereços secundários: my-pods-1
para os endereços IP de pods e my-services-1
para os endereços IP de Service.
gcloud
Criar uma rede
Primeiro, crie uma rede para o cluster. O comando a seguir cria uma rede, my-net-0
:
gcloud compute networks create my-net-0 \ --subnet-mode custom
Criar uma sub-rede e intervalos secundários
Em seguida, crie uma sub-rede, my-subnet-2
, na rede my-net-0
, com intervalos secundários my-pods-2
para pods e my-services-2
para Services:
gcloud compute networks subnets create my-subnet-2 \ --network my-net-0\ --region us-central1 \ --range 192.168.0.0/20 \ --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \ --enable-private-ip-google-access
Criar um cluster particular
Agora, crie um cluster particular, private-cluster-1
, usando a rede, a sub-rede e os intervalos secundários criados.
Para clusters padrão, execute o seguinte comando:
gcloud container clusters create private-cluster-1 \ --zone us-central1-c \ --enable-master-authorized-networks \ --network my-net-0 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods-2 \ --services-secondary-range-name my-services-2 \ --enable-private-nodes \ --enable-ip-alias \ --master-ipv4-cidr 172.16.0.16/28 \ --no-enable-basic-auth \ --no-issue-client-certificate
Para clusters do Autopilot, execute o seguinte comando:
gcloud container clusters create-auto private-cluster-1 \ --region us-central1 \ --enable-master-authorized-networks \ --network my-net-0 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods-2 \ --services-secondary-range-name my-services-2 \ --enable-private-nodes
Console
Criar uma rede, sub-rede e intervalos secundários
Acesse a página "Redes VPC" no Console do Cloud
Clique em add_boxCriar rede VPC.
Em Nome, insira
my-net-0
.Certifique-se de que o Modo de criação da sub-rede esteja configurado como Personalizado.
Na caixa Nova sub-rede, para Nome, digite
my-subnet-2
.Na lista suspensa Região, selecione a região que você quer.
Em Intervalo de endereços IP, insira
192.168.0.0/20
.Clique em Criar um intervalo de IP secundário. Digite
my-services-1
em Nome do intervalo da sub-rede e10.0.32.0/20
em Intervalo de IP secundário.Clique em Adicionar intervalo de IP. Digite
my-pods-1
em Nome do intervalo da sub-rede e10.4.0.0/14
em Intervalo de IP secundário.Defina o Acesso privado do Google como Ativado.
Clique em Concluído.
Clique em Criar.
Criar um cluster particular
Crie um cluster particular que usa a sub-rede:
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Clique em add_box Criar.
Na seção Padrão ou Autopilot, clique em Configurar.
Em Nome, insira
private-cluster-2
.Para clusters padrão, no painel de navegação, em Cluster, clique em Rede.
Selecione o botão de opção Cluster particular.
Para criar um plano de controle que possa ser acessado por intervalos de IP externos autorizados, mantenha marcada a caixa de seleção Acessar mestre usando o endereço IP externo.
(Opcional para o Autopilot) defina o Intervalo de IP principal como
172.16.0.16/28
.Na lista suspensa Rede, selecione my-net-1.
Na lista suspensa Sub-rede de nós, selecione my-subnet-2.
Desmarque a caixa de seleção Criar intervalos secundários automaticamente.
Na lista suspensa Intervalo CIDR secundário do pod, selecione my-pods-1.
Na lista suspensa Serviços do intervalo CIDR secundário, selecione my-services-1.
Marque a caixa de seleção Ativar redes mestres autorizadas.
Clique em Criar.
Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:
- O intervalo principal de
my-subnet-2
- O intervalo secundário
my-pods-1
Suponha que você tenha um grupo de máquinas fora de my-net-0
que tenham endereços no intervalo 203.0.113.0/29
. Digite o comando abaixo para autorizar que essas máquinas acessem o endpoint público:
gcloud container clusters update private-cluster-1 \ --enable-master-authorized-networks \ --master-authorized-networks 203.0.113.0/29
Nesse momento, os únicos endereços IP que têm acesso ao plano de controle são estes:
- O intervalo principal de
my-subnet-2
- O intervalo secundário
my-pods-1
- Os intervalos autorizados, como
203.0.113.0/29
Como usar o Cloud Shell para acessar um cluster particular
O cluster particular que você criou no exercício anterior, private-cluster-1
,
tem um endpoint público e tem as redes autorizadas ativadas. Se você quiser
usar o Cloud Shell para acessar o cluster, é necessário adicionar
o endereço IP público do seu Cloud Shell à lista de redes autorizadas
do cluster.
Para fazer isso:
Na janela da linha de comando do Cloud Shell, use
dig
para encontrar o endereço IP externo do seu Cloud Shell:dig +short myip.opendns.com @resolver1.opendns.com
Adicione o endereço externo do seu Cloud Shell à lista de redes autorizadas do cluster:
gcloud container clusters update private-cluster-1 \ --zone us-central1-c \ --enable-master-authorized-networks \ --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
Substitua:
EXISTING_AUTH_NETS
: a lista atual de redes autorizadas. É possível encontrar suas redes autorizadas no console ou executando o seguinte comando:gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
SHELL_IP
: é o endereço IP externo do seu Cloud Shell.
Receba as credenciais para poder usar a
kubectl
para acessar o cluster:gcloud container clusters get-credentials private-cluster-1 \ --zone us-central1-a \ --project PROJECT_ID
Substitua
PROJECT_ID
pela ID do seu projeto.
Agora é possível usar a kubectl
no Cloud Shell para acessar seu cluster privado. Por exemplo:
kubectl get nodes
Como criar um cluster privado com acesso irrestrito ao endpoint público
Nesta seção, você cria um cluster privado em que qualquer endereço IP pode acessar o plano de controle.
gcloud
Para clusters padrão, execute o seguinte comando:
gcloud container clusters create private-cluster-2 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.32/28
Para clusters do Autopilot, execute o seguinte comando:
gcloud container clusters create-auto private-cluster-2 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-private-nodes
onde:
--create-subnetwork name=my-subnet-3
faz com que o GKE crie automaticamente uma sub-rede denominadamy-subnet-3
;--no-enable-master-authorized-networks
desativa redes autorizadas para o cluster;--enable-ip-alias
torna o cluster nativo da VPC (não necessário para o Autopilot).--enable-private-nodes
indica que os nós do cluster não têm endereços IP externos;--master-ipv4-cidr 172.16.0.32/28
especifica um intervalo de endereços IP internos para o plano de controle (opcional para o Autopilot). Essa configuração é permanente para esse cluster. O uso de endereços IP internos não RFC 1918 é compatível.
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Clique em add_box Criar.
Na seção Padrão ou Autopilot, clique em Configurar.
Em Nome, insira
private-cluster-2
.Para clusters padrão, no painel de navegação, em Cluster, clique em Rede.
Selecione a opção Cluster privado.
Mantenha a caixa de seleção Acessar mestre usando o endereço IP externo marcada.
(Opcional para o Autopilot) defina o Intervalo de IP principal como
172.16.0.32/28
.Deixe Rede e sub-rede do nó definidas como
default
. Dessa forma, o GKE gera uma sub-rede para o cluster.Desmarque a caixa de seleção Ativar redes mestres autorizadas.
Clique em Criar.
Outras configurações de cluster privado
Além das configurações anteriores, é possível executar clusters privados com as seguintes configurações.
Como conceder aos nós privados acesso à Internet de saída
Para fornecer acesso à Internet de saída para seus nós privados, é possível usar o Cloud NAT ou gerenciar seu próprio gateway NAT.
Como criar um cluster privado em uma rede VPC compartilhada
Para saber como criar um cluster privado em uma rede VPC compartilhada, consulte a documentação da VPC compartilhada.
Como implantar um aplicativo de contêiner do Windows Server em um cluster privado
Para saber como implantar um aplicativo de contêiner do Windows Server em um cluster particular, consulte a documentação do pool de nós do Windows.
Como acessar o endpoint privado do plano de controle globalmente
O endpoint particular do plano de controle é implementado por um balanceador de carga TCP/UDP interno na rede VPC do plano de controle. Clientes internos ou conectados por meio de túneis do Cloud VPN e anexos da VLAN do Cloud Interconnect podem acessar balanceadores de carga TCP/UDP internos.
Por padrão, esses clientes precisam estar localizados na mesma região do balanceador de carga.
Quando você ativa o acesso global do plano de controle, o balanceador de carga TCP/UDP interno é acessível globalmente: as VMs cliente e sistemas locais podem se conectar ao endpoint particular do plano de controle, sujeito à configuração de redes autorizadas, em qualquer região.
Para mais informações sobre os balanceadores de carga TCP/UDP internos e o acesso global, consulte Balanceadores de carga internos e redes conectadas.
Como ativar o acesso global do endpoint particular do plano de controle
Esta seção se aplica somente a clusters criados no modo padrão.
Por padrão, o acesso global não é ativado para o endpoint privado do plano de
controle quando você cria um cluster privado. Para ativar o acesso global do plano de
controle, use gcloud
ou o Console do Google Cloud.
gcloud
Adicione a sinalização enable-master-global-access
para criar um cluster particular com
acesso global ao endpoint particular do plano de controle ativado:
gcloud container clusters create CLUSTER_NAME \
--enable-private-nodes \
--enable-ip-alias \
--master-ipv4-cidr=172.16.16.0/28 \
--enable-master-global-access
Também é possível ativar o acesso global ao endpoint particular do plano de controle para um cluster particular atual:
gcloud container clusters update CLUSTER_NAME \
--enable-master-global-access
Console
Para criar um novo cluster privado com acesso global do plano de controle ativado, execute as etapas a seguir:
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Clique em add_box Criar.
Digite um Nome.
No painel de navegação, em Cluster, clique em Rede.
Selecione Cluster particular.
Marque a caixa de seleção Acesso global do mestre.
Configure outros campos conforme você quiser.
Clique em Criar.
Para ativar o acesso global do plano de controle a um cluster particular atual, execute as seguintes etapas:
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Ao lado do cluster que você quer editar, clique em more_vert Ações e, depois, em edit Editar.
Na seção Rede, ao lado de Acesso global mestre, clique em edit Editar.
Na caixa de diálogo Editar acesso global mestre, marque a caixa de seleção Ativar acesso global mestre.
Clique em Salvar alterações.
Como verificar o acesso global do endpoint particular do plano de controle
Verifique se o acesso global ao endpoint privado do plano de controle está ativado executando o comando a seguir e observando a saída.
gcloud container clusters describe CLUSTER_NAME
A saída inclui uma seção privateClusterConfig
em que vê o status de masterGlobalAccessConfig
.
privateClusterConfig:
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.1.0/28
peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
privateEndpoint: 172.16.1.2
publicEndpoint: 34.68.128.12
masterGlobalAccessConfig:
enabled: true
Como se conectar ao endpoint privado do plano de controle a partir de redes locais
Ao criar um cluster privado do GKE
e desativar o endpoint público do plano de controle, ainda é possível se conectar ao
endpoint privado do plano de controle a partir de uma rede local usando ferramentas como
kubectl
. Nesta seção, descrevemos os requisitos de rede necessários para
acessar o endpoint particular do plano de controle em uma rede local.
O diagrama a seguir mostra um caminho de roteamento entre uma rede no local e os nós do plano de controle do GKE:
Para se conectar ao endpoint privado de um plano de controle da rede local, conclua as tarefas a seguir:
Identifique o peering entre a rede VPC do cluster e a rede VPC do plano de controle:
gcloud container clusters describe CLUSTER_NAME
A saída desse comando inclui o campo
privateClusterConfig.peeringName
do cluster. Esse é o nome do peering entre seu cluster e a rede VPC do plano de controle. Exemplo:privateClusterConfig: enablePrivateNodes: true masterIpv4CidrBlock: 172.16.1.0/28 peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer privateEndpoint: 172.16.1.2 publicEndpoint: 34.68.128.12
Configurar sua rede VPC para exportar as rotas personalizadas na relação de peering para a rede VPC do plano de controle. A rede VPC do plano de controle já está configurada para importar rotas personalizadas. Isso fornece um caminho para que o plano de controle envie pacotes de volta para recursos locais.
Atualize a conexão de peering, permitindo a exportação de rotas personalizadas, para a conexão de peering identificada na etapa anterior.
Para fornecer um caminho para o tráfego da sua rede local para a rede VPC do plano de controle, siga um destes procedimentos:
Para o Cloud Interconnect e o Cloud VPN: anuncie o intervalo CIDR do plano de controle usando uma divulgação de rota personalizada do Cloud Router. Se o acesso global do plano de controle estiver desativado, essa divulgação de rota personalizada precisará estar em uma sessão do BGP de um Cloud Router na mesma região do cluster. Se o acesso global do plano de controle estiver ativado, será possível colocar essa divulgação de rota personalizada em um Cloud Router em qualquer região. Consulte Como divulgar intervalos de IP personalizados para mais informações.
Para um túnel de VPN clássica que não use o roteamento dinâmico: configure uma rota estática para o intervalo CIDR do plano de controle nos seus roteadores locais.
Considerações para divulgações de rotas locais
Os CIDRs que sua rede local divulga para o Cloud Routers na rede VPC do cluster precisam atender às seguintes condições:
Enquanto a VPC do cluster aceita uma rota padrão, a rede VPC do plano de controle sempre rejeita rotas com um destino
0.0.0.0/0
(uma rota padrão), porque a rede VPC do plano de controle já tem uma rota padrão local e a rota local sempre é considerada primeiro. Se o roteador local anunciar uma rota padrão na rede VPC, ele também precisará anunciar destinos locais específicos para que o plano de controle tenha um caminho de retorno para a rede local. Esses destinos mais específicos resultam em rotas dinâmicas personalizadas mais específicas na sua rede VPC. Essas rotas mais específicas são aceitas pela rede VPC do plano de controle por meio do peering da rede VPC.Quando a rede VPC do plano de controle aceita outras rotas amplas, elas interrompem a conectividade com os endereços IP públicos de APIs e serviços do Google. Como exemplo representante, não é permitido divulgar rotas com destinos
0.0.0.0/1
e128.0.0.0/1
. Consulte o ponto anterior para obter uma alternativa.Preste muita atenção aos limites do Cloud Router, especialmente o número máximo de destinos exclusivos para rotas aprendidas.
Como desativar a exportação de rota personalizada
Para desativar a exportação de rota personalizada da sua VPC:
gcloud compute networks peerings update PEERING_NAME --network VPC_NAME --no-export-custom-routes
Substitua:
PEERING_NAME
: o valor deprivateClusterConfig.peeringName
.VPC_NAME
: o nome da VPC.
Para encontrar o peeringName
, consulte a primeira etapa das instruções acima para ativar a exportação de rota personalizada.
Verifique se os nós não têm endereços IP externos
Depois de criar um cluster privado, verifique se os nós do cluster não têm endereços IP externos.
gcloud
Execute este comando:
kubectl get nodes --output wide
A coluna EXTERNAL-IP
da resposta está vazia:
STATUS ... VERSION EXTERNAL-IP OS-IMAGE ...
Ready v.8.7-gke.1 Container-Optimized OS from Google
Ready v1.8.7-gke.1 Container-Optimized OS from Google
Ready v1.8.7-gke.1 Container-Optimized OS from Google
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Na lista de clusters, clique no nome do cluster.
Na página Clusters, clique na guia Nós.
Em Pools de nós, clique no nome do pool.
Na página Detalhes do pool de nós, em Grupos de instâncias, clique no nome do grupo. Por exemplo,
gke-private-cluster-0-default- pool-5c5add1f-grp
.Na lista de instâncias, confirme se elas não têm endereços IP externos.
Como visualizar a sub-rede do cluster e os intervalos de endereços secundários
Depois de criar um cluster particular, você pode exibir os intervalos de endereços de sub-rede e secundários que você ou o GKE provisionaram para o cluster.
gcloud
Listar todas as sub-redes
Para listar as sub-redes na rede do cluster, execute o seguinte comando:
gcloud compute networks subnets list --network NETWORK_NAME
Substitua NETWORK_NAME
pela rede do cluster particular. Se você criou o cluster com uma sub-rede criada automaticamente, use default
.
Na saída do comando, localize o nome da sub-rede do cluster.
Visualizar sub-rede do cluster
Receba informações sobre a sub-rede criada automaticamente:
gcloud compute networks subnets describe SUBNET_NAME
Substitua SUBNET_NAME
pelo nome da subnet.
A resposta mostra o intervalo de endereços principal para nós (o primeiro campo ipCidrRange
) e os intervalos secundários para pods e Serviços (em secondaryIpRanges
):
...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
rangeName: gke-private-cluster-1-services-163e3c97
...
Console
Acesse a página "Redes VPC" no Console do Cloud.
Clique no nome da sub-rede. Por exemplo,
gke-private-cluster-0-subnet-163e3c97
.Em Intervalo de endereços IP, veja o intervalo de endereços principal da sub-rede. É o intervalo usado para nós.
Em Intervalos de IP secundários, veja o intervalo de endereços IP para pods e o intervalo para serviços.
Como ver os endpoints de um cluster privado
Para visualizar os endpoints de clusters privados, use a ferramenta de linha de comando gcloud
ou o Console do Cloud.
gcloud
Execute este comando:
gcloud container clusters describe CLUSTER_NAME
A saída mostra tanto o endpoint particular quanto o público:
...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Na lista de clusters, clique no nome do cluster.
Na guia Detalhes, em Princípios básicos do cluster, procure o campo Endpoint.
Como extrair imagens de contêiner de um registro de imagem
Em um cluster privado, o ambiente de execução de contêiner pode extrair imagens do Container Registry. No entanto, não é possível extrair imagens de qualquer outro registro de imagem de contêiner na Internet. Isso ocorre porque os nós em um cluster privado não têm endereços IP externos. Portanto, por padrão, eles não podem se comunicar com serviços fora da rede do Google.
Os nós de um cluster particular poderão se comunicar com os serviços do Google, como o Container Registry, se estiverem em uma sub-rede com o acesso privado do Google ativado.
Os comandos a seguir criam uma implantação que extrai uma imagem de amostra de um repositório do Container Registry pertencente ao Google:
kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0
Como adicionar regras de firewall para casos de uso específicos
Esta seção explica como adicionar uma regra de firewall a um cluster privado. Por padrão,
as regras de firewall restringem o plano de controle do cluster a apenas iniciar conexões TCP com os
nós nas portas 443
(HTTPS) e 10250
(kubelet). Para alguns recursos do Kubernetes, talvez seja necessário adicionar regras de firewall para permitir o acesso em outras portas.
Os recursos do Kubernetes que exigem regras de firewall adicionais incluem:
- Webhooks de admissão
- Servidores de API agregados
- Conversão de webhook
- Configuração de auditoria dinâmica
- Geralmente, qualquer API que tenha um campo ServiceReference requer regras de firewall adicionais.
Adicionar uma regra de firewall permite o tráfego do plano de controle do cluster para todos os itens a seguir:
- A porta especificada de cada nó (hostPort).
- a porta especificada de cada pod em execução nesses nós
- A porta especificada de cada Service em execução nesses nós
Para saber mais sobre as regras de firewall, consulte Regras de firewall na documentação do Cloud Load Balancing
Para adicionar uma regra de firewall a um cluster privado, você precisa registrar o bloco CIDR do plano de controle do cluster e o destino usado. Depois de registrá-la, é possível criar a regra.
Etapa 1: Ver o bloco CIDR do plano de controle
Você precisa do bloco CIDR do plano de controle do cluster para adicionar uma regra de firewall.
gcloud
Execute este comando:
gcloud container clusters describe CLUSTER_NAME
Substitua CLUSTER_NAME pelo nome do cluster privado.
Na saída do comando, anote o valor no campo masterIpv4CidrBlock.
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Na lista de clusters, clique no nome do cluster que você quer.
Na guia Detalhes, em Rede, anote o valor no campo Intervalo de endereços principal.
Etapa 2: Ver as regras de firewall atuais
É necessário especificar o destino (neste caso, os nós de destino) que as regras de firewall atuais do cluster usam.
gcloud
Execute este comando:
gcloud compute firewall-rules list \ --filter 'name~^gke-CLUSTER_NAME' \ --format 'table( name, network, direction, sourceRanges.list():label=SRC_RANGES, allowed[].map().firewall_rule().list():label=ALLOW, targetTags.list():label=TARGET_TAGS )'
Na saída do comando, anote o valor no campo Destinos.
Console
Acesse o menu Regras de firewall no Console do Cloud.
Em Filtrar tabela, insira
gke-CLUSTER_NAME
.
Nos resultados, anote o valor no campo Destinos.
Etapa 3: Adicionar uma regra de firewall
gcloud
Execute este comando:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \ --action ALLOW \ --direction INGRESS \ --source-ranges MASTER_CIDR_BLOCK \ --rules PROTOCOL:PORT \ --target-tags TARGET
Substitua:
FIREWALL_RULE_NAME
: o nome escolhido para a regra de firewall.MASTER_CIDR_BLOCK
: o bloco CIDR do plano de controle do cluster (masterIpv4CidrBlock
) coletado anteriormente;PROTOCOL:PORT
: é a porta desejada e o protocolo dela,tcp
ouudp
.TARGET
: é o valor de destino (Targets
) coletado anteriormente.
Console
Acesse o menu Regras de firewall no Console do Cloud.
Clique em add_boxCriar regra de firewall.
Em Nome, insira o nome desejado para a regra de firewall.
Na lista suspensa Rede, selecione a rede relevante.
Em Direção de tráfego, clique em Entrada.
Em Ação se houver correspondência, clique em Permitir.
Na lista suspensa Destinos, selecione Tags de destino especificadas.
Em Tags de destino, insira o valor de destino que você anotou anteriormente.
Na lista suspensa Filtro de origem, selecione Intervalos de IP.
Em Intervalos de IP de origem, insira o bloco CIDR do plano de controle do cluster.
Em Protocolos e portas, clique em Protocolos e portas especificados e marque a caixa de seleção do protocolo relevante (tcp ou udp{ /1}) e insira o número da porta no campo do protocolo.
Clique em Criar.
Como proteger um cluster privado com o VPC Service Controls
Para proteger ainda mais os clusters privados do GKE, use o VPC Service Controls.
O VPC Service Controls protege ainda mais os clusters privados do GKE para reduzir o risco de exportação de dados. Ao usá-lo, é possível adicionar projetos a perímetros de serviço. Isso protege recursos e serviços contra solicitações que vêm de fora desses perímetros.
Para saber mais sobre os perímetros de serviço, consulte a página Configuração do perímetro de serviço na documentação do VPC Service Controls.
Se você usa o Container Registry com o cluster privado do GKE, é necessário realizar outras tarefas para usar esse cluster com o VPC Service Controls. Para mais informações, consulte a página Como configurar o Container Registry para clusters particulares do GKE.
Reutilização de peering de VPC
Todos os clusters particulares criados após 15 de janeiro de 2020 reutilizam as conexões do peering da rede VPC.
Todos os clusters particulares criados antes de 15 de janeiro de 2020 usam uma conexão exclusiva de peering da rede VPC. Cada rede VPC faz 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 os peerings não estejam sendo usados para outros fins.
Este recurso não é compatível com versões anteriores. Para ativar a reutilização do peering da rede VPC em clusters particulares mais antigos, é possível excluir um cluster e recriá-lo. Fazer o upgrade de um cluster não faz com que ele reutilize uma conexão atual do peering da rede VPC.
Cada local será compatível com até 75 clusters particulares se eles tiverem a reutilização de peering de VPC ativada. Zonas e regiões são tratadas como locais separados.
Por exemplo, é possível criar até 75 clusters particulares zonais em us-east1-a
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.
É possível verificar se o cluster particular reutiliza as conexões do peering de VPC.
gcloud
gcloud container clusters describe CLUSTER_NAME \ --zone=ZONE_NAME \ --format="value(privateClusterConfig.peeringName)"
Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n
. Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer
.
Console
Verifique a linha de Peering de VPC na página de detalhes do cluster. Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n
.
Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer
.
Como fazer a limpeza
Depois de concluir as tarefas nesta página, siga estas etapas para remover os recursos e evitar cobranças indesejadas na conta:
Excluir os clusters
gcloud
gcloud container clusters delete -q private-cluster-0 private-cluster-1
Console
Acesse o menu do Google Kubernetes Engine no Console do Cloud.
Selecione cada cluster.
Clique em deleteExcluir.
Excluir a rede
gcloud
gcloud compute networks delete net-0
Console
Acesse a página "Redes VPC" no Console do Cloud
Na lista de redes, clique em
net-0
.Na página Detalhes da rede, clique em deleteExcluir rede VPC.
Na caixa de diálogo Excluir uma rede, clique em Excluir.
Requisitos, restrições e limitações
Os clusters particulares têm os seguintes requisitos:
- É necessário que um cluster privado seja um cluster nativo de VPC com o recurso de intervalos IP de alias ativado. Os clusters nativos de VPC são ativados por padrão para novos clusters. Clusters nativos de VPC não são compatíveis com redes legadas.
Clusters privados têm as seguintes restrições:
- Não é possível converter um cluster não particular em um cluster particular.
- Para clusters que executam versões anteriores à 1.16.9 ou versões entre
a 1.17.0 e a 1.17.4, o plano de controle do cluster não pode ser acessado a partir de CIDRs
172.17.0.0/16
. - Para clusters executando versões anteriores à 1.14.4, um plano de controle do cluster, nó,
pod ou intervalo de IP do serviço não pode se sobrepor a
172.17.0.0/16
. - Quando você usa
172.17.0.0/16
para seu intervalo de IP do plano de controle, não é possível usar esse intervalo para endereços IP de nós, pods ou serviços. Essa restrição se aplica a clusters zonais que executam a versão 1.14.4 ou mais recentes, e a clusters regionais que executam as versões 1.16.9, 1.17.0 ou 1.17.4 e posteriores. - Excluir o peering de VPC entre o plano de controle do cluster e os nós, excluir as regras de firewall que permitem o tráfego de entrada do plano de controle do cluster para nós na porta 10250 ou excluir a rota padrão para o gateway de Internet padrão faz com que o cluster privado pare de funcionar. Para que um cluster privado apareça novamente após a exclusão da rota padrão, você precisa provisionar o VIP restrito estaticamente.
- É possível adicionar até 50 redes autorizadas (blocos CIDR permitidos) em um projeto. Para mais informações, consulte Adicionar uma rede autorizada a um cluster.
Clusters privados têm as seguintes limitações:
- O tamanho do bloco RFC 1918 do plano de controle do cluster precisa ser
/28
. - O GKE é capaz de detectar a sobreposição com o bloco de endereços do plano de controle do cluster, mas não consegue detectar a sobreposição dentro de uma rede VPC compartilhada.
- Todos os nós em um cluster particular são criados sem um IP público. Eles têm acesso limitado às APIs e aos serviços do Google. Para fornecer acesso à Internet de saída para seus nós particulares, é possível usar o Cloud NAT ou gerenciar seu próprio gateway NAT. Para permitir que os nós se comuniquem com as APIs e os serviços do Google, ative o Acesso privado do Google na sua sub-rede.
- Todos os clusters particulares criados antes de 15 de janeiro de 2020 têm um limite de no máximo 25 clusters por rede, supondo que os peerings não estejam sendo usados para outros fins. Consulte reutilização de peering de VPC para mais informações.
- Cada cluster particular requer uma rota de peering entre sua VPC e a do Google, mas apenas uma operação de peering pode acontecer por vez. Se você tentar criar vários clusters particulares ao mesmo tempo, a criação do cluster poderá expirar. Para evitar isso, crie novos clusters particulares em série para que as rotas de peering da VPC já existam para cada cluster particular subsequente. A tentativa de criar um único cluster privado também poderá expirar se houver operações em execução na VPC.
- Se você expandir o intervalo de IP principal de uma sub-rede para acomodar nós adicionais, será necessário adicionar o intervalo de endereços IP primário expandido da sub-rede à lista de redes mestres autorizadas do cluster. Se você não fizer isso, as regras de firewall de permissão de entrada relevantes para o mestre não serão atualizadas, e novos nós criados no espaço de endereço IP expandido não poderão se registrar no mestre. Isso pode levar a uma interrupção em que novos nós são continuamente excluídos e substituídos. Essa interrupção pode ocorrer ao executar upgrades de pool de nós ou quando os nós são substituídos automaticamente devido a falhas de sondagem de ativação.
Solução de problemas
Veja nas seções a seguir como resolver problemas comuns relacionados a clusters particulares.
Cluster se sobrepõe a um peering ativo
- Sintomas
- A tentativa de criar um cluster privado retorna um erro como
Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.
. - Causas possíveis
- Você escolheu um CIDR de plano de controle sobreposto.
- Resolução
- Exclua e recrie o cluster usando um CIDR de plano de controle diferente.
Não é possível acessar o cluster
- Sintomas
- Depois de criar um cluster privado, a tentativa de executar comandos
kubectl
no cluster retorna um erro, comoUnable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out
ouUnable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout
. - Causas possíveis
- A
kubectl
é incapaz de se comunicar com o plano de controle do cluster. - Resolução
Você precisa adicionar redes autorizadas ao cluster para permitir conexões com o plano de controle do cluster de sua rede.
Certifique-se de que o acesso global do endpoint particular do plano de controle esteja ativado se os clientes estiverem usando o comando
kubectl
de uma região diferente do cluster. Consulte Como acessar o endpoint particular do plano de controle globalmente para mais informações.
Não é possível criar o cluster devido à sinalização omitida
- Sintomas
gcloud container clusters create
retorna um erro comoCannot specify --enable-private-endpoint without --enable-private-nodes.
- Causas possíveis
- Você não especificou uma sinalização necessária.
- Resolução
- Especifique as sinalizações necessárias. Não é possível ativar um endpoint particular para o plano de controle do cluster sem ativar também os nós particulares.
Não é possível criar o cluster devido à sobreposição do bloco CIDR IPv4
- Sintomas
gcloud container clusters create
retorna um erro comoThe given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
- Causas possíveis
- Você especificou um bloco CIDR do plano de controle que se sobrepõe a uma sub-rede na VPC.
- Resolução
- Especifique um bloco para
--master-ipv4-cidr
CIDR para que não se sobreponha a uma sub-rede atual.
Não é possível criar uma sub-rede
- Sintomas
- Quando você tenta criar um cluster particular com uma sub-rede automática ou tenta criar uma sub-rede personalizada, pode encontrar o seguinte erro:
An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
- Causas possíveis
- O intervalo CIDR do plano de controle especificado se sobrepõe a outro intervalo de IPs no cluster. Isso também pode ocorrer se você tiver excluído recentemente um cluster particular e estiver tentando criar um novo usando o mesmo CIDR do plano de controle.
- Resolução
- Tente usar um intervalo CIDR diferente.
Não é possível extrair a imagem do Hub Docker público
- Sintomas
- Um pod em execução no cluster exibe um aviso em
kubectl describe
, comoFailed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
. - Causas possíveis
- Os nós no cluster particular não têm endereços IP externos. Portanto, eles não atendem aos requisitos de acesso à Internet. No entanto, os nós poderão acessar serviços e APIs do Google, incluindo o Container Registry, se você tiver ativado o Acesso privado do Google e atender aos requisitos de rede.
- Resolução
Use uma das seguintes soluções:
Copie as imagens no seu cluster privado do Docker Hub para o Container Registry. Consulte Como migrar contêineres de um registro de terceiros para mais informações.
Use
mirror.gcr.io
, que armazena em cache cópias de imagens acessadas com frequência no Docker Hub. Para mais informações, consulte Como extrair imagens armazenadas em cache do Docker Hub.Se você precisar extrair imagens do Docker Hub ou de outro repositório público, use o Cloud NAT ou um proxy baseado em instância que seja o destino de uma rota
0.0.0.0/0
estática.
Solicitação de API que aciona o tempo limite do webhook de admissão
- Sintomas
Uma solicitação de API que aciona um webhook de admissão configurada para usar um serviço com um targetPort diferente de 443 expira, fazendo com que a solicitação falhe:
Error from server (Timeout): request did not complete within requested timeout 30s
- Causas possíveis
Por padrão, o firewall não permite conexões TCP com nós, exceto nas portas 443 (HTTPS) e 10250 (kubelet). Um webhook de admissão que tentará se comunicar com um pod em uma porta diferente da 443 falhará se não houver uma regra de firewall personalizada que permita o tráfego.
- Resolução
Adicione uma regra de firewall para o caso de uso específico.
A seguir
- Leia a visão geral da rede GKE.
- Aprenda a criar clusters nativos de VPC.
- Saiba mais sobre o peering de VPC.