Error de entrada: ERRIODEG

Nube privada virtual Infraestructura clásica Satellite

Aprenda a resolver los errores de ERRIODEG cuando el operador de entrada se encuentra en un estado degradado.

Puede utilizar el mandato ibmcloud oc ingress status-report ignored-errors add para añadir un error a la lista de errores ignorados. Los errores ignorados siguen apareciendo en la salida del mandato ibmcloud oc ingress status-report get, pero se ignoran al calcular el estado general de Ingress.

Cuando compruebe el estado de los componentes de Ingress del clúster ejecutando el mandato ibmcloud oc ingress status-report get, verá un error similar al siguiente.

The Ingress Operator is in a degraded state (ERRIODEG).

El operador de Ingress comprueba el estado de los controladores de Ingress y entra en un estado degradado cuando fallan las comprobaciones.

Comprueba que tus nodos no estén sobrecargados. Los nodos sobrecargados pueden provocar que fallen las comprobaciones de estado de Ingress Operator.

Para comprobar si dispone de suficiente margen de CPU y memoria, ejecute el siguiente comando.

kubectl top nodes

Consulta los detalles del error ClusterOperatoringress y sigue los pasos indicados en función del mensaje de error.

Compruebe el estado de ingress ClusterOperator. Si ve False en la columna DEGRADED, espere de 10 a 15 minutos para ver si el aviso de estado de Ingress desaparece. Si no es así, continúe con los pasos de resolución de problemas basados en el mensaje de la columna MESSAGE.

oc get clusteroperator ingress

Una o más condiciones de estado indican que no está disponible: DeploymentAvailable=False

  1. Asegúrese de que el clúster tenga al menos dos nodos trabajadores. Para obtener más información, consulte Adición de nodos trabajadores a clústeres clásicos o Adición de nodos trabajadores a clústeres de VPC.
  2. Asegúrese de que los trabajadores del clúster estén en buen estado; de lo contrario, los pods del controlador de Ingress no se pueden planificar. Para obtener más información, consulte Estados de los nodos trabajadores.

Una o más condiciones de estado indican que no está disponible: LoadBalancerReady=False

  1. Sólo VPC: Asegúrese de que no ha alcanzado la cuota de instancia de LBaaS. Para obtener más información, consulte Cuotas y límites de servicio y el mandato ibmcloud is load-balancers .
  2. Asegúrese de que los maestros de clúster estén en buen estado. Para obtener más información, consulte Revisión del estado del maestro.
  3. Renueve los maestros de clúster ejecutando ibmcloud oc cluster master refresh mandato.

Una o más condiciones de estado indican un estado degradado: CanaryChecksSucceeding=False

  1. Acceda al clúster de Red Hat OpenShift.

  2. Asegúrese de que la dirección de servicio LoadBalancer correcta esté registrada para el subdominio de Ingress.

    1. Ejecute el mandato de ibmcloud oc cluster get para ver el subdominio de Ingress.
    2. Ejecute el mandato ibmcloud oc nlb-dns get para ver las direcciones registradas.
    3. Ejecute el mandato oc get services -n openshift-ingress para obtener las direcciones del equilibrador de carga real.
    4. Compare las direcciones registradas y reales y actualice el subdominio si difiere. VPC: Ejecute ibmcloud oc nlb-dns replace mandato para sustituir la dirección actual. Clásico: elimine las direcciones registradas actualmente ejecutando el ibmcloud oc nlb-dns rm classic mandato y, a continuación, añada las nuevas direcciones con el ibmcloud oc nlb-dns add mandato. Satellite: Las direcciones concretas dependen de tu configuración: si expones tus nodos de trabajo mediante un equilibrador de carga externo, registra las direcciones de dicho equilibrador; en caso contrario, registra las direcciones IP asignadas al servicio « router-external-default » en el espacio de nombres « openshift-ingress » (utiliza el comando « oc get services -n openshift-ingress router-external-default -o yaml » para obtener las direcciones). Elimine las direcciones registradas actualmente ejecutando el mandato ibmcloud oc nlb-dns rm classic y, a continuación, añada las nuevas direcciones con el mandato ibmcloud oc nlb-dns add .

  3. Sólo VPC: el tráfico de comprobación de estado canario se origina en uno de los nodos trabajadores del clúster.

    • El tráfico de comprobación de estado se origina en uno de los nodos trabajadores del clúster. En el caso de clústeres con punto final de servicio público, el tráfico se dirige a la dirección IP flotante pública de la instancia del equilibrador de carga de VPC, por lo que es necesario tener una Public Gateway conectada a todas las subredes de trabajador. En el caso de clústeres con solo puntos finales de servicio privados, el tráfico se dirige a la dirección IP de subred de VPC del equilibrador de carga de VPC, por lo tanto, no es necesaria una Public Gateway. Para clústeres con punto final de servicio público:
      1. Ejecute ibmcloud is public-gateways para ver las pasarelas públicas.
      2. Ejecute ibmcloud is subnets para ver las subredes.
      3. Para cada subred, ejecute ibmcloud is subnet <subnet-id> para comprobar siempre que tenga una pasarela pública.
        1. Si la subred no tiene una pasarela pública conectada, debe conectar una. Para obtener más información, consulte Creación de pasarelas públicas
    • Si los equilibradores de carga de VPC se encuentran en una subred distinta de los nodos trabajadores del clúster, debe actualizar el grupo de seguridad conectado a la subred del equilibrador de carga de VPC para permitir el tráfico de entrada de las subredes de trabajo.
    • Para obtener más información, consulte Creación de un clúster de Red Hat OpenShift en Virtual Private Cloud, Configuración de subredes de VPC y Creación y gestión de grupos de seguridad de VPC.

  4. Asegúrese de que ninguna regla de cortafuegos bloquee el tráfico de Canary ni el tráfico DNS a través de UDP y TCP. VPC: el tráfico canario se origina en uno de los nodos de trabajo, fluye a través de un Public Gateway de VPC y llega al lado público de la instancia del equilibrador de carga de VPC. Configure los grupos de seguridad de VPC para permitir esta comunicación. Para obtener más información, consulte Comprensión de las redes VPC de clúster seguras por defecto y Creación y gestión de grupos de seguridad VPC. Clásico: el tráfico canario se origina en la dirección IP pública de uno de los nodos trabajadores y llega a la dirección IP pública de sus balanceadores de carga clásicos. Configure las políticas de red para permitir esta comunicación. Para obtener más información, consulte Control del tráfico con políticas de red en clústeres clásicos.

Próximos pasos

  1. Espere 30 minutos y, a continuación, ejecute el mandato oc get clusteroperator ingress y vuelva a comprobar la columna MESSAGE.
  2. Si ve un mensaje de error diferente, repita los pasos de resolución de problemas.
  3. Si el problema persiste, póngase en contacto con soporte. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir los archivos de registro relevantes, los mensajes de error o las salidas de mandato.