IBM Cloud Docs
Pianificazione delle distribuzioni dell'applicazione

Pianificazione delle distribuzioni dell'applicazione

Prima di distribuire un'applicazione nel cluster IBM Cloud Kubernetes Service, si deve decidere come impostare l'applicazione, in modo che sia accessibile correttamente e possa essere integrata con altri servizi in IBM Cloud.

Spostamento dei carichi di lavoro in IBM Cloud Kubernetes Service

Scopri quali tipi di carichi di lavoro possono essere eseguiti su IBM Cloud Kubernetes Service e il modo ottimale per configurarli.

Che tipo di applicazioni posso eseguire in IBM Cloud Kubernetes Service?

Applicazioni senza stato
Le applicazioni senza stato sono preferibili per ambienti nativi del cloud, quale Kubernetes. Sono semplici da migrare e ridimensionare, poiché dichiarano le dipendenze, archiviano le configurazioni separatamente dal codice e gestiscono i servizi di backup, quali i database, come risorse collegate piuttosto che abbinate all'applicazione. I pod delle app non richiedono uno storage persistente dei dati o un indirizzo IP di rete stabile e, pertanto, possono essere terminati, riprogrammati e scalati in risposta alle richieste del carico di lavoro. L'applicazione utilizza un Database-as-a-Service per i dati persistenti, e servizi NodePort, di bilanciamento del carico o Ingress per esporre il carico di lavoro su un indirizzo IP stabile.
Applicazioni con stato
Rispetto alle applicazioni senza stato, le applicazioni con stato sono più difficili da configurare, gestire e ridimensionare, poiché i pod richiedono dati persistenti e un'identità di rete stabile. Le applicazioni con stato sono spesso costituite da database o altri carichi di lavoro distribuiti con utilizzo intensivo di dati, in cui l'elaborazione è più efficiente vicino ai dati stessi. Se desideri distribuire un'applicazione con stato, devi configurare l'archiviazione persistente e montare un volume persistente per il pod controllato da un oggetto StatefulSet. Puoi scegliere di aggiungere un'archiviazione file, blocchi od oggetti come archiviazione persistente per la tua serie con stato. È inoltre possibile installare Portworx sui nodi worker bare metal e utilizzare Portworx come soluzione di storage software-defined altamente disponibile per gestire lo storage persistente delle applicazioni stateful. Per ulteriori informazioni sul funzionamento dei set con stato, consultare la documentazione Kubernetes.

Quali sono le linee guida per lo sviluppo di applicazioni native del cloud senza stato?

Verificate la Twelve-Factor App, una metodologia neutra dal punto di vista linguistico per valutare come sviluppare la vostra applicazione attraverso 12 fattori, riassunti come segue.

  1. Base di codice: utilizzare una singola base di codice in un sistema di controllo versione per le distribuzioni. Quando estrai un'immagine per la distribuzione del tuo contenitore, specifica una tag dell'immagine testata invece di utilizzare latest.
  2. Dipendenze: dichiara esplicitamente e isola le dipendenze esterne.
  3. Configurazione: memorizza la configurazione specifica della distribuzione nelle variabili di ambiente, non nel codice.
  4. Servizi di supporto: gestisci i servizi di supporto, quali archivi dati o code di messaggi, come risorse collegate o sostituibili.
  5. Fasi dell'applicazione: crea in fasi distinte quali build, release, run, con una separazione netta delle fasi.
  6. Processi: esegui come uno o più processi senza stato che non condividono nulla e utilizzano l'archiviazione persistente per il salvataggio dei dati.
  7. Bind delle porte: i bind delle porte sono autonomi e forniscono un endpoint del servizio su un host e una porta ben definiti.
  8. Simultaneità: gestisci e ridimensiona la tua applicazione attraverso istanze di processo quali repliche e adattamento orizzontale. Imposta limiti o richieste di risorse per le tue distribuzioni. Si noti che i criteri di rete di Calico non possono limitare la larghezza di banda. Valuta, invece, Istio.
  9. Disponibilità: progetta la tua applicazione in modo che sia disponibile, con avvio minimo, arresto normale e tolleranza delle chiusure improvvise dei processi. Ricorda che contenitori, pod e nodi di lavoro sono fatti per essere disponibili, quindi pianifica la tua applicazione di conseguenza.
  10. Parità tra sviluppo e produzione: Impostare una pipeline di continuous integration e continuous delivery per la vostra applicazione, con differenze minime tra l'applicazione in sviluppo e quella in produzione.
  11. Log: gestisci i log come flussi di eventi: processi degli ambienti esterni o di hosting e file di log degli instradamenti. Importante: in IBM Cloud Kubernetes Service, i log non vengono attivati per impostazione predefinita. Per abilitarli, vedi Configurazione dell'inoltro dei log.
  12. Processi amministrativi: Mantenere gli script di amministrazione una tantum con l'applicazione ed eseguirli come oggetto Job Kubernetes per garantire che gli script di amministrazione vengano eseguiti nello stesso ambiente dell'applicazione stessa. Per l'orchestrazione di pacchetti più grandi che si vogliono eseguire nei cluster Kubernetes, si consideri l'uso di un gestore di pacchetti come Helm.

E le applicazioni senza server?

Puoi eseguire lavori e applicazioni senza server tramite il servizio IBM Cloud Code Engine. Code Engine può anche creare le immagini per te. Code Engine è progettato in modo da non dover interagire con la tecnologia sottostante su cui è costruito. Tuttavia, se hai uno strumento esistente basato su Kubernetes o Knative, puoi ancora utilizzarlo con Code Engine. Per ulteriori informazioni, vedi Utilizzo di Kubernetes per l'interazione con la tua applicazione.

Ho già un'applicazione. Come posso eseguirne la migrazione a IBM Cloud Kubernetes Service?

Puoi eseguire alcuni passi generali per inserire le tue applicazioni in contenitori, come di seguito descritto.

  1. Utilizzate l'applicazione a dodici fattori come guida per isolare le dipendenze, separare i processi in servizi separati e ridurre il più possibile la statualità dell'applicazione.
  2. Trova un'immagine di base appropriata da utilizzare. È possibile utilizzare immagini disponibili pubblicamente da Docker Hub, immagini pubbliche di IBM o costruire e gestire le proprie nel proprio sito privato IBM Cloud Container Registry.
  3. Aggiungi alla tua immagine Docker solo ciò che occorre per eseguire l'applicazione.
  4. Invece di affidarti all'archiviazione locale, pianifica di utilizzare soluzioni DBaaS (database-as-a-service) cloud o di archiviazione persistente per eseguire il backup dei dati della tua applicazione.
  5. Nel tempo, esegui il refactoring dei processi della tua applicazione in microservizi.

Descrizione degli oggetti Kubernetes per le applicazioni

Con Kubernetes, dichiari numerosi tipi di oggetti nei file di configurazione YAML, quali pod, distribuzioni e job. Questi oggetti descrivono cose quali le applicazioni inserite nei contenitori in esecuzione, le risorse che esse utilizzano e le politiche che ne gestiscono il funzionamento per il riavvio, l'aggiornamento, la replica e altro ancora. Per ulteriori informazioni, consultare i documenti di Kubernetes per le migliori pratiche di configurazione.

Pensavo di dover mettere la mia applicazione in un contenitore. Ora cosa c'entrano i pod?

Un pod è la più piccola unità dispiegabile che Kubernetes può gestire. Collochi il tuo contenitore (o un gruppo di contenitori) in un pod e utilizzi il file di configurazione del pod per dire al pod come eseguire il contenitore e condividere le risorse con altri pod. Tutti i contenitori inseriti in un pod vengono eseguiti in un contesto condiviso, il che significa che condividono la macchina virtuale o fisica.

Cosa mettere in un container
Quando si pensa ai componenti dell'applicazione, si deve considerare se hanno requisiti di risorse significativamente diversi per quanto riguarda CPU e memoria. Ci sono componenti che possono essere eseguiti con il massimo delle risorse? È accettabile che vengano disattivati temporaneamente per deviare delle risorse verso altre aree? Ci sono componenti rivolti agli utenti che devono dunque essere sempre attivi? Suddividili in contenitori distinti. Puoi sempre distribuirli sullo stesso pod, in modo che vengano eseguiti insieme in sincrono.
Cosa mettere in un pod
I contenitori per la tua applicazione non devono sempre essere nello stesso pod. Infatti, se hai un componente senza stato e difficile da ridimensionare, come ad esempio un servizio di database, collocalo in un pod differente pianificabile su un nodo di lavoro che dispone di maggiori risorse per la gestione del carico di lavoro. Se i tuoi contenitori funzionano correttamente se eseguiti su nodi di lavoro diversi, utilizza più pod. Se devono trovarsi nella stessa macchina ed essere ridimensionati insieme, raggruppa i contenitori nello stesso pod.

Se posso usare una capsula, perché ho bisogno di tutti questi tipi di oggetti?

È facile creare un file YAML pod. Puoi scriverne uno di poche righe come di seguito indicato.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Poniamo che tu non voglia limitarti a questo. Se il nodo eseguito dal tuo pod si disattiva, lo fa anche il tuo pod e non viene ripianificato. Si consiglia invece di utilizzare una distribuzione per supportare la riprogrammazione dei pod, i set di repliche e gli aggiornamenti rolling. Creare una distribuzione di base è quasi tanto semplice quanto creare un pod. Invece di definire il contenitore nella stessa spec, specifichi replicas e template nella distribuzione spec. Il modello dispone di una propria spec per i contenitori al suo interno, come di seguito indicato.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Puoi continuare ad aggiungere funzioni, come ad esempio l'anti-affinità pod e limiti delle risorse, tutti nello stesso file YAML.

