Ambiente Kubernetes: networking

Oggetto	Descrizione
kubernetes.cmp.gw	Firewall perimetrale È il default gateway di kubernetes.cmp/24. È l'unico attore della VLAN ad avere accesso ad altre reti, controllando quindi tutto il traffico N/S della stessa.
kubernetes.cmp.jump	VM Linux ad uso amministrativo Viene usata come ponte per l'accesso amministratvo, tramite SSH, alle altre macchine di kubernetes.cmp. SSH/22
kubernetes.cmp.auth	VM Linux ad uso amministrativo Eroga l'interfaccia web di dex necessaria al flusso di login di kubectl tramite Active Directory. SSH/22 HTTPS/443
kubernetes.cmp.k8s-api	VIP API K8s HTTPS/6443
kubernetes.cmp.nodes	Nodi K8s SSH/22 + varie porte e protocolli. Vedi firewalling dei nodi.
kubernetes.cmp.bgp	Routers BGP SSH/22 BGP/179
kubernetes.pods	Pods Non vengono raggiunti direttamente da nessun applicativo distribuito al di fuori di Kubernetes. Sono resi routabili all'interno dei clusters kubernetes grazie ad un overlay network instaurato dai nodi del cluster.
kubernetes.balancers	LoadBalancers Costituiscono il punto di ingresso per il traffico N/S verso i servizi esposti dall'ambiente kubernetes al resto della rete. I loro indirizzi IP sono gestiti da Cilium e la loro routabilità è ottenuta tramie l'utilizzo del protocollo BGP.

kubernetes.cmp

Per kubernetes.cmp viene definita una VLAN in ogni region. Il firewall perimetrale partecipa alla VLAN ed è il default gateway della subnet per tutti gli altri partecipanti.

Il firewall perimetrale è l'unico oggetto delle VLAN ad avere accesso ad altre reti.

kubernetes.cmp.nodes

All'interfaccia ens192 di ogni VM che funge da nodo Kubernetes viene assegnato da Cluster API un indirizzo IP appartenente a kubernetes.cmp.nodes e data connettività tramite la VLAN kubernetes.cmp.

Conettività tra i nodi

I nodi Kubernetes devono avere connettività diretta tra loro sia che siano membri del medesimo cluster sia che siano membri di clusters differenti che sono stati messi Cluster Mesh.

Nel caso in cui i nodi appartengano alla medesima region ciò è possibile by design, dal momento che essi condividono la medesima VLAN (kubernetes.cmp).

Nel caso in cui i nodi appartengano a region differenti il traffico viaggia all'interno di un tunnel VPN implementato dai firewalls perimetrali, che operano ognuno come ponte N/S verso il proprio ambiente Kubernetes.

Perché siamo interessati alla connettività tra nodi di differenti regions?

La possibilità di mettere in Cluster Mesh clusters di regions differenti è un building-block importante per implementare capacità di DR cross-sito.

kubernetes.pods

Ad ogni cluster assegnamo una subnet /16 di kubernetes.pods.
Le 10.x/16 assegnate ai Pods di ogni cluster sono enumerate qui.

All'interno di ogni cluster utilizziamo Cilium come CNI.
Cilium utilizza Kubernetes come sorgente di verità ai fini dell'IPAM dei Pods.
Kubernetes procede a sua volta ad "affettare" la /16 dei Pods in /24, ognuna delle quali viene assegnata a un nodo del cluster.

Routabilità dei pods

Il traffico tra i Pods non presenta requisiti per il network sottostante. Cilium gestisce infatti un overlay network, basato su wireguard, che poggia sulle interfacce ens192 delle VM in kubernetes.cmp.nodes.

Pertanto non vi sarebbero problemi qualora gli IP loro assegnati dovessero essere usati altrove nell'intranet.

Occorre prestare attenzione solo ai casi in cui si ritiene che un determinato servizio presente nell'intranet ed esterno al mondo kubernetes debba venir consumato dai servizi intra-kubernetes.

kubernetes.balancers

I LoadBalancer(s) sono lo strumento di networking che le applicazioni operanti in ambiente kubernetes possono usare per esporre servizi di rete al resto della nostra infrastruttura.

Ad ogni cluster Kubernetes assegnamo una subnet /24 di kubernetes.balancers.
All'interno di ogni cluster l'IPAM dei servizi LoadBalancer è gestito da Cilium.

Le subnet /24 assegnate ogni cluster per i servizi LoadBalancer sono enumerate qui.

ClusterIP

I servizi di tipo Cluster IP non vengono esposti dai clusters, né via Cluster Meshing né attraverso advertising BGP.

La connettività tra i Pods e i ClusterIP è gestita autonomamente da Cilium e non presenta requisiti per il network sottostante.

