Wie erstelle und behebe ich eine topologiebewusste Volume-Bereitstellung, die einen EBS-CSI-Treiber in Amazon EKS verwendet?

Kurze Beschreibung

Führen Sie die folgenden Schritte aus, um eine Cloud-Infrastrukturtopologie in Amazon EKS zu konfigurieren und Fehler zu beheben, die Amazon EBS-Komponenten verwendet:

1. Überprüfen Sie, ob das EBS CSI-Add-on korrekt konfiguriert ist.
2. Konfigurieren Sie die Speicherklasse mit einer topologiebewussten Implementierung.
3. Erstellen Sie einen Pod und eine Workload und testen Sie dann ein topologiebewusstes Szenario.
4. Beheben Sie EBS CSI-Controller-Fehler.

Lösung

**Hinweis:**Wenn Sie beim Ausführen von AWS CLI-Befehlen (AWS Command Line Interface) Fehler erhalten, stellen Sie sicher, dass Sie die neueste AWS CLI-Version verwenden.

Überprüfen, ob das EBS CSI-Add-on korrekt konfiguriert ist

**Hinweis:**Es hat sich bewährt, den EBS CSI-Provisioner ebs.csi.aws.com für die EBS-Volume-Bereitstellung zu verwenden. Verwenden Sie außerdem den EBS CSI-Provisioner, wenn Sie topologiebewusste Volumes implementieren, anstelle des In-Tree-Kubernetes-Provisioners kubernetes.io/aws-ebs.

Gehen Sie wie folgt vor, um zu überprüfen, ob das EBS CSI-Add-on korrekt konfiguriert ist:

1.Prüfen Sie, ob der CSI-Treiber installiert ist. Wenn er nicht installiert ist, lesen Sie den Abschnitt Amazon EBS CSI-Treiber, um den CSI-Treiber zu installieren.

2.Überprüfen Sie, ob die AWS IAM-Rolle (Identity and Access Management) für das Dienstkonto über die Mindestberechtigungen für EBS-Volume-Aktionen verfügt.

**Hinweis:**Sie müssen das Dienstkonto mit den IAM-Rollen für Dienstkonten (IRSA) versehen. Wenn Sie das Dienstkonto nicht mit IRSA versehen, übernimmt der Amazon EBS CSI-Treiber standardmäßig die IAM-Rolle auf dem Worker-Knoten. Wenn der CSI-Treiber standardmäßig die IAM-Rolle auf dem Worker-Knoten verwendet, konfigurieren Sie die erforderlichen IAM-Rollenberechtigungen in der AWS-Managementkonsole.

Konfigurieren der Speicherklasse mit einer topologiebewussten Implementierung

1.Führen Sie den folgenden Befehl aus, um die Speicherklasse bereitzustellen. Bearbeiten Sie das Manifest entsprechend Ihren spezifischen Bereitstellungsanforderungen.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

Beispiel für ein Manifest:

**Hinweis:**Ersetzen Sie die Attribute im Manifest durch solche, die für Ihren Anwendungsfall spezifisch sind.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

**Hinweis:**Stellen Sie für eine topologiebewusste Implementierung sicher, dass Sie die Option allowedTopologies konfigurieren. Wenn Sie diese Option löschen, wird die richtige Availability Zone abgeleitet und der Amazon EBS CSI-Controller erstellt ein Volume, auf dem der Pod geplant ist.

2.Verwenden Sie eine der folgenden Optionen, um einen PV-Claim zu erstellen:

(Option 1) Erstellen Sie einen PV-Claim, der ein Volume mit dem Profiltyp anfordert, der im Manifest der bereitgestellten Speicherklasse angegeben ist:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(Option 2) Erstellen Sie einen PV-Claim, der ein verfügbares EBS-Volume verwendet, das im Manifest des persistenten Volumes angegeben ist. Stellen Sie sicher, dass Sie die Option storageClassname: in eine leere Zeichenfolge**, "",** ändern und den nodeAffinity-Block nach Bedarf ändern.

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

**Hinweis:**Bei Option 1 oder Option 2 schlägt die Bereitstellung fehl, wenn in der Availability Zone des Volumes keine Knoten verfügbar sind. Dies liegt daran, dass sich der Scheduler nicht dynamisch an die Topologieeinschränkung anpassen kann.

Erstellen eines Pods und einer Workload und Testen eines topologiebewussten Szenarios

Einen Pod erstellen

1.Erstellen Sie einen Test-Pod, der den vorherigen PV-Claim verwendet:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