Per una spiegazione più dettagliata delle diverse caratteristiche che si possono aggiungere al deployment, vedere Creazione del file YAML del deployment dell'applicazione.

Che tipo di oggetti Kubernetes posso creare per la mia applicazione?

Quando prepari il file YAML della tua applicazione, hai molte opzioni per aumentare la disponibilità, le prestazioni e la sicurezza dell'applicazione. Ad esempio, invece di un singolo pod, puoi utilizzare un oggetto controller Kubernetes per gestire il tuo carico di lavoro, ad esempio una serie di repliche, un lavoro o una serie di daemon. Per ulteriori informazioni su pod e controller, consulta la documentazione Kubernetes. Una distribuzione che gestisce una serie di repliche dei pod è un caso di utilizzo comune per un'applicazione.

Ad esempio, un oggetto kind: Deployment è una buona scelta per distribuire un pod dell'applicazione perché con esso puoi specificare una serie di repliche per una maggiore disponibilità dei tuoi pod.

La seguente tabella descrive il motivo per cui potresti creare diversi tipi di oggetti del carico di lavoro Kubernetes.

Tipi di oggetti del carico di lavoro Kubernetes che puoi creare.
Oggetto Descrizione
Pod Un pod è la più piccola unità distribuibile per i tuoi carichi di lavoro e può contenere uno o più contenitori. Simili ai container, i pod sono usa e getta e vengono spesso utilizzati per il test unitario delle funzionalità dell'applicazione. Per evitare tempi di inattività per la tua applicazione, prendi in considerazione la distribuzione di pod con un controller Kubernetes, ad esempio una distribuzione. Una distribuzione ti aiuta a gestire più pod, repliche, ridimensionamento pod, rollout e altro ancora.
ReplicaSet Una serie di repliche garantisce che più repliche del tuo pod siano in esecuzione e ripianifica un pod se si arresta. Puoi creare una serie di repliche per verificare come funziona la pianificazione dei pod, ma per gestire gli aggiornamenti, i rollout e il ridimensionamento dell'applicazione, crea invece una distribuzione.
Deployment Un deployment è un controller che gestisce un pod o un insieme di replica di modelli di pod. Puoi creare pod o serie di repliche senza una distribuzione per testare le funzioni dell'applicazione. Per una configurazione a livello di produzione, utilizza le distribuzioni per gestire gli aggiornamenti, i rollout e il ridimensionamento dell'applicazione.
StatefulSet Analogamente alle distribuzioni, una serie con stato è un controller che gestisce una serie di repliche dei pod. A differenza delle distribuzioni, una serie con stato garantisce che il tuo pod abbia un'identità di rete univoca che mantiene il suo stato dopo la ripianificazione. Quando vuoi eseguire i carichi di lavoro nel cloud, prova a progettare la tua applicazione in modo che sia senza stato
affinché le istanze del servizio siano indipendenti le une dalle altre e possano non riuscire senza provocare un'interruzione del servizio. Tuttavia alcune applicazioni, come i database, devono avere uno stato. Per questi casi, valuta la possibilità di creare una serie con stato e di utilizzare un'archiviazione di file, blocchi o oggetti come archiviazione persistente per la tua serie con stato. È anche possibile installare Portworx sui nodi worker bare metal e utilizzare Portworx come soluzione di archiviazione software-defined altamente disponibile per gestire l'archiviazione persistente per i set stateful.
DaemonSet Utilizza una serie di daemon quando devi eseguire lo stesso pod su ogni nodo di lavoro nel tuo cluster. I pod gestiti da una serie di daemon sono pianificati automaticamente quando un nodo di lavoro viene aggiunto a un cluster. I casi di utilizzo tipici includono programmi di raccolta log, come ad esempio logstash o prometheus, che raccolgono i log da ogni nodo di lavoro per fornire informazioni approfondite sull'integrità di un cluster o di un'applicazione.
Job Un lavoro assicura che uno o più pod vengano eseguiti correttamente fino al completamento. Si può usare un lavoro per code o lavori batch per supportare l'elaborazione parallela di elementi di lavoro separati ma correlati, come fotogrammi specifici da renderizzare, e-mail da inviare e file da convertire. Per programmare l'esecuzione di un lavoro in determinati orari, utilizzare un'opzione CronJob.

Cosa devo fare se voglio che la mia configurazione dell'applicazione utilizzi le variabili? Come si aggiungono queste variabili allo YAML?

