Isolamento delle risorse di Ingress sui nodi worker periferici

Se si desidera pianificare i pod ALB sui nodi worker periferici, è necessario creare o utilizzare un pool di worker esistente che disponga di almeno due nodi worker periferici per zona. Ciò garantisce che siano sempre presenti nodi periferici su cui pianificare i pod ALB.

Quando si aggiorna un pod ALB, viene distribuito un nuovo pod che sostituisce quello esistente. Per garantire la disponibilità dell'ALB durante l'aggiornamento, viene eseguito un aggiornamento graduale che sostituisce un pod alla volta, in modo che almeno un pod dell'ALB rimanga sempre attivo. Tuttavia, i pod ALB sono soggetti a regole di anti-affinità che impediscono a due pod ALB di essere eseguiti sullo stesso worker. Se in una zona sono presenti almeno due nodi periferici, il nuovo pod ALB può essere sostituito su uno di essi mentre l'altro continua a funzionare.

Per garantire l'alta disponibilità dell'ALB, l'etichetta del nodo periferico viene ignorata quando non ci sono abbastanza nodi periferici in ciascuna regione, e i pod dell'ALB vengono assegnati anche a nodi non periferici.

I passaggi necessari per isolare i carichi di lavoro ALB sui nodi periferici sono gli stessi sia per l'infrastruttura classica che per quella VPC. Tuttavia, la convenzione di denominazione dell'IP esterno dell'ALB varia a seconda del tipo. Per gli ALB su infrastruttura classica, l'IP esterno è un indirizzo IP standard, ad esempio 169.46.17.2. Per gli ALB presenti nell'infrastruttura VPC, l'IP esterno è un nome host, ad esempio f3bee8b5-us-south.lb.appdomain.cloud.

Prima di iniziare

Assicurati di disporre dei seguenti ruoli IAM:
- Qualsiasi ruolo di accesso alla piattaforma per il cluster
- Ruolo di accesso al servizio “Autore” o “Amministratore” per tutti gli spazi dei nomi
Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Isolamento dei carichi di lavoro sui nodi di lavoro periferici

Per isolare il carico di lavoro sui nodi worker periferici:

Crea un pool di worker con l'etichetta " dedicated=edge " oppure aggiungi l'etichetta a uno dei tuoi pool di worker esistenti.

Per creare un pool di worker Classic, è possibile utilizzare il comando worker-pool create classic .

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Per creare un pool di worker VPC, è possibile utilizzare il [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-create-vpc-gen2-cli) ` `worker-pool create vpc-gen2` `.
```sh {: pre}
    ibmcloud oc worker-pool create vpc-gen2 --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Per assegnare un'etichetta a un gruppo di lavoratori esistente, è possibile utilizzare il [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli) ` `worker-pool label set` `.
```sh {: pre}
    ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
    ```

Verifica che il pool di nodi di lavoro e i nodi di lavoro abbiano l'etichetta dedicated=edge.

Per verificare il pool dei worker, utilizzare il comando get .

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Per controllare i singoli nodi di lavoro, esamina il campo **Labels** dell'output del seguente comando.
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

Richiama tutti gli ALB esistenti nel cluster. Controlla l'output del comando. Per ogni ALB il cui stato è impostato su “abilitato”, prendere nota dell’ID ALB e della build.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

Output di esempio

ALB ID                                Enabled   State     Type      Load Balancer Hostname                      Zone         Build                                  Status
private-crc81nk5l10gfhdql4i3qg-alb1   true      enabled   private   e9dd35e6-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   enabled
public-crc81nk5l10gfhdql4i3qg-alb1    true      enabled   public    38daf55c-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   healthy

Utilizzando l'output del passaggio precedente, eseguire il comando ibmcloud ks ingress alb update per ogni ALB abilitato. Questo comando ridistribuisce l'ALB a un nodo di lavoro edge.

Quando si esegue questo comando per ridistribuire l'ALB su un nodo worker periferico, anche l'ALB viene aggiornato all'ultima versione. Se non si desidera aggiornare l'ALB all'ultima versione, includere l'opzione --version e specificare la versione indicata nella colonna "Build" nell'output del passaggio precedente.
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
Output di esempio
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

Conferma che tutti i pod ALB siano distribuiti ai nodi edge. Ogni ALB pubblico e privato abilitato nel tuo cluster dispone di due pod.

kubectl describe nodes -l dedicated=edge | grep alb

Output di esempio

kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-27pv4    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-7p9q6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-s77z6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-kvs9f    0 (0%)        0 (0%)      0 (0%)           0 (0%)

Conferma che nessun pod ALB sia distribuito ai nodi non edge.
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
Se i pod ALB vengono distribuiti correttamente ai nodi edge, non viene restituito alcun pod ALB. Ciò significa che le tue ALB sono state ripianificate con successo esclusivamente sui nodi worker periferici.

Passi successivi

Ora che hai assegnato un'etichetta ai nodi di lavoro in un pool di lavoro tramite dedicated=edge e hai ridistribuito tutti gli ALB esistenti sui nodi periferici, anche tutti gli ALB aggiunti successivamente al cluster verranno distribuiti su un nodo periferico del tuo pool di lavoro periferico. Inoltre, puoi impedire che altri impedire l'esecuzione dei carichi di lavoro sui nodi di elaborazione periferici.