Debugging für Ingress

Virtual Private Cloud Classic-Infrastruktur

Sie haben Ihre App zugänglich gemacht, indem Sie eine Ingress-Ressource für Ihre App in Ihrem Cluster erstellt haben. Wenn Sie jedoch versuchen, über die Ingress-Unterdomäne oder die IP-Adressen der ALB eine Verbindung zu Ihrer App herzustellen, schlägt die Verbindung fehl oder scheitert an einer Zeitlimitüberschreitung.

Die Schritte in den folgenden Abschnitten können Ihnen beim Debugging Ihrer Ingress-Konfiguration helfen.

Stellen Sie zunächst sicher, dass Sie über die folgenden IBM Cloud IAM-Zugriffsrichtlinien für IBM Cloud Kubernetes Service verfügen: - Editor- oder Administrator-Plattformzugriffsrolle für den Cluster - Writer- oder Manager-Servicezugriffsrolle

Schritt 1: App-Bereitstellung überprüfen

Bevor Sie den Ingress debuggen können, machen Sie sich mit den Informationen im Abschnitt App-Bereitstellungen debuggen vertraut.

Ingress-Probleme sind häufig auf Probleme in Ihrer App-Bereitstellung oder in dem ClusterIP-Service zurückzuführen, über den Ihre App zugänglich gemacht wird. Es kann z. B. sein, dass Ihre App-Bezeichnung und der Serviceselektor nicht übereinstimmen oder für App und Service unterschiedliche Zielports verwendet werden.

Schritt 2: Ingress-Bereitstellung und Pod-Protokolle der Lastausgleichsfunktion für Anwendungen (ALB) auf Fehlernachrichten überprüfen

Beginnen Sie, indem Sie in den Ereignissen der Ingress-Ressourcenbereitstellung und in den ALB-Pod-Protokollen nach Fehlernachrichten suchen. Diese Fehlermeldungen können Ihnen dabei helfen, die Ursachen für Fehler zu ermitteln und Ihre Ingress-Konfiguration in den folgenden Abschnitten weiter zu optimieren.

  1. Überprüfen Sie Ihre Ingress-Ressourcenbereitstellung und suchen Sie nach Warnungen und Fehlernachrichten.

    kubectl describe ingress <myingress>

    Im Abschnitt Events der Ausgabe sehen Sie möglicherweise Nachrichten zu ungültigen Werten in Ihrer Ingress-Ressource oder in bestimmten Annotationen, die Sie verwendet haben. Für ALBs auf Basis von Ingress- NGINX s lesen Sie bitte die Dokumentation zur Konfiguration von Ingress-Ressourcen oder die Dokumentation zu Annotationen. Für auf Traefik basierende ALBs lesen Sie bitte die Dokumentation zur Konfiguration der Ingress-Ressource oder die Dokumentation zur Konfiguration des Ingress-Controllers.

    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

  2. Überprüfen Sie den Status Ihrer ALB-Pods.

    1. Rufen Sie die ALB-Pods ab, die in Ihrem Cluster ausgeführt werden.
        kubectl get pods -n kube-system | grep alb
    ```
2. Stellen Sie sicher, dass alle Pods ausgeführt werden, und überprüfen Sie dazu die Spalte **STATUS**.

3. Wenn ein Pod nicht den Status `Running` aufweist und demzufolge nicht aktiv ist, können Sie die ALB inaktivieren und erneut aktivieren. Ersetzen Sie in den folgenden Befehlen `<ALB_ID>` durch die ID der ALB des Pods. Beispiel: Wenn der Pod, der nicht aktiv ist, den Namen `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z` trägt, lautet die ALB-ID `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`.
    * Klassische Cluster:
        ```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>
        ```
    * VPC-Cluster:
        ```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>
        ```

  3. Überprüfen Sie die Protokolle für Ihre Lastausgleichsfunktion für Anwendungen.

    1. Rufen Sie die IDs der ALB-Pods ab, die in Ihrem Cluster ausgeführt werden.
        kubectl get pods -n kube-system | grep alb
    ```