Possiamo usare quindi la stessa subnet in ogni cluster, che per convenzione è 10.43.0.0/16.

Nameservers

Tutte le VM dell'ambiente Kubernetes della region usano come nameservers le istanze di Active Directory presenti nel proprio sito.

I nameservers dei nodi Kubernetes vengono impostati automaticamente per mezzo delle risorse VSphereMachineTemplate di CAPV.

DNS

In ogni cluster opera un servizio CoreDNS interno per la risoluzione dei propri indirizzi {servizio}.{namespace}.svc.cluster.local.

Ogni cluster espone, tramite LoadBalancer, un servizio DNS capace di risolvere la zona {nome-cluster}.k8s.{sito}.simplebooking.local.

Tale servizio viene consumato dalle istanze di Active Directory del proprio sito.

DNS LoadBalancer IP(s)

Per convenzione al servizio DNS esposto da ogni cluster è assegnato l'IP .10 della /24 utilizzata per i suoi LoadBalancers.

Esempio: risoluzione di ui.argocd.management.k8s.siziano.simplebooking.local

Traffico est/ovest

Firewalling Zero Trust

Cilium ci permette l'implementazione di policies di networking distribuite per ogni oggetto di rete distribuito tramite kubernetes.

L'agente Cilium di ogni nodo Kubernetes gestisce il traffico in entrata e uscita da ogni pod dislocato sul nodo.

Di conseguenza tutti i carichi di lavoro distribuiti nei cluster sono all'interno di un ambiente Zero Trust e per ciascuno di essi viene esplicitamente autorizzato il traffico in entrata e uscita.

Tunnels wireguard

I nodi di ogni cluster formano tra loro una mesh Wireguard.(1)

1. 

Lo stesso avviene tra i nodi dei clusters per i quali viene attivata la feature Cluster Mesh.

Il traffico di rete tra carichi di lavoro distribuiti su nodi differenti passa dai tunnel Wireguard, che procedono tanto alla crittografia quanto al routing dei pacchetti.

Nota

Nel caso in cui vengano messi in mesh clusters operanti in regions differenti il traffico cross WAN viene incapsulato due volte: la prima nel tunnel wireguard tra due nodi kubernetes, la seconda nel tunnel VPN tra i firewalls perimetrali.

Bilanciamento

Il bilanciamento del traffico orizzontale (ClusterIP) verso servizi che presentano molteplici backend viene gestito direttamente da Cilium.

Lo stesso avviene in caso di servizi con backend presenti in clusters differenti che siano stati messi in mesh.

Traffico sud > nord (egress)

Le connessioni in egress dai pods verso indirizzi IP considerati out-of-cluster (1) sono oggetto di mascheramento SNAT da parte di Cilium e si presentano con l'indirizzo IP del nodo di uscita, ossia del nodo in cui è presente il pod che attiva la connessione.

1. Cilium considera tali gli indirizzi IP che non rientrano in:

   • CIDR dei ClusterIP (per convenzione 10.43.0.0/16)
   • CIDR dei Pods (del proprio cluster o dei clusters con cui è in mesh)

I nodi poggiano sulla kubernetes.cmp/24 ed hanno kubernetes.cmp.gw come default gateway, pertanto inoltrano tutto il traffico in uscita al firewall perimetrale.

I nodi hanno IP variabili, le policies sono gestite da Cilium

La distribuzione dei nodi K8s è automatizzata e l'infrastruttura è gestita come se fosse immutabile.

Quando procediamo all'aggiornamento dei nodi (versione K8s, kernel linux, librerie, etc...) lo facciamo sostituendo quelli vecchi con nodi nuovi.

Questo significa che gli indirizzi IP dei nodi non sono stabili nel tempo e non possono quindi essere oggetto di policies specifiche nei firewalls perimetrali (solo il loro range .100-249 può esserlo).

Al fine di regolare il traffico in uscita dall'ambiente kubernetes, il firewall perimetrale tratta tutti gli applicativi distribuiti in kubernetes e i nodi stessi come un unicum indistinto, de facto dovendo autorizzare basicamente l'accesso a internet.

Questo non significa, ovviamente, non regolamentare il traffico in uscita!

Significa bensì spostarlo al livello sottostante. Le policies di egress vengono definite tramite manifests (GitOps) e implementate granularmente (Zero Trust) tramite Cilium.

Traffico nord > sud: BGP e LoadBalancers

L'infrastruttura di routing che rende usabili gli indirizzi IP dei LoadBalancers nella rete extra Kubernetes è basata sul protocollo BGP.

Cilium istanzia su ogni nodo del cluster un virtual router BGP che stabilisce un peering eBGP con i routers BGP facenti parte di kubernetes.cmp.bgp del proprio sito e procede all'advertising delle rotte inerenti gli indirizzi IP dei LoadBalancers.