Per aggiungere informazioni variabili alle distribuzioni, invece di codificare i dati nel file YAML, si può usare un'opzione Kubernetes ConfigMap o Secret oggetto.

Per utilizzare una mappa di configurazione o un segreto, devi montarli sul pod. La mappa di configurazione o il segreto vengono combinati con il pod subito prima della sua esecuzione. Puoi riutilizzare la specifica e l'immagine di una distribuzione tra molte applicazioni, ma devi quindi sostituire le mappe di configurazione e i segreti personalizzati. I segreti in particolare possono occupare molto spazio di archiviazione sul nodo locale, quindi pianifica di conseguenza.

Entrambe le risorse definiscono coppie chiave-valore, ma puoi usarle per situazioni diverse.

Mappa di configurazione
Fornisci informazioni di configurazione non sensibili per i carichi di lavoro specificati in una distribuzione. Puoi usare le mappe di configurazione in tre modi principali.
  • File system: È possibile montare un intero file o un insieme di variabili su un pod. Un file viene creato per ogni voce in base al contenuto del nome chiave del file impostato sul valore.
  • Variabile d'ambiente: Imposta dinamicamente la variabile d'ambiente per una specifica del contenitore.
  • Opzione della riga di comando: Imposta l'opzione della riga di comando utilizzata in una specifica del contenitore.
Secret
Fornisci informazioni sensibili ai tuoi carichi di lavoro, come quelle che seguono. Altri utenti del cluster potrebbero avere accesso al segreto, quindi assicurati di sapere che le informazioni sul segreto possono essere condivise con tali utenti.
  • Informazioni di identificazione personale (PII): memorizzare informazioni sensibili come indirizzi e-mail o altri tipi di informazioni necessarie per la conformità aziendale o per le normative governative.
  • Credenziali: Mettere in segreto credenziali come password, chiavi e token per ridurre il rischio di esposizione accidentale. Ad esempio, quando esegui il bind di un servizio al tuo cluster, le credenziali vengono memorizzate in un segreto.

Vuoi rendere i tuoi segreti ancora più sicuri? Chiedi al tuo amministratore del cluster di abilitare un provider di servizi di gestione delle chiavi nel tuo cluster per crittografare i segreti nuovi ed esistenti.

Come posso assicurarmi che la mia applicazione abbia le risorse corrette?

Quando si specifica il file YAML dell'applicazione, è possibile aggiungere alla configurazione dell'applicazione le funzionalità di Kubernetes, che aiutano l'applicazione a ottenere le risorse corrette. In particolare, impostare i limiti di risorse e le richieste per ogni contenitore definito nel file YAML.

Inoltre, il tuo amministratore cluster potrebbe configurare controlli delle risorse che possono influire sulla distribuzione dell'applicazione, tra cui:

Come posso aggiungere funzionalità alla configurazione della mia applicazione?

Vedi Specifica dei requisiti della tua applicazione nel file YAML per le descrizioni di ciò che potresti includere in una distribuzione. L'esempio include le seguenti opzioni.

Come posso aggiungere i servizi di IBM alla mia applicazione, ad esempio Watson?

Vedi Aggiunta dei servizi alle applicazioni.

Pianificazione delle distribuzioni altamente disponibili

Più ampiamente distribuisci la tua configurazione su più nodi di lavoro e cluster, meno è probabile che i tuoi utenti riscontrino tempi di inattività con la tua applicazione.

Rivedi queste potenziali configurazioni delle applicazioni ordinate con diversi gradi di disponibilità.

Fasi dell'alta disponibilità di un'applicazione*
dell'alta disponibilità di un'

  1. Un'installazione con n+2 pod gestiti da un set di repliche su un singolo nodo.
  2. Una distribuzione con n+2 pod gestiti da una serie di repliche ed distribuiti a più nodi (anti-affinità) in un cluster a zona singola.
  3. Una distribuzione con n+2 pod gestiti da una serie di repliche ed distribuiti a più nodi (anti-affinità) in un cluster multizona tra zone.

È anche possibile collegare più cluster in regioni diverse con un bilanciatore di carico globale.

Come posso aumentare la disponibilità della mia applicazione?

Considera le seguenti opzioni per aumentare la disponibilità della tua applicazione.

