Depuración de Ingress

[Nube privada virtual] {: tag-vpc} Infraestructura clásica

Ha expuesto la app creando un recurso de Ingress para la app en el clúster. Sin embargo, cuando intenta conectarse a la aplicación a través del subdominio de Ingress o la dirección IP del controlador de Ingress, la conexión falla o excede el tiempo de espera.

Los pasos de las secciones siguientes pueden ayudarle a depurar la configuración de Ingress.

Antes de empezar, asegúrese de que tiene las siguientes políticas de acceso de IBM Cloud IAM para IBM Cloud Kubernetes Service: - El rol de acceso a la plataforma Editor o Administrador para el clúster - El rol de acceso de servicio Escritor o **Gestor **

¿Está viendo la página La aplicación no está disponible al intentar acceder al subdominio de la app? Comprueba la implementación de tu aplicación y la configuración de los recursos Ingress y Route. ¿Está viendo la página Tiempo de espera de conexión? Comprobar el estado de los pods del controlador de Ingress.

Paso 1: Comprueba la configuración de los recursos de implementación de la aplicación, Ingress y Route

Empiece por comprobar si hay errores en el despliegue de apps y en el despliegue de los recursos de Ingress. Mensajes de error en los despliegues pueden ayudarle a encontrar las causas raíz de las anomalías y a depurar aún más la configuración de Ingress en las secciones siguientes.

  1. Antes de depurar Ingress, consulte el tema sobre Depuración de los despliegues de app. Los problemas de Ingress suelen estar causados por problemas subyacentes del despliegue de la app o del servicio ClusterIP que expone la app. Por ejemplo, es posible que la etiqueta de la app y el selector del servicio no coincidan, o que los puertos de destino del servicio y de la app no coincidan.

  2. Compruebe el despliegue de recursos de Ingress y mire si hay avisos o mensajes de error.

    oc describe ingress <ingress_resource_name>

    En la sección de sucesos de la salida, es posible que vea mensajes de aviso sobre valores no válidos en el recurso de Ingress o en determinadas anotaciones que haya utilizado. En cuanto a las anotaciones, ten en cuenta que las anotaciones IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) y Ingress- NGINX (nginx.ingress.kubernetes.io/<annotation>) no son compatibles con el controlador Ingress ni con el recurso Ingress en la versión 4 de Red Hat OpenShift. Si desea personalizar las reglas de enrutamiento para las aplicaciones de un clúster que ejecuta la versión 4 de Red Hat OpenShift, puede utilizar anotaciones específicas de la ruta HAProxy, que tienen el formato haproxy.router.openshift.io/<annotation> o router.openshift.io/<annotation>.

    NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  default-http-backend:80 (<none>)
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:  <none>
Events:       <none>

  3. Comprueba la implementación de tu recurso Route y busca posibles advertencias o mensajes de error.

    oc describe route <myroute>

    En las secciones Estado y Eventos del resultado, es posible que aparezcan mensajes de advertencia sobre valores no válidos en tu recurso Route o en determinadas anotaciones que hayas utilizado.

    Name:         myroute
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  route.openshift.io/v1
Kind:         Route
Metadata:
  Creation Timestamp:  2026-07-01T10:18:43Z
  Generation:          1
  Owner References:
    API Version:     networking.k8s.io/v1
    Controller:      true
    Kind:            Ingress
    Name:            coffee-ingress
    UID:             e7a18dd4-402d-461c-a41f-c4750b6d2032
  Resource Version:  178601
  UID:               17c623e6-e9ef-4179-a3ad-af8ea311f2e5
Spec:
  Host:  mycluster-<hash>-0000.us-south.containers.appdomain.cloud
  Path:  /
  Port:
    Target Port:  http
  Tls:
    Certificate:  ...
    Insecure Edge Termination Policy:  Redirect
    Key: ...
    Termination:  edge
  To:
    Kind:           Service
    Name:           myservice1
    Weight:         100
  Wildcard Policy:  None
Status:
  Ingress:
    Conditions:
      Last Transition Time:     2026-07-01T10:18:43Z
      Status:                   True
      Type:                     Admitted
    Host:                       mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Canonical Hostname:  router-default.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Name:                default
    Wildcard Policy:            None
Events:  <none>

  4. Comprueba si hay advertencias o mensajes de error en los eventos a nivel de clúster.

    oc get events

    En algunos casos, se emiten eventos de advertencia o error relacionados con los recursos de Ingress a nivel de clúster. Ten en cuenta que los eventos se limitan al espacio de nombres.

    LAST SEEN   TYPE      REASON                          OBJECT             MESSAGE
