Container Service for Kubernetes:Preguntas frecuentes sobre ALB Ingress

¿Por qué no se aplican las reglas de ALB Ingress?

Los ALB Ingresses mantienen las reglas de enrutamiento en modo inline. Cuando varios Ingresses comparten la misma instancia de ALB, un error de configuración en cualquiera de ellos impide que el resto de los Ingresses de esa instancia surtan efecto.

Para solucionarlo, localice el Ingress con el error (por lo general, uno creado antes de los Ingresses afectados) y corrija su configuración. Los demás Ingresses volverán a funcionar en cuanto se resuelva el error.

¿Cuál es la diferencia entre los ALB Ingresses y los NGINX Ingresses?

Los ALB Ingresses se basan en ALB, un servicio en la nube totalmente administrado que no requiere mantenimiento manual. En cambio, con los NGINX Ingresses usted debe gestionar el controlador por su cuenta.

Para ver una comparación detallada, consulte Comparison among NGINX Ingresses, ALB Ingresses, and MSE Ingresses.

¿Qué es el grupo de servidores kube-system-fake-svc-80?

ALB exige una regla de reenvío predeterminada antes de crear un listener, y cada regla de reenvío debe asociarse exactamente con un grupo de servidores. El grupo de servidores kube-system-fake-svc-80 cumple este requisito: funciona como marcador de posición para la regla de reenvío predeterminada. No procesa ninguna solicitud y no se puede eliminar.

¿Se puede habilitar el acceso interno y externo a la vez en un ALB Ingress?

Sí. Cree una instancia de ALB orientada a Internet. La instancia aprovisiona automáticamente una dirección IP elástica (EIP) en cada zona para el tráfico de Internet. Además, se le asigna una dirección IP virtual (VIP) privada para el acceso desde la red interna, por lo que ambos modos de acceso funcionan de manera simultánea.

Si solo necesita acceso interno, cree una instancia de ALB orientada a la red interna.

¿Por qué no aparece el pod del controlador de ALB Ingress en mi clúster?

El pod del controlador de ALB Ingress solo es visible en el namespace kube-system dentro de los clústeres ACK dedicated. En los clústeres ACK Basic, ACK Pro y ACK Serverless, el controlador de ALB Ingress se ejecuta como un componente totalmente administrado y no se expone como un pod en el clúster.

Si desea migrar desde un clúster ACK dedicated, consulte Hot migration from ACK dedicated clusters to ACK Pro clusters.

¿Cómo evito que cambie el nombre de dominio de ALB?

El nombre de dominio permanece estable siempre que no modifique el IngressClass ni el objeto AlbConfig al que hace referencia. Cuando usa un objeto AlbConfig para crear una instancia de ALB, el Ingress apunta a dicha instancia mediante un IngressClass. Por lo tanto, el nombre de dominio está vinculado a la instancia de ALB y no al Ingress en sí.

¿Se crea automáticamente una instancia de ALB al habilitar ALB Ingress durante la creación del clúster?

No. Al seleccionar ALB Ingress durante la creación de un clúster administrado de ACK, solo se instala el controlador de ALB Ingress. La instancia de ALB debe crearse por separado.

¿ALB Ingress admite la selección de Services entre namespaces?

No. ALB Ingress no admite la selección de Services entre distintos namespaces. Un recurso Ingress solo puede hacer referencia a Services dentro de su mismo namespace. Si el Service referenciado reside en otro namespace, el Ingress no podrá asociar correctamente el servicio de backend.

¿El límite de QPS de ALB Ingress tiene un costo adicional? ¿Cuál es su alcance? ¿Cómo configuro límites distintos para diferentes rutas?

Facturación: el límite de QPS no genera cargos adicionales. Sin embargo, la instancia de ALB se cobra según el uso; consulte ALB billing.

Alcance aplicable: la anotación alb.ingress.kubernetes.io/traffic-limit-qps se aplica en el nivel de Ingress. Al configurar esta anotación, el controlador aplica la misma configuración de límite a cada regla de reenvío de ALB generada para el Ingress. Este valor no se puede establecer de forma independiente para una sola ruta, ni la cuota de QPS se comparte entre varias rutas.

Distintas configuraciones de límite: si diferentes rutas requieren valores de límite distintos, divida la configuración en varios Ingresses y asigne una anotación de límite específica a cada uno. No es necesario crear varias instancias de ALB, ya que una sola instancia puede asociarse con varios Ingresses. Para escenarios avanzados, configure TrafficLimit mediante una acción de regla de reenvío personalizada. Tenga en cuenta que este método no es compatible con la anotación global traffic-limit-qps.

¿ALB Ingress admite varios nombres de dominio?

Sí. Un solo listener de ALB puede vincular distintos nombres de dominio mediante la configuración de varias reglas de reenvío.

