Neste documento, mostramos como planejar seus endereços IP para uma instalação do GKE no VMware.
Antes de começar
Leia a Visão geral do GKE no VMware e a visão geral da instalação.
Exemplo de alocação de endereço IP
Nesta seção, você verá um exemplo de como alocar endereços IP estáticos em uma instalação que inclui estes elementos:
Uma estação de trabalho de administrador
Um cluster de administrador de alta disponibilidade (HA, na sigla em inglês)
Um cluster de usuário de alta disponibilidade com cinco nós de trabalho
Um cluster de usuário sem HA com quatro nós de trabalho
Neste exemplo, os clusters de usuário têm o Controlplane V2 ativado. Com o Controlplane V2, os nós do plano de controle do cluster de usuário estão no próprio cluster de usuário.
Se você não quiser ativar o plano de controle V2 para os clusters de usuário, consulte Planejar seus endereços IP (kubeception). O termo kubeception se refere ao caso em que o plano de controle de um cluster de usuário é executado em um ou mais nós no cluster de administrador. Não recomendamos o uso do kubeception. Recomendamos ativar o plano de controle V2.
Nós do cluster de administrador
Um cluster de administrador tem três nós, cada um executando componentes do plano de controle.
Balanceamento de carga
Neste exemplo, suponha que os clusters estejam usando o balanceador de carga MetalLB. Esse balanceador de carga é executado nos nós do cluster. Portanto, nenhuma outra VM é necessária para o balanceamento de carga.
Sub-redes
Neste exemplo, suponha que cada cluster esteja na própria VLAN e os clusters estejam nestas sub-redes:
| VMs | Sub-rede | Gateway padrão |
|---|---|---|
| Estação de trabalho do administrador e cluster de administrador | 172.16.20.0/24 | 172.16.20.1 |
| Cluster de usuário 1 | 172.16.21.0/24 | 172.16.21.1 |
| Cluster de usuário 2 | 172.16.22.0/24 | 172.16.22.1 |
O diagrama a seguir ilustra as três VLANs e sub-redes. Os VIPs não são mostrados associados a um nó específico em um cluster. Isso ocorre porque o balanceador de carga do MetalLB pode escolher qual nó anuncia o VIP de um Serviço individual. Por exemplo, no cluster de usuário 1, um nó de trabalho pode anunciar 172.16.21.31, e um nó de trabalho diferente pode anunciar 172.16.21.32.
Exemplo de endereço IP: estação de trabalho do administrador
Neste exemplo, a estação de trabalho do administrador está na mesma sub-rede do cluster de administrador: 172.16.20.0/24. Um endereço próximo aos endereços do nó seria adequado para a estação de trabalho de administrador. Por exemplo: 172.16.20.20.
Exemplo de endereços IP: nós de cluster de administrador
O cluster de administrador neste exemplo tem três nós. Portanto, é necessário definir três endereços IP. Por exemplo, é possível reservar os seguintes endereços IP para nós no cluster de administrador:
| Cluster de administrador | Endereços IP |
|---|---|
| Cluster de administrador de alta disponibilidade | 172.16.20.2 - 172.16.20.4 |
Exemplo de endereços IP: VIPs para o cluster de administrador
Você precisa reservar um VIP para o servidor da API Kubernetes do cluster de administrador.
Observe que, no arquivo de configuração do cluster, o campo para esse VIP é chamado de
controlPlaneVIP. Por exemplo, é possível reservar o seguinte VIP para o
servidor da API Kubernetes do cluster de administrador:
| VIP | Endereço IP |
|---|---|
| VIP para o servidor da API Kubernetes do cluster de administrador | 172.16.20.30 |
Exemplo de endereços IP: nós do cluster de usuário 1
Para um cluster de usuário que tem oito nós, você precisa separar nove endereços IP. O endereço extra é necessário porque ele é usado durante o upgrade, a atualização e o reparo automático do cluster. Por exemplo, é possível separar os endereços IP a seguir para nós no cluster de usuário 1:
| Endereços IP para nós no cluster de usuário 1 |
|---|
| 172.16.21.2 - 172.16.21.10 |
Exemplos de endereços IP: VIPs para o cluster de usuário 1
A tabela a seguir mostra um exemplo de como designar VIPs para configuração no balanceador de carga para o cluster de usuário 1:
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP para o servidor da API Kubernetes do cluster de usuário 1 | Configurado no balanceador de carga para o cluster de usuário 1 | 172.16.21.30 |
| VIP de entrada para o cluster de usuário 1 | Configurado no balanceador de carga para o cluster de usuário 1 | 172.16.21.31 |
| VIPs de serviço para o cluster de usuário 1 | 10 endereços para serviços do tipo LoadBalancer.Configurado conforme necessário no balanceador de carga para o cluster de usuário 1. Esse intervalo inclui o VIP de entrada. Este é um requisito para o balanceador de carga do MetalLB. |
172.16.21.31 - 172.16.21.40 |
Exemplo de endereços IP: nós do cluster de usuário 2
Para um cluster de administrador com cinco nós, você precisa separar seis endereços IP. O endereço extra é necessário porque ele é usado durante o upgrade, a atualização e o reparo automático do cluster. Por exemplo, é possível separar os endereços IP a seguir para nós no cluster de usuário 2:
| Endereços IP para nós no cluster de usuário 2 |
|---|
| 172.16.22.2 - 172.16.22.7 |
Exemplos de endereços IP: VIPs para o cluster de usuário 2
A tabela a seguir mostra um exemplo de como designar VIPs para configuração no balanceador de carga para o cluster de usuário 2:
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP para o servidor da API Kubernetes para cluster de usuário 2 | Configurado no balanceador de carga para o cluster de usuário 2 | 172.16.22.30 |
| VIP de entrada para o cluster de usuário 2 | Configurado no balanceador de carga para o cluster de usuário 2 | 172.16.22.31 |
| VIPs de serviço para o cluster de usuário 2 | 10 endereços para serviços do tipo LoadBalancer.Configurado conforme necessário no balanceador de carga para o cluster de usuário 2. Esse intervalo inclui o VIP de entrada. Este é um requisito para o balanceador de carga do MetalLB. |
172.16.22.31 - 172.16.22.40 |
Exemplo de endereços IP: pods e serviços
Antes de criar um cluster, é preciso especificar um
intervalo de
CIDR a ser usado para endereços IP do pod e outro intervalo CIDR a ser usado para
os endereços ClusterIP de Serviços do Kubernetes.
Decida quais intervalos CIDR você quer usar para pods e serviços. Exemplo:
| Finalidade | Intervalo CIDR |
|---|---|
| Pods no cluster de administrador | 192.168.0.0/16 |
| Pods no cluster de usuário 1 | 192.168.0.0/16 |
| Pods no cluster de usuário 2 | 192.168.0.0/16 |
| Serviços no cluster de administrador | 10.96.232.0/24 |
| Serviços no cluster de usuário 1 | 10.96.0.0/20 |
| Serviços no cluster de usuário 2 | 10.96.128.0/20 |
Os exemplos anteriores ilustram esses pontos:
O intervalo CIDR do pod pode ser o mesmo para vários clusters.
Normalmente, você precisa de mais pods do que serviços. Portanto, para um determinado cluster, você provavelmente quer um intervalo CIDR de pod maior que o intervalo CIDR de serviço. O intervalo de exemplo de pod para um cluster de usuário é 192.168.0.0/16, que tem 2^(32-16) = 2^16 endereços. Mas o intervalo de Serviços de exemplo para um cluster de usuário é 10.96.0.0/20, que tem apenas 2^(32-20) = 2^12 endereços.
Evitar sobreposição
É recomendável usar intervalos CIDR não padrão para evitar a sobreposição com endereços IP acessíveis na sua rede. Os intervalos de serviços e pods não podem se sobrepor a nenhum endereço fora do cluster que você queira acessar de dentro dele.
Por exemplo, suponha que seu intervalo de serviço seja 10.96.232.0/24 e seu intervalo de pod seja 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Qualquer tráfego enviado de um pod para um endereço em qualquer um desses intervalos vai ser tratado como no tráfego no cluster e não vai atingir nenhum destino fora dele.
Os intervalos de serviços e pods não podem se sobrepor a:
Endereços IP de nós em qualquer cluster
Endereços IP usados por máquinas de balanceador de carga
VIPs usados por nós do plano de controle e balanceadores de carga
Endereços IP dos servidores vCenter, DNS e NTP
Recomendamos que os intervalos de serviços e pods estejam no espaço de endereço particular RFC 1918.
Veja um motivo por que recomendamos usar endereços RFC 1918. Suponha que o intervalo de pods ou de serviços contenha endereços IP externos. Qualquer tráfego enviado de um pod para um desses endereços externos será tratado como tráfego no cluster e não chegará ao destino externo.
Servidor DNS e gateway padrão
Antes de preencher os arquivos de configuração, é preciso saber o endereço IP de um servidor DNS que pode ser usado pela estação de trabalho do administrador e pelos nós do cluster.
Também é preciso saber o endereço IP do gateway padrão de cada uma das sub-redes. Nos exemplos anteriores, o gateway padrão de cada sub-rede é o primeiro endereço no intervalo. Por exemplo, na sub-rede do cluster de administrador, o gateway padrão é mostrado como 172.16.20.1.