Utilizza le distribuzioni e le serie di repliche per distribuire la tua applicazione e le sue dipendenze.
Una distribuzione è una risorsa di Kubernetes che si può usare per dichiarare tutti i componenti dell'applicazione e le sue dipendenze. Con le distribuzioni, non è necessario annotare tutti i passaggi e ci si può concentrare sulla propria applicazione. Quando si distribuisce più di un pod, viene creato automaticamente un set di replica per le distribuzioni che monitora i pod e assicura che il numero specificato di pod sia attivo e funzionante. In caso di interruzione di un pod, la serie di repliche sostituisce il pod inattivo con uno nuovo. Puoi utilizzare una distribuzione per definire le strategie di aggiornamento per la tua applicazione, incluso il numero di pod da aggiungere durante un aggiornamento continuo e il numero di pod che possono non essere disponibili in un determinato momento. Quando si esegue un aggiornamento continuo, l'installazione controlla se la revisione funziona e interrompe il rollout quando vengono rilevati errori. Con le distribuzioni, è possibile distribuire contemporaneamente più revisioni con opzioni diverse. Ad esempio, puoi verificare una distribuzione prima di decidere di metterla in produzione. Utilizzando le distribuzioni, puoi tenere traccia delle eventuali revisioni distribuite. Puoi utilizzare questa cronologia per eseguire il rollback a una versione precedente nel caso in cui riscontri che gli aggiornamenti non funzionano come previsto.
Includi repliche sufficienti per il carico di lavoro della tua applicazione, più due
Per rendere la tua applicazione ancora più disponibile e più resiliente agli errori, valuta la possibilità di includere delle repliche aggiuntive rispetto al numero minimo per gestire il carico di lavoro previsto. Le repliche aggiuntive possono gestire il carico di lavoro se si verifica un arresto anomalo del pod e la serie di repliche non ha ancora ripristinato il pod arrestato. Per la protezione da due errori simultanei, includi due ulteriori repliche. Questa configurazione è un modello N+2, dove N è il numero di repliche per gestire il carico di lavoro in entrata e +2 sono le due repliche aggiuntive. Finché il tuo cluster ha spazio sufficiente, puoi avere quanti pod desideri.
Espandi i pod tra più nodi (anti-affinità)
Quando crei la tua distribuzione, ogni pod può essere distribuito allo stesso nodo di lavoro. Questo fenomeno è noto come affinità o colocazione. Per proteggere l'applicazione dai guasti dei nodi worker, è possibile configurare la distribuzione in modo che i pod siano distribuiti su più nodi worker, utilizzando l'opzione podAntiAffinity con i cluster standard. Puoi definire due tipi di anti-affinità pod: preferito o richiesto. Per ulteriori informazioni, consultare la documentazione di Kubernetes sull'assegnazione dei Pod ai nodi.

Per un esempio di affinità nella distribuzione di un'applicazione, vedi Creazione del file YAML di distribuzione della tua applicazione.
Distribuisci i pod tra più zone o regioni
Per proteggere la tua applicazione da un malfunzionamento della zona, puoi creare più cluster in zone separate o aggiungere zone ad un pool di nodi di lavoro in un cluster multizona. I cluster multizona sono disponibili solo in determinate multizone classic o VPC, come Dallas. Se crei più cluster in zone separate, devi impostare un programma di bilanciamento del carico globale. Quando usi una serie di repliche e specifichi l'anti-affinità pod, Kubernetes espande i pod dell'applicazione tra i nodi. Se i tuoi nodi si trovano in più zone, i pod vengono distribuiti tra le zone, aumentando la disponibilità della tua applicazione. Se vuoi limitare le tue applicazioni affinché vengano eseguite in una sola zona, puoi configurare l'affinità pod o creare ed etichettare un pool di nodi di lavoro in una zona.
In una distribuzione in cluster multizona, i pod delle applicazioni sono distribuiti uniformemente tra i nodi?
I pod vengono distribuiti uniformemente tra le zone, ma non sempre tra i nodi. Ad esempio, se hai un cluster con un nodo in ciascuna delle tre zone e distribuisci una serie di repliche di sei pod, ciascun nodo ottiene due pod. Tuttavia, se hai un cluster con due nodi in ciascuna delle tre zone e distribuisci una serie di repliche di sei pod, ciascuna zona pianifica due pod e potrebbe pianificare o meno un solo pod per nodo. Per un maggiore controllo sulla pianificazione, è possibile impostare l'affinità dei pod.
Se una zona va in tilt, come vengono riprogrammati i pod sui nodi rimanenti nelle altre zone?
Dipende dalla politica di pianificazione che hai utilizzato nella distribuzione. Se si è inclusa l'affinità di pod specifica per il nodo, i pod non vengono riprogrammati. Se non l'hai inclusa, i pod verranno creati sui nodi di lavoro disponibili nelle altre zone, ma potrebbero non essere bilanciati. Ad esempio, due pod potrebbero essere distribuiti tra i due nodi disponibili oppure potrebbero essere entrambi pianificati su un unico nodo con capacità disponibile. Allo stesso modo, quando la zona non disponibile torna disponibile, i pod non vengono eliminati e ribilanciati automaticamente tra i nodi. Se si desidera che i pod vengano riequilibrati tra le zone dopo il ripristino della zona, configurare il descheduler Kubernetes. Nei cluster multizona, cercare di mantenere la capacità dei nodi worker al 50% per zona, in modo che rimanga abbastanza capacità per proteggere il cluster da un guasto zonale.
E se volessi diffondere la mia applicazione in più regioni?
Per proteggere l'applicazione da un guasto della regione, creare un secondo cluster in un'altra regione, impostare un bilanciatore di carico globale per collegare i cluster e utilizzare un YAML di distribuzione per distribuire un set di repliche duplicato con pod anti-affinity per l'applicazione.
E se le mie applicazioni necessitano di uno storage persistente?
Usa un servizio cloud come IBM Cloudant o IBM Cloud Object Storage.

Come posso ridimensionare la mia applicazione?

Se vuoi aggiungere e rimuovere dinamicamente le applicazioni in risposta all'utilizzo del carico di lavoro, vedi Ridimensionamento delle applicazioni per i passi per abilitare il ridimensionamento automatico pod orizzontale.

Controllo della versione e aggiornamento di applicazioni

Ti sei prodigato per preparare la prossima versione della tua applicazione. Puoi utilizzare gli strumenti di aggiornamento di IBM Cloud e Kubernetes per distribuire versioni diverse della tua applicazione.

Come posso organizzare le mie distribuzioni per renderle più facili da aggiornare e gestire?

Ora che hai un'idea precisa di cosa includere nella tua distribuzione, potresti chiederti come gestirai tutti questi file YAML differenti. Per non parlare degli oggetti che creano nel tuo ambiente Kubernetes!

I seguenti suggerimenti possono aiutarti a organizzare i file YAML di distribuzione.

  • Utilizza un sistema di controllo delle versioni, come ad esempio Git.
  • Raggruppa gli oggetti Kubernetes strettamente correlati in un unico file YAML. Ad esempio, se stai creando una deployment, potresti voler aggiungere al file YAML anche il file service. Separare gli oggetti con ---, come nel seguente esempio.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    ...
    ---
    apiVersion: v1
    kind: Service
    metadata:
    ...
    
  • Puoi utilizzare il comando kubectl apply -f da applicare a un'intera directory, non solo a un singolo file.
  • Prova il progetto kustomize che puoi utilizzare come ausilio per scrivere, personalizzare e riutilizzare le configurazioni YAML delle tue risorse Kubernetes.

All'interno del file YAML, puoi utilizzare etichette o annotazioni come metadati per gestire le tue distribuzioni.

Etichette
Le etichette sono coppie di key:value che possono essere allegate agli oggetti di Kubernetes, come pod e distribuzioni. Possono essere qualsiasi cosa desideri e sono utili per selezionare gli oggetti in base alle informazioni dell'etichetta. Le etichette forniscono le basi per il raggruppamento degli oggetti. Consultare i seguenti esempi per le idee per le etichette.
  • app: nginx
  • version: v1
  • env: dev
Annotazioni
Le annotazioni sono simili alle etichette, in quanto sono anch'esse coppie key:value. Sono migliori per le informazioni non identificative che possono essere sfruttate da strumenti o librerie, come ad esempio l'organizzazione di ulteriori informazioni sull'origine di un oggetto, come utilizzare l'oggetto, i puntatori ai repository di traccia correlati o una politica sull'oggetto. Non selezioni gli oggetti in base alle annotazioni.

Quali strategie di aggiornamento dell'applicazione posso utilizzare?

Per aggiornare la tua applicazione, puoi scegliere tra varie strategie, come quelle di seguito indicate. Puoi iniziare con una distribuzione graduale o con uno switch istantaneo prima di passare a una distribuzione canary più complicata.

Distribuzione graduale
Puoi utilizzare la funzionalità nativa di Kubernetes per creare una distribuzione v2 e sostituire gradualmente la tua distribuzione v1 precedente. Questo approccio prevede che le app siano compatibili con le versioni precedenti, in modo che gli utenti che ricevono la versione dell'app v2 non subiscano alcuna modifica. Per ulteriori informazioni, vedi Gestione delle distribuzioni graduali per aggiornare le tue applicazioni.
Passaggio istantaneo
Denominata anche distribuzione blu-verde: un passaggio istantaneo richiede il doppio delle risorse di calcolo per avere due versioni di un'applicazione in esecuzione contemporaneamente. Con questo approccio, puoi far passare i tuoi utenti alla versione più recente in tempo reale. Assicurarsi di usare i selettori di etichetta del servizio (come version: green e version: blue) per assicurarsi che le richieste siano inviate alla versione corretta dell'applicazione. Puoi creare la nuova distribuzione version: green, attendere finché non è pronta e infine eliminare la distribuzione version: blue. Oppure si può eseguire un aggiornamento continuo, ma impostando il parametro maxUnavailable su 0% e il parametro maxSurge su 100%.
Distribuzione canary o A/B
Si tratta di una strategia di aggiornamento più complessa: la distribuzione canary si verifica quando selezioni una percentuale di utenti quale il 5% e la invii alla nuova versione dell'applicazione. Raccogli le metriche nei tuoi strumenti di registrazione e monitoraggio delle prestazioni della nuova versione dell'applicazione, effettui test A/B, quindi esegui il rollout dell'aggiornamento per più utenti. Come con tutte le distribuzioni, l'etichettatura dell'applicazione (come version: stable e version: canary) è fondamentale. Per gestire le distribuzioni canary, si potrebbe installare il service mesh del componente aggiuntivo Istio gestito, impostare Monitoring per il cluster e quindi utilizzare il service mesh Istio per i test A/B, come descritto in questo post del blog.