Para configurar varios nombres de dominio, defina varias entradas host dentro de spec.rules en el recurso Ingress. Cada entrada host especifica un nombre de dominio, lo que le permite asociar distintos Services de backend con diferentes nombres de dominio dentro del mismo Ingress.

¿Por qué se sobrescriben los cambios que hago en la consola de ALB?

La configuración de ALB Ingress se gestiona a través del objeto ALB Ingress o AlbConfig en el servidor de API del clúster. Los cambios realizados directamente en la consola de ALB no se sincronizan con el servidor de API. Por ello, cualquier llamada interna u operación del clúster sobrescribirá los cambios de la consola con la configuración almacenada en el clúster.

¿Qué hago si recibo un error HTTP 503 tras eliminar una regla de reenvío recién creada?

Compruebe si el ALB Ingress de la regla de reenvío tiene la anotación canary:true. En los despliegues canary, el tráfico se redirige de la versión anterior del Service a la versión canary. Agregue canary:true únicamente al Ingress canary, no al Ingress del Service anterior.

Los despliegues canary solo admiten dos Ingresses y un número limitado de condiciones de reenvío. Si necesita un enrutamiento de tráfico más flexible, utilice reglas de reenvío personalizadas. Consulte Use ALB Ingresses to perform canary releases y Configure custom forwarding rules for ALB Ingresses.

¿Por qué no surten efecto los cambios de mi ALB Ingress aunque no haya errores?

Es posible que el IngressClass esté apuntando a un objeto AlbConfig incorrecto. Compruebe que el campo parameters de su IngressClass esté configurado correctamente. Consulte Use an IngressClass to associate an AlbConfig object with an Ingress.

¿Por qué se eliminaron algunos listeners después de ejecutar kubectl apply para actualizar el AlbConfig?

El comando kubectl apply sobrescribe todo el recurso AlbConfig. Si su archivo YAML omite algún listener configurado previamente, ese listener se elimina.

Siempre que sea posible, utilice kubectl edit. Este comando abre el recurso actual completo para su edición y evita omisiones accidentales:

kubectl -n <namespace> edit AlbConfig <albconfig-name>

Si ya se eliminaron listeners, vuelva a agregarlos con el mismo comando kubectl edit mostrado anteriormente.

¿Por qué el endpoint externo de un ALB Ingress está vacío o no se puede obtener la dirección, y cómo lo soluciono?

Si el endpoint externo de un ALB Ingress está vacío o no se puede obtener la dirección, revise las causas comunes a continuación y aplique la solución correspondiente:

1. No se especificó el IngressClass: asegúrese de que el recurso Ingress indique el valor correcto de ingressClassName (por ejemplo, alb). Si ingressClassName no está definido o el valor no coincide con el IngressClass gestionado por el ALB Ingress Controller, el controlador no procesará el Ingress y el endpoint permanecerá vacío.

2. Asociación incorrecta del AlbConfig: compruebe si el IngressClass está asociado con el nombre de AlbConfig adecuado y verifique que el estado del AlbConfig sea normal. Una asociación incorrecta o un AlbConfig en estado anómalo impide que se aprovisione ALB. Para obtener más información, consulte Use an IngressClass to associate an AlbConfig with an ingress.

3. Direcciones IP insuficientes en el vSwitch: revise la cantidad de direcciones IP disponibles en los vSwitches asociados con el AlbConfig. Para garantizar que las funciones elásticas de ALB funcionen por completo, reserve como mínimo 8 direcciones IP en cada vSwitch donde se despliegue la instancia de ALB. Si las direcciones IP disponibles son insuficientes, sustituya el vSwitch o amplíe su rango CIDR.

4. Zonas de disponibilidad insuficientes: ALB requiere alta disponibilidad, por lo que necesita vSwitches en como mínimo dos zonas de disponibilidad distintas. Si solo configuró una zona, agregue vSwitches en otra zona de disponibilidad como mínimo.

5. Opción de instalación de componentes: si durante la instalación de componentes seleccionó None, no se creó automáticamente ninguna instancia de ALB ni ningún AlbConfig. Deberá manually create AlbConfig and IngressClass y associate an AlbConfig with an Ingress using IngressClass.

¿Cómo reduzco el tiempo de reconciliación durante el escalado de pods?

El tiempo de reconciliación aumenta según la cantidad de Ingresses asociados a un Service. Utilice alguno de estos enfoques:

• Limite los Ingresses por Service: mantenga un máximo de 30 Ingresses asociados a un mismo Service.

• Consolide las reglas de Ingress: asocie varios Services al mismo Ingress y defina reglas de enrutamiento independientes dentro de él, en lugar de crear un Ingress por cada Service.