Implementazioni Kubernetes: una guida completa

Kubernetes, uno dei preferiti dalla comunità degli sviluppatori, è una piattaforma ampiamente utilizzata per l’esecuzione di contenitori Docker in cluster. Questa potente piattaforma offre diversi metodi per distribuire e aggiornare le applicazioni in esecuzione nei contenitori, fornendo così un elevato livello di flessibilità per diversi scenari. In Kubernetes, i contenitori vengono eseguiti in pod e la loro implementazione è definita dai Kubernetes Deployments. Questo post del blog tratta i Kubernetes Deployments, i loro tipi, le strategie di implementazione e le procedure consigliate.

Try NAKIVO Backup & Replication

Try NAKIVO Backup & Replication

Get a free trial to explore all the solution’s data protection capabilities. 15 days for free. Zero feature or capacity limitations. No credit card required.

Che cos’è un’implementazione Kubernetes?

Un’implementazione in Kubernetes è un oggetto risorsa che gestisce la distribuzione e il ciclo di vita delle applicazioni containerizzate nei cluster. Fornisce aggiornamenti alle applicazioni, garantendo che il numero necessario di pod identici sia sempre in esecuzione e disponibile. Fornisce inoltre aggiornamenti dichiarativi per Pod e ReplicaSet. Le implementazioni sono una funzione chiave di Kubernetes per automatizzare la scalabilità, gli aggiornamenti continui e i rollback.L’implementazione è un oggetto Kubernetes che specifica lo stato desiderato per i pod e crea e gestisce i replica set per garantire che tale stato venga mantenuto. Un ReplicaSet gestisce direttamente i pod, compreso il loro stato e numero. La distribuzione indica a Kubernetes come modificare o creare le istanze dei pod che contengono i contenitori con le applicazioni. Lo stato dell’implementazione dei pod è descritto in un manifesto.Gli amministratori possono scalare in modo efficiente il numero di pod replica, eseguire il rollout del codice dell’applicazione aggiornato con un elevato livello di controllo e, se necessario, eseguire il rollback alle versioni precedenti delle implementazioni. Per gestire le implementazioni Kubernetes, gli amministratori utilizzano la riga di comando kubectl su Linux e altri sistemi operativi supportati. Ogni pod creato con una implementazione ha un ReplicaSet correlato a questo pod. Un ReplicaSet, a sua volta, ha un puntatore all’implementazione che ha creato questo ReplicaSet.

Nozioni fondamentali sulle implementazioni Kubernetes

Le implementazioni Kubernetes sono sviluppate per distribuire e garantire la scalabilità di applicazioni containerizzate in cluster. Le implementazioni forniscono un modo dichiarativo per definire lo stato desiderato dell’applicazione e automatizzare il processo per raggiungere e mantenere tale stato. I concetti e i componenti fondamentali relativi alle implementazioni Kubernetes sono:

  • Stato desiderato. L’implementazione definisce lo stato desiderato di un’applicazione, come il numero di repliche di un pod, le immagini dei contenitori da utilizzare e le risorse allocate a ciascun pod.
  • Configurazione dichiarativa. Le implementazioni utilizzano solitamente un approccio dichiarativo, in cui gli amministratori specificano lo stato in un file JSON o YAML. Mentre l’approccio imperativo consente agli amministratori di impostare direttamente cosa fare, l’approccio dichiarativo in Kubernetes consente agli amministratori di definire il risultato obbligatorio e Kubernetes lo raggiungerà con i suoi meccanismi interni. Il controller di implementazione di Kubernetes monitora lo stato di salute dei nodi e dei pod. Se si verificano cambiamenti in tempo reale, come un guasto di un pod, questo pod può essere sostituito. Pertanto, Kubernetes monitora lo stato del cluster in tempo reale e apporta le modifiche necessarie per raggiungere lo stato desiderato.
  • ReplicaSet. Una implementazione gestisce un ReplicaSet. Il ReplicaSet crea ed elimina i pod secondo necessità per mantenere il numero desiderato di repliche. Questo approccio consente a Kubernetes di garantire che le repliche dei pod specificate siano in esecuzione in qualsiasi momento.
  • Aggiornamenti continui. Le implementazioni supportano gli aggiornamenti continui, che consentono di aggiornare l’applicazione senza tempi di inattività. Kubernetes sostituisce gradualmente i vecchi pod con quelli nuovi, contribuendo a garantire che l’applicazione containerizzata rimanga disponibile durante il processo di aggiornamento dell’implementazione.
  • RollbackSe qualcosa va storto durante un aggiornamento in Kubernetes, è possibile ripristinare una versione precedente dell’implementazione, riportando l’applicazione a uno stato noto e in buono stato.

