Neste documento, mostramos como planejar seus endereços IP para uma instalação do Google Distributed Cloud que inclui clusters de usuários que usam o kubeception.
O que é kubeception?
O termo kubeception é usado para transmitir a ideia de que um cluster do Kubernetes é usado para criar e gerenciar outros clusters do Kubernetes. No contexto do Google Distributed Cloud, "kubeception" se refere ao caso em que o plano de controle de um cluster de usuário é executado em um ou mais nós em um cluster de administrador.
Não recomendamos o uso do kubeception. Em vez disso, recomendamos usar o Controlplane V2. 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.
Antes de começar
Leia a Visão geral do Google Distributed Cloud 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 sete 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
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
Para um cluster de administrador com sete nós, você precisa separar oito 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 reservar os seguintes endereços IP para nós no cluster de administrador:
| Endereços IP para nós no cluster de administrador |
|---|
| 172.16.20.2 - 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 estão na sub-rede do cluster
de administrador. Isso porque, neste exemplo, o servidor da API Kubernetes para um cluster de usuário
é executado em um nó do cluster de administrador. Observe que, 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
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 1:
| Endereços IP para nós no cluster de usuário 1 |
|---|
| 172.16.21.2 - 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
Para um cluster de administrador com quatro nós, você precisa separar cinco 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.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 CIDR a ser usado para endereços IP de pods 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. Por 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ços particulares 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.