Débogage d'Ingress

Cloud privé virtuel Infrastructure classique

Vous avez exposé votre application en créant une ressource Ingress pour votre application dans votre cluster. Cependant, lorsque vous tentez de vous connecter à votre application via le sous-domaine Ingress ou l'adresse IP publique de l'équilibreur de charge d'application, la connexion échoue ou arrive à expiration.

Les étapes des sections suivantes vous aident à déboguer votre configuration Ingress.

Avant de commencer, vérifiez que vous disposez des règles d'accès IBM Cloud IAM pour IBM Cloud Kubernetes Service : -Rôle d'accès à la plateforme Éditeur ou Administrateur pour le cluster - Rôle d'accès au service Writer ou Manager

Etape 1 : Vérification de votre déploiement d'application

Avant de procéder au débogage d'Ingress, consultez d'abord la rubrique Débogage des déploiements d'application.

Les problèmes Ingress sont souvent provoqués par des problèmes sous-jacents dans votre déploiement d'application ou dans le service ClusterIP qui expose votre application. Par exemple, votre libellé d'application et votre sélecteur de service risquent de ne pas correspondre, ou vos ports cible d'application et de service risquent de ne pas correspondre.

Etape 2 : Recherche de messages d'erreur dans le déploiement de votre ressource Ingress et dans les journaux de pod de l'équilibreur de charge d'application (ALB)

Commencez par vérifier les messages d'erreur dans les événements de déploiement de la ressource Ingress et les journaux de pod d'équilibreur de charge d'application. Ces messages d'erreur peuvent vous aider à identifier les causes profondes des défaillances et à poursuivre le débogage de votre configuration Ingress dans les sections suivantes.

Vérifiez le déploiement de votre ressource Ingress et recherchez les messages d'avertissement et d'erreur.

kubectl describe ingress <myingress>

Dans la section Events de la sortie, vous pourrez voir des messages d'avertissement signalant des valeurs non valides dans votre ressource Ingress ou dans certaines annotations que vous avez utilisées. Pour les ALB basés sur Ingress ( NGINX ), consultez la documentation relative à la configuration des ressources Ingress ou celle concernant les annotations. Pour les ALB basés sur Traefik, consultez la documentation relative à la configuration de la ressource Ingress ou celle relative à la configuration du contrôleur 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

Vérifiez le statut de vos pods d'équilibreur de charge d'application.

Obtenez les pods d'équilibreur de charge d'application qui s'exécutent dans votre cluster.

    kubectl get pods -n kube-system | grep alb
    ```
2. Vérifiez que tous les pods sont opérationnels en examinant la colonne **STATUS**.

3. Si un pod n'est pas en cours d'exécution (statut `Running`), vous pouvez désactiver puis réactiver l'équilibreur de charge d'application. Dans les commandes suivantes, remplacez `<ALB_ID>` par l'ID de l'ALB du pod. Par exemple, si le pod qui n'est pas en cours d'exécution est nommé `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`, l'ID de l'équilibreur de charge d'application est `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`.
    * Clusters classiques :
        ```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>
        ```
    * Clusters 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>
        ```

Vérifiez les journaux de votre équilibreur de charge d'application.

