Depuración de Ingress

Virtual Private Cloud 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? Compruebe el despliegue de app y la configuración de recursos de Ingress. ¿Está viendo la página Tiempo de espera de conexión? Comprobar el estado de los pods del controlador de Ingress.

Paso 1: Comprobar el despliegue de apps y la configuración de recursos de Ingress

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.

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.

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. Para las anotaciones, tenga en cuenta que las anotaciones IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) y las anotaciones NGINX (nginx.ingress.kubernetes.io/<annotation>) no son compatibles con el controlador Ingress o el recurso Ingress en Red Hat OpenShift versión 4. Si desea personalizar las reglas de direccionamiento para apps en un clúster que ejecuta Red Hat OpenShift versión 4, puede utilizar anotaciones HAProxy específicas de la ruta, 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:
    custom-port:        protocol=http port=7490; protocol=https port=4431
    location-modifier:  modifier='~' serviceName=myservice1;modifier='^~' serviceName=myservice2
Events:
    Type     Reason             Age   From                                Message
    ----     ------             ----  ----                                -------
    Warning  TLSSecretNotFound  1m    router-default-69d6f598f8-vn8tj     Failed to apply ingress resource.
    Warning  AnnotationError    2s    router-default-69d6f598f8-vn8tj     Failed to apply ingress.bluemix.net/custom-port annotation.
    Warning  TLSSecretNotFound  1m    router-dal10-y2d4359tf4-g4ar7       Failed to apply ingress resource.
    Warning  AnnotationError    2s    router-dal10-y2d4359tf4-g4ar7       Failed to apply ingress.bluemix.net/custom-port annotation.

Compruebe el archivo de configuración de recursos de Ingress.
```
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>
```
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 la salud 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.

Compruebe el estado de los pods de operador de Ingress.
1. Obtenga los pods del operador de Ingress que se ejecutan en el clúster.
```
oc get pods -n openshift-ingress-operator
```
2. Asegúrese de que todos los pods están en ejecución seleccionando la columna ESTADO.
3. Si un pod no tiene el estado Running, puede suprimir el pod para reiniciarlo.
```
oc delete pod <pod> -n openshift-ingress-operator
```
4. Obtenga los registros para el operador de Ingress y busque mensajes de error en los registros.
```
oc logs deployments/ingress-operator -n openshift-ingress-operator -c ingress-operator
```
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.
```
oc delete pod <pod> -n openshift-ingress
```
4. Obtenga los registros para cada pod y busque mensajes de error en los registros.
```
oc logs <pod> -n openshift-ingress
```
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:
```
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.
```
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?.

Paso 3: Hacer ping al subdominio de entrada y a la dirección IP pública del controlador de entrada

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.

Verifique que los servicios de controlador de Ingress sean accesibles para la comprobación de estado del controlador de Ingress.
- Clásico: si utiliza las políticas de red anteriores a DNAT de Calico u otro cortafuegos personalizado para bloquear el tráfico entrante en el clúster, debe permitir el acceso de entrada en el puerto 80 o 443 desde las direcciones IP de IPv4 de Akamai y el panel de control de Red Hat OpenShift a las direcciones IP de los servicios del controlador de Ingress, para que el panel de control de Red Hat OpenShift pueda comprobar el estado de los controladores de Ingress. Por ejemplo, si utiliza políticas Calico, cree una política Calico pre-DNAT para permitir el acceso entrante a sus controladores Ingress desde las direcciones IP de origen de Akamai que se utilizan para comprobar el estado de sus controladores Ingress en el puerto 80 y las subredes del plano de control para la región donde se encuentra su clúster. Continúe en el paso siguiente para obtener las direcciones IP de servicio del controlador de Ingress.
- VPC: Si tiene un grupo de seguridad personalizado en las instancias VPC LBaaS ( LoadBalancer-as-a-Service ) para la entrada del clúster, asegúrese de que las reglas del grupo de seguridad permiten el tráfico de comprobación de estado necesario desde las direcciones IP del plano de control Kubernetes al puerto 443.
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?.
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.

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

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
```
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
```
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.
```
host www.my-domain.com
```
  Salida de ejemplo
```
www.my-domain.com has address 169.XX.XX.XXX
www.my-domain.com has address 169.XX.XX.XXX
```