Configurazione dichiarativa

In Kubernetes, un approccio dichiarativo significa che si specifica lo stato desiderato del sistema e Kubernetes intraprende le azioni necessarie per raggiungere e mantenere tale stato. Si descrive l’obiettivo finale utilizzando file di configurazione (in genere scritti in YAML o JSON) e Kubernetes lavora continuamente per garantire che lo stato effettivo corrisponda a quello desiderato.L’approccio dichiarativo è generalmente preferito in Kubernetes perché consente di mantenere la coerenza dello stato desiderato, facilita l’automazione e supporta una migliore collaborazione e controllo delle versioni. L’approccio imperativo può essere utile per attività rapide e ad hoc, ma è meno adatto alla gestione di implementazioni complesse e a lungo termine di applicazioni.

Come funzionano insieme implementazioni, pod e replica set

In Kubernetes, Deployments, Pods e ReplicaSets sono componenti strettamente correlati che gestiscono collettivamente l’implementazione, la scalabilità e il ciclo di vita delle applicazioni. È importante comprendere la relazione tra loro e sapere come funzionano insieme in Kubernetes per una corretta configurazione.

  • A Pod è l’oggetto più semplice e più piccolo in un cluster Kubernetes e rappresenta una singola istanza di un processo in esecuzione. Un Pod può contenere uno o più contenitori che condividono gli stessi volumi di storage e lo stesso namespace di rete. I Pod sono effimeri per definizione, poiché possono essere creati e distrutti secondo necessità per adattarsi allo stato desiderato specificato da oggetti di livello superiore come le implementazioni.
  • A ReplicaSet garantisce che un numero specificato di Pod identici sia in esecuzione in un dato momento. Gestisce la creazione e l’eliminazione dei Pod per mantenere il numero desiderato di repliche. Ogni ReplicaSet utilizza selettori di etichette per identificare e gestire i Pod sotto il suo controllo, garantendo il mantenimento dei Pod corretti. Sebbene sia possibile creare e gestire direttamente i ReplicaSet, questi sono in genere gestiti dai Deployment, che forniscono funzionalità aggiuntive.
  • A Implementazione è un oggetto Kubernetes di livello superiore che gestisce i ReplicaSet e fornisce aggiornamenti dichiarativi alle applicazioni. Le implementazioni consentono agli amministratori di definire lo stato necessario dell’applicazione e altre impostazioni, come spiegato sopra.

Quando si crea o si aggiorna una implementazione, viene automaticamente creato un nuovo ReplicaSet per gestire i pod in base alle specifiche definite. Ogni volta che si aggiorna una implementazione, viene creato un nuovo ReplicaSet per gestire la nuova versione dei pod, mentre il vecchio ReplicaSet rimane fino a quando i nuovi pod non vengono distribuiti con successo. Ciò garantisce che gli aggiornamenti vengano implementati in modo controllato, mantenendo la disponibilità dell’applicazione.L’implementazione gestisce il ciclo di vita dei Pod indirettamente attraverso i suoi ReplicaSet. Definendo lo stato desiderato nell’implementazione, si specificano le caratteristiche e il numero di Pod che si desidera eseguire. L’implementazione garantisce quindi questo stato gestendo i ReplicaSet appropriati, che a loro volta gestiscono i Pod.Pertanto, i pod sono le unità di esecuzione che eseguono i contenitori, i ReplicaSet garantiscono che sia in esecuzione il numero necessario di pod e le implementazioni forniscono la gestione dichiarativa e gli aggiornamenti per le applicazioni controllando i ReplicaSet. Questa struttura gerarchica garantisce che le applicazioni siano scalabili, con resilienza e facili da gestire. Le implementazioni astraggono le complessità della gestione diretta dei ReplicaSet e dei pod, offrendo un modo potente per gestire gli aggiornamenti e la scalabilità delle applicazioni.