Obtenez les ID des pods d'équilibreur de charge d'application en cours d'exécution dans votre cluster.

    kubectl get pods -n kube-system | grep alb
    ```
1. Pour les ALB basés sur Ingress ( NGINX ), récupérez les journaux du conteneur « `nginx-ingress` » sur chaque pod de l'ALB. Pour les ALB basés sur Traefik, récupérez les journaux du conteneur « `traefik` » sur chaque pod de l'ALB.
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. Recherchez les messages d'erreur dans les journaux de l'équilibreur de charge d'application.

Etape 3 : Exécution d'une commande ping sur le sous-domaine et les adresses IP publiques de l'ALB

Vérifiez la disponibilité du sous-domaine Ingress et des adresses IP publiques des équilibreurs de charge d'application. Veillez également à ce que le service « IBM » ( NS1 ) puisse accéder à vos ALB afin d'effectuer des contrôles d'intégrité.

Obtenez les adresses IP (classique) ou le nom d'hôte (VPC) sur lesquels vos ALB publics sont en mode écoute.

ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

Exemple de sortie d'un cluster multizone classique avec des noeuds worker dans les zones dal10 et 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 public n'a pas d'adresse IP (classique) ou de nom d'hôte (VPC), voir L'équilibreur de charge d'application Ingress ne se déploie pas dans une zone.

Vérifiez que le diagnostic d'intégrité des équilibreurs de charge d'application peut accéder à vos adresses IP d'équilibreur de charge d'application.
- Classique: si vous utilisez les politiques réseau pré-DNAT d’ Calico ou un autre pare-feu personnalisé pour bloquer le trafic entrant vers votre cluster, vous devez autoriser l’accès entrant sur les ports 80 ou 443 depuis le plan de contrôle Kubernetes et les adresses IP IBM, NS1 et IPv4 vers les adresses IP de vos ALB, afin que le plan de contrôle Kubernetes puisse vérifier l’état de santé de vos ALB. Par exemple, si vous utilisez des règles « Calico », créez une règle de pré-DNAT « Calico » afin d’autoriser l’accès entrant vers les adresses IP de votre ALB à partir des adresses IP sources IBM et NS1 sur le port 80, ainsi que des sous-réseaux du plan de contrôle de la région où se trouve votre cluster.
- VPC: Si vous disposez d'un groupe de sécurité personnalisé sur les instances de l' LBaaS VPC ( LoadBalancer-as-a-Service ) pour l'ingress du cluster, assurez-vous que les règles de ce groupe de sécurité autorisent le trafic nécessaire aux contrôles d'intégrité provenant des adresses IP du plan de contrôle Kubernetes vers le port 443.

Vérifiez l'intégrité des adresses IP (classique) ou du nom d'hôte (VPC) de votre ALB.

Envoyez une requête ping à l'adresse IP (classique) ou au nom d'hôte (VPC) de chaque ALB public afin de vous assurer que chaque ALB est en mesure de recevoir correctement les paquets. Si vous utilisez des ALB privés, vous pouvez exécuter une commande ping sur leurs adresses IP (classique) ou leur nom d'hôte (VPC) uniquement à partir du réseau privé.

    ping <ALB_IP>
    ```
    * Si l'interface de ligne de commande renvoie un dépassement de délai et que vous disposez d'un pare-feu personnalisé pour protéger vos noeuds worker, vérifiez que vous avez autorisé ICMP dans votre pare-feu.
    * Si vous ne disposez d'aucun pare-feu ou si votre pare-feu ne bloque pas les commandes ping et que ces commandes renvoient un dépassement de délai, [vérifiez le statut de vos pods d'équilibreur de charge d'application](#check_pods).

