Gestione degli indirizzi GKE: ottimizzazione degli indirizzi IPv4

Questo documento fa parte di una serie destinata agli architetti della rete. La serie illustra le opzioni di gestione degli indirizzi Google Kubernetes Engine (GKE) disponibili per le organizzazioni con limiti di indirizzo IPv4.

La serie è composta dalle seguenti parti:

Questo documento descrive un processo per identificare i requisiti del blocco CIDR di GKE. Poi introduce un modello decisionale che ti aiuta a identificare quale soluzione è consigliata per ogni scenario specifico. Infine, il documento illustra le varie soluzioni, le descrive brevemente ed elenca i relativi vantaggi e svantaggi.

Identificazione dei requisiti per il blocco CIDR di GKE

In questa sezione puoi determinare le dimensioni dei blocchi CIDR per il tuo cluster. È fondamentale farlo correttamente perché non puoi modificare o espandere un blocco CIDR dopo aver creato il cluster.

Determinazione delle dimensioni del blocco CIDR del nodo

Segui questi passaggi per determinare la dimensione del blocco CIDR del nodo:

  1. Determina il numero massimo di nodi necessari nel cluster durante il suo ciclo di vita.

    Se puoi determinare questo numero, che dipende dalle applicazioni, dalla progettazione e dalle previsioni di crescita del cliente, utilizzalo come numero di nodi richiesto. Se non riesci a determinare il numero massimo di nodi necessari, utilizza un limite massimo di 5000 nodi.

  2. Determina i bit host necessari per tenere conto del numero richiesto di nodi.

    Quando conosci il numero di nodi richiesto, puoi utilizzare la tabella 1 per calcolare i bit host necessari per generare una netmask. Individua il numero di nodi richiesti nella colonna Nodi obbligatori. Per il passaggio successivo, utilizza il numero corrispondente nella colonna bit dell'host per i nodi.

    Nodi obbligatori Bit dell'host per i nodi
    1-4 3
    5-12 4
    13-28 5
    29-60 6
    61-124 7
    125-252 8
    253-508 9
    509-1020 10
    1021-2044 11
    2045-4092 12
    4093-8188 13

    Tabella 1. Bit necessari per gli indirizzi dei nodi.

  3. Genera una netmask di blocco CIDR, utilizzando il numero della colonna bit host per nodo che hai determinato nel passaggio precedente:

    32 – bit dell'host per i nodi = netmask del blocco CIDR del nodo

    La figura seguente mostra l'equazione in modo grafico.

    Netmask del blocco CIDR del nodo.

    Ad esempio, per un cluster da 5000 nodi, la tabella 1 mostra che alla netmask dei nodi sono necessari 13 bit host per i nodi. Per calcolare la netmask completa, sostituisci il numero di bit host per i nodi nell'equazione, 32 – 13 = 19. Il risultato è una netmask di /19.

Determinazione delle dimensioni del blocco CIDR del pod

Segui questi passaggi per determinare la dimensione del blocco CIDR del pod:

  1. Determina il numero massimo di pod per nodo necessari per il cluster nel corso della sua durata.

    Se puoi determinare questo numero, che dipende dall'applicazione, utilizzalo come numero richiesto di pod per nodo. Se non riesci a determinare il numero massimo necessario, utilizza il limite di quota di 110 pod per nodo come massimo.

  2. Determina i bit host necessari per il numero richiesto di pod.

    Quando conosci i pod necessari per ogni conteggio dei nodi, puoi utilizzare la tabella 2 per calcolare i bit host necessari per generare una netmask. Individua il numero di pod obbligatori per nodo nella colonna Conteggio pod per nodo. Per il passaggio successivo, utilizza il numero corrispondente nella colonna bit dell'host per i pod.

    Conteggio pod per nodo Bit dell'host per i pod
    1-8 4
    9-16 5
    17-32 6
    33-64 7
    65-110 8

    Tabella 2. Bit necessari per i pod per nodo.

  3. Genera una netmask di blocco CIDR, utilizzando il numero di bit host per i nodi che hai determinato nel passaggio due della sezione Determinare la dimensione del blocco CIDR di nodi e il numero di bit host per i pod determinati nel passaggio precedente:

    32 – (bit host per i nodi + bit host per i pod) = netmask del blocco CIDR pod

    La figura seguente mostra l'equazione in modo grafico.

    Netmask del blocco CIDR pod.

    Ad esempio, se hai bisogno di 110 pod per nodo, saranno necessari 8 bit host per i pod per nodo. Prendi quindi i bit host per i nodi (13) e sostituisci questi numeri nell'equazione, 32 - (13 + 8) = 11. Il risultato è una netmask di /11.

