Este documento dá um exemplo de como atribuir endereços IP para um cluster de administrador de alta disponibilidade (HA) e dois clusters de utilizadores de HA.
Antes de começar
Para saber mais sobre clusters de administrador, clusters de utilizadores e alta disponibilidade, consulte o artigo Escolher um modelo de implementação.
Exemplo de atribuição de endereço IP
Esta secção dá um exemplo de como atribuir endereços IP numa instalação que inclui estes elementos:
Endereços IP para nós de cluster
Endereços IP para pods
Endereços IP do cluster para serviços
Endereços IP virtuais (VIPs) para os planos de controlo e os proxies de entrada
VIPs a serem usados como endereços IP externos para serviços
Administre nós de cluster
O cluster de administrador neste exemplo tem três nós. Cada nó executa componentes do plano de controlo.
Nós do cluster de utilizadores
Neste exemplo, cada cluster de utilizadores tem seis nós: três nós do plano de controlo e três nós de trabalho.
Balanceamento de carga
Para este exemplo, partimos do princípio de que os clusters estão a usar o equilibrador de carga do MetalLB incluído. O balanceador de carga é executado nos nós do cluster, pelo que não são necessárias máquinas adicionais para o balanceamento de carga.
Sub-redes
Para este exemplo, suponha que cada cluster está no seu próprio domínio da camada 2 e que os clusters estão nestas sub-redes:
Cluster | Sub-rede | Gateway predefinido |
---|---|---|
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 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ó pode anunciar 172.16.21.52 e um nó diferente pode anunciar 172.16.21.53.
Exemplos de endereços IP: nós do cluster de administrador
Precisa de três endereços IP para os nós do cluster de administrador, que executam todos os componentes do plano de controlo. Por exemplo, pode usar os seguintes endereços IP para nós no cluster de administrador. As moradas neste exemplo são consecutivas, mas isso não é um requisito:
Endereços IP para nós no cluster de administrador |
---|
172.16.20.2 - 172.16.20.4 |
Exemplo de endereço IP: VIP do plano de controlo para o cluster de administrador
Tem de reservar um IP virtual para o servidor da API Kubernetes do cluster de administrador.
No ficheiro de configuração do cluster, isto chama-se controlPlaneVIP
.
Por exemplo, pode reservar o seguinte endereço IP para ser usado como o VIP do plano de controlo para o cluster de administrador:
VIP do plano de controlo para o cluster de administrador |
---|
172.16.20.50 |
Exemplos de endereços IP: nós do cluster de utilizadores 1
Exemplo: pode usar os seguintes endereços IP para três nós do plano de controlo e três nós de trabalho no cluster de utilizador 1. As moradas neste exemplo são consecutivas, mas isso não é um requisito:
Endereços IP para nós no cluster de utilizadores 1 |
---|
172.16.21.2 - 172.16.21.7 |
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. Os VIPs neste exemplo são consecutivos, mas isso não é um requisito:
VIP | Descrição | Endereço IP |
---|---|---|
VIP do plano de controlo para o cluster de utilizadores 1 | Configurado no equilibrador de carga para o cluster de utilizadores 1 | 172.16.21.50 |
VIP de entrada para o cluster de utilizadores 1 | Configurado no equilibrador de carga para o cluster de utilizadores 1 | 172.16.21.51 |
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 equilibrador de carga MetalLB. |
172.16.21.51 - 172.16.21.60 |
Exemplos de endereços IP: nós do cluster de utilizadores 2
Exemplo: pode usar os seguintes endereços IP para nós no cluster de utilizadores 2. As moradas neste exemplo são consecutivas, mas isso não é um requisito:
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. Os VIPs neste exemplo são consecutivos, mas isso não é um requisito.
VIP | Descrição | Endereço IP |
---|---|---|
VIP do plano de controlo para o cluster de utilizadores 2 | Configurado no equilibrador de carga para o cluster de utilizadores 2 | 172.16.22.50 |
VIP de entrada para o cluster de utilizadores 2 | Configurado no equilibrador de carga para o cluster de utilizadores 2 | 172.16.22.51 |
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.51 - 172.16.22.60 |
Exemplos de endereços IP: pods e serviços
Antes de criar um cluster, tem de especificar um intervalo de CIDR a usar para endereços IP de pods e outro intervalo de 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.0.0/20 |
Serviços no cluster de utilizadores 1 | 10.96.0.0/20 |
Serviços no cluster de utilizadores 2 | 10.96.0.0/20 |
Os exemplos anteriores ilustram os seguintes pontos:
O intervalo CIDR do pod pode ser o mesmo para vários clusters no modelo de rede predefinido, no modo isolado. Numa rede de modo simples, os pods têm de ter endereços IP exclusivos em todos os clusters. Para mais informações acerca dos modelos de rede que afetam os pods, consulte o artigo Modelos de rede de modo simples vs. isolado.
O intervalo CIDR do serviço 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
Tenha cuidado para que os seus intervalos CIDR não se sobreponham a endereços IP acessíveis na sua rede. Os intervalos de serviços e 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.0.0/20 e o seu intervalo de pods é 192.168.0.0/16. 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 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.
Variações na atribuição de endereços IP
O exemplo apresentado neste documento mostra uma forma de atribuir endereços IP para um tipo específico de instalação. No entanto, existem várias formas de instalar o Google Distributed Cloud, e a variação que escolher afeta a forma como planeia os seus endereços IP.
Por exemplo, pode decidir usar clusters não de HA ou ter os nós do cluster distribuídos por vários domínios da camada 2. Pode decidir usar uma rede no modo simples em vez de uma rede no modo isolado.
Para ver exemplos de como os endereços IP são especificados em ficheiros de configuração de clusters para vários tipos de instalações, consulte Exemplos de configuração de clusters
Para mais informações sobre como planear os seus endereços IP para diferentes tipos de instalações, consulte os seguintes documentos:
Modelo de rede de modo simples vs. modo isolado
No modo simples, os pods têm endereços únicos em mais do que um cluster. Ajuste os intervalos CIDR dos pods em conformidade.
Redes de pilha dupla IPv4/IPv6
Os nós, os pods e os serviços têm endereços IPv4 e IPv6. A rede IPv6 está no modo simples, mas a rede IPv4 pode estar no modo isolado ou no modo simples. Para redes no modo simples, tem de organizar a acessibilidade do agrupamento.
Implemente o modelo de rede de modo IPv4 simples
Tem de garantir a acessibilidade do pod. Faça com que os subconjuntos de intervalos de nós e de pods sejam de um intervalo maior.
Implemente o modelo de rede de modo simples com suporte de BGP
Precisa de endereços IP flutuantes para os altifalantes BGP no seu cluster e tem de especificar os endereços IP dos routers pares.
Configure balanceadores de carga agrupados com BGP
Precisa de endereços IP flutuantes para os altifalantes BGP no cluster e tem de especificar os endereços IP dos routers de pares.
Configure o gateway de conetividade de rede
Tem de especificar os endereços IP de pares e os endereços IP de túneis locais.