Dettagli sulla configurazione dell’implementazione

L’uso di YAML per l’implementazione in Kubernetes è una pratica comune grazie alla sua leggibilità e semplicità. Kubernetes supporta sia il formato YAML che JSON per i file di configurazione, ma YAML è più diffuso grazie alla sua sintassi intuitiva.YAML (YAML Ain’t Markup Language) è uno standard di serializzazione dei dati leggibile dall’uomo e facile da scrivere. È comunemente utilizzato per i file di configurazione e lo scambio di dati tra linguaggi con strutture di dati diverse. In Kubernetes, YAML viene utilizzato per definire lo stato desiderato di vari oggetti, tra cui implementazioni, Servizi, Pod e altro ancora.Componenti chiave di un file di distribuzione YAML:

  • apiVersion viene utilizzato per specificare la versione API (ad esempio, apps/v1) dell’oggetto Kubernetes.
  • gentile specifica il tipo di oggetto Kubernetes (ad esempio, implementazione).
  • metadati contiene metadati relativi all’oggetto, come il nome e le etichette.
  • specifiche (specifica) viene utilizzata per definire lo stato desiderato dell’oggetto Kubernetes, tra cui:
    • repliche specifica il numero di repliche del pod da mantenere.
    • selettore specifica come identificare i pod gestiti dall’implementazione.
    • modello definisce il modello del pod, inclusi i metadati e le specifiche dei pod.
    • contenitori elenca i contenitori all’interno del pod, inclusi:
      • nome: il nome del contenitore
      • [image]: l’immagine docker da utilizzare
      • porte: le porte da esporre

Le differenze tra YAML e JSON per la sintassi di configurazione dell’implementazione Kubernetes sono:

  • YAML è più leggibile dall’uomo, poiché utilizza indentazioni e coppie chiave-valore senza parentesi graffe o parentesi.
  • JSON utilizza una struttura più rigida con parentesi graffe ({}) e parentesi quadre ([]), rendendolo meno leggibile per configurazioni complesse.

YAML è solitamente preferito per le implementazioni Kubernetes.

Esempio di implementazione YAML

Di seguito è riportato un esempio di implementazione Kubernetes in formato YAML con configurazioni dettagliate per pod e contenitori.apiVersion: apps/v1tipo: Implementazionemetadati:  nome: nome-implementazionespecifiche:  repliche: 3  selettore:    matchLabels:      app: nome-app  modello:    metadati:      etichette:        app: nome-app    specifiche:      contenitori:      – nome: nome-contenitore        immagine: nome-immagine:1.0        porte:        – porta del contenitore: 80        resources:          richieste:            memoria: “128Mi”            CPU: “250 m”          limiti:            memoria: “256Mi”            CPU: “500 m”        env:        – nome: MY_ENV_VAR          valore: “qualche valore”        volumeMounts:        – mountPath: “/percorso/volume”          nome: nome-volume      volumi:      – nome: nome-volume        persistentVolumeClaim:          nomeRichiesta: nome-pvcSpieghiamo ogni sezione in dettagli per renderla più chiara. Configurando queste sezioni, è possibile definire un’implementazione dell’applicazione robusta e scalabile in Kubernetes, assicurando che i pod e i contenitori siano configurati in base ai propri requisiti.

Sezioni principali della configurazione

1. Metadatimetadati:  nome: nome-implementazioneDove:nome: il nome dell’implementazione2. Spec (Specifiche di implementazione)specifiche:  repliche: 3  selettore:    matchLabels:      app: nome-appDove:repliche: il numero di repliche del pod da mantenereselettore: definisce come identificare i pod gestiti dall’implementazione utilizzando le etichette3. Modello di pod (specifiche del pod)modello:  metadati:    etichette:      app: nome-app  specifiche:    contenitori:    – nome: nome-contenitore      immagine: nome-immagine:1.0Dove:metadati: etichette per identificare i baccellispecifiche: configurazione dei pod e dei relativi contenitori

Configurazione dei contenitori

