KubeIP v2: IP pubblici statici per i nodi Kubernetes su qualsiasi cloud provider

In determinati scenari, i nodi Kubernetes possono trarre vantaggio da indirizzi IP pubblici statici dedicati.

KubeIP, un'utility open source, risponde proprio a questa esigenza assegnando IP pubblici statici ai nodi Kubernetes. L'ultima versione, KubeIP v2, estende il supporto da GKE di Google Cloud ad Amazon EKS, con un'architettura pronta ad accogliere altri cloud provider. Funziona come DaemonSet e offre maggiore affidabilità, flessibilità di configurazione e semplicità d'uso rispetto al precedente approccio basato su controller Kubernetes. KubeIP v2 supporta l'assegnazione di indirizzi sia IPv4 sia IPv6.

In questo articolo analizzeremo i casi d'uso specifici di KubeIP, lo confronteremo con i NAT gateway cloud ed esploreremo l'architettura e la configurazione di KubeIP.

KubeIP è utile in diversi scenari in cui i nodi Kubernetes necessitano di IP pubblici statici.

Ecco alcuni casi d'uso comuni:

Applicazioni di gaming

Nel gaming, una console può aver bisogno di stabilire una connessione diretta con una VM cloud per ridurre al minimo gli hop di rete e la latenza. Assegnare un IP pubblico dedicato al nodo che ospita il server di gioco consente alla console di connettersi direttamente, migliorando l'esperienza di gioco grazie a una latenza inferiore e a una minore perdita di pacchetti.

Whitelist degli IP degli agent

Se ha più agent o servizi su Kubernetes che devono connettersi direttamente a un server esterno, e quel server deve inserire in whitelist gli indirizzi IP degli agent, KubeIP semplifica la gestione assegnando IP pubblici stabili ai nodi, evitando di dover autorizzare intervalli CIDR più ampi. È una soluzione particolarmente utile quando il server esterno applica controlli di accesso rigorosi basati sull'IP.

Evitare il SNAT per pod selezionati

Per impostazione predefinita, ai pod vengono assegnati IP privati dall'intervallo CIDR della VPC. Quando comunicano con indirizzi IPv4 esterni, il plugin Amazon VPC CNI traduce l'IP del pod nell'IP privato primario dell'interfaccia di rete del nodo tramite SNAT (source network address translation).

In alcuni casi può essere preferibile evitare il SNAT per determinati pod, in modo che i servizi esterni vedano gli IP effettivi dei pod. Per ottenere questo risultato basta assegnare IP pubblici ai nodi con KubeIP e impostare hostNetwork: true nella spec del pod. Il pod potrà così comunicare direttamente con i servizi esterni utilizzando l'IP pubblico del nodo.

Connessioni inbound dirette e scenari di networking personalizzati

Assegnare IP pubblici ai nodi tramite KubeIP abilita un'ampia varietà di scenari di networking. È possibile, ad esempio, inoltrare il traffico direttamente ai pod in esecuzione su quei nodi: una soluzione utile quando occorre esporre i servizi del nodo su Internet senza ricorrere a un load balancer tradizionale.

Un esempio è eseguire un web server su un pod e inoltrarvi il traffico utilizzando l'IP pubblico del nodo.

KubeIP può inoltre essere utilizzato per implementare scenari di networking personalizzati che richiedono IP pubblici sui nodi. Si può ad esempio creare un load balancer personalizzato che inoltra il traffico a nodi specifici in base all'IP pubblico. Questa flessibilità rende KubeIP uno strumento potente per testare o distribuire soluzioni di networking su misura in Kubernetes.

KubeIP estende le proprie funzionalità oltre IPv4, supportando anche l'assegnazione di indirizzi IPv6 pubblici statici ai nodi. Si tratta di una funzionalità sempre più rilevante, dato che Internet sta progressivamente migrando verso IPv6 a causa dell'esaurimento degli indirizzi IPv4.

