Definire Risorse Personalizzate su Kubernetes

Kubernetes ha fatto molta strada dal suo rilascio iniziale nel 2014, iniziando con risorse integrate come Pod, Servizi, Deployments e Replication Controllers. Quando gli sviluppatori hanno iniziato a costruire applicazioni più complesse, hanno avuto bisogno di risorse che andassero oltre quelle inizialmente fornite da Kubernetes. Avevano bisogno di funzionalità come workflow personalizzati, configurazioni avanzate e supporto per componenti infrastrutturali non standard. Le risorse integrate (ad esempio, Pods, Servizi) funzionavano bene per le distribuzioni standard, ma non avevano la flessibilità necessaria per gestire questi requisiti unici. Ciò ha creato la necessità di soluzioni più adattabili

Di conseguenza, le risorse di terze parti (TPR) sono state introdotte nel 2016 con Kubernetes 1.2 come tentativo di offrire flessibilità alle risorse esterne. Tuttavia, le TPR sono risultate insufficienti in termini di convalida dei dati, funzionalità e prestazioni, portando all’introduzione delle Custom Resource Definitions (CRD) nel 2017 con Kubernetes 1.7.

In questo articolo tratteremo i motivi per cui gli sviluppatori ci tengono a migliorare Kubernetes con le Custom Resource Definitions (CRD) e di quali tipi di sfide o workflow le CRD possono affrontare che le risorse integrate non possono.

Alla fine di questo articolo, capirete la funzione critica che le CRD svolgono in Kubernetes e perché sono diventate uno strumento essenziale per gli sviluppatori che vogliono costruire processi complessi e flessibili in Kubernetes.

Cos’è una Custom Resource Definition (CRD)?

Proprio come le modalità di guida programmabili nelle auto moderne consentono agli automobilisti di personalizzare la propria esperienza regolando elementi come la posizione del sedile o la sensibilità dello sterzo, le CRD sono una potente funzionalità che consente agli utenti di Kubernetes di estendere la piattaforma con risorse personalizzate in base alle proprie esigenze specifiche.

A differenza dei TPR, le CRD offrono funzionalità avanzate, tra cui il versioning delle API, la perfetta integrazione con i controller personalizzati e la scalabilità, che li rendono user privilegiati nell’ecosistema Kubernetes. Sebbene le CRD non abbiano trasformato Kubernetes da soli, hanno contribuito in modo significativo alla sua adattabilità, dando agli sviluppatori la possibilità di creare risorse specifiche per le esigenze delle loro applicazioni.

Le CRD consentono agli sviluppatori di modellare risorse non standard in Kubernetes, dando loro la flessibilità di gestire qualsiasi cosa, da database e backup a workflow complessi e componenti infrastrutturali personalizzati. Con l’aiuto delle CRD, Kubernetes si trasforma da semplice strumento per l’orchestrazione dei container in una piattaforma altamente flessibile in grado di gestire quasi tutte le infrastrutture o applicazioni. 

Le CRD possono essere abbinati a controller personalizzati, che utilizzano risorse appena definite per automatizzare attività complesse. Questa collaborazione consente agli sviluppatori di gestire applicazioni o infrastrutture in modo dichiarativo, proprio come Kubernetes fa già per le sue risorse principali.

In definitiva, le CRD consentono a Kubernetes di diventare un sistema espandibile che può essere rimodellato per soddisfare requisiti specifici. Gli sviluppatori possono specificare le loro risorse, creare oggetti personalizzati e far sì che Kubernetes li gestisca correttamente, riducendo l’onere di mantenere applicazioni varie e specializzate.

La sicurezza delle CRDs

Pur essendo incredibilmente potenti, le CRD comportano potenziali implicazioni per la sicurezza. Configurazioni improprie, dati non validati o accessi troppo permissivi possono aprire vulnerabilità nel cluster Kubernetes. Alcuni modi per evitare questi rischi sono:

• Applicare le policy RBAC per limitare chi può definire o gestire le CRD.
• Definire schemi di validazione forti per garantire che le risorse personalizzate aderiscano alle strutture previste.
• Proteggere i controllori personalizzati eseguendoli con permessi minimi e aggiornamenti regolari.

Per apprezzare appieno il potenziale delle CRD, è essenziale comprendere la relazione tra le API di Kubernetes e le differenze tra risorse native e personalizzate.

L’API di Kubernetes e risorse native vs risorse custom

L’API di Kubernetes è la sala macchine di Kubernetes. Gestisce il modo in cui le risorse, sia native che personalizzate, vengono create, definite e gestite. Espone le risorse di Kubernetes (come pod, servizi, ecc.) fornendo un’interfaccia RESTful che consente ai client di interagire con il suo server API tramite richieste HTTP.

