Wie kann ich Probleme mit dem etc/dadm-Controller in EKS Anywhere beheben?

Lesedauer: 4 Minute
0

Ich möchte die Protokolle in den etcdadm-Pods auf Hinweise zur Behebung von ETCD-Bootstrap-Fehlern überprüfen.

Kurze Beschreibung

Wenn bei Ihren Amazon Elastic Kubernetes Service (Amazon EKS) Anywhere-Knoten ein Bootstrap-Fehler auftritt, suchen Sie in den Protokollen nach etc/dadm-Pods. Überprüfen Sie auch die Protokolle für etcd-Pods, die Sie für einen gestapelten etcd-Cluster erstellt haben.

Melden Sie sich zum weiteren Debuggen bei einer der virtuellen Maschinen (VMs) von etcd an. Wenn Sie vor dem Bootstrap-Fehler keine etcd-VM erstellt haben, können Sie die VM nicht zum Debuggen verwenden.

Auflösung

Überprüfe die Logs in den etc/dadm-Pods

**Hinweis:**Ersetzen Sie in den folgenden Befehlen SUFFIX durch das Suffix Ihres Bootstrap-Anbieters. Ersetzen Sie KUBECONFIG\ _FILE durch den Speicherort Ihrer kubeconfig-Datei.

Nachdem Sie Erstellen Ihren Cluster haben, können Sie ihn mit der generierten KUBECONFIG-Datei in Ihrem lokalen Verzeichnis verwenden:

KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

Führen Sie den folgenden Befehl aus, um in den Protokollen nach etcdadm-bootstrap-provider-controller zu suchen:

kubectl -n etcdadm-bootstrap-provider-system logs etcdadm-bootstrap-provider-controller-SUFFIX  
    --kubeconfig=KUBECONFIG_FILE

Führen Sie den folgenden Befehl aus, um in den Protokollen nach etcdadm-controller-controller-manager zu suchen:

kubectl -n etcdadm-controller-system logs etcdadm-controller-controller-manager-SUFFIX --kubeconfig=KUBECONFIG_FILE

Suchen Sie in den Protokollen nach einem gestapelten etcd

Wenn Sie Pods für einen gestapelten etcd-Cluster erstellt haben, führen Sie den folgenden Befehl aus, um die Protokolle dieser Pods zu überprüfen:

kubectl logs -n kube-system etcd-$CONTROL_PLANE_VM_IP --kubeconfig=KUBECONFIG_FILE

**Hinweis:**Ersetzen Sie KUBECONFIG\ _FILE durch den Speicherort Ihrer kubeconfig-Datei.

Überprüfen Sie die VM-Protokolle

Nachdem Sie den kubectl-Client verwendet haben, um nach Protokollen zu suchen, können Sie auch auf den VMs nach Protokollen suchen:

1.Melden Sie sich in der Steuerungsebene der VM an:

ssh -i $PRIV_KEY ec2-user@$CONTROL_PLANE_VM_IP

**Hinweis:**Ersetzen Sie PRIV_KEY durch Ihren privaten Schlüssel. Ersetzen Sie CONTROL_PLANE\ _VM\ _IP durch die IP-Adresse der VM Ihrer Steuerungsebene.

2.Für ein BottleRocket-Betriebssystem (OS): Um die Root-Shell für einen Knoten abzurufen, der auf BottleRocket OS läuft, führen Sie den Befehlsudo sheltie aus.

3.Nachdem Sie sich bei einer etcd-VM angemeldet haben, können Sie weitere zugehörige Container-Logs an der folgenden Stelle überprüfen:

cd /var/log/containers

Suchen Sie in den Protokollen nach einem entstapelten oder externen etcd

Melden Sie sich für ein entstapeltes oder externes etcd bei jeder etcd-VM an, die Sie erstellt haben.

1.Führen Sie den folgenden Befehl aus, um sich bei Ihrer etcd-VM anzumelden:

ssh -i $PRIV_KEY ec2-user@$ETCD_VM_IP

**Hinweis:**Ersetzen Sie PRIV_KEY durch Ihren privaten Schlüssel. Ersetzen Sie ETCD_VM\ _IP durch die IP-Adresse Ihrer VM.

2.Für ein BottleRocket-Betriebssystem (OS): Um die Root-Shell für einen Knoten abzurufen, der auf BottleRocket OS läuft, führen Sie den Befehlsudo sheltie aus.

3.Nachdem Sie sich bei einer etcd-VM angemeldet haben, können Sie weitere zugehörige Container-Logs an der folgenden Stelle überprüfen:

cd /var/log/containers  
bash-5.1# ls -lrt  
total 4  
lrwxrwxrwx. 1 root root 90 Apr 11 16:38 etcd-mgmt-etcd-4mt4g_kube-system_etcd-aa91be45434b920903e0630254cb5f319b86b50c56b87d8f992b0285272b93c4.log -> /var/log/pods/kube-system_etcd-mgmt-etcd-4mt4g_88b6dbc1be367b4ffc5a6bfab65e7376/etcd/0.log

Führen Sie einen Gesundheitscheck durch

ETCD_CONTAINER_ID=$(ctr -n k8s.io c ls | grep -w "etcd-io" | cut -d " " -f1)  
ctr -n k8s.io t exec -t --exec-id etcd ${ETCD_CONTAINER_ID} etcdctl \  
     --cacert=/var/lib/etcd/pki/ca.crt \  
     --cert=/var/lib/etcd/pki/server.crt \  
     --key=/var/lib/etcd/pki/server.key \  
     endpoint health  

127.0.0.1:2379 is healthy: successfully committed proposal: took = 10.241212ms

Beispiele für Fehlermeldungen

Wenn Sie Ihre Protokolle überprüfen, werden möglicherweise verschiedene Fehlermeldungen angezeigt, die sich auf Ihren Bootstrap-Fehler beziehen. Die folgenden Beispiele sind einige der häufigsten Fehler:

„Ich warte darauf, dass External ETCD bereit ist.“

Informationen zur Behebung dieses Fehlers finden Sie in der Dokumentation zur Fehlerbehebung für Amazon EKS Anywhere.

Kubelet von ETCD-VMs stürzt ab.“

Die Cluster-Bereitstellung wird nach der Erstellung Ihrer ETCD-VM nicht fortgesetzt. Dieses Problem tritt auch bei der folgenden Kubelet-Fehlermeldung auf:

„ContainerManager konnte nicht gestartet werden“ err="Ungültige Node Allocatable-Konfiguration. Die Ressource \„ephemeral-storage\“ hat eine Zuweisungskapazität von {{1175812097 0} {<nil>} BinarySI}, Kapazität von {{-155109377 0} {<nil>} BinarySI}“

Dies weist darauf hin, dass der kurzlebige Speicher auf dem Knoten nicht über ausreichend freien Speicherplatz verfügt. In jedem Kubernetes-Knoten befinden sich das Stammverzeichnis (standardmäßig /var/lib/kubelet) und das Protokollverzeichnis (/var/log) von Kubelet auf der Root-Partition des Knotens.

Führen Sie den folgenden Befehl aus, um den freien Speicherplatz eines bestimmten Dateisystems anzuzeigen:

"df -h"

Führen Sie den folgenden Befehl aus, um eine Liste aller Dateien und ihrer jeweiligen Größen anzuzeigen:

"sudo du -d 3 /var/lib/"

Wenn Sie nicht über genügend freien Speicherplatz verfügen, bereinigen Sie Ihren Knoten, um Speicherplatz freizugeben. Oder erweitern Sie die Speicherkapazität der Root-Partition Ihres Knotens.

Verwandte Informationen

Installieren Sie etcd (etcd-Website)

So überprüfen Sie den Clusterstatus (etcd-Website)

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr