Come cambiare rapidamente il contesto di Kubernetes con Kubectx e Kubens
Agenzia web » Notizie digitali » Cosa sono le definizioni delle risorse personalizzate (CRD) di Kubernetes?

Cosa sono le definizioni delle risorse personalizzate (CRD) di Kubernetes?

Le definizioni delle risorse personalizzate (CRD) sono estensioni dell'API Kubernetes che possono definire nuovi tipi di oggetti. Pod, ReplicaSet, ConfigMaps e Ingress sono esempi di risorse integrate comuni. I CRD ti consentono di aggiungere tipi completamente nuovi a questo elenco e quindi gestirli utilizzando strumenti Kubernetes familiari come Kubectl.

Il meccanismo CRD è intenzionalmente astratto e può essere utilizzato in diversi modi per archiviare dati e creare nuove funzionalità. Troverai risorse personalizzate in molti popolari strumenti della community: Cert-Manager definisce gli oggetti che rappresentano i certificati SSL e gli emittenti, mentre Helm rappresenta i grafici come il proprio CRD.

Cosa rende una risorsa?

Le risorse Kubernetes definiscono i tipi di dati che puoi archiviare nel tuo cluster. Sono accessibili tramite l'API Kubernetes che fornisce endpoint per creare, elencare e modificare elementi in ogni tipo di risorsa.

Puoi aggiungere risorse personalizzate per archiviare i tuoi dati arbitrari nel tuo cluster. Gli elementi che crei verranno archiviati dal componente del piano di controllo etcd, insieme alle istanze di risorse integrate. Le risorse personalizzate vengono visualizzate automaticamente dall'API, quindi non è necessario configurare i propri strumenti per creare istanze di elementi.

I CRD agiscono come semplici strutture di dati per impostazione predefinita. Sebbene i CRD in natura spesso abbiano i propri comportamenti, questo non è fornito dal meccanismo CRD. I controller e gli operatori Kubernetes personalizzati possono essere utilizzati per implementare funzionalità relative alle risorse personalizzate. Senza un controller, gli elementi in un CRD continueranno a esistere come dati statici nel cluster con cui puoi interagire tramite gli endpoint CRUD forniti dall'API Kubernetes.

I CRD sono componenti dinamici che possono essere creati ed eliminati in qualsiasi momento. Alcuni tipi di oggetti inclusi in Kubernetes sono anche implementati come CRD, il che fornisce una maggiore modularità al centro del cluster.

Creazione di un CRD

I CRD sono essi stessi un tipo di oggetto Kubernetes. Li crei allo stesso modo di qualsiasi altra risorsa, scrivendo un file YAML e applicandolo al tuo cluster:

apiVersion: apiextensions.k8s.io/v1
tipo: Risorsa personalizzataDefinizione
metadati:
  Nome: custom-apps.crds.example.com
spec:
  gruppo: crds.example.com
  versioni:
    - nome: v1
      servito: vero
      conservazione: vero
      schema:
        Schema openAPIV3:
          Digitare: oggetto
          proprietà:
            spec:
              Digitare: oggetto
              proprietà:
                nome dell'applicazione:
                  Digitare: stringa
                app-versione:
                  Digitare: stringa
                conteggio dei rilasci:
                  Digitare: numero intero
  portata: Spazio dei nomi
  nomi:
    plurale: app personalizzate
    singolare: app personalizzata
    tipo: App personalizzata

Usa Kubectl per aggiungere CustomApp CRD al tuo cluster:

$ kubectl apply -f custom-apps-crd.yaml customresourcedefinition.apextensions.k8s.io/custom-apps.crds.example.com creato

Il file YAML definisce un CRD che può essere utilizzato per memorizzare i dati dell'applicazione. I CRD hanno bisogno di a metadata.name et spec.group campo in un formato specifico: il gruppo assume la forma di un sottodominio a cui appartiene il CRD. Lo stesso sottodominio deve essere incluso nei CRD metadata.name . Il valore di names.plural viene aggiunto come nuovo componente del sottodominio per creare la versione finale metadata.name.

