Este documento mostra como planear os seus endereços IP para uma instalação do Google Distributed Cloud que inclua clusters de utilizadores que usam o kubeception.
O que é o kubeception?
O termo kubeception é usado para transmitir a ideia de que um cluster do Kubernetes é usado para criar e gerir outros clusters do Kubernetes. No contexto do Google Distributed Cloud, o kubeception refere-se ao caso em que o plano de controlo de um cluster de utilizador é executado num ou mais nós num cluster de administrador.
Não recomendamos a utilização do kubeception. Em alternativa, recomendamos que use o Controlplane V2. Com o Controlplane V2, os nós do plano de controlo para o cluster de utilizadores estão no próprio cluster de utilizadores.
Antes de começar
Leia a vista geral do Google Distributed Cloud e a vista geral da instalação.
Exemplo de atribuição de endereço IP
Esta secção dá um exemplo de como atribuir endereços IP estáticos numa instalação que inclui estes elementos:
Uma estação de trabalho de administrador
Um cluster de administrador
Um cluster de utilizadores de alta disponibilidade (HA) com cinco nós de trabalho
Um cluster de utilizadores não de HA com quatro nós de trabalho
Administre nós de cluster
O cluster de administrador tem sete nós:
- Um nó que executa o plano de controlo para o cluster de administrador
- Dois nós que executam suplementos para o cluster de administrador
- Três nós que executam o plano de controlo para o cluster de utilizadores de HA
- Um nó que executa o plano de controlo para o cluster de utilizador não de HA
Balanceamento de carga
Para este exemplo, partimos do princípio de que os clusters estão a usar o balanceador de carga MetalLB. Este equilibrador de carga é executado nos nós do cluster, pelo que não são necessárias VMs adicionais para o equilíbrio de carga.
Sub-redes
Para este exemplo, suponha que cada cluster está na sua própria VLAN e que os clusters estão nestas sub-redes:
| VMs | Sub-rede | Gateway predefinido |
|---|---|---|
| Estação de trabalho de administrador e cluster de administrador | 172.16.20.0/24 | 172.16.20.1 |
| Cluster de utilizadores 1 | 172.16.21.0/24 | 172.16.21.1 |
| Cluster de utilizadores 2 | 172.16.22.0/24 | 172.16.22.1 |
O diagrama seguinte ilustra as três VLANs e sub-redes. Tenha em atenção que os IPs virtuais não são apresentados associados a nenhum nó específico num cluster. Isto deve-se ao facto de o balanceador de carga do MetalLB poder escolher que nó anuncia o VIP para um serviço individual. Por exemplo, no cluster de utilizadores 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 que o cluster do administrador: 172.16.20.0/24. Um endereço perto das moradas dos nós seria adequado para a estação de trabalho do administrador. Por exemplo, 172.16.20.20.
Exemplos de endereços IP: nós do cluster de administrador
Para um cluster de administrador com sete nós, tem de reservar oito endereços IP. A morada adicional é necessária porque é necessária durante a atualização, a atualização e a reparação automática do cluster. Por exemplo, pode reservar os seguintes endereços IP para nós no cluster de administração:
| Endereços IP para nós no cluster de administrador |
|---|
| 172.16.20.2 - 172.16.20.9 |
Exemplos de endereços IP: IPs virtuais na sub-rede do cluster de administrador
A tabela seguinte dá um exemplo de como pode designar IPs virtuais para serem configurados no equilibrador de carga para o cluster de administrador. Tenha em atenção que os IPs virtuais para os servidores da API Kubernetes dos clusters de utilizadores estão na sub-rede do cluster de administrador. Isto deve-se ao facto de, neste exemplo, o servidor da API Kubernetes para um cluster de utilizador ser executado num nó no cluster de administrador. Tenha em atenção que, nos ficheiros de configuração do cluster, o campo onde especifica o VIP para um servidor da API Kubernetes chama-se controlPlaneVIP:
| VIP | Endereço IP |
|---|---|
| VIP para o servidor da API Kubernetes do cluster de administrador | 172.16.20.30 |
| Suplementos VIP de cluster de administrador | 172.16.20.31 |
| VIP para o servidor da API Kubernetes do cluster de utilizador 1 | 172.16.20.32 |
| VIP para o servidor da API Kubernetes do cluster de utilizador 2 | 172.16.20.33 |
Exemplos de endereços IP: nós do cluster de utilizadores 1
Para um cluster de utilizadores com cinco nós, tem de reservar seis endereços IP. A morada adicional é necessária porque é necessária durante a atualização, a atualização e a reparação automática do cluster. Por exemplo, pode reservar os seguintes endereços IP para nós no cluster de utilizadores 1:
| Endereços IP para nós no cluster de utilizadores 1 |
|---|
| 172.16.21.2 - 172.16.21.7 |
Exemplo de endereços IP: VIPs na sub-rede do cluster de utilizadores 1
A tabela seguinte dá um exemplo de como pode designar IPs virtuais para serem configurados no equilibrador de carga para o cluster de utilizadores 1:
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP de entrada para o cluster de utilizadores 1 | Configurado no equilibrador de carga para o cluster de utilizadores 1 | 172.16.21.30 |
| VIPs de serviço para o cluster de utilizadores 1 | Dez moradas para serviços do tipo LoadBalancer.Configurado conforme necessário no equilibrador de carga para o cluster de utilizadores 1. Repare que este intervalo inclui o VIP de entrada. Este é um requisito para o balanceador de carga do MetalLB. |
172.16.21.30 - 172.16.21.39 |
Exemplos de endereços IP: nós do cluster de utilizadores 2
Para um cluster de utilizadores com quatro nós, tem de reservar cinco endereços IP. A morada adicional é necessária porque é necessária durante a atualização, a atualização e a reparação automática do cluster. Por exemplo, pode reservar os seguintes endereços IP para nós no cluster de utilizadores 2:
| Endereços IP para nós no cluster de utilizadores 2 |
|---|
| 172.16.22.2 - 172.16.22.6 |
Exemplo de endereços IP: VIPs na sub-rede do cluster de utilizadores 2
A tabela seguinte dá um exemplo de como pode designar IPs virtuais para serem configurados no equilibrador de carga para o cluster de utilizadores 2:
| VIP | Descrição | Endereço IP |
|---|---|---|
| VIP de entrada para o cluster de utilizadores 2 | Configurado no equilibrador de carga para o cluster de utilizadores 2 | 172.16.22.30 |
| VIPs de serviço para o cluster de utilizadores 2 | Dez moradas para serviços do tipo LoadBalancer.Configurado conforme necessário no equilibrador de carga para o cluster de utilizadores 2. Repare que este intervalo inclui o VIP de entrada. Este é um requisito para o balanceador de carga do MetalLB. |
172.16.22.30 - 172.16.22.39 |
Exemplos de endereços IP: pods e serviços
Antes de criar um cluster, tem de especificar um intervalo CIDR a usar para endereços IP de pods e outro intervalo CIDR a usar para os endereços ClusterIP de serviços Kubernetes.
Decida que intervalos CIDR 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 utilizadores 1 | 192.168.0.0/16 |
| Pods no cluster de utilizadores 2 | 192.168.0.0/16 |
| Serviços no cluster de administrador | 10.96.232.0/24 |
| Serviços no cluster de utilizadores 1 | 10.96.0.0/20 |
| Serviços no cluster de utilizadores 2 | 10.96.128.0/20 |
Os exemplos anteriores ilustram os seguintes pontos:
O intervalo CIDR de pods pode ser o mesmo para vários clusters.
Normalmente, precisa de mais pods do que serviços. Por isso, para um determinado cluster, é provável que queira um intervalo CIDR de pods maior do que o intervalo CIDR de serviços. O intervalo de pods de exemplo para um cluster de utilizadores é 192.168.0.0/16, que tem 2^(32-16) = 2^16 endereços. No entanto, um exemplo de intervalo de serviços para um cluster de utilizadores é 10.96.0.0/20, que tem apenas 2^(32-20) = 2^12 endereços.
Evite a sobreposição
Recomendamos que use intervalos CIDR não predefinidos para evitar a sobreposição com endereços IP acessíveis na sua rede. Os intervalos de serviços e de pods não podem sobrepor-se a nenhum endereço fora do cluster que quer alcançar a partir do interior do cluster.
Por exemplo, suponhamos que o seu intervalo de serviços é 10.96.232.0/24 e o seu intervalo de pods é 192.168.0.0/16 (192.168.0.1 - 192.168.255.254). Todo o tráfego enviado de um pod para um endereço num desses intervalos é tratado como tráfego no cluster e não chega a nenhum destino fora do cluster.
Em particular, os intervalos de serviços e pods não podem sobrepor-se a:
Endereços IP de nós em qualquer cluster
Endereços IP usados por máquinas do balanceador de carga
VIPs usados por nós do plano de controlo e balanceadores de carga
Endereços IP de servidores vCenter, servidores DNS e servidores NTP
Recomendamos que os intervalos de serviços e pods estejam no espaço de endereço privado da RFC 1918.
Segue-se um motivo para a recomendação de usar endereços RFC 1918. Suponhamos que o intervalo do seu pod ou serviço contém endereços IP externos. Qualquer tráfego enviado de um pod para um desses endereços externos é tratado como tráfego no cluster e não chega ao destino externo.
Servidor DNS e gateway predefinido
Antes de preencher os ficheiros de configuração, tem de saber o endereço IP de um servidor DNS que pode ser usado pela sua estação de trabalho de administrador e nós do cluster.
Também tem de saber o endereço IP do gateway predefinido para cada uma das suas sub-redes. Nos exemplos anteriores, o gateway predefinido para cada sub-rede é o primeiro endereço no intervalo. Por exemplo, na sub-rede do cluster de administrador, o gateway predefinido é apresentado como 172.16.20.1.
Mais informações
Faça a gestão dos endereços IP dos nós