Grazie al supporto IPv6 di KubeIP, può assegnare indirizzi IPv6 pubblici statici ai propri nodi Kubernetes, consentendo loro di comunicare direttamente con i servizi esterni tramite IPv6. È un vantaggio particolarmente significativo per le applicazioni che richiedono connettività IPv6: se sta sviluppando o distribuendo un'applicazione che deve supportare IPv6, può utilizzare KubeIP per fornire connettività IPv6 ai pod che eseguono la sua applicazione.

IPv6 offre inoltre uno spazio di indirizzamento più ampio, un formato di header semplificato, un supporto migliore per estensioni e opzioni, un routing multicast più efficiente e altri miglioramenti rispetto a IPv4.

I NAT gateway sono servizi cloud gestiti che forniscono accesso a Internet in uscita alle risorse nelle subnet private, traducendo i loro IP privati in IP pubblici. Sono progettati per consentire alle risorse di una rete privata di avviare connessioni in uscita verso Internet, preservando al tempo stesso la privacy e la sicurezza di tali risorse.

I NAT gateway, tuttavia, non supportano connessioni in entrata e non assegnano IP pubblici direttamente alle risorse. Sono quindi una soluzione eccellente per garantire un accesso in uscita sicuro, ma non sono pensati per gli scenari in cui sono richieste connessioni in entrata o in cui le risorse devono disporre di un proprio IP pubblico.

KubeIP, al contrario, assegna IP pubblici statici direttamente ai nodi Kubernetes. Questo permette di stabilire connessioni in entrata direttamente verso i pod in esecuzione su quei nodi, inoltrando il traffico dal nodo al pod. Una caratteristica particolarmente preziosa per le applicazioni che devono essere accessibili da Internet o per scenari di networking personalizzati.

Inoltre, quando hostNetwork è abilitato, i pod possono avviare connessioni in uscita utilizzando direttamente l'indirizzo IP dell'host. Questa configurazione può migliorare le prestazioni di rete e semplificare il troubleshooting, ma va adottata con attenzione per le possibili implicazioni di sicurezza.

In sintesi, mentre i NAT gateway rappresentano un'ottima soluzione per un accesso in uscita sicuro, KubeIP offre maggiore flessibilità e controllo sulla connettività in entrata e in uscita per pod e nodi specifici.

Nel valutare il costo di KubeIP rispetto ai NAT gateway cloud occorre tenere presenti diversi fattori.

Costi dei NAT gateway cloud

I NAT gateway cloud sono un servizio gestito e, in quanto tali, hanno un costo. Tale costo dipende generalmente dalla quantità di dati elaborati e dal tempo in cui il NAT gateway resta attivo e disponibile.

AWS, ad esempio, addebita 0,045 $ all'ora per un NAT gateway, oltre agli oneri per l'elaborazione dei dati al momento della stesura di questo articolo. Sono inoltre previsti i costi standard di trasferimento dati AWS per tutto il traffico che transita attraverso il NAT gateway.

Il modello di pricing di Google Cloud NAT è analogo.

Costi di KubeIP

KubeIP, invece, è uno strumento open source e non comporta costi diretti per il suo utilizzo. Esistono però diversi costi indiretti da considerare:

1. Indirizzi IP pubblici statici: dovrà sostenere il costo degli indirizzi IP pubblici statici assegnati ai suoi nodi. Il costo varia in base al cloud provider. AWS, ad esempio, addebita 0,005 $ all'ora per un indirizzo Elastic IP, indipendentemente dal fatto che sia in uso o meno. Google Cloud applica lo stesso importo per un indirizzo IP statico.
2. Trasferimento dati: si applicano i costi standard di trasferimento dati per il traffico veicolato tramite gli indirizzi IP pubblici statici assegnati. Tali costi dipendono dal pricing del trasferimento dati del suo cloud provider.
3. Workloads aggiuntivi sul cluster: pur funzionando come DaemonSet e consumando poche risorse in termini di CPU e memoria, KubeIP rappresenta comunque un workload aggiuntivo in esecuzione sul cluster Kubernetes. Questo potrebbe influire sulle prestazioni di altri workloads, soprattutto sui cluster con risorse limitate. Nella maggior parte dei casi, tuttavia, l'impatto è minimo.
4. Manutenzione e supporto: trattandosi di uno strumento open source, KubeIP non include un supporto dedicato. Eventuali attività di manutenzione, troubleshooting o aggiornamento dovranno essere gestite dal suo team. Pur non avendo un costo diretto, richiedono tempo ed energie, che si traducono comunque in un costo per l'organizzazione.

