Gestione del ciclo di vita dell'applicazione

Utilizza gli strumenti nativi di Kubernetes e di terze parti per eseguire aggiornamenti continui e rollback delle applicazioni senza tempi di inattività per i tuoi utenti.

Strategie di aggiornamento

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 retrocompatibili, in modo che gli utenti a cui viene fornita la versione dell'app " v2 " non subiscano alcuna modifica che comprometta il funzionamento. 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 però 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, è possibile installare il service mesh aggiuntivo gestito Istio, configurare Monitoring per il proprio cluster e quindi utilizzare il service mesh Istio per i test A/B, come descritto in questo post del blog.

Ridimensionamento delle applicazioni

Con Kubernetes, puoi abilitare l'autoscaling orizzontale dei pod per aumentare o diminuire automaticamente il numero di istanze delle tue app in base al carico della CPU.

Vuoi ridimensionare i tuoi nodi di lavoro anziché i tuoi pod? Controlla il cluster autoscaler.

Prima di cominciare:

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.
Assicurati di avere un ruolo di accesso al servizio che ti conceda il ruolo RBAC appropriato " Kubernetes ", in modo da poter utilizzare le risorse " Kubernetes " nel namespace.

Per scalare le vostre applicazioni:

Distribuisci la tua applicazione al cluster dalla CLI. Per distribuzioni più complesse, potresti dover creare un file di configurazione.
```
kubectl create deployment <app_name> --image=<image>
```
Imposta i limiti delle risorse CPU in millicore per i contenitori in esecuzione nella tua distribuzione, ad esempio 100m. Puoi anche impostare dei limiti di memoria, ma l'autoscaler di pod orizzontale considera solo i limiti delle risorse CPU ai fini del ridimensionamento. Per ulteriori informazioni, consultare la documentazione relativa a “ kubectl set resources ”.
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

Crea un autoscaler di pod orizzontale e definisci la tua politica. Per ulteriori informazioni, consultare la documentazione relativa a “ kubectl autoscale ”.

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

Conoscere le opzioni di comando
Opzioni	Descrizione
`--cpu-percent`	L'utilizzo medio della CPU mantenuto da Horizontal Pod Autoscaler, che viene specificato come percentuale.
`--min`	Il numero minimo di pod distribuiti utilizzati per mantenere la percentuale di utilizzo della CPU specificata.
`--max`	Il numero massimo di pod distribuiti utilizzati per mantenere la percentuale di utilizzo della CPU specificata.

Gestione delle distribuzioni graduali per aggiornare le tue applicazioni

Puoi gestire il rollout delle modifiche della tua applicazione in modo automatizzato e controllato per i carichi di lavoro con un template di pod come le distribuzioni. Se la distribuzione non avviene secondo i tuoi piani, puoi riportarla alla revisione precedente.

Vuoi evitare tempi di inattività durante l'aggiornamento continuo? Assicurati di specificare un'analisi di disponibilità nella tua distribuzione in modo che il rollout proceda al successivo pod dell'applicazione una volta pronto l'ultimo pod aggiornato.

Prima di cominciare:

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.
Crea una distribuzione.
Assicurati di disporre di un ruolo di accesso al servizio che ti conceda il ruolo RBAC appropriato " Kubernetes ", in modo da poter utilizzare le risorse " Kubernetes " nel namespace.

Per gestire gli aggiornamenti continui per le tue applicazioni:

Per accertarti che le tue distribuzioni vengano contrassegnate come pronte solo quando il contenitore è in esecuzione e pronto a rispondere alle richieste di servizio, aggiungi analisi di attività e di disponibilità alla tua distribuzione.
Aggiorna la tua distribuzione in modo da includere una strategia di aggiornamento continuo che specifica il picco massimo e i pod non disponibili o la percentuale di pod durante l'aggiornamento.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

Per impostazione predefinita, le distribuzioni attendono fino a quando il pod viene contrassegnato come ready per continuare con il rollout. Se noti che la distribuzione continua a creare pod anche se la tua app nel pod più recente non è ancora pronta, utilizza questo campo per rallentare il rollout di distribuzione. Ad esempio, se specifichi 5, una volta che il pod è ready la distribuzione attende 5 secondi prima di creare il pod successivo.

spec.progressDeadlineSeconds

Imposta un timeout, in secondi, prima che una distribuzione venga considerata non riuscita. Ad esempio, in assenza di un timeout, se la nuova versione dell’app presenta un bug e si blocca immediatamente, il rollout non può proseguire perché il pod non raggiunge mai lo stato “ ready ”. Se imposti questo timeout su 600 secondi, se una qualsiasi fase del rollout non riesce ad avanzare per 10 minuti, la distribuzione viene contrassegnata come non riuscita e il rollout si arresta.

spec.strategy.type

Specifica il tipo di strategia RollingUpdate.

spec.strategy.rollingUpdate.maxUnavailable