2m40s       Warning   IncompleteIngressToRouteRules   ingress/myingress  Incomplete ingress to route rules detected: Invalid or missing TLS secret for rule host "mycluster-<hash>-0000.us-south.containers.appdomain.cloud" at index 0, path index 0

  5. Comprueba el archivo de configuración del recurso Ingress o Route.

    oc get ingress -o yaml

    1. Asegúrese de definir un host solo en un recurso de Ingress. Si se define un host en varios recursos de Ingress, el controlador de Ingress podría no reenviar el tráfico correctamente y podría experimentar errores.

    2. Compruebe que el subdominio y el certificado TLS sean correctos. Para consultar el certificado TLS y el subdominio de Ingress proporcionados por IBM, ejecute ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

    3. Asegúrese de que su app está a la escucha en la misma vía de acceso que está configurada en la sección path de Ingress.

    4. Edite el YAML de configuración de recursos según sea necesario. Cuando se cierra el editor, los cambios se guardan y se aplican automáticamente.

        oc edit ingress <myingressresource>
    ```

  6. Compruebe si ha alcanzado el número máximo de equilibradores de carga de VPC permitidos por cuenta. Consulte las cuotas de recursos de VPC en la documentación de cuotas de VPC en todos los clústeres de VPC en la VPC.

Paso 2: Comprobar el estado del controlador Ingress

Verifique que el operador de Ingress y el controlador de Ingress tengan un estado correcto. Los controladores de Ingress los gestionan el operador de Ingress. El controlador de Ingress reenvía solicitudes a los pods para esa aplicación solo de acuerdo con las reglas definidas en el recurso de Ingress e implementadas por el controlador de Ingress.

  1. Comprueba el estado de tu operador de Ingress consultando el recurso personalizado IngressController. En Red Hat OpenShift en IBM Cloud, el operador Ingress es gestionado por la plataforma y no se puede acceder directamente a sus pods. En su lugar, compruebe el estado del operador a través del estado del recurso IngressController.
    1. Describa la configuración predeterminada IngressController y revise la sección Condiciones para ver si hay entradas de estado Unknown False o y sus mensajes.
        oc describe ingresscontroller/default -n openshift-ingress-operator
    ```
2. Enumera todos los recursos `IngressController` para comprobar que ninguno se encuentre en un estado degradado.
```sh {: pre}
    oc get ingresscontrollers -n openshift-ingress-operator
    ```
  2. Compruebe el estado y los registros de los pods del controlador de Ingress.
    1. Obtenga los pods del controlador de Ingress que se ejecutan en el clúster.
        oc get pods -n openshift-ingress
    ```
2. Para asegurarse de que todos los pods de `router-default` y los pods de los controladores de Ingress en cualquier otra zona se estén ejecutando, consulte la columna **ESTADO**. Si tiene un clúster multizona, tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina `router-default`, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, `router-dal12`.

3. Si un pod no tiene el estado `Running`, puede suprimir el pod para reiniciarlo.
```sh {: pre}
    oc delete pod <pod> -n openshift-ingress
    ```
4. Obtenga los registros para cada pod y busque mensajes de error en los registros.
```sh {: pre}
    oc logs <pod> -n openshift-ingress
    ```
  3. Compruebe si hay sucesos y errores en cada servicio del controlador de Ingress.
    1. Liste los servicios del espacio de nombres openshift-ingress.
        oc get svc -n openshift-ingress
    ```
    Salida de ejemplo para un clúster multizona con nodos trabajadores en `dal10` y `dal13`:
    ```sh {: screen}
    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
    router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
    router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d
    ```
2. Describa cada servicio del controlador de Ingress y compruebe si hay mensajes en la sección `Events` de la salida.
```sh {: pre}
    oc describe svc router-default -n openshift-ingress
    ```
    Por ejemplo, en clústeres de VPC, puede ver un error como el siguiente: `The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline`. Para obtener más información, consulte [Clústeres de VPC: ¿Por qué mi app no puede conectarse a través del equilibrador de carga?](/docs/openshift?topic=openshift-vpc_ts_lb).

Paso 3: Realizar una prueba de ping al subdominio de Ingress y a la dirección IP pública del controlador de Ingress

Compruebe la disponibilidad de las direcciones IP públicas del controlador de Ingress y verifique las correlaciones de subdominio. Asimismo, asegúrese de que el panel de control de Red Hat OpenShift pueda acceder a los controladores de Ingress para comprobar su estado.

  1. Verifique que los servicios de controlador de Ingress sean accesibles para la comprobación de estado del controlador de Ingress.

    • Clásico: Si utiliza políticas de red pre-DNAT de Calico u otro cortafuegos personalizado para bloquear el tráfico entrante a su clúster, debe permitir el acceso entrante en los puertos 80 o 443 desde el plano de control Red Hat OpenShift y las direcciones IP IBM, NS1 y IPv4 de a las direcciones IP de sus servicios de controladores de Ingress, de modo que el plano de control Red Hat OpenShift pueda comprobar el estado de sus controladores de Ingress. Por ejemplo, si utilizas políticas de Calico, crea una política de Calico previa a DNAT para permitir el acceso entrante a tus controladores Ingress desde las direcciones IP de origen de IBM NS1, que se utilizan para comprobar el estado de tus controladores Ingress en el puerto 80 y las subredes del plano de control de la región en la que se encuentra tu clúster. Continúe en el paso siguiente para obtener las direcciones IP de servicio del controlador de Ingress.

    • VPC: Si dispone de un grupo de seguridad personalizado en las instancias de VPC LBaaS ( LoadBalancer-as-a-Service ) para el ingreso al clúster, asegúrese de que las reglas del grupo de seguridad permitan el tráfico necesario para las comprobaciones de estado desde las direcciones IP del plano de control de Kubernetes al puerto 443.

  2. Obtenga las direcciones IP externas donde escuchan los servicios de controlador de Ingress. Si tiene un clúster multizona, tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, router-dal12. En clústeres de VPC, las direcciones IP externes están detrás de un nombre de host asignado por el equilibrador de carga de VPC, como por ejemplo aabb1122-us-south.lb.appdomain.cloud.

    oc get svc -n openshift-ingress

    Salida de ejemplo para un clúster clásico multizona con nodos trabajadores en dal10 y dal13:

    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d

    Si un controlador de Ingress no tiene dirección IP externa (clásica) o nombre de host (VPC), consulte Versión 4: ¿Por qué el controlador Ingress no se despliega en una zona?.

  3. Compruebe el estado de los pods de Ingress (clásica) o el nombre de host (VPC).

    • Clústeres clásicos: Compruebe el estado de los pods del controlador de Ingress.
    • Clústeres VPC: los servicios de direccionamiento en clústeres multizona se crean en una ruta /healthz para que se pueda comprobar el estado de salud de cada dirección IP de servicio. El comando siguiente cURL HTTP usa la ruta /healthz, que devuelve el estado ok en el caso de una IP sana.
    curl -X GET http://<router_svc_IP_or_hostname>/healthz -H "Host:router-default.<ingress_subdomain>"

    Si una o varias de las direcciones IP no devuelve ok, compruebe el estado de los pods del controlador de Ingress.

  4. Obtenga el subdominio de Ingress proporcionado por IBM.

    ibmcloud oc cluster get --cluster <cluster_name_or_ID> | grep Ingress

    Salida de ejemplo

    Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

  5. Asegúrese de que la dirección IP del controlador de Ingress esté registrada con el subdominio de Ingress proporcionado por IBM del clúster. Por ejemplo, en un clúster multizona, la IP del controlador de Ingress público en cada zona donde tenga nodos de trabajador debe estar registrada bajo el mismo subdominio.

    host <ingress_subdomain>

    Salida de ejemplo

    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XXX.XX

  6. Si utiliza un dominio personalizado, verifique que ha utilizado el proveedor de DNS para correlacionar el dominio personalizado con el subdominio proporcionado por IBM o la dirección IP pública del controlador de Ingress.

    • CNAME del subdominio proporcionado por IBM: compruebe que el dominio personalizado esté correlacionado con el subdominio proporcionado por IBM del clúster en el registro de nombre canónico (CNAME).
        host www.my-domain.com
    ```
    Salida de ejemplo
    ```sh {: screen}
    www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    ```
* **Registro A de la dirección IP pública**: compruebe que el dominio personalizado esté correlacionado con la dirección IP pública portátil del controlador de Ingress en el registro A.
```sh {: pre}
    host www.my-domain.com
    ```
    Salida de ejemplo
    ```sh {: screen}
    www.my-domain.com has address 169.XX.XX.XXX
    www.my-domain.com has address 169.XX.XX.XXX
    ```