Che tipo di applicazioni posso eseguire in Red Hat OpenShift on IBM Cloud?

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 un'archiviazione permanente dei dati né un indirizzo IP di rete stabile; pertanto, i pod possono essere terminati, riprogrammati e ridimensionati in base alle esigenze 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 di lavoro bare metal e utilizzare Portworx come soluzione di storage software-defined ad alta disponibilità per gestire lo storage persistente delle applicazioni stateful. Per ulteriori informazioni sul funzionamento degli “stateful set”, consultare la documentazione su “ Kubernetes ”.

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

Scopri la " Twelve-Factor App ", una metodologia indipendente dal linguaggio di programmazione che ti aiuta a valutare come sviluppare la tua app sulla base di 12 fattori, riassunti come segue.

1. Base di codici: 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 le politiche di rete di Calico non consentono di limitare la larghezza di banda.
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 ambiente di sviluppo e produzione: configura una pipeline di integrazione continua e distribuzione continua per la tua app, in modo che vi sia una differenza minima tra l'app in fase di 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 Red Hat OpenShift on IBM Cloud, i log non vengono attivati per impostazione predefinita. Per abilitarli, vedi Configurazione dell'inoltro dei log.
12. Processi amministrativi: conservare eventuali script amministrativi una tantum all’interno dell’app ed eseguirli come oggetti “Job” di Kubernetes, per garantire che gli script amministrativi vengano eseguiti nello stesso ambiente dell’app stessa. Per l'orchestrazione di pacchetti di grandi dimensioni che si desidera eseguire nei propri cluster Kubernetes, si consiglia di utilizzare un gestore di pacchetti come Helm.

E le applicazioni senza server?

È possibile eseguire applicazioni e attività senza server tramite il IBM Cloud Code Engine servizio. Code Engine può anche creare immagini per voi.

Ho già un'applicazione. Come posso eseguirne la migrazione a Red Hat OpenShift on IBM Cloud?

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

1. Utilizza il modello " Twelve-Factor App" come guida per isolare le dipendenze, separare i processi in servizi distinti e ridurre il più possibile la dipendenza dallo stato della tua applicazione.
2. Trova un'immagine di base appropriata da utilizzare. È possibile utilizzare immagini disponibili pubblicamente su Docker Hub, immagini pubbliche su IBM oppure creare e gestire le proprie immagini nel proprio IBM Cloud Container Registry privato.
3. Aggiungi alla tua immagine Docker solo ciò che occorre per eseguire l'applicazione.
4. Riesamina gli scenari comuni di modifica delle applicazioni.
5. 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.
6. Nel tempo, esegui il refactoring dei processi della tua applicazione in microservizi.

Passi di esempio per fornire l'accesso privilegiato a una distribuzione

Se disponi di un'app che viene eseguita con i permessi di root, devi modificare la tua distribuzione in modo che sia compatibile con i vincoli del contesto di sicurezza impostati per il tuo cluster Red Hat OpenShift. Ad esempio, potresti configurare il tuo progetto con un account di servizio per controllare l'accesso privilegiato e quindi modificare la tua distribuzione per utilizzare questo account di servizio.

Prima di iniziare: accedi al tuo cluster Red Hat OpenShift.

1. Come amministratore del cluster, crea un progetto.

   oc adm new-project <project_name>
   

2. Indica il progetto come destinazione in modo che le successive risorse che crei siano nello spazio dei nomi del progetto.

   oc project <project_name>
   

3. Crea un account di servizio per il progetto.

   oc create serviceaccount <sa_name>
   

4. Aggiungi un vincolo del contesto di sicurezza privilegiato all'account di servizio per il progetto. Se vuoi verificare quali criteri sono presenti nell'SCC " privileged ", esegui il comando oc describe scc privileged. Per ulteriori informazioni sugli SCC, consultare la Red Hat OpenShift documentazione.

   oc adm policy add-scc-to-user privileged -n <project_name> -z <sa_name>
   

5. Nel tuo file di configurazione della distribuzione, fai riferimento all'account di servizio con privilegi e imposta il contesto di sicurezza su privilegiato.

   • In spec.template.spec, aggiungi serviceAccount: <sa_name>.
   • In spec.template.spec.containers, aggiungi securityContext: privileged: true.

   Esempio

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: myapp_deployment
     labels:
       app: myapp
   spec:
     ...
     template:
       ...
       spec:
         serviceAccount: <sa_name>
         containers:
         - securityContext:
             privileged: true
         ...
   