Come posso automatizzare la distribuzione della mia applicazione?

Se intendi eseguire la tua applicazione in più cluster, ambienti pubblici e privati e persino in più provider cloud, potresti chiederti come puoi fare in modo che la tua strategia di distribuzione funzioni in tutti questi ambienti. Con IBM Cloud e altri strumenti open source, puoi creare pacchetti della tua applicazione per facilitare l'automazione delle distribuzioni.

Configurazione di una pipeline di fornitura e integrazione continue (CI/CD)
Con i file di configurazione della tua applicazione organizzati in un sistema di gestione del controllo di origine, come Git, puoi creare la tua pipeline per testare e distribuire il codice in diversi ambienti, ad esempio test e prod. Collabora con il tuo amministratore del cluster per configurare l'integrazione e la fornitura continue.
Creazione del pacchetto dei file di configurazione dell'applicazione
Crea un pacchetto della tua applicazione con strumenti come Kustomize o Helm.
  • Con il progetto kustomize è possibile scrivere, personalizzare e riutilizzare le configurazioni YAML delle risorse di Kubernetes.
  • Con il Helm Kubernetes è possibile specificare tutte le risorse di Kubernetes richieste dalla propria applicazione in un grafico di Helm. Quindi, puoi utilizzare Helm per creare i file di configurazione YAML e distribuirli nel tuo cluster. Puoi anche integrare i grafici Helm forniti da IBM Cloud per estendere le capacità del tuo cluster, ad esempio con un plug-in di archiviazione a blocchi.

Stai cercando di creare modelli di file YAML? Alcuni utilizzano Helm per fare proprio questo, oppure si possono provare altri strumenti della comunità, come ad esempio ytt.

Configurazione del rilevamento di servizi

Ognuno dei tuoi pod nel tuo cluster Kubernetes ha un indirizzo IP. Tuttavia, quando distribuisci un'applicazione nel tuo cluster non vuoi affidarti all'indirizzo IP del pod per il rilevamento dei servizi e le reti. I pod vengono rimossi e sostituiti frequentemente e dinamicamente. Utilizza invece un servizio Kubernetes, che rappresenta un gruppo di pod e fornisce un punto di ingresso stabile tramite l'indirizzo IP virtuale del servizio, denominato cluster IP. Per ulteriori informazioni, consultare la documentazione di Kubernetes sui servizi.

Come posso assicurarmi che i miei servizi siano collegati alle distribuzioni corrette e siano pronti all'uso?

Per la maggior parte dei servizi, aggiungi un selettore al file .yaml del tuo servizio, cosicché venga applicato ai pod che eseguono le tue applicazioni in base a quell'etichetta. Spesso, quando l'applicazione viene avviata per la prima volta, non si vuole che elabori immediatamente le richieste. Aggiungi un'analisi di disponibilità alla tua distribuzione, in modo che il traffico venga inviato a un pod solo se considerato pronto. Per un esempio di distribuzione con un servizio che utilizza le etichette e imposta una sonda di prontezza, vedere questo YAML di NGINX.

A volte, non desideri che il servizio utilizzi un'etichetta. Ad esempio, potresti avere un database esterno o voler puntare il servizio verso un altro servizio in uno spazio dei nomi differente all'interno del cluster. Quando ciò accade, devi aggiungere manualmente un oggetto endpoint e collegarlo al servizio.

Come posso esporre i miei servizi su Internet?

Puoi creare tre tipi di servizi per reti esterne: NodePort, LoadBalancer e Ingress.

Hai diverse opzioni che dipendono dal tuo tipo di cluster. Per ulteriori informazioni, vedi Pianificazione dei servizi di rete.

Quando pianifichi il numero di oggetti Service di cui necessiti nel tuo cluster, ricorda che Kubernetes utilizza iptables per gestire le regole di rete e inoltro della porta. Se si eseguono molti servizi nel cluster, come 5000, le prestazioni potrebbero essere compromesse.

Protezione delle applicazioni

