Clusters Públicos e Privados
No Compute Cloud@Customer, antes de criar um cluster, decida que tipo de acesso de rede o cluster exige: se você precisa de um cluster público ou privado. Você não pode criar clusters públicos e privados em uma VCN.
A principal diferença entre um cluster público e um cluster privado é se você configura sub-redes públicas ou privadas para o ponto final da API do Kubernetes e o balanceador de carga de trabalho.
As sub-redes dos nós de trabalho e dos nós do plano de controle são sempre privadas.
Para os nós de trabalho e os nós de plano de controle, você pode configurar regras de roteamento que permitam acesso somente dentro da VCN ou fora da VCN. Esta documentação nomeia essas tabelas de roteamento como "vcn_private" e "nat_private". Você pode escolher uma dessas configurações de sub-rede privada para seus nós de trabalho e nós de plano de controle se o cluster é privado ou se o cluster é público.
Clusters Públicos
Um cluster público requer os seguintes recursos de rede:
-
Uma sub-rede pública para o ponto final da API Kubernetes. Consulte as instruções para criar uma sub-rede pública "control-plane-endpoint" em Criando uma Sub-rede de Plano de Controle do OKE (Sobreposição de Flannel) e Criando uma Sub-rede de Plano de Controle (Pod Nativo da VCN).
-
Uma sub-rede pública para o balanceador de carga de trabalho. Consulte as instruções para criar uma sub-rede pública "service-lb" em Criando uma Sub-rede do Worker Load Balancer (Sobreposição do Flannel) e Criando uma Sub-rede do Worker Load Balancer (Pod Nativo da VCN).
-
Um gateway de internet para conectar recursos de uma sub-rede pública à internet usando endereços IP públicos.
-
Um gateway NAT. Use um gateway NAT para acesso à internet de saída. Um gateway NAT conecta recursos de uma sub-rede privada à internet sem expor endereços IP privados.
-
Pelo menos três endereços IP públicos gratuitos. Endereços IP públicos gratuitos são necessários para o gateway NAT, o balanceador de carga do plano de controle e o balanceador de carga do trabalhador.
O balanceador de carga de trabalho requer um endereço IP público gratuito para expor aplicativos. O balanceador de carga do trabalhador pode exigir mais endereços IP públicos gratuitos, dependendo dos aplicativos em execução nos pods.
Clusters Privados
Se você criar várias VCNs do OKE, cada CIDR deverá ser exclusivo. CIDRs de diferentes VCNs para clusters privados não podem se sobrepor a nenhum outro CIDR da VCN ou a qualquer CIDR on-premises. Os endereços IP usados devem ser exclusivos de cada VCN.
Um cluster privado tem os seguintes recursos de rede:
-
Uma sub-rede privada para o ponto final da API Kubernetes. Consulte as instruções para criar uma sub-rede privada "control-plane-endpoint" em Criando uma Sub-rede do Plano de Controle do OKE (Sobreposição de Flannel) e Criando uma Sub-rede do Plano de Controle (Pod Nativo da VCN).
-
Uma sub-rede privada para o balanceador de carga de trabalho. Consulte as instruções para criar uma sub-rede privada "service-lb" em Criando uma Sub-rede do Balanceador de Carga do Plano de Controle do OKE (Sobreposição do Flannel) e Criando uma Sub-rede do Balanceador de Carga do Plano de Controle (Pod Nativo da VCN).
-
Uma tabela de roteamento sem regras de roteamento. Essa tabela de roteamento só permite acesso dentro da VCN.
-
(Opcional) Um LPG (Local Peering Gateway). Use um LPG para permitir acesso de outras VCNs. Um LPG permite o acesso ao cluster de uma instância em execução em outra VCN. Crie um LPG na VCN do OKE e um LPG em uma segunda VCN no Compute Cloud@Customer. Use o comando de conexão LPG para parear os dois LPGs. As VCNs pareadas podem estar em diferentes tenancies. Os CIDRs das VCNs pareadas não podem se sobrepor. Consulte Conectando VCNs por meio de um LPG (Local Peering Gateway).
Crie uma regra de roteamento para direcionar o tráfego de sub-rede da VCN de/para os LPGs e regras de segurança para permitir ou negar determinados tipos de tráfego. Consulte Criando uma VCN (Sobreposição de Canal) ou Criando uma VCN (Pod Nativo da VCN) para que a tabela de roteamento seja adicionada à VCN do OKE e à tabela de roteamento semelhante para adicionar à segunda VCN. Adicione a mesma regra de roteamento na segunda VCN, especificando o CIDR da VCN do OKE como destino.
Instale o OCI SDK e o
kubectlna instância na segunda VCN e conecte-se ao cluster privado. Consulte Criando um Arquivo de Configuração do Kubernetes. -
(Opcional) Um DRG (Dynamic Routing Gateway). Use um DRG para permitir o acesso pela rede local. Um DRG permite o tráfego entre a VCN do OKE e o espaço de endereço IP da rede local. Crie o DRG no compartimento da VCN do OKE e anexe a VCN do OKE a esse DRG. Consulte Conexão com a Rede Local por meio de um DRG (Dynamic Routing Gateway).
Crie uma regra de roteamento para direcionar o tráfego para o espaço de endereço IP da rede de data center local. Consulte Criando uma VCN (Sobreposição do Canal) ou Criando uma VCN (Pod Nativo da VCN) para que a tabela de roteamento seja adicionada à VCN do OKE.