In sintesi, sebbene KubeIP non abbia un costo diretto, esistono diversi costi indiretti da valutare. Tuttavia, in molti casi, la flessibilità e il controllo che offre superano ampiamente questi costi.

Considerazioni sui costi

Nel valutare il rapporto costo-efficacia di KubeIP è importante considerare sia i costi diretti sia quelli indiretti: il costo degli indirizzi IP pubblici statici, le tariffe per il trasferimento dati, l'impatto potenziale di un workload aggiuntivo sul cluster Kubernetes e il tempo necessario per manutenzione e supporto.

Anche se KubeIP non ha un costo diretto, questi costi indiretti possono accumularsi, soprattutto sui cluster di grandi dimensioni. La flessibilità e il controllo che offre, però, possono generare un valore significativo, in particolare per i casi d'uso che richiedono connessioni in entrata dirette o scenari di networking personalizzati.

I NAT gateway cloud, dal canto loro, offrono un servizio gestito che può semplificare la connettività in uscita per le risorse nelle subnet private. Pur avendo un costo, questo servizio garantisce vantaggi come facilità d'uso, scalabilità e affidabilità.

In conclusione, la scelta tra KubeIP e un NAT gateway cloud dipende dal suo specifico caso d'uso, dalle dimensioni e dai requisiti del suo cluster Kubernetes e dal budget a disposizione. Le consigliamo di calcolare i costi sulla base del trasferimento dati previsto, del numero di nodi e indirizzi IP e delle esigenze di manutenzione, così da prendere una decisione informata.

KubeIP viene eseguito come DaemonSet sui nodi desiderati. Su ciascun nodo:

1. Recupera le informazioni sul nodo e sul cloud provider tramite la Kubernetes Downward API.
2. Acquisisce un lock a livello di cluster per garantire che un solo nodo alla volta assegni un IP, prevenendo race condition e conflitti tra IP.
3. Seleziona un IP statico disponibile dal pool configurato utilizzando filtri e selettori.
4. Assegna l'IP all'interfaccia di rete primaria del nodo tramite l'API del cloud provider.
5. Se l'assegnazione fallisce per via di un errore, ad esempio un'interruzione di rete o un errore dell'API, KubeIP riprova fino al limite configurato.
6. Quando un nodo viene eliminato, KubeIP rilascia l'IP assegnato restituendolo al pool, così da renderlo disponibile per altri nodi.

KubeIP supporta indirizzi IPv4 e IPv6 e può essere configurato per utilizzare pool diversi per ciascuno. Supporta inoltre pool IP personalizzati per nodi o gruppi di nodi differenti, offrendo flessibilità nella gestione degli IP.

KubeIP v2 è progettato come un DaemonSet Kubernetes standard, e viene quindi eseguito su ogni nodo del cluster.

Questa architettura migliora l'affidabilità e la semplicità d'uso rispetto al precedente approccio basato su controller. Semplifica inoltre il processo di deployment e garantisce che ogni nodo riceva un IP pubblico. Sfruttando funzionalità Kubernetes standard come node selector o node affinity, può inoltre stabilire su quali nodi distribuire KubeIP, ottenendo un controllo granulare sull'assegnazione degli IP e potendo così assegnare IP pubblici a nodi specifici in base alle proprie esigenze.

L'architettura estensibile di KubeIP v2 consente una facile integrazione con altri cloud provider oltre a GKE ed EKS, rendendolo uno strumento versatile per la gestione degli IP pubblici in ambienti multi-cloud.