Quindi, l’esecuzione di comandi come “kubectl get pods -n e-commerce” utilizza fondamentalmente il metodo HTTP “get” per estrarre informazioni da tutti i pod in quel namespace. Questo è utile perché utilizza gli URL basati sulle risorse Kubernetes per rappresentare le risorse Kubernetes.

Le risorse native di Kubernetes (come le distribuzioni e i pod) sono solitamente predefinite nell’API e hanno i loro schemi e controller. Ciò significa che le API hanno un modo per accedere e gestire queste risorse native.

Ogni risorsa nativa in Kubernetes ha una struttura definita che comprende quattro componenti critici utilizzati da Kubernetes per comprenderli, crearli e gestirli. Questi componenti sono:

• Metadata: Contiene informazioni sul nome della risorsa, sullo spazio dei nomi, sulle etichette e sulle annotazioni. I metadati consentono di fare riferimento alla risorsa e di scoprirla.
• ApiVersion: Specifica la versione dell’API Kubernetes da utilizzare per una particolare risorsa, per interpretarne al meglio lo schema e il comportamento.
• Kind: Definisce il tipo di risorsa gestita per aiutare Kubernetes a capire il suo ruolo e come i controller devono gestirla.
• Spec: Le specifiche definiscono aspetti come le configurazioni e i requisiti e forniscono a Kubernetes informazioni sullo stato desiderato della risorsa da gestire. Kubernetes può quindi utilizzare la sua API per monitorare quando la risorsa si discosta da questo stato.

È importante notare che Kubernetes ha una conoscenza incorporata di queste risorse native attraverso i suoi schemi e controller predefiniti per gestirle più facilmente. Lo svantaggio è che questi schemi e controller coprono solo alcune delle potenziali esigenze degli sviluppatori.

Per rispondere alla crescente complessità delle esigenze degli sviluppatori senza espandere l’API di Kubernetes, sono state introdotte le CRD. Le CRD consentono agli sviluppatori di definire i propri tipi di risorse, integrandoli perfettamente nell’ecosistema Kubernetes. Questa flessibilità consente alle risorse personalizzate di comportarsi come componenti nativi di Kubernetes.

Sebbene le risorse personalizzate funzionino in modo simile alle risorse native, presentano importanti distinzioni che influiscono sul modo in cui vengono utilizzate e gestite all’interno di Kubernetes. Esploriamo queste differenze tra risorse native e personalizzate.

Risorse native vs Risorse personalizzate

Sebbene le API di Kubernetes gestiscano entrambe, presentano differenze nella struttura, nel comportamento e nello scopo.

Comprendendo queste differenze, possiamo capire meglio come funzionano le CRD e perché consentono agli sviluppatori di creare risorse personalizzate. Esploriamo ulteriormente questi concetti nella prossima sezione.

Come funzionano le CRD?

Le CRD possono essere utilizzate per estendere le funzionalità di Kubernetes e soddisfare le esigenze specifiche di uno sviluppatore.  Sebbene siano potenti da soli, quando vengono abbinati all’Operator Pattern, sbloccano un nuovo livello di automazione ed efficienza.

Gli operatori sono il “cervello” delle risorse personalizzate. Mentre le CRD definiscono la struttura di una risorsa, gli operatori le danno vita aggiungendo la logica necessaria. Immaginate di gestire un database: operazioni come il ridimensionamento delle risorse in caso di traffico elevato o l’esecuzione di backup a intervalli regolari possono essere automatizzate con un operatore. Tuttavia, è importante notare che la creazione di un operatore richiede una logica personalizzata che deve essere progettata con cura e testata a fondo per garantire l’affidabilità. Una volta implementati, gli operatori possono anche intervenire per ripristinare i sistemi se qualcosa va storto, aggiungendo un valore significativo alla vostra configurazione Kubernetes.

Questo tipo di automazione è particolarmente importante per le applicazioni che devono gestire e memorizzare lo stato in modo coerente. Con l’Operator Pattern, gli sviluppatori possono programmare Kubernetes non solo per gestire queste risorse personalizzate, ma anche per ottimizzarle in base a esigenze specifiche. Gli operatori consentono a Kubernetes di gestire le applicazioni con la stessa fluidità con cui gestisce le risorse integrate.

In sostanza, gli operatori portano le CRD a un livello superiore, trasformandoli in potenti strumenti per automatizzare i flussi di lavoro, garantire l’affidabilità e ridurre i costi manuali della gestione di sistemi complessi.

Perchè usare le CRD?

Finora abbiamo analizzato le CRD, spiegando cosa sono, come funzionano e in che modo possono migliorare l’esperienza Kubernetes. Vediamo perché le CRD sono essenziali in vari casi d’uso:

