Aislamiento de los recursos de Ingress en los nodos de trabajo periféricos

Si deseas asignar pods de ALB a nodos de trabajo perimetrales, debes crear o utilizar un grupo de trabajo ya existente que cuente con al menos dos nodos de trabajo perimetrales por zona. Esto garantiza que siempre haya nodos periféricos disponibles para programar los pods de ALB.

Cuando actualizas un pod de ALB, se implementa un nuevo pod para sustituir al existente. Para que el ALB siga estando disponible durante la actualización, se lleva a cabo una actualización progresiva en la que se sustituye un pod cada vez, de modo que siempre haya al menos un pod del ALB activo. Sin embargo, los pods de ALB tienen reglas de anti-afinidad que impiden que dos pods de ALB se ejecuten en el mismo trabajador. Si hay al menos dos nodos periféricos en una zona, el nuevo pod de ALB se puede sustituir en uno de ellos mientras el otro sigue funcionando.

Para garantizar la alta disponibilidad del ALB, la etiqueta del nodo periférico se ignora cuando no hay suficientes nodos periféricos en cada región, y los pods del ALB se programan también en nodos no periféricos.

Los pasos para aislar las cargas de trabajo de ALB en los nodos periféricos son los mismos tanto para la infraestructura clásica como para la de VPC. Sin embargo, la convención de nomenclatura de la IP externa del ALB varía según el tipo. En el caso de los ALB que se ejecutan en infraestructura clásica, la IP externa es una dirección IP estándar, como 169.46.17.2. En el caso de los ALB en la infraestructura VPC, la IP externa es un nombre de host, como f3bee8b5-us-south.lb.appdomain.cloud.

Antes de empezar

Asegúrate de que dispones de los siguientes roles de IAM:
- Cualquier rol de acceso a la plataforma para el clúster
- Rol de acceso al servicio Escritor o Gestor sobre todos los espacios de nombres
Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

Aislamiento de cargas de trabajo en los nodos de trabajo periféricos

Para aislar tu carga de trabajo en los nodos de trabajo periféricos:

Crea un grupo de trabajadores con la etiqueta « dedicated=edge » o añade la etiqueta a uno de tus grupos de trabajadores ya existentes.

Para crear un grupo de trabajadores «Classic», puedes utilizar la herramienta « worker-pool create classic comando ».

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Para crear un grupo de trabajadores de VPC, puedes utilizar la herramienta « `worker-pool create vpc-gen2` [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-create-vpc-gen2-cli) ».
```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
    ```
* Para asignar una etiqueta a un grupo de trabajadores ya existente, puedes utilizar el comando « `worker-pool label set` [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli) ».
```sh {: pre}
    ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
    ```

Verifique que la agrupación de nodos trabajadores y los nodos trabajadores tengan la etiqueta dedicated=edge.

Para comprobar el grupo de trabajadores, utiliza el comando « get ».

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Para comprobar los nodos trabajadores individuales, revise el campo **Labels** de la salida del mandato siguiente.
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

Recupere todos los ALB existentes en el clúster. Revise la salida del mandato. Para cada ALB cuyo valor de « Estado » esté establecido en « activado », anota « ID de ALB » y « Compilar ».

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

Salida de ejemplo

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

Utilizando la salida del paso anterior, ejecute el mandato ibmcloud ks ingress alb update para cada ALB habilitado. Este mandato vuelve a desplegar el ALB en un nodo trabajador de extremo.

Cuando ejecuta este mandato para volver a desplegar el ALB en un nodo de trabajador periférico, el ALB también se actualiza a la última versión. Si no deseas actualizar el ALB a la última versión, incluye la opción « --version » y especifica la versión que aparece en el campo «Build» en el resultado del paso anterior.
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
Salida de ejemplo
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

Confirm that all ALB pods are deployed to edge nodes. Each public and private ALB that is enabled in your cluster has two pods.

kubectl describe nodes -l dedicated=edge | grep alb

Salida de ejemplo

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

Confirme que no se ha desplegado ningún pod de ALB en nodos que no sean de extremo.
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
Si los pods de ALB se han desplegado correctamente en nodos de extremo, no se devuelve ningún pods de ALB. Esto significa que tus ALB se han reprogramado correctamente para que se ejecuten únicamente en nodos de trabajo periféricos.

Próximos pasos

Ahora que has etiquetado los nodos de trabajo de un grupo de trabajo con « dedicated=edge » y has vuelto a implementar todos los ALB existentes en los nodos periféricos, todos los ALB que se añadan posteriormente al clúster también se implementarán en un nodo periférico de tu grupo de trabajo periférico. A continuación, puedes evitar que otros evitar que las cargas de trabajo se ejecuten en los nodos de trabajo periféricos.