6. Distribuisci il file di configurazione dell'applicazione.

   oc apply -f <filepath/deployment.yaml>
   

7. Verifica che il pod sia in uno stato Running. Se il tuo pod mostra uno stato di errore o rimane bloccato in uno stato per molto tempo, descrivi il pod e vedi la sezione Eventi per iniziare a risolvere i problemi relativi alla distribuzione.

   oc get pods
   

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

Un pod è l'unità dispiegabile più semplice 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 container 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

Nel valutare i componenti della tua applicazione, valuta se presentano requisiti di risorse significativamente diversi per quanto riguarda, ad esempio, la CPU e la memoria. È possibile che alcuni componenti funzionino secondo il principio del “best effort”, per cui è accettabile che smettano di funzionare per un breve periodo per destinare le risorse ad 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.

Allora, se posso usare un pod, perché mi servono tutti questi diversi 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. Utilizza invece un’implementazione per supportare la riprogrammazione dei pod, i set di repliche e gli aggiornamenti graduali. 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 funzionalità che puoi aggiungere alla tua distribuzione, consulta la sezione " Creazione del file YAML di distribuzione dell'app ".

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 sui pod e sui controller, consulta la documentazione su “ 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.

Cosa devo fare se voglio che la mia configurazione dell'applicazione utilizzi le variabili? Come faccio ad aggiungere queste variabili al file YAML?

Per aggiungere informazioni variabili alle tue distribuzioni, invece di inserire i dati in modo statico nel file YAML, puoi utilizzare un Kubernetes ConfigMap o Secret.

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.

• Sistema di file: è possibile montare un file intero 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 container.
• Opzione da riga di comando: imposta l'opzione da riga di comando utilizzata in una specifica del container.

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): conservare in modo riservato le informazioni sensibili, quali indirizzi e-mail o altri tipi di dati necessari ai fini della conformità aziendale o delle normative governative.
• Credenziali: inserire le credenziali, quali password, chiavi e token, in un segreto per ridurre il rischio di divulgazione 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 del servizio di gestione delle chiavi nel cluster per crittografare i segreti nuovi ed esistenti.

Come posso assicurarmi che la mia app disponga delle risorse corrette?

Quando si specifica il file YAML dell'app, è possibile aggiungere alla configurazione dell'app alcune funzionalità di " Kubernetes " che aiutano l'app a ottenere le risorse corrette. In particolare, imposta i limiti delle risorse e le richieste per ciascun container definito nel tuo file YAML.

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

• Quote di risorse
• Priorità dei pod

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.

• Serie di repliche
• Etichette
• Affinità
• Politiche di immagine
• Porte
• Richieste e limiti di risorse
• Analisi di attività e disponibilità
• Servizi per rendere accessibile il servizio dell'app su una porta.
• Configmaps per impostare variabili di ambiente del contenitore.
• Segreti per impostare le variabili di ambiente del contenitore.
• Volumi persistenti montati sul container a scopo di archiviazione.

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

Vedi Aggiunta dei servizi alle applicazioni.

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.

Un deployment è una risorsa di Kubernetes che puoi utilizzare per dichiarare tutti i componenti della tua app e le relative dipendenze. Con le operazioni di distribuzione, non è necessario annotare tutti i passaggi e ci si può concentrare invece sulla propria app. Quando si distribuiscono più pod, viene creato automaticamente un replica set per le distribuzioni, che monitora i pod e garantisce 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 graduale, il processo di distribuzione verifica se la revisione funziona e interrompe l'implementazione qualora vengano rilevati degli 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 app ancora più altamente disponibile e più resiliente ai guasti, valuta la possibilità di includere repliche aggiuntive oltre al numero minimo necessario per gestire il carico di lavoro previsto. Ulteriori repliche sono in grado di gestire il carico di lavoro nel caso in cui un pod si blocchi e il replica set non abbia ancora ripristinato il pod in questione. Per proteggersi da due guasti simultanei, includere due repliche aggiuntive. Questa configurazione segue il modello “ N+2 ”, dove N è il numero di repliche necessarie per gestire il carico di lavoro in entrata e +2 indica 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 collocazione. Per proteggere la tua app da eventuali guasti dei nodi di lavoro, puoi configurare la distribuzione in modo da distribuire i pod su più nodi di lavoro utilizzando l'opzione " podAntiAffinity " con i tuoi cluster standard. Puoi definire due tipi di anti-affinità pod: preferito o richiesto. Per ulteriori informazioni, consultare la documentazione di Kubernetes relativa all’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 classiche 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 un'implementazione di cluster multizona, i pod della mia app sono distribuiti in modo uniforme 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 avere un maggiore controllo sulla pianificazione, è possibile impostare l'affinità dei pod.