Automatizzano flussi di lavoro complessi con controller personalizzati.

Abbinando le CRD ai controller personalizzati, è possibile automatizzare flussi di lavoro complessi specifici per le risorse personalizzate. Le CRD aiutano a creare risorse che si adattano alle esigenze uniche degli sviluppatori. Ad esempio, una risorsa VideoEncoder personalizzata può automatizzare il ridimensionamento tra le regioni, aggiungendo o rimuovendo pod in base alla domanda. I controller gestiscono anche i guasti dei pod ricreandoli automaticamente, garantendo la disponibilità. Inoltre, gestiscono attività di routine come i backup o la pulizia delle risorse, contribuendo a ottimizzare le prestazioni.

Aiutano a mantenere omogeneità tra i team

Immaginate una grande azienda di videogiochi come Sony, dove diversi team gestiscono vari aspetti dell’applicazione, come lo sviluppo dei giochi e la distribuzione dei contenuti. Le CRD consentono di creare tipi di risorse standardizzate e riutilizzabili da tutti i team. Ad esempio, il team di sviluppo dei giochi in una sede e il team di distribuzione dei contenuti in un’altra possono entrambi utilizzare lo stesso schema CRD. Questo garantisce coerenza e configurazioni uniformi, indipendentemente dalla sede dei team e dai componenti gestiti.

Migliorano la scalabilità e l’estensibilità a lungo termine

Uno dei vantaggi principali delle CRD è la loro capacità di scalare ed evolvere insieme alle esigenze dell’organizzazione. Man mano che le applicazioni crescono, le CRD consentono di integrare nuove funzionalità, supportare diversi carichi di lavoro e adattarsi ai cambiamenti del mercato senza dover rivedere l’infrastruttura esistente. Le CRD sono una soluzione plug-and-play che consente una facile espansione. Che si tratti di aggiungere funzionalità ai servizi di gioco o di scalare le risorse, le CRD semplificano il processo di gestione ed evoluzione delle applicazioni.

Usare le CRD con Mia-Platform Console

Invece di creare una risorsa personalizzata da zero, Mia-Platform Console offre un approccio semplificato. All’interno della sua interfaccia facile da usare per gli sviluppatori, è possibile definire, deployre e gestire facilmente le risorse infrastrutturali, integrandole senza problemi con la propria applicazione. Mia-Platform consente di gestire facilmente risorse personalizzate e strumenti Infrastructure-as-Code (IaC) come Terraform o Crossplane, tutti integrati direttamente nelle funzioni di gestione dell’infrastruttura. Definendo le risorse infrastrutturali, è possibile gestire facilmente le CRD nel proprio cluster Kubernetes o persino effettuare il provisioning di nuovi cluster utilizzando lo strumento IaC preferito.

È facile creare e gestire risorse su Mia-Platform. Avete due opzioni per creare queste risorse: creare una nuova risorsa personalizzata dal marketplace o crearne una da zero.

Per creare la risorsa da zero, la piattaforma fornisce una console facile da usare che indica dove è possibile compilare campi come apiVersion, tipo e metadati. Una volta impostata la risorsa, è possibile monitorare, aggiornare e versionare le risorse personalizzate all’interno della piattaforma, consentendo regolazioni rapide e un’integrazione fluida con la configurazione Kubernetes esistente. Ecco come si presenta:

Mia-Platform Console fornisce anche modelli precostituiti per vari tipi di risorse personalizzate. In questo modo si risparmia lo sforzo e il tempo di creare CRD da zero. È sufficiente sfogliare i modelli e sceglierne uno adatto al proprio caso d’uso. Una volta selezionati, questi modelli possono essere personalizzati in base ai requisiti dell’applicazione.

Quali sono i prossimi passi?

Con l’evoluzione di Kubernetes, cresce la richiesta di una soluzione più robusta e flessibile che permetta agli sviluppatori di modificare Kubernetes in base alle proprie esigenze senza sentirsi limitati dalle risorse integrate. Anche le definizioni di risorse personalizzate di Kubernetes si sono dimostrate strumenti efficaci all’interno dell’ecosistema Kubernetes. 

Consentono agli sviluppatori di progettare risorse su misura per le loro applicazioni o richieste di software, ampliando le capacità di Kubernetes. Consentono l’automazione, la scalabilità e la personalizzazione, rendendo la piattaforma più flessibile, adattabile ed efficiente per vari flussi di lavoro.

Con strumenti come Mia-Platform, potete distribuire le vostre moderne configurazioni Kubernetes senza problemi in pochi minuti. Consultate questo white paper, che illustra gli usi reali e fornisce una panoramica di Kubernetes.