Depuración de Ingress

Nube privada virtual Infraestructura clásica

Ha expuesto la app creando un recurso de Ingress para la app en el clúster. Sin embargo, cuando intenta conectar con la app a través del subdominio de Ingress o de las direcciones IP de los ALB, la conexión falla o se 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 **

Paso 1: Comprobar el despliegue de la app

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.

Paso 2: Comprobar si hay mensajes de error en los registros de despliegue de Ingress y de pod de ALB

En primer lugar, compruebe si hay mensajes de error en los registros de pod de ALB y los sucesos de despliegue de recursos de Ingress. Estos mensajes de error pueden ayudarte a identificar las causas fundamentales de los fallos y a seguir depurando tu configuración de Ingress en las secciones siguientes.

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

kubectl describe ingress <myingress>

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 los ALB basados en Ingress ( NGINX ), consulta la documentación sobre la configuración de recursos de Ingress o la documentación sobre anotaciones. Para los ALB basados en Traefik, consulta la documentación sobre la configuración de recursos de Ingress o la documentación sobre la configuración del controlador de Ingress.

NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  <default>
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:                                         <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync

Compruebe el estado de los pods de ALB.

Obtenga los pods de ALB que se ejecutan en el clúster.

    kubectl get pods -n kube-system | grep alb
    ```
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 En ejecución (`Running`), puede inhabilitar y volver a habilitar el ALB. En los mandatos siguientes, sustituya `<ALB_ID>` por el ID del ALB del pod. Por ejemplo, si el pod que no se está ejecutando tiene el nombre `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`, el ID de ALB es `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`.
    * Clústeres clásicos:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
    * Clústeres VPC:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>
        ```

Compruebe los registros para su ALB.

