Abilitazione degli aggiornamenti automatici

Quando abiliti gli aggiornamenti automatici, i tuoi ALB vengono aggiornati alla versione contrassegnata come predefinita. Quando una versione più recente diventa la versione predefinita, i tuoi ALB vengono aggiornati automaticamente a quella versione.

Se esiste solo un nodo di lavoro in una zona nel tuo cluster e imposti il numero di repliche ALB su 1, questo singolo pod ALB viene eliminato e viene creato un nuovo pod ogni volta che vengono applicati degli aggiornamenti. Questo processo potrebbe causare interruzioni del traffico anche se hai nodi di lavoro e repliche ALB in altre zone. Per evitare interruzioni del traffico, assicurati che esistano almeno due nodi di lavoro in ciascuna zona e che esistano due repliche per ogni ALB. Nota che durante il processo di aggiornamento, solo le connessioni nuove vengono instradate al secondo pod ALB; le connessioni esistenti sul pod ALB di aggiornamento vengono terminate in modo sicuro. Per le connessioni esistenti terminate durante l'aggiornamento, avviare un nuovo tentativo nelle applicazioni client.

Pianificazione delle finestre di manutenzione per gli aggiornamenti automatici

È possibile controllare e gestire gli aggiornamenti automatici di ALB creando un'attività pianificata personalizzata ( ConfigMap ) che specifichi l'ora in cui si desidera che gli aggiornamenti vengano eseguiti.

Per impostare un orario per gli aggiornamenti automatici, si impostano le chiavi updateStartTime e updateEndTime nella distribuzione ConfigMap. Ogni chiave rappresenta un'ora assegnata in formato 24 ore (HH:MM). Notare che questa ora è specificata in UTC (coordinated universal time) piuttosto che nell'ora locale.

1. Crea un file YAML per il tuo ConfigMap. Specificare i campi updateStartTime e updateEndTime come coppie chiave-valore nel campo data.

   Il seguente esempio ConfigMap imposta la funzione di aggiornamento automatico per aggiornare i pod ALB nel cluster tra le 20:34 e le 23:59 UTC.

   apiVersion: v1
   kind: ConfigMap
   metadata:
       name: ibm-ingress-deploy-config
       namespace: kube-system
   data:
       "updateStartTime": "20:34"
       "updateEndTime": "23:59"
   

2. Distribuisci ConfigMap nel tuo cluster. Le nuove regole vengono applicate la volta successiva che viene eseguito un aggiornamento.

   kubectl apply -f <filename>.yaml
   

Disabilitazione degli aggiornamenti automatici

Per ricevere correzioni di bug e aggiornamenti di sicurezza, mantenere abilitati gli aggiornamenti automatici. Quando gli aggiornamenti automatici vengono disabilitati, sei responsabile dell'aggiornamento manuale dei tuoi ALB.

Puoi disabilitare gli aggiornamenti automatici per i tuoi ALB eseguendo ibmcloud ks ingress alb autoupdate disable -c CLUSTER_NAME_OR_ID.

Per verificare se gli aggiornamenti automatici sono abilitati per il proprio cluster, utilizzare il comando ibmcloud ks ingress alb autoupdate get -c CLUSTER_NAME_OR_ID. Se si decide di abilitare nuovamente gli aggiornamenti automatici, è possibile eseguire ibmcloud ks ingress alb autoupdate enable -c CLUSTER_NAME_OR_ID.

Applicazione degli aggiornamenti manuali

Puoi applicare manualmente un aggiornamento unico dei tuoi pod ALB Ingress con il comando ibmcloud ks ingress alb update. Questo comando applica la versione dell'immagine ALB predefinita, ma puoi applicare un'altra versione includendo l'opzione --version. Per ulteriori informazioni o opzioni di comandi, vedi il riferimento CLI.

Per aggiornare la tua immagine ALB a una versione specifica con l'opzione --version, devi disabilitare gli aggiornamenti ALB automatici e mantenerli disabilitati per tutto il tempo in cui desideri eseguire la versione specificata. Gli aggiornamenti automatici applicano sempre la versione predefinita e sovrascrivono gli aggiornamenti manuali che si applicano. Se si desidera utilizzare una versione diversa, non è possibile abilitare gli aggiornamenti automatici.

• Per elencare le versioni ALB disponibili, immetti il seguente comando.

  ibmcloud ks ingress alb versions --region REGION
  

• Per aggiornare tutti i pod ALB nel cluster, immetti il seguente comando.

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION
  

• Per aggiornare l'ALB per specifici ALB, immetti il seguente comando.

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION --alb ALB_ID [--alb ALB_2_ID ...]
  

Visualizzazione delle versioni dell'immagine supportate

Per elencare le ultime tre versioni supportate per ogni tipo di immagine, esegui questo comando.

ibmcloud ks ingress alb versions

Output di esempio

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

La versione Kubernetes Ingress segue il formato <community_version>_<ibm_build>_iks. Il numero di build " IBM " indica la build più recente della versione " Kubernetes " di Ingress NGINX rilasciata da IBM Cloud Kubernetes Service. Ad esempio, la versione 1.1.2_2507_iks indica la build più recente della versione NGINX di Ingress 0.47.0. IBM Cloud Kubernetes Service potrebbe rilasciare build della versione dell'immagine della community per risolvere eventuali vulnerabilità.

Per le modifiche presenti in ciascuna versione delle immagini Ingress, vedi il log delle modifiche della versione Ingress.

Ripristino di una versione precedente

Se i tuoi pod ALB sono stati aggiornati di recente, ma una configurazione personalizzata per i tuoi ALB è influenzata dalla build della versione dell'immagine più recente, puoi utilizzare il comando ibmcloud ks ingress alb update con l'opzione --version per eseguire il rollback dei pod ALB a una versione precedente e supportata. La versione dell'immagine in cui modifichi il tuo ALB deve essere una versione dell'immagine supportata elencata nell'output di ibmcloud ks ingress alb versions.

Nota che se ritorni a una versione precedente, devi disabilitare gli aggiornamenti ALB automatici e quindi mantenerli disabilitati per tutto il tempo in cui vuoi eseguire la versione precedente. Gli aggiornamenti automatici applicano sempre la versione più recente e sovrascrivono gli aggiornamenti manuali che si applicano. Se si desidera utilizzare una versione precedente, non è possibile abilitare gli aggiornamenti automatici.

Creazione di più ALB in una zona

Ogni ALB in una zona viene distribuito come due pod su nodi di lavoro diversi. Per aumentare le tue capacità di elaborazione ALB e gestire più connessioni, puoi creare ulteriori ALB in una zona. L'indirizzo IP del nuovo ALB viene aggiunto automaticamente al dominio secondario Ingress.

Quando crei un cluster multizona, viene creato un ALB pubblico predefinito in ciascuna zona in cui sono presenti nodi di lavoro. Se in seguito si rimuove una di queste tre zone iniziali e si aggiungono worker in una zona diversa, in quella nuova zona non viene creato un ALB pubblico predefinito. Puoi creare manualmente un ALB per l'elaborazione delle connessioni in quella nuova zona.

Quando utilizzi la convalida della risorsa Ingress, ogni richiesta di creazione e aggiornamento viene convalidata da tutti gli ALB. Se nessun pod è in esecuzione per una particolare istanza ALB, potresti non essere in grado di applicare le risorse Ingress sul tuo cluster. Assicurati di avere almeno un pod in esecuzione per ogni ALB in stato abilitato. Per ulteriori informazioni, vedi Riferimento per la personalizzazione della distribuzione Ingress.

1. Crea un ALB in ogni zona in cui sono presenti nodi di lavoro.

   Il seguente comando si applica ai cluster classici. Per ulteriori informazioni e opzioni di comandi, vedi il riferimento CLI.

   ibmcloud ks ingress alb create --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID [--ip IP_ADDRESS] [--version image_version]
   

   Il seguente comando si applica ai cluster VPC. Per ulteriori informazioni e opzioni di comandi, vedi il riferimento CLI.

   ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone VPC_ZONE [--version image_version]
   

2. Verifica che gli ALB che hai creato in ciascuna zona abbiano uno Stato di enabled. Per i cluster classici, controlla che sia assegnato un IP ALB. Per i cluster VPC, controlla che Load Balancer Hostname sia assegnato.

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   Esempio di output per un cluster classico.

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021       -
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945       -
   

   Esempio di output per un cluster VPC.

   ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks
   

Modifica del numero di repliche del pod ALB

Per impostazione predefinita, ogni ALB ha 2 repliche. Puoi personalizzare le tue funzionalità di elaborazione ALB modificando manualmente il numero di pod ALB o abilitando il ridimensionamento automatico e dinamico.

Un singolo pod ALB può gestire una grande quantità di richieste. Se si verificano timeout, risposte lente o altri segni di sovraccarico, controllare lo stato dell'applicazione di backend. Assicurati che ALB sia il collo di bottiglia della tua applicazione prima di ridimensionare i pod ALB, altrimenti potrebbe non fornire i risultati previsti.

Per i cluster classici: se la configurazione del servizio del programma di bilanciamento del carico dell'ALB ha externalTrafficPolicy impostato su Local, non ridimensionare oltre 2 repliche. I programmi di bilanciamento del carico classici vengono eseguiti con una configurazione fissa di 2 repliche e possono inoltrare il traffico solo ai pod ALB che si trovano sullo stesso nodo dei pod del programma di bilanciamento del carico.

Per impostazione predefinita, gli aggiornamenti periodici della versione Ingress vengono automaticamente sottoposti a rollout per i tuoi ALB. Se esiste solo un nodo di lavoro in una zona nel tuo cluster e imposti il numero di repliche ALB su 1, questo singolo pod ALB viene eliminato e viene creato un nuovo pod ogni volta che vengono applicati degli aggiornamenti. Questo processo potrebbe causare interruzioni del traffico, anche se hai nodi di lavoro e repliche ALB in altre zone. Per evitare interruzioni del traffico, assicurati che esistano almeno due nodi di lavoro in ogni zona e che esistano due repliche per ogni ALB. Nota che durante il processo di aggiornamento, solo le connessioni nuove vengono instradate al secondo pod ALB; le connessioni esistenti sul pod ALB di aggiornamento vengono terminate in modo sicuro. Si consiglia che le applicazioni client avviino un nuovo tentativo per le connessioni esistenti terminate durante l'aggiornamento.

Modifica manualmente il numero di replica ALB creando una ConfigMap. Nota che non puoi ridimensionare manualmente le tue repliche ALB se hai configurato il tuo ALB per utilizzare la scalabilità dinamica.

1. Ottieni gli ID per i tuoi ALB.

   ibmcloud ks ingress alb ls -c CLUSTER_NAME_OR_ID
   

2. Crea un file YAML per una mappa di configurazione ibm-ingress-deploy-config. Per ogni ALB, aggiungere '{"replicas":<number_of_replicas>}'. Questo esempio aumenta il numero di pod ALB a 4 repliche.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":4}'
     <alb2-id>: '{"replicas":4}'
     ...
   

3. Crea la mappa di configurazione ibm-ingress-deploy-config nel tuo cluster.

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. Per applicare le modifiche, aggiorna i tuoi ALB. Tenere presente che l'applicazione delle modifiche potrebbe richiedere fino a 5 minuti.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Verificare che il numero di pod ALB presenti su Ready sia aumentato fino a raggiungere il numero di repliche specificato.

   kubectl get pods -n kube-system | grep alb
   

Comandi di esempio per la configurazione del ridimensionamento automatico ALB dinamico

Comando di esempio per la scalabilità dinamica basato su un utilizzo CPU medio del 60%.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

Comando di esempio per il ridimensionamento dinamico basato su metriche personalizzate memorizzate in un file denominato my-custom-metrics.yaml.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --custom-metrics-file my-custom-metrics.yaml

Calcolo dell'utilizzo medio della CPU

La seguente immagine mostra uno scenario di esempio per determinare l'utilizzo della CPU quando pianifichi una configurazione di ridimensionamento automatico.

Supponi di avere un cluster inattivo con due repliche ALB in esecuzione che non ha traffico in entrata. La richiesta CPU totale in questo caso è 2*20m=40m. Una delle repliche potrebbe utilizzare la CPU 5m e l'altra CPU 7m. È possibile calcolare l'utilizzo della CPU utilizzando la seguente formula.

Disabilitazione del ridimensionamento automatico ALB

Esegui il comando per disabilitare il ridimensionamento automatico per un ALB.

ibmcloud ks ingress alb autoscale unset --alb ALB --cluster CLUSTER