Este documento mostra como planear os seus endereços IP para uma instalação do Google Distributed Cloud.
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 de alta disponibilidade (HA)
Um cluster de utilizadores de HA com cinco nós de trabalho
Um cluster de utilizadores não de HA com quatro nós de trabalho
Neste exemplo, os clusters de utilizadores têm o Controlplane V2 ativado. Com o Controlplane V2, os nós do plano de controlo de um cluster de utilizador estão no próprio cluster de utilizador.
Se não quiser ativar o Controlplane V2 para os seus clusters de utilizadores, consulte o artigo Planeie os seus endereços IP (kubeception). O termo kubeception refere-se ao caso em que o plano de controlo de um cluster de utilizador é executado num ou mais nós no cluster de administrador. Não recomendamos a utilização do kubeception. Recomendamos que ative o Controlplane V2.
Administre nós de cluster
Um cluster de administrador tem três nós, cada um dos quais executa componentes do plano de controlo.
Balanceamento de carga
Para este exemplo, partimos do princípio de que os clusters estão a usar o balanceador de carga MetalLB. Este balanceador de carga é executado nos nós do cluster, pelo que não são necessárias VMs adicionais para o balanceamento 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
O cluster de administrador neste exemplo tem três nós, pelo que tem de definir três endereços IP. Por exemplo, pode reservar os seguintes endereços IP para nós no cluster de administração:
| Cluster de administrador | Endereços IP |
|---|---|
| Cluster de administrador de HA | 172.16.20.2 - 172.16.20.4 |
Exemplos de endereços IP: VIP para o cluster de administrador
Tem de reservar um IP virtual para o servidor da API Kubernetes do cluster de administrador.
Tenha em atenção que, no ficheiro de configuração do cluster, o campo para este IP virtual chama-se
controlPlaneVIP. Por exemplo, pode reservar o seguinte IP virtual 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 |
Tenha em atenção que, para clusters de administrador de HA, o controlPlaneVIP tem de estar na mesma VLAN que os IPs dos nós do plano de controlo especificados em network.controlPlaneIPBlock.
Exemplos de endereços IP: nós do cluster de utilizadores 1
Para um cluster de utilizadores com oito nós, tem de reservar nove 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.10 |
Exemplos de endereços IP: IPs virtuais para o 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 para o servidor da API Kubernetes do cluster de utilizador 1 | Configurado no equilibrador de carga para o cluster de utilizadores 1 | 172.16.21.30 |
| VIP de entrada para o cluster de utilizadores 1 | Configurado no equilibrador de carga para o cluster de utilizadores 1 | 172.16.21.31 |
| 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.31 - 172.16.21.40 |
Tenha em atenção que o VIP para o servidor da API Kubernetes é especificado em loadBalancer.vips.controlPlaneVIP do ficheiro de configuração do cluster. Quando o ControlPlane V2 está ativado, o controlPlaneVIP tem de estar na mesma VLAN que os IPs dos nós do plano de controlo especificados em network.controlPlaneIPBlock.
Exemplos de endereços IP: nós do cluster de utilizadores 2
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 2:
| Endereços IP para nós no cluster de utilizadores 2 |
|---|
| 172.16.22.2 - 172.16.22.7 |
Exemplos de endereços IP: VIPs para o 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 para o servidor da API Kubernetes para o cluster de utilizadores 2 | Configurado no equilibrador de carga para o cluster de utilizadores 2 | 172.16.22.30 |
| VIP de entrada para o cluster de utilizadores 2 | Configurado no equilibrador de carga para o cluster de utilizadores 2 | 172.16.22.31 |
| 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.31 - 172.16.22.40 |
Tenha em atenção que o VIP para o servidor da API Kubernetes é especificado em loadBalancer.vips.controlPlaneVIP do ficheiro de configuração do cluster. Quando o ControlPlane V2 está ativado, o controlPlaneVIP tem de estar na mesma VLAN que os IPs dos nós do plano de controlo especificados em network.controlPlaneIPBlock.
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 administração 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