Integrazione Kubernetes ed F5

Sto maturando in questi ultimi tempi una certa esperienza nella gestione di una infrastuttura basata su Docker e Kubernetes e dopo un periodo di gestazione di circa un anno, confrontandomi con colleghi che lavorano in altre realtà pare sia una tempistica comune, sono arrivato a metterla in produzione e cominciare a installare o adattare le prime applicazioni, traendo talvolta dei notevole vantaggi ed a volte dovendo risolvere problemi inaspettati.

Come sempre dopo la diffidenza e poi la crescente confidenza nella specifica tecnologia, si comincia a volere di più. Lo scenario classico in cui Kubernetes viene deployato prevede alcuni nodi master, preferibilmente in numero dispari e maggiore di tre (la componente critica che richiede queste attenzioni è il backend etcd, essendo basato su quorum) su cui gira Kubernetes, ed un numero sempre crescente di worker, o minion per i nostalgici, su cui girano invece le applicazioni containerizzate. In questo scenario la situazione è la seguente:

 

Su ciascun nodo worker è esposta solitamente una porta per ciascun “servizio” (probabilmente una singola applicazione ma anche l’aggregato di più applicazioni tramite un Ingress, assimilabile ad un reverse proxy), questa porta è gestita da kube-proxy che fa da load balancer tra il mondo esterno ed i container della applicazione associata (nel nostro caso App 1), che essi siano su quell’host o su un qualsiasi host. In pratica qualsiasi worker diventa un possibile punto di ingresso per collegarsi alla nostra “App 1”. Volendoci astrarre dal singolo nodo, abbiamo poi bisogno di un bilanciatore, che sia LVS, Kemp o F5, davanti a tutti questi worker in modo tale da poter distribuire il carico di ingresso su tutti i worker e gestire la rottura di un qualsiasi nodo. Quella fatta fino ad ora è una semplificazione, ma è sufficiente per introdurre il tema.

La situazione sopra citata non è affatto male ed è già utilizzata da me con successo, ma ha alcuni limiti ed alcune noie. La prima noia, se ne accorge chiunque entra in questo mondo, è che probabilmente presto le richieste di nuovi servizi potrà esplodere per i seguenti motivi:

• la facilità con cui è possibile, applicativamente parlando, pacchettizzare l’applicazione in formato Docker rendendola indipendente dalle altre fino ad ora sviluppate e non dover invece installarla su un application server comune (che sia IIS, un server PHP, Node o JBoss) dovendone gestire la convivenza
• la tendenza attuale a dividere applicazioni monolitiche in applicazioni – servizi – più piccoli facilmente manutenibili

tutto ciò crea un sacco di attività amministrative che come minimo impattano, oltre che su Kubernetes dove devo definire l’applicazione, il servizio e le risorse che usa, anche Load Balancer, DNS e PKI, a meno di non usare stretegie lazy come il wildcard dns e certificate.

Il limite invece è il fatto che se in una applicazione tradizionale il load balancer F5 vede direttamente l’applicazione sul singolo nodo, quindi ne effettua la verifica tramite Health Check e la esclude singolarmente, in questo contesto il balancer è tagliato fuori e può intervenire solo per bilanciare il bilanciatore (Kube-Proxy) dei container. Overhead da una parte, minor controllo dall’altra facendo in pratica due volte lo stesso lavoro, con la scomodità di dover configurare in maniera fantasiosa lo stikyness delle sessioni, che F5 gestirebbe egregiamente dal suo lato.

Qui ci viene in aiuto l’integrazione tra F5 e Kubernetes perché il Load Balancer non è più spettatore esterno di quel che succede all’interno del mondo containerizzato, ma vede direttamente i container e quindi è possibile sfruttare la maturità delle funzioni di bilanciamento, persistenza ed offloading. Ci sono dei prerequisiti per poter sfruttare questa integrazione:

• il primo è disporre di una licenza che preveda il supporto SDN, cioè Software Defined Networks, per permettere la configurazione del tunnel VXLAN; nel mio caso ho utilizzato una licenza developer e quindi ero già perfettamente coperto
• il secondo è di utilizzare per le overlay network flannel o simili (ad esempio Canal, che comprende sia Calico che Flannel) configurato per utilizzare le VXLAN; è previsto anche il supporto BGP ma non mi sono interessato

Lo schema che si va a realizzare è il seguente:

Come fa l’F5 a contattare direttamente i Pod? Per farlo prende parte alla overlay network utilizzata dai Pod e dai nodi per comunicare tra loro. Flannel, uno dei più utilizzati supporti di rete su Kubernetes, non fa altro che creare una rete virtuale tra gli host in modo tale da assegnare, per ciascun Pod (quindi container in esecuzione), un IP su questa rete e permettere ai Pod di vedersi direttamente tra loro; questo è il modo con cui Kube-Proxy configura o realizza il bilanciamento di Pod all’interno o all’esterno dell’host. Quello che si va a realizzare in realtà è quindi una cosa del genere:

Dando i nomi alle cose, vediamo che l’F5 ha una sua interfaccia di rete sulla rete L2 che connette tra loro gli host; questi, tramite flannel, hanno una interfaccia di rete virtuale sulla overlay network, rete ampia (solitamente una classe B) su cui sono installati i POD. Ciascun host per semplicità gestisce una intera classe C (es. 10.10.1.0/24 sul worker node 1, 10.10.2.0/24 sul worker node 2) ed ha una interfaccia di rete flannel su questa rete, il tutto gestito in autonomia dall’agent flannel (il plugin CNI, Container Network Interface) che registra queste informazioni “su Kubernetes”. Ogni volta che aggiungo un worker, viene assegnata una nuova classe C libera e viene detto a tutti i nodi che qualora si voglia raggiungere quella rete, si dovrà contattare il nuovo nodo nella rete VXLAN. Se prendiamo ad esempio Worker 1:

La prima cosa da fare quindi configurare su F5 una interfaccia su questa VXLAN creando prima la definizione del tunnel:

e poi configurando, su questa nuova interfaccia dell’F5, un SelfIP sulla rete flannel che andremo ad assegnare poi anche su Kubernetes, ad esempio 10.10.30.15 sulla classe C 10.10.30.0/24 e quindi:

rileviamo il mac-address che ha l’interfaccia flannel_vxlan in modo da riutilizzarla poco dopo:

Informiamo poi Kubernetes della nostra scelta creando un nodo fittizio alla rete flannel che rappresenti l’interfaccia virtuale dell’F5:

L’errore che io ho fatto a questo punto è quello di credere che i nodi possano già pingare l’F5, ma in verità l’F5 non è informato di quali siano gli altri endpoint della rete flannel ed è qui che entra in gioco il controller F5. Il produttore infatti mette a disposizione due applicazioni docker, un “controller” ed un sostituto del kube-proxy (non più necessario dalla versione 1.4 dell’integrazione) fornito da Kubernetes. Il primo tra i suoi molti compiti ha anche quello di aggiornare tunnel static forwarding table dell’F5 e indicare quali siano gli altri endpoint.

Si installa quindi lo snippet fornito da F5, personalizzando (qui è semplificato e non si è passati da una Secret) per lo meno l’IP di management dell’F5, username, password, la modalità di integrazione (detta cluster) e l’interfaccia tunnel utilizzata per questo cluster, ipotizzando infatti che questo F5 serva altri cluster nel medesimo modo. E’ necessario anche creare su F5 ed indicare qui una partizione, perché volutamente questa integrazione non può agire sulla partizione /Common:

sufficiente per fare in modo che l’F5 ora sia cosciente del fatto che esistono altri nodi sulla rete flannel e sappia come contattarli

da ora sarà quindi pingabile il 10.10.30.15 da tutti i nodi. Con l’ultima versione dell’integrazione, la 1.4.0, qualcosa è cambiato perché non è più necessario sostituire il kube-proxy fornito Kubernetes con uno fornito da F5, semplificando e standardizzando l’integrazione visto che ad ogni aggiornamento il kube-proxy sarebbe stato ri-aggiornato alla versione Kubernetes.

Partiamo ora da una applicazione generica da bianciare con F5, ad esempio un hello world in ascolto sulla 9000 (avendo un cluster misto con nodi Windows e Linux è necessario specificare il nodeSelector):

l’applicazione se contattata ci riporta anche il REMOTE_ADDR e l’HTTP_HOST in modo da poter verificare il corretto bilanciamento. Creiamo poi un Service a cui non assegnamo ne un NodePort (cioè una porta esposta su ciascun nodo) ne un ClusterIP (quindi un bilanciatore interno alla rete Kubernetes accessibile da un VIP), quindi una semplice entry a DNS che elenchi tutti i Pod attivi e Ready detta Headless:

che immediatamente configura come endpoint tutti i Pod attualmente attivi per l’applicazione hello-world:

Ora è possibile configurare un VirtualServer su F5 definendolo su Kubernetes come:

Mentre nelle versioni precedenti era necessario definire il VirtualServer con una notazione JSON del tutto estranea agli oggetti Kubernetes (cosa ancora supportata per esigenze non HTTP):

ora l’F5 agisce come Ingress controller e quindi configura, tramite apposite annotations, tutte la caratteristiche tipiche dei questo oggetto come la partizione, il tipo di bilanciamento, la porta e l’IP associati e come backend, come in un qualsiasi Ingress, l’oggetto service precedentemente configurato.

Quel che succede è che su F5 verrà configurato, e continuamente aggiornato, un Virtual Server con l’IP indicato, associato ad un pool di server che riporterà direttamente gli IP dei Pod; ad ogni cambio di stato dei container associati al service la configurazione del pool verrà aggiornata con i nuovi nodi. L’healthcheck definito a livello di VirtualServer si sommerà a quello eventualmente configurato a livello di Pod; in caso di fallimento nel primo caso il pool-node verrà marcato come down, nel secondo sarà eliminato dalla lista dei nodi perché rimosso dagli endpoint del Service Kubernetes.

Concludo dicendo che la soluzione è molto comoda per tante ragioni: da una parte è possibile sfruttare le funzionalità offerte da F5 in termini di gestione della persistenza, senza dover inserire un componente aggiuntivo che lo faccia (solitamente un Ngnix configurato come ingress controller), oltre a poter automatizzare tutta la parte di provisioning dei VS. Dall’altra però questa soluzione non appare ancora pronta per la produzione, basti pensare al cambio di rotta nel come l’integrazione è realizzata (inizialmente sostituendo il kube-proxy), al fatto che fino ad un paio di versioni fa un heathcheck fosse configurabile solo nel contenuto inviato al node ma non per la verifica della risposta ed infine l’impossibilità di configurare tutti gli aspetti di un Virtual Server o di un Pool. L’implementazione maturerà, il poter configurare tutto in un unico punto e strumento (applicazione tramite il deployment, load balancer tramite service e ingress, senza ricorrere ad altri tool come Ansible) merita davvero l’impegno necessario al primo setup, quindi se si ha a disposizione un F5 e le licenze necessarie, si può cominciare a lavorarci e se le proprie necessità sono coperte dell’attuale implementazione, provarlo negli ambienti non produttivi.

Riferimenti:

• http://clouddocs.f5.com/containers/v2/
• http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/v1.4/