1. Bei Ingress- und NGINX-basierten ALBs rufen Sie die Protokolle für den Container „ `nginx-ingress` “ in jedem ALB-Pod ab. Bei Traefik-basierten ALBs rufen Sie die Protokolle für den Container „ `traefik` “ in jedem ALB-Pod ab.
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. Suchen Sie nach Fehlernachrichten in den Protokollen der Lastausgleichsfunktion für Anwendungen.

Schritt 3: ALB-Unterdomäne und öffentliche IP-Adressen mit Ping überprüfen

Überprüfen Sie die Verfügbarkeit Ihrer Ingress-Unterdomäne und der öffentlichen IP-Adressen der ALBs. Stellen Sie außerdem sicher, dass der „ IBM “ ( NS1 ) auf Ihre ALBs zugreifen kann, um deren Funktionsfähigkeit zu überprüfen.

  1. Rufen Sie die IP-Adressen (klassische Cluster) oder den Hostnamen (VPC-Cluster) ab, an denen Ihre öffentlichen ALBs empfangsbereit sind.

    ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

    Beispielausgabe für einen klassischen Mehrzonencluster mit Workerknoten in dal10 und 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       -

  2. Überprüfen Sie, ob Ihre ALB-IP-Adressen von der ALB-Statusprüfung erreicht werden.

    • Klassisch: Wenn Sie Netzwerkrichtlinien von „ Calico “ vor der DNAT oder eine andere benutzerdefinierte Firewall verwenden, um eingehenden Datenverkehr zu Ihrem Cluster zu blockieren, müssen Sie den eingehenden Zugriff auf Port 80 oder 443 von den IP-Adressen der Steuerungsebene Kubernetes sowie von den IP-Adressen IBM, NS1 und IPv4 zu den IP-Adressen Ihrer ALBs zulassen, damit die Steuerungsebene Kubernetes den Betriebszustand Ihrer ALBs überprüfen kann. Wenn Sie beispielsweise „ Calico “-Richtlinien verwenden, erstellen Sie eine „ Calico “-Pre-DNAT-Richtlinie, um eingehenden Zugriff auf Ihre ALB-IP-Adressen von den Quell-IP-Adressen IBM und NS1 auf Port 80 sowie von den Subnetzen der Steuerungsebene für die Region, in der sich Ihr Cluster befindet, zuzulassen.

    • VPC: Wenn Sie in der VPC LBaaS (LoadBalancer-as-a-Service) eine benutzerdefinierte Sicherheitsgruppe für den Cluster-Ingress eingerichtet haben, stellen Sie sicher, dass die Regeln dieser Sicherheitsgruppe den erforderlichen Datenverkehr für den Health-Check von Kubernetes IP-Adressen der Steuerungsebene zu Port 443 zulassen.

  3. Überprüfen Sie den Allgemeinzustand Ihrer ALB-IPs (klassische Cluster) oder Ihres Hostnamens (VPC-Cluster).

    • Führen Sie einen Ping an die IP-Adresse (klassisch) oder den Hostnamen (VPC) jedes öffentlichen ALB durch, um sicherzustellen, dass jedes ALB Pakete erfolgreich empfangen kann. Wenn Sie private ALBs verwenden, können Sie deren IP-Adressen (klassische Cluster) oder Hostnamen (VPC-Cluster) nur über das private Netz mit Ping überprüfen.
        ping <ALB_IP>
    ```
    * Wenn die Befehlszeilenschnittstelle (CLI) eine Zeitlimitüberschreitung zurückgibt und Sie über eine angepasste Firewall zum Schutz Ihrer Workerknoten verfügen, müssen Sie sicherstellen, dass Ihre Firewall ICMP zulässt.
    * Wenn keine Firewall vorhanden ist oder zumindest keine Firewall, die die Pingsignale blockiert, und die Pingsignale weiterhin das Zeitlimit überschreiten, müssen Sie den [Status der ALB-Pods überprüfen](#check_pods).

* Nur bei Mehrzonenclustern: Sie können die MZLB-Zustandsprüfung verwenden, um den Status Ihrer ALB-IPs (klassische Cluster) oder Hostnamen (VPC-Cluster) zu ermitteln. Der folgende HTTP-cURL-Befehl verwendet den Host `albhealth`, der von IBM Cloud Kubernetes Service so konfiguriert wird, dass er entweder den Status `healthy` oder den Status `unhealthy` für eine ALB-IP zurückgibt.
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    Beispielbefehl:
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    Beispielausgabe
    ```sh {: screen}
    healthy
    ```
    Wenn ein oder mehrere IPs `unhealthy` zurückgeben, müssen Sie [den Status der ALB-Pods überprüfen](#check_pods).

  4. Rufen Sie die von IBM bereitgestellte Ingress-Unterdomäne ab.

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

    Beispielausgabe

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

  5. Stellen Sie sicher, dass die IPs (klassische Cluster) oder der Hostname (VPC-Cluster) für jede öffentliche ALB, die Sie in Schritt 1 dieses Abschnitts abgerufen haben, bei der von IBM bereitgestellten Ingress-Unterdomäne Ihres Clusters registriert sind. In einem klassischen Mehrzonencluster muss beispielsweise die öffentliche ALB-IP in jeder Zone, in der Sie Workerknoten haben, unter derselben Unterdomäne registriert sein.

    kubectl get ingress -o wide

    Beispielausgabe

    NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h

Schritt 4: Domänenzuordnungen und Ingress-Ressourcenkonfiguration überprüfen

  1. Wenn Sie eine angepasste Domäne verwenden, stellen Sie sicher, dass Sie Ihren DNS-Provider verwendet haben, um die von IBM bereitgestellte Unterdomäne oder die öffentliche IP-Adresse der ALB zuzuordnen. Dabei ist zu beachten, dass die Verwendung eines CNAME bevorzugt wird, weil IBM automatische Zustandsprüfungen für die IBM Unterdomäne ermöglicht und alle fehlgeschlagenen IPs aus der DNS-Antwort entfernt.
    • Von IBM bereitgestellte Unterdomäne - CNAME: Überprüfen Sie, ob Ihre angepasste Domäne der von IBM bereitgestellten Unterdomäne des Clusters im CNAME-Datensatz (kanonischer Name) zugeordnet ist.
        host www.my-domain.com
    ```
    Beispielausgabe
    ```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
    ```
