Neste documento, mostramos como planejar os endereços IP para uma instalação de clusters do Anthos no VMware (GKE On-Prem).
Antes de começar
Leia a visão geral dos clusters do Anthos 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
Um cluster de usuário de alta disponibilidade (HA, na sigla em inglês) com cinco nós de trabalho
Um cluster de usuário sem HA com quatro nós de trabalho
Nós do cluster de administrador
O cluster de administrador tem os seguintes nós:
- Um nó que executa o plano de controle para o cluster de administrador
- Dois nós que executam complementos para o cluster de administrador
- Três nós que executam o plano de controle do cluster de usuário HA
- Um nó que executa o plano de controle do cluster de usuário sem HA
- Um nó temporário que será usado durante o upgrade, a atualização e o reparo automático
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
A tabela a seguir mostra um exemplo de como endereços IP podem ser usados para os nós no cluster de administrador. A tabela mostra um nó extra: admin-vm-8. O extra é necessário durante o upgrade, a atualização e o reparo automático do cluster. Para mais informações, consulte Gerenciar endereços IP de nós.
| Nome do host da VM | Descrição | Endereço IP |
|---|---|---|
| admin-vm-1 | Nó do plano de controle do cluster do administrador | 172.16.20.2 |
| admin-vm-2 | Nó do complemento do cluster de administrador | 172.16.20.3 |
| admin-vm-3 | Nó do complemento do cluster de administrador | 172.16.20.4 |
| admin-vm-4 | Nó do plano de controle para o cluster de usuário 1. Este nó está no cluster de administrador. |
172.16.20.5 |
| admin-vm-5 | Nó do plano de controle para o cluster de usuário 1. Este nó está no cluster de administrador. |
172.16.20.6 |
| admin-vm-6 | Nó do plano de controle para o cluster de usuário 1. Este nó está no cluster de administrador. |
172.16.20.7 |
| admin-vm-7 | Nó do plano de controle para o cluster de usuário 2 Esse nó está no cluster de administrador. |
172.16.20.8 |
| admin-vm-8 | 172.16.20.9 |
Exemplo de endereços IP: VIPs na sub-rede do cluster de administrador
A tabela a seguir mostra um exemplo de como é possível designar VIPs para
configuração no balanceador de carga do cluster de administrador. Os VIPs
para os servidores da API Kubernetes dos clusters de usuário precisam estar na sub-rede do cluster
de administrador. Isso ocorre porque o servidor da API Kubernetes para um cluster de usuário é executado em um
nó no cluster de administrador. Nos arquivos de configuração do cluster, o
campo em que você especifica o VIP de um servidor da API Kubernetes é chamado de
controlPlaneVIP:
| VIP | Endereço IP |
|---|---|
| VIP para o servidor da API Kubernetes do cluster de administrador | 172.16.20.30 |
| VIP de complementos do cluster de administrador | 172.16.20.31 |
| VIP para o servidor da API Kubernetes do cluster de usuário 1 | 172.16.20.32 |
| VIP para o servidor da API Kubernetes do cluster de usuário 2 | 172.16.20.33 |
Exemplo de endereços IP: nós do cluster de usuário 1
A tabela a seguir mostra um exemplo de como endereços IP podem ser usados para os nós no cluster de usuário. A tabela mostra um nó extra: user-1-vm-6. O extra é necessário durante o upgrade, a atualização e o reparo automático do cluster. Para mais informações, consulte Gerenciar endereços IP de nós.
| Nome do host da VM | Descrição | Endereço IP |
|---|---|---|
| user-1-vm-1 | Nó de trabalho do cluster de usuário | 172.16.21.2 |
| user-1-vm-2 | Nó de trabalho do cluster de usuário | 172.16.21.3 |
| user-1-vm-3 | Nó de trabalho do cluster de usuário | 172.16.21.4 |
| user-1-vm-4 | Nó de trabalho do cluster de usuário | 172.16.21.5 |
| user-1-vm-5 | Nó de trabalho do cluster de usuário | 172.16.21.6 |
| user-1-vm-6 | 172.16.21.7 |
Exemplo de endereços IP: VIPs na sub-rede do 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 de entrada para o cluster de usuário 1 | Configurado no balanceador de carga para o cluster de usuário 1 | 172.16.21.30 |
| 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.30 - 172.16.21.39 |
Exemplo de endereços IP: nós do cluster de usuário 2
A tabela a seguir mostra um exemplo de como os endereços IP podem ser usados para os nós em user-cluster-2. A tabela mostra um nó extra: user-2-vm-5. O extra é necessário durante o upgrade, a atualização e o reparo automático do cluster. Para mais informações, consulte Gerenciar endereços IP de nós.
| Nome do host da VM | Descrição | Endereço IP |
|---|---|---|
| user-2-vm-1 | Nó de trabalho do cluster de usuário | 172.16.22.2 |
| user-2-vm-2 | Nó de trabalho do cluster de usuário | 172.16.22.3 |
| user-2-vm-3 | Nó de trabalho do cluster de usuário | 172.16.22.4 |
| user-2-vm-4 | Nó de trabalho do cluster de usuário | 172.16.22.5 |
| user-2-vm-5 | 172.16.22.6 |
Exemplo de endereços IP: VIPs na sub-rede do 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 de entrada para o cluster de usuário 2 | Configurado no balanceador de carga para o cluster de usuário 2 | 172.16.22.30 |
| 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.30 - 172.16.22.39 |
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.