Habilitación de actualizaciones automáticas

Cuando habilita las actualizaciones automáticas, los ALB se actualizan a la versión que está marcada como predeterminada. Cuando una versión más reciente se convierte en la versión predeterminada, los ALB se actualizan automáticamente a dicha versión.

Si solo existe un nodo trabajador en una zona del clúster, y establece el número de réplicas de ALB en 1, este único pod de ALB se suprime y se crea un nuevo pod siempre que se aplican actualizaciones. Este proceso podría provocar interrupciones en el tráfico, incluso si dispone de nodos de trabajo y réplicas de ALB en otras zonas. Para evitar interrupciones en el tráfico, asegúrese de que haya al menos dos nodos de trabajo en cada zona y de que haya dos réplicas para cada ALB. Tenga en cuenta que durante el proceso de actualización, sólo las conexiones nuevas se direccionan al segundo pod de ALB; las conexiones existentes en el pod de ALB de actualización se terminan de forma segura. Para las conexiones existentes que se terminan durante la actualización, inicie un reintento en las aplicaciones cliente.

Planificación de ventanas de mantenimiento para actualizaciones automáticas

Puede controlar y gestionar las actualizaciones automáticas de ALB creando una tarea de programación de tareas ( ConfigMap ) personalizada que especifique la hora en la que desea que se realicen las actualizaciones.

Para configurar una hora para las actualizaciones automáticas, hay que establecer las claves updateEndTime y updateStartTime en el archivo de configuración de implementación ( ConfigMap ). Cada clave representa una hora asignada en formato de 24 horas (HH:MM). Tenga en cuenta que esta hora se indica en hora universal coordinada (UTC), y no en la hora local.

1. Cree un archivo YAML para el mapa de configuración. Especifica los campos updateEndTime updateStartTime, y como pares clave-valor en el campo data.

   El siguiente ejemplo ConfigMap configura la función de actualización automática para actualizar los pods de ALB de tu clúster entre las 20:34 y las 23:59 UTC.

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

2. Despliegue el mapa de configuración en el clúster. Las nuevas reglas se aplican la próxima vez que se lleva a cabo una actualización.

   kubectl apply -f <filename>.yaml
   

Inhabilitación de actualizaciones automáticas

Para recibir correcciones de errores y actualizaciones de seguridad, mantenga las actualizaciones automáticas habilitadas. Cuando las actualizaciones automáticas están inhabilitadas, el usuario es responsable de actualizar los ALB manualmente.

Puede inhabilitar las actualizaciones automáticas para los ALB ejecutando ibmcloud ks ingress alb autoupdate disable -c CLUSTER_NAME_OR_ID.

Para comprobar si las actualizaciones automáticas están habilitadas para el clúster, utilice el mandato ibmcloud ks ingress alb autoupdate get -c CLUSTER_NAME_OR_ID. Si decide volver a habilitar las actualizaciones automáticas, puede ejecutar ibmcloud ks ingress alb autoupdate enable -c CLUSTER_NAME_OR_ID.

Aplicación de actualizaciones manuales

Puede aplicar manualmente una actualización única de los pods de ALB de Ingress con el mandato ibmcloud ks ingress alb update. Este mandato aplica la versión de imagen de ALB predeterminada, pero puede aplicar una versión diferente incluyendo la opción --version. Para obtener más información u opciones de mandato, consulte la Referencia de CLI.

Para actualizar la imagen de ALB a una versión específica con la opción --version, debe inhabilitar las actualizaciones automáticas de ALB y, a continuación, mantenerlas inhabilitadas durante el tiempo que desee ejecutar la versión especificada. Las actualizaciones automáticas siempre aplican la versión predeterminada y sobrescriben las actualizaciones manuales que aplique. Si desea utilizar una versión diferente, no puede habilitar las actualizaciones automáticas.

• Para ver la lista de versiones disponibles de ALB, ejecuta el siguiente comando.

  ibmcloud ks ingress alb versions --region REGION
  

• Para actualizar todos los pods de ALB del clúster, ejecute el mandato siguiente.

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

• Para actualizar el ALB para ALB específicos, ejecute el mandato siguiente.

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

Visualización de versiones de imagen soportadas

Para listar las tres últimas versiones compatibles con cada tipo de imagen, ejecute el mandato siguiente.

ibmcloud ks ingress alb versions

Salida de ejemplo

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

La versión de Ingress de Kubernetes sigue el formato <community_version>_<ibm_build>_iks. El número de compilación de IBM indica la compilación más reciente del release de Ingress NGINX de Kubernetes que IBM Cloud Kubernetes Service ha lanzado. Por ejemplo, la versión 1.1.2_2507_iks indica la compilación más reciente de la versión de 0.47.0 Ingress NGINX. IBM Cloud Kubernetes Service puede publicar compilaciones de la versión de imagen de comunidad para resolver vulnerabilidades.

Para conocer los cambios que se han introducido en cada versión de las imágenes de Ingress, consulta el registro de cambios de versiones de Ingress.

Revertir a una versión anterior

Si tus pods de ALB se han actualizado recientemente, pero una configuración personalizada de tus ALB se ve afectada por la última versión de la imagen, puedes utilizar el comando ibmcloud ks ingress alb update con la --version opción para revertir los pods de ALB a una versión anterior compatible. La versión de la imagen a la que cambie el ALB debe ser una versión de imagen soportada que se liste en la salida de ibmcloud ks ingress alb versions.

Tenga en cuenta que si revierte a una versión anterior, debe inhabilitar las actualizaciones automáticas de ALB y, a continuación, mantenerlas inhabilitadas durante el tiempo que desee ejecutar la versión anterior. Las actualizaciones automáticas siempre aplican la última versión y sobrescriben las actualizaciones manuales que aplique. Si desea utilizar una versión anterior, no puede habilitar las actualizaciones automáticas.

Creación de más ALB en una zona

Cada ALB de una zona se despliega como dos pods en distintos nodos trabajadores. Para aumentar las prestaciones de proceso de ALB y manejar más conexiones, puede crear ALB adicionales en una zona. La dirección IP del nuevo ALB se añade automáticamente al subdominio de Ingress.

Cuando se crea un clúster multizona, se crea un ALB público predeterminado en cada zona en la que tiene nodos trabajadores. Si posteriormente eliminas una de estas tres zonas originales y añades trabajadores en una zona diferente, no se creará un ALB público predeterminado en esa nueva zona. En esa zona puede crear manualmente un ALB para procesar conexiones.

Cuando se utiliza la validación de recursos de Ingress, todos los ALB validan cada solicitud de creación y actualización. Si no hay pods en ejecución para una instancia de ALB determinada, es posible que no pueda aplicar recursos de Ingress en el clúster. Asegúrese de tener al menos un pod en ejecución para cada ALB en estado habilitado. Para obtener más información, consulte Referencia de personalización de despliegue de Ingress.

1. En cada zona en la que tiene nodos trabajadores, cree un ALB.

   El mandato siguiente se aplica a los clústeres clásicos. Para obtener más información y opciones de mandato, consulte la Referencia de 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]
   

   El mandato siguiente se aplica a los clústeres de VPC. Para obtener más información y opciones de mandato, consulte la Referencia de CLI.

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

2. Verifique que los ALB que ha creado en cada zona tienen un Estado de enabled. Para los clústeres clásicos, compruebe que se haya asignado una IP de ALB. Para clústeres de VPC, compruebe que se haya asignado el Nombre de host del equilibrador de carga.

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   Ejemplo de resultado para un clúster clásico.

   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       -
   

   Ejemplo de resultado para un clúster 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
   

Cambiar el número de réplicas de un pod de ALB

De forma predeterminada, cada ALB tiene 2 réplicas. Puede personalizar las prestaciones de proceso de ALB cambiando manualmente el número de pods de ALB o habilitando el escalado dinámico y automático.

Un único pod de ALB puede manejar una gran cantidad de solicitudes. Si experimenta tiempos de espera excedidos, respuestas lentas u otros signos de sobrecarga, compruebe el estado de la aplicación de fondo. Asegúrese de que ALB sea el cuello de botella de la aplicación antes de escalar los pods de ALB; de lo contrario, es posible que no proporcione los resultados esperados.

Para clústeres clásicos: si la configuración del servicio equilibrador de carga del ALB tiene el valor externalTrafficPolicy establecido en Local, no escale por encima de 2 réplicas. Los equilibradores de carga clásicos se ejecutan con una configuración fija de 2 réplicas y solo pueden reenviar el tráfico a los pods de ALB que se encuentran en el mismo nodo que los pods de equilibrador de carga.

De forma predeterminada, las actualizaciones periódicas de la versión de Ingress se envían automáticamente a los ALB. Si solo existe un nodo trabajador en una zona del clúster, y establece el número de réplicas de ALB en 1, este único pod de ALB se suprime y se crea un nuevo pod siempre que se aplican actualizaciones. Este proceso puede provocar interrupciones del tráfico, incluso si tiene nodos trabajadores y réplicas de ALB en otras zonas. Para evitar interrupciones del tráfico, asegúrese de que hay al menos dos nodos trabajadores en cada zona y que existen dos réplicas para cada ALB. Tenga en cuenta que durante el proceso de actualización, sólo las conexiones nuevas se direccionan al segundo pod de ALB; las conexiones existentes en el pod de ALB de actualización se terminan de forma segura. Se recomienda que las aplicaciones cliente inicien un reintento para las conexiones existentes que finalizan durante la actualización.

Cambie manualmente el número de réplicas de ALB creando un ConfigMap. Tenga en cuenta que no puede escalar manualmente las réplicas de ALB si ha configurado el ALB para utilizar el escalado dinámico.

1. Obtenga los ID de los ALB.

   ibmcloud ks ingress alb ls -c CLUSTER_NAME_OR_ID
   

2. Cree un archivo YAML para un mapa de configuración ibm-ingress-deploy-config. Para cada ALB, añada '{"replicas":<number_of_replicas>}'. Este ejemplo aumenta el número de pods de ALB a 4 réplicas.

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

3. Cree el mapa de configuración ibm-ingress-deploy-config en el clúster.

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

4. Para aplicar los cambios, actualice sus ALB. Ten en cuenta que los cambios pueden tardar hasta 5 minutos en aplicarse.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Comprueba que el número de pods de ALB haya aumentado Ready hasta alcanzar el número de réplicas que has especificado.

   kubectl get pods -n kube-system | grep alb
   

Mandatos de ejemplo para configurar el escalado automático de ALB dinámico

Mandato de ejemplo para el escalado dinámico basado en un promedio de utilización de CPU 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

Mandato de ejemplo para el escalado dinámico basado en métricas personalizadas almacenadas en un archivo denominado 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

Cálculo del promedio de utilización de CPU

La imagen siguiente muestra un escenario de ejemplo para determinar el uso de CPU al planificar la configuración de escalado automático.

Supongamos que tiene un clúster desocupado con dos réplicas de ALB en ejecución que no tiene tráfico de entrada. La solicitud de CPU total en este caso es 2*20m=40m. Una de las réplicas puede utilizar la CPU de 5m y la otra CPU de 7m. Podemos calcular la utilización de CPU utilizando la siguiente fórmula.

Inhabilitación del escalado automático de ALB

Ejecute el mandato para inhabilitar el escalado automático para un ALB.

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