* **Öffentliche IP-Adresse - A-Datensatz**: Prüfen Sie, ob Ihre angepasste Domäne der portierbaren öffentlichen IP-Adresse der ALB im A-Datensatz zugeordnet ist. Die IPs müssen mit den öffentlichen ALB-IPs übereinstimmen, die Sie in Schritt 1 des [vorherigen Abschnitts](#ping) erhalten haben.
```sh {: pre}
    host www.my-domain.com
    ```
    Beispielausgabe
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```
  2. Überprüfen Sie die Ingress-Ressourcenkonfigurationsdateien für Ihren Cluster.
    kubectl get ingress -o yaml

    1. Stellen Sie sicher, dass Sie einen Host in nur einer Ingress-Ressource definieren. Wenn ein Host in mehreren Ingress-Ressourcen definiert ist, leitet die Lastausgleichsfunktion für Anwendungen den Datenverkehr möglicherweise nicht ordnungsgemäß weiter und es können Fehler auftreten.

    2. Prüfen Sie, ob die Unterdomäne und das TLS-Zertifikat korrekt sind. Um die von IBM bereitgestellte Ingress-Unterdomäne und das TLS-Zertifikat zu suchen, führen Sie ibmcloud ks cluster get --cluster <cluster_name_or_ID> aus.

    3. Stellen Sie sicher, dass Ihre App denselben Pfad überwacht, der im Abschnitt path von Ingress konfiguriert ist. Wenn Ihre App so eingerichtet ist, dass sie den Rootpfad überwacht, verwenden Sie / als Pfad. Wenn der eingehende Datenverkehr für diesen Pfad auf einen anderen Pfad umgeleitet werden soll, auf dem Ihre App lauscht, verwenden Sie die Annotation „rewrite paths“ für Ingress – NGINX. Verwenden Sie für Traefik die Middleware „ ReplacePath “.

    4. Bearbeiten Sie die YAML-Datei für die Ressourcenkonfiguration nach Bedarf. Wenn Sie den Editor schließen, werden Ihre Änderungen gespeichert und automatisch angewendet.

        kubectl edit ingress <myingressresource>
    ```

Entfernen einer ALB aus dem DNS zur Fehlerbehebung in Classic

Wenn Sie nicht über eine bestimmte ALB-IP auf Ihre App zugreifen können, können Sie die ALB vorübergehend aus der Produktion nehmen, indem Sie ihre DNS-Registrierung inaktivieren. Anschließend können Sie die IP-Adresse der ALB verwenden, um Debugging-Tests für diese ALB auszuführen.

Beispiel: Angenommen, Sie haben einen Mehrzonencluster in zwei Zonen und die beiden öffentlichen ALBs haben die IP-Adressen 169.46.52.222 und 169.62.196.238. Obwohl die Zustandsprüfung für den ALB der zweiten Zone einen einwandfreien Zustand (healthy) meldet, ist Ihre App nicht direkt über die App erreichbar. Sie entscheiden, die IP-Adresse der ALB 169.62.196.238 zu Debugging-Zwecken aus der Produktion zu nehmen. Die ALB-IP der ersten Zone (169.46.52.222) wird bei Ihrer Domäne registriert und leitet den Datenverkehr weiter, während Sie das Debugging für die ALB der zweiten Zone durchführen.

  1. Verwenden Sie den folgenden Befehl, um die IP-Adresse aus dem Domainnamen zu entfernen. Der Befehl „update“ ersetzt die registrierten IP-Adressen vollständig, daher müssen Sie im Befehl nur die funktionierenden IP-Adressen angeben:

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

  2. Stellen Sie sicher, dass die ALB-IP-Adresse aus dem DNS-Eintrag Ihrer Domain entfernt wurde, indem Sie den Server „ IBM “ unter NS1 überprüfen. Beachten Sie, dass die Aktualisierung der DNS-Registrierung einige Minuten in Anspruch nehmen kann.

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

    Beispielausgabe, die bestätigt, dass nur die einwandfreie ALB-IP 169.46.52.222 in der DNS-Registrierung verbleibt und dass die nicht einwandfreie ALB-IP 169.62.196.238 entfernt wurde:

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

  3. Da die ALB-IP nun aus der Produktion genommen wurde, können Sie sie zur Ausführung der Debugging-Tests für Ihre App verwenden. Um die Kommunikation mit Ihrer App über diese IP zu testen, können Sie den folgenden cURL-Befehl ausführen und dabei die Beispielwerte durch eigene Werte ersetzen:

    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/
    • Wenn alles ordnungsgemäß konfiguriert ist, erhalten Sie die erwartete Antwort von Ihrer App.
    • Wenn die Antwort einen Fehler enthält, liegt möglicherweise ein Fehler in Ihrer App oder in einer Konfiguration vor, die nur für diese spezielle ALB gültig ist. Überprüfen Sie Ihren App-Code, Ihre „ Konfigurationsdateien für Ingress-Ressourcen “ auf „ Ingress-NGINX “ oder „ Dokumentation zur Konfiguration des Ingress-Controllers “ auf „ Traefik “ sowie alle anderen Konfigurationen, die Sie ausschließlich für diesen ALB vorgenommen haben.

  4. Nachdem Sie die Fehlerbehebung abgeschlossen haben, stellen Sie die DNS-Eintragung des ALB mit dem folgenden Befehl wieder her:

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

  5. Vergewissern Sie sich, dass die ALB-IP-Adresse in der DNS-Eintragung Ihrer Domain wiederhergestellt wurde, indem Sie den Server „ IBM “ unter NS1 überprüfen. Beachten Sie, dass die Aktualisierung der DNS-Registrierung einige Minuten in Anspruch nehmen kann.

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

    Beispielausgabe

    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