Se una zona smette di funzionare, in che modo i pod vengono riprogrammati sui nodi rimanenti nelle altre zone?

Dipende dalla politica di pianificazione che hai utilizzato nella distribuzione. Se hai specificato l'affinità dei pod a un nodo specifico, i tuoi 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 ridistribuiti tra le zone una volta ripristinata la zona, configurare il descheduler " Kubernetes "{: shortdesc}. Nei cluster multizona, cerca di mantenere la capacità dei nodi di lavoro al 50% per ogni zona, in modo da garantire una capacità sufficiente a proteggere il cluster da un guasto a livello di zona.

E se volessi distribuire la mia app in diverse regioni?

Per proteggere la tua app da un guasto a livello di regione, crea un secondo cluster in un’altra regione, configura un bilanciatore di carico globale per collegare i tuoi cluster e utilizza un file YAML di distribuzione per distribuire un set di repliche duplicato con anti-affinità dei pod per la tua app.

E se le mie app avessero bisogno di uno spazio di archiviazione permanente?

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 la procedura per abilitare il ridimensionamento pod orizzontale.

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 oc apply -f da applicare a un'intera directory, non solo a un singolo file.

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

Etichette

Le etichette sono coppie “ key:value ” che possono essere associate a oggetti dell Kubernetes, come i pod e i deployment. 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 anch'esse sono 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 richiede che le app siano compatibili con le versioni precedenti, in modo che gli utenti a cui viene fornita la versione dell'app " v2 " non riscontrino modifiche che compromettono la funzionalità. 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. Assicurati di utilizzare i selettori di etichetta del servizio (come version: green e version: blue) per garantire che le richieste vengano inviate alla versione corretta dell'app. Puoi creare la nuova distribuzione version: green, attendere finché non è pronta e infine eliminare la distribuzione version: blue. In alternativa, è possibile eseguire un aggiornamento graduale, 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.

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 l'amministratore del cluster per configurare l'integrazione e la distribuzione continue.

Creazione del pacchetto dei file di configurazione dell'applicazione

Con il HelmKubernetes gestore di pacchetti, è possibile specificare tutte le risorse Kubernetes richieste dall'app in un grafico Helm. Quindi, puoi utilizzare Helm per creare i file di configurazione YAML e distribuirli nel tuo cluster. È inoltre possibile integrare i grafici Helm forniti d IBM Cloud per ampliare le funzionalità del proprio cluster, ad esempio con un plug-in per lo storage a blocchi.

Stai cercando di creare modelli di file YAML? Alcuni utilizzano Helm proprio per questo scopo, oppure potresti provare altri strumenti della community come ytt.

Come posso assicurarmi che i miei servizi siano collegati alle distribuzioni corrette e 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, al primo avvio dell'app, non si desidera che questa 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 etichette e imposta un test di prontezza, dai un’occhiata a questo file YAML disponibile all’indirizzo 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.

• Cluster standard: puoi esporre la tua applicazione utilizzando un servizio NodePort, programma di bilanciamento del carico o Ingress.
• Cluster reso privato utilizzando Calico: puoi esporre la tua applicazione utilizzando un servizio NodePort, programma di bilanciamento del carico o Ingress. Devi inoltre utilizzare una politica di rete preDNAT di Calico per bloccare le porte del nodo pubblico.

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 nel cluster sono in esecuzione molti servizi, ad esempio 5000, le prestazioni potrebbero risentirne.

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

Gli amministratori dell'account e del cluster possono gestire gli accessi a diversi livelli: il cluster, l' Red Hat OpenShift l progetto, il pod e il container.

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, puoi configurare i vincoli di contesto di sicurezza (SCC, security context constraint).

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 relativa a “ Kubernetes ”.

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

È possibile configurare la registrazione e il monitoraggi IBM Cloud i per il proprio cluster.