Isoler les ressources Ingress sur les nœuds de travail en périphérie

Si vous souhaitez affecter des pods ALB à des nœuds de travail en périphérie, vous devez créer ou utiliser un pool de travail existant comprenant au moins deux nœuds de travail en périphérie par zone. Cela garantit que des nœuds périphériques sont toujours disponibles pour accueillir les pods ALB à planifier.

Lorsque vous mettez à jour un pod ALB, un nouveau pod est déployé pour remplacer celui qui existe déjà. Afin de garantir la disponibilité de l'ALB pendant la mise à jour, une mise à jour progressive remplace un pod à la fois, de sorte qu'au moins un pod ALB reste toujours actif. Cependant, les pods ALB sont soumis à des règles d'anti-affinité qui empêchent deux pods ALB de s'exécuter sur le même nœud de travail. S'il y a au moins deux nœuds périphériques dans une zone, le nouveau pod ALB peut être déployé sur l'un d'entre eux tandis que l'autre continue de fonctionner.

Afin d'assurer la haute disponibilité de l'ALB, l'étiquette du nœud périphérique est ignorée lorsqu'il n'y a pas suffisamment de nœuds périphériques dans chaque région, et les pods de l'ALB sont également planifiés sur des nœuds non périphériques.

Les étapes permettant d'isoler les charges de travail ALB sur les nœuds périphériques sont les mêmes, que ce soit pour une infrastructure classique ou pour une infrastructure VPC. Cependant, la convention de nommage de l'adresse IP externe de l'ALB varie selon le type. Pour les ALB déployés sur une infrastructure classique, l'adresse IP externe est une adresse IP standard, telle que 169.46.17.2. Pour les ALB déployés sur une infrastructure VPC, l'adresse IP externe correspond à un nom d'hôte tel que f3bee8b5-us-south.lb.appdomain.cloud.

Avant de commencer

Assurez-vous de disposer des rôles IAM suivants :
- N'importe quel rôle d'accès à la plateforme pour le cluster
- Rôle d'accès au service Auteur ou Responsable pour tous les espaces de nom
Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Isolation des charges de travail sur les nœuds de travail en périphérie

Pour isoler votre charge de travail sur les nœuds de travail en périphérie :

Créez un pool de travailleurs portant le libellé « dedicated=edge » ou ajoutez ce libellé à l'un de vos pools de travailleurs existants.

Pour créer un pool de travailleurs « Classic », vous pouvez utiliser la commande « 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
    ```
* Pour créer un pool de travailleurs VPC, vous pouvez utiliser la [commande](/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
    ```
* Pour attribuer une étiquette à un pool de travailleurs existant, vous pouvez utiliser la [commande](/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
    ```

Vérifiez que le pool de noeuds worker et les noeuds worker comportent le libellé dedicated=edge.

Pour vérifier le pool de travailleurs, utilisez la commande « get ».

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Pour vérifier les noeuds worker individuels, examinez la zone **Labels** de la sortie de la commande suivante :
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

Extrayez tous les équilibreurs de charge d'application du cluster. Consultez la sortie de la commande. Pour chaque ALB dont la valeur « Statut » est définie sur « activé », notez les adresses ALB ID et Construire.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

Exemple de sortie

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

A l'aide de la sortie de l'étape précédente, exécutez la commande ibmcloud ks ingress alb update pour chaque ALB activée. Cette commande redéploie l'équilibreur de charge d'application sur un noeud worker de périphérie.

Lorsque vous exécutez cette commande pour redéployer ALB sur un nœud worker d'arête, ALB met également à jour la dernière version. Si vous ne souhaitez pas mettre à jour l'ALB vers la dernière version, incluez l'option « --version » et indiquez la version mentionnée sous « Build » dans le résultat de l'étape précédente.
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
Exemple de sortie
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

Vérifiez que tous les pods d'équilibreur de charge d'application sont déployés sur des noeuds de périphérie. Chaque équilibreur de charge d'application public et privé qui est activé dans votre cluster comporte deux pods.

kubectl describe nodes -l dedicated=edge | grep alb

Exemple de sortie

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%)

Vérifiez qu'aucun pod d'équilibreur de charge d'application n'est déployé sur des noeuds autres que des noeuds de périphérie.
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
Si les pods d'équilibreur de charge d'application sont correctement déployés sur des noeuds de périphérie, aucun pod d'équilibreur de charge d'application n'est renvoyé. Cela signifie que vos ALB ont été replanifiées avec succès sur des nœuds de travail périphériques uniquement.

Etapes suivantes

Maintenant que vous avez attribué des étiquettes aux nœuds de travail d'un pool de travail à l'aide de l' dedicated=edge et que vous avez redéployé tous les ALB existants vers les nœuds périphériques, tous les ALB ajoutés par la suite au cluster seront également déployés sur un nœud périphérique de votre pool de travail périphérique. Vous pouvez ensuite empêcher d'autres charges de travail de s'exécuter sur les nœuds de travail en périphérie.