Imposta il numero massimo di pod che possono non essere disponibili durante un aggiornamento, sotto forma di numero (2) o percentuale (50%). In generale, utilizza un percentuale in modo tale che se successivamente modifichi il numero di repliche non devi ricordarti di aggiornare il numero qui, a meno che non desideri limitare il rollout per consentire l'inattività di un solo pod alla volta. Se non si desidera mai scendere al di sotto del 100% della capacità, impostare questo valore su “ 0% ” e specificare il parametro “ spec.strategy.type.rollingUpdate.maxSurge ”.

spec.strategy.rollingUpdate.maxSurge

Imposta il numero di risorse supplementari che la distribuzione può utilizzare durante il rollout, sotto forma di numero (2) o di percentuale (50%). Ad esempio, se la tua distribuzione specifica 10 repliche e imposti maxSurge su 2, durante il rollout, vengono create due nuove repliche. Ora hai 12 repliche (10 esistenti e 2 nuove). Dopo che le due nuove repliche sono pronte, la distribuzione abbassa le vecchie repliche a 8 per soddisfare le 10 repliche specificate. Questo processo continua fino a quando il rollout non è completo e tutte e 10 le repliche eseguono la nuova versione.

Se si desidera eseguire un aggiornamento dello stile dello switch istantaneo blu - verde, impostare maxSurge su 100%. La distribuzione crea tutte le nuove repliche richieste, quindi riduce le repliche della versione precedente a 0.

Eseguire il rollout di un cambiamento. Ad esempio, potresti voler modificare l'immagine che hai utilizzato nella tua distribuzione iniziale.

Ottieni il nome della distribuzione.

    kubectl get deployments
    ```
2. Ottieni il nome del pod.

```sh {: pre}
    kubectl get pods
    ```
3. Ottieni il nome del contenitore che viene eseguito nel pod.

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. Configura la nuova immagine per la distribuzione da utilizzare.

```sh {: pre}
    kubectl set image deployment/<deployment_name> <container_name>=<image_name>
    ```
Quando esegui i comandi, la modifica viene immediatamente applicata e registrata nella cronologia di distribuzione.

Controlla lo stato della tua distribuzione.
```
kubectl rollout status deployments/<deployment_name>
```
Se noti qualcosa nello stato e desideri avere il tempo di controllarlo, puoi mettere in pausa e riprendere il tuo rollout con i seguenti comandi.
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```

Annulla una modifica.

Visualizza la cronologia di distribuzione e identifica il numero di revisione della tua ultima distribuzione.

    kubectl rollout history deployment/<deployment_name>
    ```
    Per visualizzare i dettagli relativi a una revisione specifica, indicare il numero di revisione.
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. Riporta la distribuzione alla versione precedente o specifica una revisione. Per tornare alla versione precedente, utilizza il seguente comando.

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

Configurazione di integrazione e fornitura continue

Con IBM Cloud e altri strumenti open source, puoi configurare l'integrazione e la fornitura continue (CI/CD), il controllo della versione, le toolchain e altro ancora per automatizzare lo sviluppo e la distribuzione delle applicazioni.

Per vedere l'elenco delle integrazioni supportate e i passaggi per impostare una pipeline di consegna continua, consultare le integrazioni disponibili nella console IBM Cloud e la documentazione relativa al cluster.

Copia delle distribuzioni in un altro cluster

Quando si utilizza un sistema di controllo delle versioni come Git, progetti di gestione della configurazione o strumenti di distribuzione continua all'interno del proprio cluster, è possibile distribuire rapidamente i file di configurazione dell'applicazione da un cluster all'altro. A volte hai solo poche distribuzioni testate in un cluster e preferisci copiare queste distribuzioni e ridistribuirle in un altro cluster.

Prima di iniziare, sono necessari due cluster e il ruolo di accesso al servizio Manager per tutti gli spazi dei nomi presenti in entrambi i cluster, in modo da poter copiare tutte le risorse da un cluster e distribuirle su un altro.

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Elenca tutti i file di configurazione nel tuo cluster e verifica di voler copiare queste configurazioni.

kubectl get all

Output di esempio

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d
NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d
NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

Copia i file di configurazione presenti nel tuo cluster in una directory locale. Quindi, rimuovere manualmente i campi specifici del cluster, quali resourceVersion, uid, creationTimestamp e status dal file YAML esportato prima di applicare i file a un altro cluster.
```
kubectl get all -o yaml > myconfigs.yaml
```
Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.
Facoltativo: se il cluster utilizzava più spazi dei nomi, creare gli stessi spazi dei nomi nel cluster standard e copiare il segreto di recupero dell'immagine in ciascuno di essi.
Distribuisci i file di configurazione copiati al tuo cluster. Se un file di configurazione contiene informazioni specifiche che non possono essere applicate, potrebbe essere necessario aggiornare il file di configurazione e riapplicarlo.
```
kubectl apply -f myconfigs.yaml
```
Output di esempio
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
Verifica che i tuoi file di configurazione siano stati applicati.
```
kubectl get all
```