Determinazione delle dimensioni del blocco CIDR IP del cluster in corso...

Segui questi passaggi per determinare la dimensione del blocco CIDR dell'indirizzo IP del cluster:

  1. Determina il numero massimo di indirizzi IP del cluster di cui hai bisogno nel tuo cluster per tutta la sua durata.

    Se puoi determinare questo numero, che dipende dall'applicazione, utilizzalo come numero richiesto di indirizzi IP del cluster. Se non riesci a determinare il numero massimo necessario, utilizza la maschera di rete /20 predefinita. Se utilizzi la netmask predefinita, puoi ignorare il passaggio seguente.

  2. Determina la netmask per il blocco CIDR dell'indirizzo IP del cluster.

    Quando conosci il numero massimo di indirizzi IP del cluster di cui hai bisogno, puoi utilizzare la tabella 3 per trovare la netmask.

    Numero di indirizzi IP del cluster Maschera di rete
    1-32 /27
    33-64 /26
    65-128 /25
    129-256 /24
    257-512 /23
    513-1024 /22
    1025-2048 /21
    2049-4096 /20
    4097-8192 /19
    8193-16.384 /18
    16.385-32.768 /17
    32.769-65.536 /16

    Tabella 3. Service' Netmask del blocco CIDR.

Informazioni sulla domanda di indirizzi

Quando osservi i requisiti per il blocco CIDR derivati dai passaggi precedenti, nota che il blocco CIDR di pod determina la maggiore richiesta di spazio di indirizzi IP. Nella maggior parte dei casi, il CIDR del nodo pone la seconda domanda più grande, seguita dal blocco CIDR dei servizi.

Ora che hai calcolato i requisiti dell'indirizzo IP del cluster, devi esaminare lo spazio di indirizzi IP RFC 1918 disponibile e selezionare un percorso in avanti.

Selezione della soluzione migliore

La Figura 1 mostra una struttura decisionale che puoi utilizzare per determinare la soluzione migliore in base ai requisiti del blocco CIDR. La sezione Rivedere le soluzioni riepiloga ogni soluzione.

