Warum können meine Pods nach dem Löschen aller Workerknoten auf neuen Workerknoten nicht gestartet werden?

Beheben Sie Fehler beim Löschen von Worker-Knoten und festgefrorene Pods.

Virtuelle Private Cloud Klassische Infrastruktur

Sie haben alle Workerknoten in Ihrem Cluster gelöscht, sodass keine Workerknoten mehr vorhanden sind. Anschließend haben Sie Workerknoten hinzugefügt. Wenn Sie den folgenden Befehl ausführen, weisen mehrere Pods für Kubernetes-Komponenten über einen längeren Zeitraum den Status ContainerCreating und die calico-node-Pods den Status CrashLoopBackOff auf.

oc -n calico-system get pods

Wenn Sie alle Workerknoten in Ihrem Cluster löschen, ist kein Workerknoten für die Ausführung des Calico-Controller-Pods (calico-kube-controllers) verfügbar. Die Daten des Calico-Controllerpods können nicht aktualisiert werden, um die Daten der gelöschten Workerknoten zu entfernen. Wenn der Calico-Controller-Pod auf den neuen Workerknoten erneut ausgeführt wird, werden die zugehörigen Daten nicht in Bezug auf die neuen Workerknoten aktualisiert und der Pod startet die calico-node-Pods nicht.

Löschen Sie die vorhandenen Workerknoteneinträge für calico-node, sodass neue Pods erstellt werden können.

Vorbereitende Schritte: Installieren Sie die Calico-CLI.

  1. Führen Sie den Befehl ibmcloud oc cluster config aus, kopieren Sie die Ausgabe und fügen Sie sie ein, um die Umgebungsvariable KUBECONFIG festzulegen. Fügen Sie die Optionen --admin und --network im Befehl ibmcloud oc cluster config hinzu. Durch die Option --admin werden die Schlüssel für den Zugriff auf Ihr Infrastrukturportfolio und zum Ausführen von Calico-Befehlen in Ihren Workerknoten heruntergeladen. Durch die Option --network wird die Calico-Konfigurationsdatei für die Ausführung aller Calico-Befehle heruntergeladen.

    ibmcloud oc cluster config --cluster CLUSTER_NAME_OR_ID --admin --network
    
  2. Notieren Sie sich für die calico-node-Pods, die bereits über einen längeren Zeitraum den Status CrashLoopBackOff aufweisen, die IP-Adressen unter NODE.

    oc -n calico-system get pods -o wide
    

    In dieser Beispielausgabe kann der calico-node-Pod nicht auf dem Workerknoten gestartet werden 10.176.48.106.

    NAME                                           READY   STATUS              RESTARTS   AGE     IP              NODE            NOMINATED NODE   READINESS GATES
    ...
    calico-kube-controllers-656c5785dd-kc9x2       1/1     Running             0          25h     10.176.48.107   10.176.48.107   <none>           <none>
    calico-node-mkqbx                              0/1     CrashLoopBackOff    1851       25h     10.176.48.106   10.176.48.106   <none>           <none>
    coredns-7b56dd58f7-7gtzr                       0/1     ContainerCreating   0          25h     172.30.99.82    10.176.48.106   <none>           <none>
    
  3. Rufen Sie die IDs der Workerknoteneinträge für calico-node ab. Kopieren Sie nur die IDs für die IP-Adressen der Workerknoten, die Sie im vorherigen Schritt abgerufen haben.

    calicoctl get nodes -o wide
    
  4. Löschen Sie die Workerknoteneinträge mithilfe der IDs. Nach dem Löschen der Workerknoteneinträge sorgt der Calico-Controller dafür, dass die calico-node-Pods auf die neuen Workerknoten umgestellt werden.

    calicoctl delete node <node_ID>
    
  5. Stellen Sie sicher, dass die Pods für Kubernetes-Komponenten einschließlich der calico-node-Pods jetzt betriebsbereit sind. Es kann einige Minuten dauern, bis die calico-node-Pods umgestellt und neue Komponentenpods erstellt werden.

    oc -n calico-system get pods
    

Sie können diesen Fehler in Zukunft verhindern, indem Sie niemals sämtliche Workerknoten in Ihrem Cluster löschen. Es sollte stets mindestens ein Workerknoten in Ihrem Cluster aktiv sein (bzw. zwei Workerknoten je Zone, wenn Sie Ingress oder Routen verwenden, um Apps bereitzustellen).