In questa parte è possibile vedere le sezioni YAML delle implementazioni per configurare i contenitori.1. Immagine del contenitoreimmagine: nome-immagine:1.0Dove:image: l’immagine del contenitore da utilizzare. Può includere un tag (ad esempio, 1.0) per specificare la versione.2. Porte.porte:– porta del contenitore: 80Dove:containerPort: la porta su cui il contenitore ascolterà il traffico3. Richieste e limiti delle risorseresources:  richieste:    memoria: “128Mi”    CPU: “250 m”  limiti:    memoria: “256Mi”    CPU: “500 m”Dove:richieste: i requisiti minimi necessarilimiti: le risorse massime che il contenitore può utilizzare4. Variabili d’ambienteenv:– nome: MY_ENV_VAR  valore: “qualche valore”Dove:env: definisce le variabili di ambiente per il contenitore5. Montaggi dei volumivolumeMounts:– mountPath: “/percorso/volume”  nome: nome-volumeDove:volumeMounts: specifica i volumi da montare all’interno del contenitoremountPath: il percorso all’interno del contenitore in cui verrà montato il volume

Configurazione dei volumi

Il volumi La sezione è responsabile della configurazione dei volumi.volumi:– nome: nome-volume  persistentVolumeClaim:    nomeRichiesta: nome-pvcDove:volumi: definisce i volumi disponibili per il montaggionome: il nome del volumepersistentVolumeClaim: specifica un PersistentVolumeClaim (PVC) da utilizzare per il volume

Configurazioni avanzate

1. Prove di vitalità e prontezzalivenessProbe:  httpGet:    percorso: /healthz    porta: 8080  ritardoInizialeInSecondi: 3  periodSeconds: 3readinessProbe:  httpGet:    percorso: /pronto    porta: 8080  ritardoInizialeInSecondi: 5  periodSeconds: 10Dove:livenessProbe: controlla se il contenitore è attivoreadinessProbe: viene utilizzato per verificare se il contenitore corrente è pronto ad accettare traffico2. Comando e argomenticomando: [“my-command”]argomenti: [“arg1”, “arg2”]Dove:comando: sovrascrive il punto di ingresso predefinito del contenitoreargomenti: specifica gli argomenti del comando3. ConfigMap e segretienvDa:– configMapRef:  nome: my-configmap– secretRef:  nome: il-mio-segretoDove:envDa: importa le variabili d’ambiente da un ConfigMap o da un segreto

La strategia di implementazione di Kubernetes

Esistono diverse strategie (tipi) di implementazione di Kubernetes ed è possibile selezionare quella più efficace per il proprio scenario attuale. Le applicazioni aziendali hanno requisiti diversi in termini di uptime e disponibilità. Selezionando la strategia giusta è possibile evitare tempi di inattività e interruzioni del servizio, nonché utilizzare le risorse in modo efficace. Di seguito sono riportati i tipi di implementazione di Kubernetes più comuni.

Aggiornamenti continui e rollback

Un aggiornamento graduale presuppone la migrazione da una versione dell’applicazione a un’altra, la versione più recente nell’ordine definito. Viene avviato un nuovo ReplicaSet con la nuova versione dell’applicazione. Le repliche della versione precedente vengono terminate. Di conseguenza, i pod della versione precedente vengono sostituiti con quelli nuovi. L’aggiornamento graduale offre la possibilità di passare agevolmente dalle versioni precedenti a quelle nuove, ma l’operazione richiede un po’ di tempo per essere completata.

Ricrea implementazione

I pod attualmente in esecuzione vengono terminati e quindi ricreati con una nuova versione. Questa strategia di implementazione è comunemente utilizzata negli ambienti Kubernetes per gli sviluppatori in cui l’attività degli utenti non è un problema. Si verifica un periodo di inattività quando la vecchia implementazione viene chiusa, la strategia di ricreazione avvia le nuove istanze di implementazione e ricrea i pod e lo stato dell’applicazione.

Implementazioni blu-verde

L’implementazione Blue-Green è un altro modo per aggiornare le applicazioni in Kubernetes, ma con una transizione rapida. L’implementazione Blue-Green di Kubernetes presuppone l’esecuzione di due ambienti: la versione precedente (blu) e quella nuova (verde). Entrambe vengono implementate “affiancate” o in parallelo. Una volta che la nuova versione è stata testata e ne è stato confermato il corretto funzionamento (funziona come previsto), l’etichetta della versione viene sostituita aggiornando il Service Selector. Questa azione viene eseguita per un oggetto Kubernetes Service che esegue il bilanciamento del carico in un cluster. Successivamente, il traffico viene immediatamente trasferito alla nuova versione.La strategia di implementazione Blue-Green di Kubernetes consente agli amministratori di eseguire un rapido rollout senza i problemi causati dalle diverse versioni durante la transizione tra di esse. È importante tenere presente che l’utilizzo delle risorse è maggiore perché due ambienti funzionano in parallelo per un certo periodo.

Implementazioni Canary

La distribuzione canary di Kubernetes presuppone che solo un piccolo gruppo di utenti venga indirizzato alla nuova versione di un’applicazione containerizzata. La nuova versione viene eseguita su un sottoinsieme di pod più piccolo rispetto alla versione precedente che era in esecuzione fino a quel momento. Lo scopo principale delle implementazioni canary è quello di testare la funzionalità delle nuove versioni dell’applicazione in un ambiente di produzione. Se nella nuova versione non vengono rilevati errori, gli amministratori procedono al potenziamento della nuova versione e la versione precedente viene sostituita nell’ordine appropriato.Se dopo l’implementazione della nuova versione per un piccolo gruppo di utenti si verificano problemi, gli amministratori possono ripristinare le implementazioni canary alla versione precedente. Il vantaggio è la possibilità di testare le nuove funzionalità su un piccolo gruppo di utenti senza il rischio di effetti negativi sul funzionamento complessivo del sistema.

Kubernetes Ricrea implementazione

Quando si utilizza la funzione Ricrea implementazione, tutti i pod vengono terminati e sostituiti con la nuova versione. Questa strategia può essere utilizzata quando la versione precedente e quella nuova non possono essere eseguite contemporaneamente. Il tempo di inattività dipende dal tempo necessario per arrestare l’applicazione precedente e avviare quella nuova nei contenitori. Al termine, lo stato dell’applicazione è completamente rinnovato.

Scalabilità e gestione

La scalabilità e la gestione delle implementazioni Kubernetes sono fondamentali per garantire che le applicazioni containerizzate possano funzionare con carichi di lavoro variabili e mantenere un’elevata disponibilità. Kubernetes fornisce meccanismi robusti per la scalabilità sia manuale che automatica, nonché strumenti per gestire le implementazioni in modo efficiente.

Scalabilità manuale

La scalabilità manuale viene utilizzata per regolare manualmente il numero di repliche (istanze) dell’applicazione utilizzando il comando kubectl strumento a riga di comando.

  • Scalabilità:

    kubectl scale implementazione nome-distribuzione repliche=10

    Questo comando aumenta il numero di repliche per l’implementazione my-deployment a 10.

  • Scalabilità:

    kubectl scale implementazione nome-distribuzione repliche=2

    Questo comando riduce il numero di repliche per l’implementazione my-deployment a 2.

Autoscaler pod orizzontale (HPA)

L’Horizontal Pod Autoscaler (HPA) regola automaticamente il numero di repliche dei pod in base all’utilizzo della CPU osservato o ad altre metriche selezionate.

  1. Il comando per creare un HPA è:

    kubectl autoscale implementazione nome-distribuzione percentuale CPU=50 min=2 max=10

    Questo comando configura un HPA per nome-implementazione mantenere l’utilizzo della CPU intorno al 50%, con una scalabilità tra 2 e 10 repliche.

  2. La configurazione HPA in YAML è un metodo più avanzato. Di seguito è riportato un esempio di configurazione di implementazione YAML per il ridimensionamento automatico orizzontale.

    apiVersion: autoscaling/v1

    tipo: HorizontalPodAutoscaler

    metadati:

      nome: nome-hpa-implementazione

    specifiche:

      scaleTargetRef:

        apiVersion: apps/v1

        tipo: Implementazione

        nome: nome-implementazione

      minReplicas: 2

      maxReplicas: 10

      percentuale di utilizzo della CPU target: 50

    Applica la configurazione YAML con:

    ubectl apply -f hpa.yaml

Vertical Pod Autoscaler (VPA)

Il Vertical Pod Autoscaler (VPA) regola automaticamente le richieste di risorse e i limiti dei pod in base all’utilizzo effettivo. La configurazione VPA in YAML è la seguente:apiVersion: autoscaling.k8s.io/v1tipo: VerticalPodAutoscalermetadati:  nome: nome-implementazione-vpaspecifiche:  targetRef:    apiVersion: “apps/v1”    tipo: Implementazione    nome: nome-implementazione  politica di aggiornamento:    modalità di aggiornamento: “Auto”Per applicare la configurazione YAML, utilizzare il comando:kubectl apply -f vpa.yaml

Procedure consigliate per le implementazioni Kubernetes

La corretta configurazione delle implementazioni Kubernetes garantisce un ambiente affidabile e di successo per l’esecuzione di applicazioni containerizzate. Una configurazione errata o una strategia di gestione delle implementazioni non corretta possono causare tempi di inattività, perdita di dati e altri problemi. Le procedure consigliate per le implementazioni Kubernetes aiutano a garantire che le applicazioni siano resilienti, scalabili e gestibili.

  • Utilizza la configurazione dichiarativa. Archivia le configurazioni Kubernetes in file con controllo delle versioni in formato YAML/JSON. Ciò semplifica la gestione delle modifiche e il ripristino, se necessario. Utilizza kubectl apply -f applicare queste configurazioni, poiché consente operazioni idempienti, garantendo che lo stato del cluster corrisponda ai file di configurazione.
  • Utilizza l’isolamento dello spazio dei nomi. Utilizza gli spazi dei nomi per isolare logicamente diversi ambienti (ad esempio, sviluppo, staging, produzione) e team. Ciò consente di gestire le risorse e le autorizzazioni in modo più efficace.
  • Richieste e limiti delle risorse. Definisci le richieste e i limiti delle risorse per i tuoi pod per garantire che dispongano delle risorse necessarie e per evitare conflitti di risorse.
  • Sonde di vivacità e prontezza. Configurare i test di integrità per riavviare i contenitori non funzionanti e i test di disponibilità per controllare il traffico verso i contenitori.
  • Utilizza etichette e selettori organizzare e selezionare le risorse. Le etichette possono essere utilizzate per raggruppare le risorse per applicazione, ambiente, versione, ecc.
  • Utilizza ConfigMap e segreti. Archivia i dati di configurazione non sensibili in ConfigMaps. Archivia i dati sensibili, comprese le password e le chiavi API, in Secrets.
  • Monitorare e registrare il proprio ambienteImplementa il monitoraggio utilizzando strumenti come Grafana e Prometheus per verificare le prestazioni e lo stato delle tue applicazioni containerizzate. Utilizza soluzioni di registrazione centralizzate come ELK stack (Elasticsearch, Logstash, Kibana) o Fluentd per raccogliere e analizzare i log.
  • Segui le procedure consigliate per la sicurezza. Implementa i criteri di sicurezza dei pod per applicare gli standard di sicurezza sui tuoi pod. Utilizza i criteri di rete per le implementazioni Kubernetes per controllare il traffico tra i pod.
  • Prepararsi per i backup e il ripristino di emergenza. Eseguite backup regolari delle vostre risorse Kubernetes e dei dati persistenti. Pianificate e testate strategie di ripristino di emergenza per garantire che le applicazioni e i servizi possano essere ripristinati rapidamente in caso di guasto.

Conclusione

Le implementazioni Kubernetes svolgono un ruolo cruciale nella gestione del ciclo di vita delle applicazioni all’interno di un cluster Kubernetes. Forniscono un approccio dichiarativo alla definizione dello stato desiderato delle applicazioni, compreso il numero di repliche, le immagini dei contenitori e le impostazioni di configurazione. Orchestrando i ReplicaSet, le implementazioni assicurano che il numero specificato di pod sia in esecuzione e gestiscono automaticamente gli aggiornamenti e i rollback in modo controllato e senza interruzioni. Ciò si traduce in una maggiore scalabilità, resilienza e facilità di gestione delle applicazioni, rendendo le implementazioni Kubernetes uno strumento essenziale per la distribuzione e il funzionamento delle applicazioni moderne.

Try NAKIVO Backup & Replication

Try NAKIVO Backup & Replication

Get a free trial to explore all the solution’s data protection capabilities. 15 days for free. Zero feature or capacity limitations. No credit card required.

Le persone leggono anche