Obtenga los ID de los pods de ALB que se ejecutan en el clúster.

    kubectl get pods -n kube-system | grep alb
    ```
1. Para los ALB basados en Ingress ( NGINX ), obtén los registros del contenedor « `nginx-ingress` » en cada pod del ALB. En el caso de los ALB basados en Traefik, obtén los registros del contenedor « `traefik` » en cada pod del ALB.
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. Mire si hay mensajes de error en los registros del ALB.

Paso 3: Ejecutar ping sobre el subdominio del ALB y las direcciones IP públicas

Compruebe la disponibilidad del subdominio de Ingress y las direcciones IP públicas de los ALB. Además, asegúrate de que el servicio de gestión de aplicaciones ( IBM ) NS1 pueda acceder a tus ALB para realizar comprobaciones de estado.

Obtenga las direcciones IP (clásico) o el nombre de host (VPC) donde los ALB públicos están a la escucha.

ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

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

ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
private-cr24a9f2caf6554648836337d240064935-alb1   false     disabled   private   -               dal13   ingress:1.1.2_2507_iks   2294021       -
private-cr24a9f2caf6554648836337d240064935-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
public-cr24a9f2caf6554648836337d240064935-alb1    true      enabled    public    169.62.196.238  dal13   ingress:1.1.2_2507_iks   2294019       -
public-cr24a9f2caf6554648836337d240064935-alb2    true      enabled    public    169.46.52.222   dal10   ingress:1.1.2_2507_iks   2234945       -

Si un ALB público no tiene ninguna dirección IP (clásico) o nombre de host (VPC), consulte ALB de Ingress no se despliega en una zona.

Verifique que la comprobación de estado de ALB puede acceder a las direcciones IP de ALB.
- Clásico: Si utilizas políticas de red pre-DNAT de Calico u otro cortafuegos personalizado para bloquear el tráfico entrante a tu clúster, debes permitir el acceso entrante en los puertos 80 o 443 desde el plano de control Kubernetes y las direcciones IP IBM, NS1 y IPv4 hacia las direcciones IP de tus ALB, para que el plano de control Kubernetes pueda comprobar el estado de tus ALB. Por ejemplo, si utilizas políticas de « Calico », crea una política de pre-DNAT de « Calico » para permitir el acceso entrante a las direcciones IP de tu ALB desde las direcciones IP de origen de IBM y NS1 en el puerto 80, así como desde las subredes del plano de control de la región en la que se encuentra tu clúster.
- VPC: Si tienes un grupo de seguridad personalizado en la VPC LBaaS ( LoadBalancer-as-a-Service ) para las instancias de entrada del clúster, asegúrate 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.

Compruebe el estado de las IP (clásico) o del nombre de host (VPC) de los ALB.

Realiza una prueba de ping a la dirección IP (clásica) o al nombre de host (VPC) de cada ALB público para asegurarte de que cada ALB pueda recibir paquetes correctamente. Si está utilizando ALB privados, solo puede hacer ping a sus direcciones IP (clásico) o a su nombre de host (VPC) desde la red privada.

    ping <ALB_IP>
    ```
    * Si la CLI devuelve un tiempo de espera excedido y tiene un cortafuegos personalizado que protege los nodos trabajadores, asegúrese de permitir ICMP en el cortafuegos.
    * Si no tiene un cortafuegos o si el cortafuegos no bloquea los mandatos ping y estos siguen excediendo el tiempo de espera, [compruebe el estado de los pods de ALB](#check_pods).

* Solo clústeres multizona: puede utilizar la comprobación de estado de MZLB para determinar el estado de las IP (clásico) o del nombre de host (VPC) de los ALB. El siguiente mandato cURL de HTTP utiliza el host `albhealth`, que está configurado por IBM Cloud Kubernetes Service para devolver los valores de estado `healthy` o `unhealthy` para una IP de ALB.
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    Mandato de ejemplo:
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    Salida de ejemplo
    ```sh {: screen}
    healthy
    ```
    Si una o varias de las IP devuelven el valor `unhealthy`, [compruebe el estado de los pods de ALB](#check_pods).

Obtenga el subdominio de Ingress proporcionado por IBM.

ibmcloud ks 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 las IP (clásico) o el nombre de host (VPC) de cada ALB público que ha obtenido en el paso 1 de esta sección se registran con el subdominio de Ingress proporcionado por IBM del clúster. Por ejemplo, en un clúster clásico multizona, la IP de ALB pública de cada zona en la que tenga nodos trabajadores se debe registrar bajo el mismo subdominio.
```
kubectl get ingress -o wide
```
Salida de ejemplo
```
NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h
```

Paso 4: Comprobar las correlaciones de dominio y la configuración de recursos de Ingress

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 con la dirección IP pública de ALB. Tenga en cuenta que se prefiere el uso de un CNAME porque IBM proporciona comprobaciones de estado automáticas en el subdominio de IBM y elimina cualquier IP anómala de la respuesta de DNS.

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.46.52.222
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238
    ```
* **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 de ALB en el registro A. Las IP deben coincidir con las IP de ALB públicas que ha obtenido en el paso 1 de la [sección anterior](#ping).
```sh {: pre}
    host www.my-domain.com
    ```
    Salida de ejemplo
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```

Compruebe los archivos de configuración de recursos de Ingress para el clúster.
```
kubectl 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 ALB no puede reenviar el tráfico correctamente y puede que se produzcan 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 ks 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. Si la app se ha configurado para que escuche en la vía de acceso raíz, utilice / como vía de acceso. Si el tráfico entrante dirigido a esta ruta debe redirigirse a otra ruta en la que tu aplicación esté a la escucha, utiliza la anotación «rewrite paths» de Ingress: NGINX. Para Traefik, utiliza el middleware « ReplacePath ».
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.
```
    kubectl edit ingress <myingressresource>
    ```
```

Eliminación de un ALB del DNS para la depuración en Classic

Si no puede acceder a la app a través de una IP de ALB específica, puede eliminar temporalmente el ALB de la producción inhabilitando su registro de DNS. A continuación, puede utilizar la dirección IP de ALB para ejecutar pruebas de depuración en ese ALB.

Por ejemplo, supongamos que tiene un clúster multizona en 2 zonas y los 2 ALB públicos tienen las direcciones IP 169.46.52.222 y 169.62.196.238. A pesar de que la comprobación de estado devuelve el valor healthy para el ALB de la segunda zona, no se puede acceder directamente a la app a través de él. Decide eliminar esa dirección IP de ALB, 169.62.196.238, de la producción para depurarla. La IP de ALB de la primera zona, 169.46.52.222, se registra con el dominio y sigue direccionando tráfico mientras se depura el ALB de la segunda zona.

Utiliza el siguiente comando para eliminar la dirección IP del nombre de dominio. El comando de actualización sustituye por completo las direcciones IP registradas, por lo que solo debes definir las direcciones IP que funcionan correctamente en el comando :
```
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222
```
Comprueba que la dirección IP del ALB se haya eliminado del registro DNS de tu dominio consultando el servidor IBM NS1. Tenga en cuenta que el registro de DNS puede tardar unos minutos en actualizarse.
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net
```
Salida de ejemplo que confirma que solo la IP de ALB en buen estado, 169.46.52.222, permanece en el registro de DNS y que la IP de ALB en mal estado, 169.62.196.238, se ha eliminado:
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
```
Ahora que la dirección IP de ALB se ha eliminado de la producción, puede ejecutar pruebas de depuración en la app a través de ella. Para probar la comunicación a la app a través de esta IP, puede ejecutar el siguiente mandato cURL sustituyendo los valores de ejemplo por sus propios valores:
```
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/
```
- Si todo está configurado correctamente, obtendrá la respuesta esperada de la app.
- Si obtiene un error en la respuesta, puede que haya un error en la app o en una configuración que se aplique únicamente a este ALB específico. Comprueba el código de tu aplicación, los archivos de configuración de recursos de Ingress (Ingress- NGINX ) o la documentación de configuración del Ingress Controller para Traefik, así como cualquier otra configuración que hayas aplicado exclusivamente a este ALB.

Una vez finalizada la depuración, restaura el registro DNS del ALB mediante el siguiente comando :

ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238

Comprueba que la dirección IP del ALB se haya restablecido en el registro DNS de tu dominio consultando el servidor IBM NS1. Tenga en cuenta que el registro de DNS puede tardar unos minutos en actualizarse.

host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net

Salida de ejemplo

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238