Mentre pianifichi e sviluppi la tua applicazione, considera le seguenti opzioni per mantenere un'immagine sicura, assicurati che le informazioni sensibili siano crittografate, crittografa il traffico tra i microservizi dell'applicazione e controlla il traffico tra i tuoi pod dell'applicazione e altri pod e servizi nel cluster.

Sicurezza dell'immagine
Per proteggere la tua applicazione, devi proteggere l'immagine e stabilire i controlli per garantire l'integrità dell'immagine. Esamina l'argomento sulla sicurezza di immagini e registri per i passi che puoi eseguire per garantire immagini del contenitore sicure. Ad esempio, si può usare Vulnerability Advisor per controllare lo stato di sicurezza delle immagini dei container. Quando aggiungi un'immagine allo spazio dei nomi IBM Cloud Container Registry della tua organizzazione, Vulnerability Advisor ne esegue automaticamente la scansione per individuare problemi di sicurezza e potenziali vulnerabilità. Se si riscontrano dei problemi di sicurezza, vengono fornite le istruzioni per facilitare la correzione delle vulnerabilità segnalate. Per iniziare, vedi Gestione della sicurezza delle immagini con Vulnerability Advisor.
Segreti Kubernetes
Quando si distribuisce l'applicazione, non memorizzare informazioni riservate, come credenziali o chiavi, nel file di configurazione YAML, nelle configmap o negli script. Utilizza invece i segreti Kubernetes, ad esempio un segreto di pull dell'immagine per le credenziali del registro. Puoi quindi fare riferimento a questi segreti nel tuo file YAML di distribuzione.
Crittografia dei segreti
È possibile crittografare i segreti Kubernetes creati nel cluster utilizzando un provider di servizi di gestione delle chiavi (KMS). Per iniziare, vedi Crittografa i segreti utilizzando un provider KMS e Verifica che i segreti siano crittografati.
Crittografia del traffico dei microservizi
Dopo aver distribuito la tua applicazione, puoi configurare una rete di servizi e abilitare la crittografia mTLS per il traffico tra i servizi nella rete. Per iniziare, configura il componente aggiuntivo Istio gestito. Quindi, segui la procedura in Protezione del traffico nel cluster abilitando mTLS.
Gestione del traffico pod
Politiche di rete Kubernetes protegge i pod dal traffico di rete interno. Ad esempio, se la maggior parte o tutti i pod non richiedono l'accesso a specifici pod o servizi e vuoi assicurarti che i pod per impostazione predefinita non possano accedere a tali pod o servizi, puoi creare una politica di rete Kubernetes per bloccare il traffico in ingresso a questi pod o servizi. Le politiche di rete Kubernetes possono anche aiutarti ad applicare l'isolamento del carico di lavoro tra gli spazi dei nomi controllando il modo in cui i pod e i servizi in diversi spazi dei nomi possono comunicare. Per i cluster che eseguono Kubernetes 1.21 e versioni successive, i token dell'account di servizio che i pod utilizzano per comunicare con il server API Kubernetes sono limitati nel tempo, aggiornati automaticamente, con ambito a un particolare gruppo di utenti (il pod) e invalidati dopo l'eliminazione del pod. Per continuare a comunicare con il server API, devi progettare le tue applicazioni per leggere il valore del token aggiornato su base regolare, ad esempio ogni minuto. Per ulteriori informazioni, vedi Bound Service Account Tokens.

Gestione dell'accesso e monitoraggio dell'integrità dell'applicazione

Dopo aver distribuito la tua applicazione, puoi controllare chi può accedervi e monitorare l'integrità e le prestazioni dell'applicazione.

Come posso controllare chi ha accesso alle distribuzioni della mia applicazione?

Gli amministratori di account e di cluster possono controllare l'accesso su molti livelli diversi: cluster, spazio dei nomi Kubernetes, pod e contenitore.

Con IBM Cloud IAM, puoi assegnare autorizzazioni a singoli utenti, gruppi o account di servizio a livello di istanza del cluster. Puoi ridurre ulteriormente l'accesso al cluster limitando gli utenti a determinati spazi dei nomi all'interno del cluster. Per ulteriori informazioni, vedi Assegnazione dell'accesso al cluster.

Per controllare l'accesso a livello di pod, è possibile configurare i criteri di sicurezza del pod (PSP).

All'interno del file YAML di distribuzione dell'applicazione, puoi impostare il contesto di sicurezza per un pod o un contenitore. Per ulteriori informazioni, consultare la documentazione Kubernetes.

Dopo aver distribuito la mia applicazione, come posso monitorarne l'integrità?

Puoi configurare registrazione e monitoraggio di IBM Cloud per il tuo cluster. Puoi anche scegliere di integrare un servizio di registrazione o monitoraggio di terze parti.