La spec.names Il campo definisce come farete riferimento al CRD quando utilizzate l'API Kubernetes e i comandi Kubectl. In questo esempio, puoi eseguire kubectl get custom-apps et kubectl get custom-app/example-app per interagire con oggetti che utilizzano il CRD. Quando crei un nuovo oggetto come file YAML, devi impostare kind: CustomApp per farne un'istanza del CRD.

Il CRD è configurato come tipo di oggetto a livello di spazio dei nomi da scope campo. Puoi usare Cluster come valore alternativo per questo campo per creare oggetti che esistono a livello di cluster, al di fuori di qualsiasi spazio dei nomi.

I dati associati ai tuoi oggetti personalizzati sono definiti in spec.versions.schema.openAPIV3Schema campo. Ogni "versione" elencata crea una nuova versione dell'API CRD a cui puoi fare riferimento con il apiVersion nei tuoi file YAML di risorse. I dati CRD vengono configurati utilizzando le proprietà OpenAPI; qui, ogni "applicazione personalizzata" nel tuo cluster dovrebbe avere app-name, app-versionet release-count proprietà definite nel suo YAML spec.

Usando il tuo CRD

Il provisioning degli endpoint API per un nuovo CRD può richiedere alcuni minuti. Controlla lo stato di avanzamento recuperando i dettagli CRD con Kubectl:

$ kubectl describe crd custom-apps.crds.example.com ... Stato: Nomi accettati: Tipo: CustomApp List Tipo: CustomAppList Plurale: custom-apps Singolare: custom-app Condizioni: Ultima transizione: 2022-04-04 T13: 29:24Z Messaggio: nessun conflitto trovato Motivo: NoConflicts Stato: True Tipo: NamesAccepted Ultimo tempo di transizione: 2022-04-04T13:29:24Z Messaggio: i nomi iniziali sono stati accettati Motivo: InitialNamesAccepted Stato: True Tipo: Stabilito ...

Il CRD è pronto per l'uso quando lo vedi Type: Established verso la fine dell'output del comando. Kubernetes accetterà le richieste all'endpoint dell'API CRD. In questo caso, l'URL dell'API di base sarà:

/apis/custom-apps.crds.example.com/v1/namespaces/*/custom-apps/...

Ora puoi usare Kubectl per visualizzare gli oggetti che sono stati creati con il CRD:

$ kubectl ottieni app personalizzate Nessuna risorsa trovata nello spazio dei nomi predefinito.

Sebbene non esista ancora alcun oggetto, Kubernetes ora sa di avere un tipo di risorsa chiamato custom-apps.

Per creare un oggetto "applicazione personalizzata", scrivi un nuovo file YAML con kind: CustomApp. il apiVersion deve essere impostato sul nome del gruppo e sulla versione API forniti dal CRD. All'interno del spec includere le proprietà definite nello schema CRD.

apiVersion: crds.example.com/v1
tipo: App personalizzata
metadati:
  Nome: demo-app-1
spec:
  nome dell'applicazione: applicazione demo
  app-versione: 1.1.0
  conteggio dei rilasci: 5

Usa Kubectl per aggiungere l'oggetto al tuo cluster:

$ kubectl apply -f custom-app.yaml customapp.crds.example.com/demo-app creato

Ora puoi recuperare i dettagli dell'oggetto usando i soliti comandi Kubectl:

$ kubectl describe custom-app/demo-app-1 Nome: demo-app Spazio dei nomi: default Etichette: Appunti: Versione API: crds.example.com/v1 Tipo: CustomApp ... Specifiche: App - Nome: app demo App - Versione: 1.1.0 Release - Conteggio: 5 ... Eventi:

Hai una risorsa personalizzata funzionante che ora archivia alcuni dati nel tuo cluster Kubernetes. Puoi rimuovere il CRD eliminandolo in Kubectl; questo ripulirà automaticamente tutti gli oggetti che lo utilizzano.

$ kubectl elimina crd custom-apps.crds.example.com customresourcedefinition.apextensions.k8s.io "custom-apps.crds.example.com" eliminato

Creazione di API dichiarative con CRD

Questo CRD non aggiunge alcuna funzionalità al cluster. Memorizza i dati, fornisce un'API per interagire con essi e può essere referenziato da altri oggetti. I CRD diventano più potenti se associati a un controller personalizzato che può assumersi la responsabilità della loro gestione.

I controllori tengono traccia delle risorse e agiscono in risposta ai loro eventi. Scrivere un controller per i tuoi CRD ti consente di trasformarli in API dichiarative che guidano un cambiamento reale all'interno del tuo cluster. I tuoi oggetti possono rappresentare il voulu stato, invece del preciso stato attuale.

Cert-Manager utilizza questo modello per acquisire automaticamente i certificati SSL quando vengono visualizzati nuovi oggetti CertificateRequest nel tuo cluster. All'interno del core Kubernetes, i nodi estraggono ed eseguono le immagini del contenitore in risposta alla generazione dei pod. I controller ti consentono di allegare il comportamento ai tuoi CRD, quindi l'aggiunta di un'"applicazione personalizzata" potrebbe comportare il recupero della sua configurazione da un servizio esterno. Puoi iniziare a creare controller utilizzando Go SDK per integrare il tuo codice con il runtime Kubernetes.

Quando usare i CRD?

I CRD sono utilizzati al meglio per gestire i dati interni all'organizzazione, al team o al progetto. Sono progettati per rappresentare schemi chiaramente definiti, sia come valori statici che come API dichiarative supportate da un'implementazione di controller personalizzata.

Le funzionalità avanzate consentono di implementare routine di convalida per i campi nello schema. Puoi anche utilizzare i finalizzatori per gestire le eliminazioni di oggetti e adottare il sistema di controllo delle versioni per gestire le modifiche alle definizioni CRD.

I CRD a volte si sovrappongono a Kubernetes ConfigMaps. Sono oggetti integrati per la memorizzazione di dati di configurazione generici associati alle applicazioni. Un ConfigMap è appropriato quando si consumano i valori in un punto specifico del cluster, ad esempio un pod che accede alle impostazioni del database come variabili di ambiente iniettate da un ConfigMap.

I CRD sono destinati all'uso quando i dati devono essere cittadini di prima classe nel tuo cluster. Puoi creare più istanze del tipo di risorsa CRD, interagire direttamente con esse utilizzando Kubectl e creare schemi strutturati personalizzati che guidano gli utenti all'immissione di valori corretti. Potrebbero essere una scelta migliore quando i dati esistono indipendentemente da qualsiasi altra cosa nel tuo cluster.

sommario

Le definizioni delle risorse personalizzate (CRD) di Kubernetes definiscono nuovi tipi di oggetti che puoi utilizzare con l'API Kubernetes e Kubectl. Ogni CRD ottiene la propria API con versione, ha uno schema strutturato e può essere usato per implementare nuove funzionalità nel cluster se supportato da un controller complementare.

I CRD a volte possono sembrare complicati e riservati a situazioni avanzate. Questo non deve essere il caso. Semplici CRD per la memorizzazione di valori statici nel tuo cluster sono facili da creare, come dimostrato dall'esempio di "applicazione personalizzata" sopra. Possono essere utilizzati per contenere dati di cluster autonomi in modo che ricevano un trattamento di prima classe in Kubernetes.

È anche importante riconoscere dove i CRD non si adattano. Gli oggetti integrati come ConfigMaps e Secrets sono progettati per ospitare la maggior parte delle forme di configurazione che verranno utilizzate direttamente dai pod dell'app. La scrittura di un CRD che definisce lo schema del file di configurazione dell'applicazione è in genere non necessaria e più difficile da mantenere nel tempo perché non si trarranno vantaggio dalle funzionalità di ConfigMap come gli aggiornamenti continui automatici e l'iniezione di variabili di ambiente.

★ ★ ★ ★ ★