KubeIP richiede un service account Kubernetes con i permessi per ottenere informazioni sui nodi e gestire i lease.

Sul lato cloud serve un ruolo IAM o un service account con i permessi per assegnare e rimuovere IP pubblici, elencarli e ottenere informazioni sui nodi.

Ecco un esempio di policy IAM AWS:

{
  "Version": "2012-10-17",
  "Statement": [\
    {\
      "Effect": "Allow",\
      "Action": [\
        "ec2:AssociateAddress",\
        "ec2:DisassociateAddress",\
        "ec2:DescribeInstances",\
        "ec2:DescribeAddresses"\
      ],\
      "Resource": "*"\
    }\
  ]
}

E un ruolo IAM Google Cloud:

title: "KubeIP Role"
description: "KubeIP required permissions"
stage: "GA"
includedPermissions:
- compute.instances.addAccessConfig
- compute.instances.deleteAccessConfig
- compute.instances.get
- compute.addresses.get
- compute.addresses.list
- compute.addresses.use
- compute.zoneOperations.get
- compute.subnetworks.useExternalIp
- compute.projects.get

Per scegliere quali IP utilizzare occorre specificare i filtri usando la stessa sintassi della CLI/API del cloud per l'elenco degli IP. Ad esempio:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubeip
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kubeip
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: kubeip
    spec:
      serviceAccountName: kubeip-service-account
      terminationGracePeriodSeconds: 30
      priorityClassName: system-node-critical
      nodeSelector:
        nodegroup: public
        kubeip: "use"
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
        - operator: "Exists"
          effect: "NoExecute"
      containers:
      - name: kubeip
        image: doitintl/kubeip-agent
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "10m"
            memory: "32Mi"
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: LEASE_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: FILTER
          value: "Name=tag:kubeip,Values=reserved;Name=tag:environment,Values=prod"
        - name: LOG_LEVEL
          value: "debug"
        - name: LOG_JSON
          value: "true"

Con questa configurazione, KubeIP su AWS prenderà in considerazione solo gli IP con i tag kubeip=reserved ed environment=prod.

Il filtro KubeIP per AWS supporta la stessa sintassi del comando AWS describe-addresses. Per maggiori informazioni, consulti describe-addresses. Se specifica più filtri, questi vengono uniti con un AND e la richiesta restituisce solo i risultati che corrispondono a tutti i filtri specificati. I filtri multipli devono essere separati da punto e virgola (;).

Il filtro KubeIP per Google Cloud supporta la stessa sintassi del comando Google Cloud gcloud compute addresses list. Per maggiori informazioni, consulti gcloud topic filter. Se specifica più filtri, questi vengono uniti con un AND e la richiesta restituisce solo i risultati che corrispondono a tutti i filtri specificati. I filtri multipli devono essere separati da punto e virgola (;).

La directory examples contiene configurazioni Terraform per avviare cluster GKE ed EKS con KubeIP già distribuito.

Per eseguirlo su EKS:

cd examples/aws

terraform init

terraform apply

E su GKE:

cd examples/gcp

terraform init

# senza supporto IPv6
terraform apply -var="project_id=<your-project-id>"

# con supporto IPv6
terraform apply -var="project_id=<your-project-id>" -var="ipv6_support=true"

Verrà così effettuato il provisioning di un cluster con node pool pubblici e privati, riservati alcuni IP statici e distribuito il DaemonSet KubeIP configurato per utilizzare gli IP riservati.

Trattandosi di un progetto open source, ogni contributo è benvenuto. Può inviare pull request, aprire issue, contribuire alla documentazione o aiutarci a far conoscere il progetto.

Con il supporto cloud ampliato e il modello DaemonSet semplificato della v2, non vediamo l'ora di scoprire quali nuovi casi d'uso saranno resi possibili da KubeIP. Lo provi nel suo ambiente e ci racconti com'è andata!