Hinweis: Wenn Sie topology.ebs.csi.aws.com/zone in allowedTopologies innerhalb einer Speicherklasse oder eines persistenten Volumes verwenden, wird der Pod in der Availability Zone platziert, die in den Konfigurationsmanifesten angegeben ist. Wenn in dieser Availability Zone kein Knoten verfügbar ist, bleibt der Pod im Status Ausstehend hängen.

2.Führen Sie die folgenden Befehle zum Abrufen und Beschreiben des Pods aus, um den Status der Bereitstellung zu überprüfen:

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

**Hinweis:**Ersetzen Sie EXAMPLE_POD_NAME durch den Namen Ihres Pods.

Eine Workload erstellen

1.Führen Sie den folgenden Befehl aus, um die Workload statefulSet zu erstellen, der den vorherigen PV-Claim verwendet:

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2.Führen Sie den folgenden Befehl zum Abrufen und Beschreiben aus, um den Status der Workload statefulSet zu überprüfen:

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

**Hinweis:**Der Controller statefulSet erstellt einige PV-Claims, um die Volume-Anfrage der Pods für Volumes in den AWS-Regionen „us-east-2b“ und „us-east-2c“ zu erfüllen. Bei Beendigung von statefulSets wird nicht garantiert, dass persistente Volumes bereinigt werden. Dies kann dazu führen, dass Volumes für statefulSet-Pods, die in eine andere Availability Zone verschoben werden, nicht erneut bereitgestellt werden.

Testen eines topologiebewussten Szenarios

(Optional) Um zu testen, wie das Ersetzen von Knoten in einer anderen Availability Zone gehandhabt wird, simulieren Sie die Neustrukturierung von Knoten, indem Sie die Knoten in der angegebenen AZ herunterskalieren. Skalieren Sie dann neue Knoten in einer anderen AZ hoch. Wenn Sie fertig sind, lesen Sie die Abschnitte Pod erstellen und Workload erstellen.

Beispielausgabe zu einem simulierten Bereitstellungsproblem:

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

Um den hängengebliebenen Pod zu beheben, skalieren Sie einen Knoten in der angegebenen Availability Zone erneut hoch, um den Fehler beim Affinitätskonflikt beim Volume-Knoten zu beheben.

**Hinweis:**Beim Hochskalieren eines neuen Knotens in der erwarteten Availability Zone kann die Bereitstellung aufgrund fehlgeschlagener Reconciler-Ausführungen fehlschlagen. Schritte zur Fehlerbehebung finden Sie im folgenden Abschnitt: Fehlerbehebung bei EBS CSI-Controller-Fehlern.

Fehlerbehebung bei EBS CSI-Controller-Fehlern

Beispiel für einen EBS CSI-Fehler, bei dem Pod-Churn und Knoten-Recycling simuliert wurden:

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1.Um das Problem einzugrenzen, beschreiben Sie den Pod und überprüfen Sie die Fehlerprotokolleinträge im Ereignis. Im vorherigen Beispielfehler zeigt die Meldung, dass vier von fünf Knoten aufgrund von Knoten-Taints und der Topologie oder Affinitätskonfiguration nicht geplant werden können. Außerdem hat der letzte Knoten, der in der richtigen Availability Zone ausgeführt wurde, kein verfügbares persistentes Volume zum Binden gefunden.

2.Um dieses Problem einzugrenzen, überprüfen Sie den Status der PV-Claim-Bindung:

kubectl describe persistentvolumeclaim <PVC_NAME>

**Hinweis:**Die Status des PV-Claims lauten wartend, gebunden, ungültig oder nicht gefunden. Im folgenden Beispiel wartet der PV-Claim darauf, dass der Treiber ein Volume erstellt. Während der Wartezeit bindet sich der PV-Claim nicht an einen Zielknoten.

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3.Überprüfen Sie die csi-provisioner-Container-Protokolle im Pod ebs-csi-controller:

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

Die folgende Ausgabe ist ein Beispiel für ein Fehlerereignis:

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

**Hinweis:**Wenn ähnliche Fehlerereignisse wie in der vorherigen Meldung auftreten, konnte der PV-Claim-Reconciler die Anmerkung eines ausgewählten Zielknotens nicht finden. Entfernen Sie diese Anmerkung, damit der PV-Claim erfolgreich synchronisiert werden kann.

4.Führen Sie den folgenden Befehl aus, um die Anmerkung des ausgewählten Zielknotens zu entfernen. Stellen Sie sicher, dass Sie die Ausgabe kopieren und in das PV-Claim-Manifest speichern, um die Anmerkung selected-node zu entfernen.

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

Wenn die weiteren Schritte zur Fehlerbehebung Ihr Problem nicht lösen, sammeln Sie die Protokolle der isolierten Container-Workload und wenden Sie sich an den AWS Support. Sie können auch im GitHub-Repository nach ähnlichen Problemen suchen.