Esempio di configurazione del servizio. (Per una versione PDF leggibile dallo schermo, fai clic sull'immagine).
Figura 1. Esempio di configurazione del servizio. Per una versione PDF leggibile sullo schermo, fai clic sull'immagine.

Esaminare le soluzioni

Questa sezione descrive ogni soluzione e quando utilizzarla e riepiloga eventuali vantaggi, svantaggi e altri problemi.

Assegnazione dello spazio di indirizzi disponibile

Quando utilizzarli:

  • Dopo aver esaminato lo spazio di indirizzi IP disponibile e aver esplorato la figura 1, hai determinato che lo spazio di indirizzi RFC 1918 è sufficiente da allocare per i blocchi CIDR del cluster. Ad esempio, anche se l'indirizzo 10.0.0.0/8 potrebbe essere esaurito, lo spazio nell'indirizzo 172.16.0.0/12 o 192.168.0.0/16 è sufficiente per soddisfare i requisiti del blocco CIDR.

Descrizione:

  • Per questa soluzione non sono necessari altri passaggi speciali di configurazione, quindi alloca lo spazio degli indirizzi e continua con l'installazione.

Vantaggi:

  • La soluzione più semplice di tutte.
  • Non richiede nessuna configurazione speciale.

Svantaggi:

  • Esaurisce lo spazio di indirizzi IP disponibile.

Altri problemi:

Traduzione del blocco CIDR del pod GKE

Quando utilizzarli:

  • Dopo aver esaminato lo spazio di indirizzi IP disponibile e aver esplorato la figura 1, hai determinato che lo spazio di indirizzi RFC 1918 è sufficiente per allocarlo per il blocco del nodo, ma non c'è abbastanza spazio per il blocco CIDR del pod. Devi quindi tradurre i blocchi CIDR di pod (e potenzialmente di servizio).

Descrizione:

  • Per tradurre i blocchi CIDR di pod in un cluster GKE, devi implementare la funzionalità ip-masquerade-agent come mostrato nella figura 2. Questa funzionalità nasconde gli indirizzi IP dei pod dietro gli indirizzi IP dei nodi. Con questo design, è anche possibile riutilizzare i blocchi CIDR per il blocco CIDR servizio.

    NAT per un blocco CIDR pod in un cluster GKE. (Per una versione PDF leggibile dallo schermo, fai clic sull'immagine).
    Figura 2. NAT per un blocco CIDR pod in un cluster GKE. Per una versione PDF leggibile sullo schermo, fai clic sull'immagine.

    Questa architettura ha diversi componenti:

    • Nuova terminologia per descrivere le caratteristiche del blocco CIDR in relazione al NAT.
    • La funzionalità ip-masquerade-agent.
    • Blocchi CIDR RFC 1918 riutilizzati.
    • Filtraggio in base alla connessione on-premise.

Vantaggi:

  • Alleggerisce i roadblock di allocazione degli indirizzi IPv4 per il CIDR del pod.
  • Esegue la scalabilità fino al blocco CIDR pod più grande.
  • Isola i blocchi CIDR RFC 1918 riutilizzati dalla tabella di routing globale.
  • Rende ancora possibili i mesh Istio multi-cluster.
  • Rende ancora possibili le configurazioni di gruppi di endpoint di rete.

Svantaggi:

  • NAT introduce nuovi problemi, ad esempio il tethering di indirizzo e la registrazione, che devi risolvere.
  • Non tutte le risorse nel VPC possono comunicare con le risorse on-premise a cui è assegnato lo stesso intervallo CIDR dell'intervallo CIDR pod. Questo problema si verifica anche per le risorse on-premise che condividono il blocco CIDR di servizio se l'intervallo di servizi viene riutilizzato. Il problema è che i blocchi CIDR riutilizzati vengono visualizzati come route locali al VPC e quindi non vengono mai instradati al di fuori del VPC.

Altri problemi:

  • Fai attenzione quando selezioni i blocchi CIDR RFC 1918 da riutilizzare per i blocchi CIDR GKE.
  • Non pubblicizzare i blocchi CIDR RFC 1918 riutilizzati sulla rete on-premise.
  • Poiché i blocchi CIDR riutilizzati si trovano nella tabella di routing VPC, fai attenzione quando utilizzi il peering VPC o le connessioni VPN.

Traduzione di tutti i blocchi CIDR di GKE

Quando utilizzarli:

  • Dopo aver esaminato lo spazio di indirizzi IP disponibile e seguito la figura 1, hai determinato che lo spazio di indirizzi RFC 1918 non è sufficiente da allocare ai blocchi CIDR dei pod o dei nodi del cluster. Pertanto, devi tradurre tutti i blocchi CIDR.

Descrizione:

  • Per tradurre tutti i blocchi CIDR in un cluster GKE, devi implementare l'architettura mostrata nella figura 3.

    NAT per tutti i blocchi CIDR in un cluster GKE. (Per una versione PDF leggibile dallo schermo, fai clic sull'immagine).
    Figura 3. NAT per tutti i blocchi CIDR in un cluster GKE. Per una versione PDF leggibile sullo schermo, fai clic sull'immagine.

    Questa architettura ha diversi componenti:

    • Nuova terminologia per descrivere le caratteristiche del blocco CIDR in relazione al NAT.
    • Blocchi CIDR RFC 1918 riutilizzati.
    • Un VPC host con una rete condivisa.
    • Un VPC di servizio chiamato VPC isolato che contiene il cluster GKE.
    • Un'istanza di Compute Engine, denominata gateway VPC isolato, che esegue NAT e ha un'interfaccia di rete sia nel VPC isolato che in quello VPC host.
    • Il concetto di blocco CIDR interno del bilanciatore del carico.
    • Route statiche in entrambi i VPC che indirizzano in modo appropriato il traffico.
    • Filtraggio in base alla connessione on-premise.

Vantaggi:

  • Alleggerisce i roadblock di allocazione degli indirizzi IPv4.
  • Scala fino al più grande cluster supportato.
  • Consente la replica ridotta per cookie per più cluster.
  • Offre il miglior isolamento dei blocchi CIDR RFC 1918 riutilizzati dalla tabella di routing globale.
  • Rende ancora possibili le configurazioni di gruppi di endpoint di rete.

Svantaggi:

  • Introduce più complessità rispetto alle soluzioni precedenti.
  • NAT introduce nuovi problemi, ad esempio il tethering di indirizzo e la registrazione, che devi risolvere.
  • I mesh Istio multicluster non sono possibili in alcuni deployment.

Altri problemi:

  • Fai attenzione quando selezioni i blocchi CIDR RFC 1918 da riutilizzare per i blocchi CIDR GKE.
  • Non pubblicizzare i blocchi CIDR RFC 1918 riutilizzati sulla rete on-premise.

Passaggi successivi