* Clusters multizone uniquement : vous pouvez utiliser le diagnostic d'intégrité MZLB pour déterminer le statut des adresses IP (classique) ou du nom d'hôte (VPC) de votre ALB. La commande curl HTTP suivante utilise l'hôte `albhealth`, qui est configuré par IBM Cloud Kubernetes Service de sorte à renvoyer le statut `healthy` ou `unhealthy` pour une adresse IP ALB.
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    Exemple de commande :
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    Exemple de sortie
    ```sh {: screen}
    healthy
    ```
     Si une ou plusieurs adresses IP renvoient `unhealthy`, [vérifiez le statut des pods d'équilibreur de charge d'application](#check_pods).

Obtenez le sous-domaine Ingress fourni par IBM.

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

Exemple de sortie

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

Vérifiez que les adresses IP (classique) ou le nom d'hôte (VPC) de chaque ALB public que vous avez obtenus à l'étape 1 de cette section sont enregistrés avec le sous-domaine Ingress fourni par IBM de votre cluster. Par exemple, dans un cluster multizone classique, l'adresse IP de l'équilibreur de charge d'application public dans chaque zone contenant vos noeuds worker doit être enregistrée sous le même sous-domaine.
```
kubectl get ingress -o wide
```
Exemple de sortie
```
NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h
```

Etape 4 : Vérification de vos mappages de domaine et de la configuration de la ressource Ingress

Si vous utilisez un domaine personnalisé, vérifiez que vous avez utilisé votre fournisseur DNS pour mapper le domaine personnalisé au sous-domaine fourni par IBM ou à l'adresse IP publique de l'équilibreur de charge d'application. Notez que l'utilisation de CNAME est privilégiée car IBM fournit des diagnostics d'intégrité automatiques sur le sous-domaine IBM et retire toutes les adresses IP défaillantes dans la réponse DNS.

CNAME de sous-domaine fourni par IBM : vérifiez que votre domaine personnalisé est mappé au sous-domaine fourni par IBM du cluster dans l'enregistrement CNAME (Canonical Name record).

    host www.my-domain.com
    ```
    Exemple de sortie
    ```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
    ```
* **Enregistrement A d'adresse IP publique** : vérifiez que votre domaine personnalisé est mappé à l'adresse IP publique portable de l'équilibreur de charge d'application dans l'enregistrement A. Les adresses IP doivent correspondre aux adresses IP d'équilibreur de charge d'application publiques que vous avez obtenues à l'étape 1 de la [section précédente](#ping).
```sh {: pre}
    host www.my-domain.com
    ```
    Exemple de sortie
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```

Vérifiez les fichiers de configuration de la ressource Ingress pour votre cluster.
```
kubectl get ingress -o yaml
```
1. Veillez à définir un hôte dans une seule ressource Ingress. Si un hôte est défini dans plusieurs ressources Ingress, l'équilibreur de charge d'application risque de ne pas acheminer le trafic correctement et vous pourrez obtenir des erreurs.
2. Vérifiez que le sous-domaine et le certificat TLS sont corrects. Pour trouver le sous-domaine Ingress et le certificat TLS IBM, exécutez ibmcloud ks cluster get --cluster <cluster_name_or_ID>.
3. Assurez-vous que votre application est en mode écoute sur le même chemin que celui qui est configuré dans la section path de votre ressource Ingress. Si votre application est configurée pour être en mode écoute à la racine, utilisez / comme chemin. Si le trafic entrant vers ce chemin doit être redirigé vers un autre chemin sur lequel votre application est à l'écoute, utilisez l'annotation « rewrite paths » pour Ingress : NGINX. Pour Traefik, utilisez le middleware « ReplacePath ».
4. Editez le fichier YAML de configuration de votre ressource selon les besoins. Lorsque vous fermez l'éditeur, vos modifications sont sauvegardées et automatiquement appliquées.
```
    kubectl edit ingress <myingressresource>
    ```
```

Suppression d'un ALB du DNS à des fins de débogage sur Classic

Si vous ne parvenez pas à accéder à votre application via une adresse IP d'équilibreur de charge d'application spécifique, vous pouvez retirer provisoirement l'équilibreur de charge d'application de l'environnement de production en désactivant son enregistrement DNS. Vous pouvez ensuite utiliser l'adresse IP de l'équilibreur de charge d'application pour exécuter des tests de débogage sur cet équilibreur de charge d'application.

Par exemple, admettons que vous disposez d'un cluster multizone dans 2 zones et que 2 équilibreurs de charge d'application publics aient les adresses IP 169.46.52.222 et 169.62.196.238. Bien que le diagnostic d'intégrité indique que l'équilibreur de charge d'application de la deuxième zone est sain (healthy), votre application n'est pas accessible directement en l'utilisant. Vous décidez de retirer l'adresse IP de cet équilibreur de charge d'application, 169.62.196.238, de l'environnement de production à des fins de débogage. L'adresse IP de la première zone, 169.46.52.222, est enregistrée avec votre domaine et continue à router le trafic pendant que vous déboguez l'équilibreur de charge d'application de la deuxième zone.

Utilisez la commande suivante pour supprimer l'adresse IP du nom de domaine. La commande de mise à jour remplace intégralement les adresses IP enregistrées; vous devez donc n'indiquer dans la commande que les adresses IP opérationnelles :
```
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222
```
Vérifiez que l'adresse IP de l'ALB a bien été supprimée de l'enregistrement DNS de votre domaine en consultant le serveur IBM NS1. Notez que la mise à jour de l'enregistrement DNS peut prendre quelques minutes.
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net
```
Exemple de sortie confirmant que seule l'adresse IP d'équilibreur de charge d'application saine, 169.46.52.222, reste dans l'enregistrement DNS et que l'adresse IP d'équilibreur de charge d'application qui n'est pas saine, 169.62.196.238, a été retirée :
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
```
Maintenant que l'adresse IP de l'équilibreur de charge d'application a été retirée de l'environnement de production, vous pouvez effectuer des tests de débogage sur votre application en l'utilisant. Pour tester la communication avec votre application via cette adresse IP, vous pouvez exécuter la commande cURL suivante, en remplaçant les valeurs indiquées en exemple par vos propres valeurs :
```
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 tout est configuré correctement, vous obtenez la réponse prévue de votre application.
- Si vous obtenez une erreur en réponse, une erreur a pu se produire dans votre application ou dans une configuration qui ne s'applique qu'à cet équilibreur de charge d'application spécifique. Vérifiez le code de votre application, vos fichiers de configuration des ressources Ingress ( Ingress- NGINX ) ou la documentation de configuration d'Ingress Controller pour Traefik, ainsi que toute autre configuration que vous avez appliquée exclusivement à cet ALB.

Une fois le débogage terminé, rétablissez l'enregistrement DNS de l'ALB à l'aide de la commande suivante :

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

Vérifiez que l'adresse IP de l'ALB a bien été rétablie dans l'enregistrement DNS de votre domaine en consultant le serveur IBM NS1. Notez que la mise à jour de l'enregistrement DNS peut prendre quelques minutes.

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

Exemple de sortie

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