Distributed Cloud Connected Storage konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Speicher für mit Distributed Cloud verbundene Cluster konfigurieren. Dazu gehören:

Distributed Cloud connected für Symcloud Storage konfigurieren

Mit Distributed Cloud verbundene Knoten stellen ihren lokalen Speicher nicht direkt für Ihre Arbeitslasten zur Verfügung. Stattdessen verwendet Distributed Cloud connected Rakuten Symcloud Storage, eine Drittanbieterlösung, die als Abstraktionsebene für den lokalen Speicher fungiert. Sie wird auf jedem mit Distributed Cloud verbundenen Knoten ausgeführt und stellt den lokalen Speicher für Arbeitslasten zur Verfügung, die auf allen mit Distributed Cloud verbundenen Knoten in einem Cluster ausgeführt werden.

Container Storage Interface (CSI) ist eine API mit offenen Standards, die von vielen großen Speicheranbietern unterstützt wird und Kubernetes ermöglicht, beliebige Speichersysteme für containerisierte Arbeitslasten verfügbar zu machen. In Distributed Cloud connected ist Symcloud Storage die unterstützte und verwaltete CSI-Speicherlösung. Wenn Symcloud Storage aktiviert ist, werden die erforderlichen Kubernetes StorageClasses für Sie konfiguriert. Anschließend können Sie Ihre Arbeitslasten so konfigurieren, dass sie die entsprechende Speicherklasse verwenden.

Symcloud Storage wird über Google Cloud Marketplace bereitgestellt und unterliegt den dort genannten Bedingungen. Google bietet eingeschränkten Support für die Verwendung von Symcloud Storage mit Distributed Cloud connected und wendet sich möglicherweise an den Drittanbieter, um Unterstützung zu erhalten. Softwareupdates für Symcloud Storage sind in den Softwareupdates für Distributed Cloud connected enthalten.

Diese Version von Distributed Cloud connected wird mit Symcloud Storage 6.0.0-226 ausgeliefert und unterstützt diese Version. Keine andere Version von Symcloud Storage wird in dieser Version von Distributed Cloud connected unterstützt.

Symcloud Storage-Lizenz erwerben

Sie müssen eine Symcloud Storage-Lizenz im YAML-Format über Google Cloud Marketplace erwerben:

Marketplace aufrufen

Vorbereitung

Führen Sie vor Beginn die folgenden Schritte aus:

  1. Konfigurieren Sie Logging und Monitoring für das Zielprojekt von Distributed Cloud connected.
  2. Erstellen Sie den Zielcluster von Distributed Cloud connected. Sie können den Bereitstellungsfortschritt verfolgen.
  3. Konfigurieren Sie Ihr Distributed Cloud-Netzwerk so dass Pods im Zielcluster von Distributed Cloud connected das Rechenzentrum erreichen können. Google Cloud
  4. Softwaredefinierte Speicherlösungen (Software-Defined Storage, SDS) wie Symcloud Storage zielen auf ungebundene local-block-Rohblockgeräte ab. Distributed Cloud connected erwartet, dass bei der Clustererstellung eine SDS-Lösung installiert wird, wenn ungebundene local-block-Geräte verfügbar sind.

Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten installieren

So installieren Sie Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten:

  1. Verwenden Sie den folgenden Befehl, um die Symcloud Storage-Lizenz auf Ihren Cluster anzuwenden. Ersetzen Sie LICENSE_FILE durch den vollständigen Pfad und Namen der Symcloud Storage-Lizenzdatei.

    kubectl apply -f LICENSE_FILE -n robin-admin

  2. Verwenden Sie den folgenden Befehl, um den Status des RobinCluster-Dienstes und aller Symcloud Storage-Knoten zu prüfen:

    kubectl describe robinclusters -n robinio

    Die Ausgabe des Befehls sieht in etwa so aus:

    [...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]

    Der erwartete Status für den Dienst und die Knoten ist Ready.

Symcloud Storage als Standardspeicherklasse festlegen

Verwenden Sie den folgenden Befehl, um Symcloud Storage als Standardspeicherklasse in Ihrem mit Distributed Cloud verbundenen Cluster festzulegen. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Weitere Informationen zum Festlegen der Standardspeicherklasse finden Sie in der Kubernetes-Dokumentation unter Standard-StorageClass ändern.

Symcloud Storage-Klassen

In diesem Abschnitt werden die Speicherklassen beschrieben, die Symcloud Storage in Ihrem mit Distributed Cloud verbundenen Cluster aktivieren kann. Symcloud Storage in Distributed Cloud connected unterstützt weder die Speicherklasse robin-rwx noch benutzerdefinierte RWX-Dateisystemmodus-Volumes. Weitere Informationen zu Symcloud Storage-Klassen finden Sie unter Robin CNS in Kubernetes verwenden.

Speicherklasse robin

Die Speicherklasse robin ist eine einfache RWO-Speicherklasse (Read Write-Once). Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Speicherklasse robin-immediate

Die robin-immediate Speicherklasse ist mit robin identisch, mit dem Unterschied, dass das nichtflüchtige Volume sofort nach dem Erstellen des entsprechenden PersistentVolumeClaim erstellt wird. Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

Speicherklasse robin-repl-3

robin-repl-3 ist eine RWO-Speicherklasse mit drei Replikaten, die sich über mehrere Distributed Cloud-Knoten erstrecken. Das folgende Beispiel veranschaulicht die Instanziierung der Klasse:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

Abstrakte Symcloud Storage-Volumes für Arbeitslasten konfigurieren

In diesem Abschnitt finden Sie Beispiele für die Verwendung von Symcloud Storage-Klassen zum Konfigurieren von abstraktem Speicher für Ihre mit Distributed Cloud verbundenen Arbeitslasten. Weitere Informationen zum Konfigurieren von Symcloud Storage-Volumes finden Sie unter Robin CNS in Kubernetes verwenden.

ext4-RWO-Volume im Dateisystemmodus konfigurieren

Das folgende Beispiel veranschaulicht, wie Sie einen PersistentVolumeClaim für ein RWO-Volume im Dateisystemmodus mit dem ext4-Dateisystem konfigurieren. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

RWO-Volume im Blockmodus konfigurieren

Das folgende Beispiel veranschaulicht, wie Sie einen PersistentVolumeClaim für ein RWO-Volume im Blockmodus konfigurieren. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

Konfiguration eines vorhandenen Volumes ändern

Das folgende Beispiel veranschaulicht, wie Sie die Konfiguration eines vorhandenen Symcloud Storage-RWO-Volumes mit LZ4-Komprimierung mithilfe von Annotationen ändern. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Das folgende Beispiel veranschaulicht, wie Sie die Konfiguration eines vorhandenen Symcloud Storage-RWO-Volumes mit dem xfs-Dateisystem mithilfe von Annotationen ändern. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud Storage-Klassen.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Symcloud Storage-CLI-Client konfigurieren

Symcloud Storage bietet einen Befehlszeilenclient (Command-Line Interface, CLI), mit dem Sie Ihre Symcloud Storage-Konfiguration verwalten können. So konfigurieren Sie den Client in Ihrem mit Distributed Cloud verbundenen Cluster:

  1. Rufen Sie den Symcloud Storage-Imagepfad ab, der von der RobinCluster-Dienstinstanz verwendet wird, die in Ihrem mit Distributed Cloud verbundenen Cluster bereitgestellt wurde, und legen Sie Ihre Umgebungsvariablen so fest:

    image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

  2. Erstellen Sie eine robincli-Ressource mit folgendem Inhalt:

    kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

    Ersetzen Sie ROBIN_CNS_IMAGE durch den vollständigen Repository-Pfad und Namen des Images, das Sie in Schritt 1 abgerufen haben.

  3. Wenden Sie die robincli-Ressource auf Ihren mit Distributed Cloud verbundenen Cluster an.

  4. Bei der Erstinstallation generiert Symcloud Storage im Namespace robinio ein default-admin-user-Secret mit einem zufälligen Passwort. Verwenden Sie die folgenden Befehle, um diese Anmeldedaten abzurufen:

    1. Rufen Sie den Nutzernamen ab:

      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d

    2. Rufen Sie das Passwort ab:

       
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d

  5. Melden Sie sich im neu erstellten Pod an und führen Sie den Client aus:

    kubectl exec -it robincli -- bash

Auf die Speicherklasse in einem StatefulSet verweisen

Das folgende Beispiel zeigt, wie Sie in einer StatefulSet Arbeitslast auf eine Symcloud Storage-Klasse verweisen.

Im Beispiel wird davon ausgegangen, dass Sie die vorkonfigurierte Speicherklasse robin-repl-3 verwenden, die Volumes bereitstellt, die für Hochverfügbarkeit auf drei verschiedenen Worker-Knoten repliziert werden.

Wenn Sie ein StatefulSet für Hochverfügbarkeit konfigurieren, sollten Sie die folgenden Best Practices in Ihre Konfiguration aufnehmen:

  • Monitorloser Dienst: Ein StatefulSet erfordert einen zugehörigen monitorlosen Dienst, der mit dem Feld serviceName übereinstimmt. Ein monitorloser Dienst ist ein Dienst mit clusterIP: None. Dieser Dienst weist jedem Pod im Set stabile DNS-Hostnamen zu.
  • Pod-Anti-Affinität: Wenn Sie eine replizierte Speicherklasse wie robin-repl-3 verwenden, werden Ihre Daten sicher auf mehreren Worker-Knoten gespiegelt. Wenn Kubernetes jedoch alle Pods Ihrer Anwendung auf demselben Worker-Knoten plant, kann ein einzelner Knotenausfall dazu führen, dass Ihre Anwendung ausfällt. Durch die Konfiguration der Pod-Anti-Affinität werden Ihre Pods auf verschiedene Worker-Knoten verteilt, sodass die Verfügbarkeit Ihrer Compute-Ressourcen mit der Redundanz Ihres Speichers übereinstimmt.

Das folgende Beispiel zeigt eine vollständige Konfiguration, die den monitorlosen Dienst (nginx) und ein StatefulSet enthält, das mit Pod-Anti-Affinität konfiguriert ist und auf die Speicherklasse robin-repl-3 verweist. Wenn die Speicheranforderungen Ihrer Arbeitslast im Laufe der Zeit steigen, können Sie die Größe des Volumes dynamisch ändern, indem Sie die Speicheranfrage im PersistentVolumeClaim bearbeiten.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

Einschränkungen von Symcloud Storage

Wenn Sie Symcloud Storage mit Distributed Cloud connected verwenden, können Sie nur dann Hochverfügbarkeit erreichen, wenn Ihr mit Distributed Cloud verbundener Cluster aus mindestens drei mit Distributed Cloud verbundenen Knoten besteht.

Knoten, die Symcloud Storage verwenden, aus einem Cluster entfernen

Symcloud Storage-Volume-Replikate werden auf Worker-Knoten in Ihrem mit Distributed Cloud verbundenen Cluster gespeichert. Wenn Sie einen Knoten aus dem Cluster entfernen, sind die auf diesem Knoten gespeicherten Symcloud Storage-Volume-Daten nicht mehr verfügbar. Um dies zu verhindern, haben Sie folgende Möglichkeiten:

  • Wenn Sie den gesamten Cluster entfernen, entfernen Sie die Arbeitslasten und die entsprechenden nichtflüchtigen Symcloud Storage-Volumes, bevor Sie den Cluster selbst entfernen.
  • Wenn Sie bestimmte Knoten aus dem Cluster entfernen, müssen Sie die auf diesen Knoten gespeicherten Arbeitslastdaten migrieren, bevor Sie die Knoten aus dem Cluster entfernen. Eine Anleitung finden Sie unter Volumes von einem Laufwerk entfernen.

Lokale Speicherschemas konfigurieren

Ein Speicherschema ist eine logische Gruppierung einer oder mehrerer Partitionen. Jede Partition ist eine logisch unabhängige Speichereinheit. Partitionen werden sequenziell in Ihrem Cluster erstellt, bis der physische Speicherplatz auf der Festplatte erschöpft ist. Jedes Speicherschema hat einen eindeutigen Namen, der es identifiziert.

Wenn Sie ein neues lokales Speicherschema für Ihren mit Distributed Cloud verbundenen Cluster erstellen möchten, müssen Sie es bei Google anfordern. Sobald wir das Schema getestet und in Ihrem Cluster erstellt haben, können Sie es mit der gcloud-CLI anwenden.

Sie können ein Schema nicht mehr ändern, nachdem es auf einen Cluster angewendet wurde. Wenn Sie ein vorhandenes Schema ändern möchten, müssen Sie bei Google die Löschung des vorhandenen Schemas beantragen und dann die Erstellung eines neuen Schemas beantragen, das es ersetzt.

Partitionen für ein lokales Speicherschema definieren

Bevor Sie ein lokales Speicherschema anfordern können, müssen Sie zuerst die Partitionen für dieses Schema definieren.

Eine Partition hat die folgenden Eigenschaften:

  • Größe. Sie können entweder eine Partitionsgröße in binären Byte angeben oder den gesamten verbleibenden Speicherplatz auf der lokalen Festplatte verwenden.
  • Typ. Sie können eine Partition entweder als nichtflüchtiges Kubernetes-Volume (PersistentVolume, PV) oder als lokales Linux-Volume auf der lokalen Festplatte konfigurieren.
  • Modus. Sie können das in der Partition gespeicherte Volume entweder als Block-Volume oder als Dateisystem-Volume konfigurieren. Bei Partitionen mit nichtflüchtigen Volumes ist die Speicherklasse der Partition entweder local-block oder local-disks. Bei Partitionen mit lokalen Volumes können Sie die Bindungs- und Bereitstellungspunkte für die enthaltenen Dateisysteme angeben.

Lokales Speicherschema anfordern

Wenn Sie ein neues lokales Speicherschema für Ihren mit Distributed Cloud verbundenen Cluster anfordern möchten, wenden Sie sich an den Google-Support und geben Sie Größe, Typ, Modus und optional Bereitstellungs- und Bindungspunkte für jede Partition an, die Sie im Schema erstellen möchten.

Wenn wir Ihre Anfrage erhalten, führen wir eine Reihe von Tests durch, um die Robustheit des Schemas zu gewährleisten, und erstellen es dann in Ihrem mit Distributed Cloud verbundenen Cluster.

Standardmäßige lokale Speicherschemas

Distributed Cloud connected wird mit den folgenden standardmäßigen lokalen Speicherschemas ausgeliefert:

  • default_control_plane_node. Dieses Schema definiert die folgenden Partitionen:

    • Eine 100 GB große lokale Volume-Partition im Dateisystemmodus.
    • Eine Partition mit nichtflüchtigem Volume im Blockmodus, die den verbleibenden freien Speicherplatz auf der Festplatte belegt.

  • default_worker_node. Dieses Schema definiert eine 410 GB große Partition mit nichtflüchtigem Volume im Blockmodus.

Lokales Speicherschema auf einen Cluster anwenden

So wenden Sie ein lokales Speicherschema auf Ihren mit Distributed Cloud verbundenen Cluster an:

  • Wenn Sie ein lokales Speicherschema auf die Knoten der Steuerungsebene des Clusters anwenden möchten, verwenden Sie beim Erstellen des Clusters das Flag --control-plane-node-storage-schema. Weitere Informationen finden Sie unter Cluster erstellen.

  • Wenn Sie ein lokales Speicherschema auf die Worker-Knoten des Clusters anwenden möchten, verwenden Sie beim Erstellen eines Knotenpools für den Cluster das Flag --node-storage-schema. Weitere Informationen finden Sie unter Knotenpool erstellen.

Distributed Cloud connected erstellt die in Ihrem lokalen Speicherschema definierten Partitionen nach erfolgreicher Erstellung des Clusters oder Knotenpools.

Standardmäßige statische lokale nichtflüchtige Volumes

Distributed Cloud connected wird mit den folgenden Arten von vorab bereitgestellten standardmäßigen statischen lokalen nichtflüchtigen Volumes (PersistentVolumes, PVs) ausgeliefert:

  • anthos-system (97 GiB): Eine vorab bereitgestellte statische lokale Volume-Speicherklasse im Dateisystemmodus.
  • local-shared (97 GiB): Eine vorab bereitgestellte statische lokale Volume-Speicherklasse im Dateisystemmodus.
  • local-disks: Eine vorab bereitgestellte statische lokale Volume-Speicherklasse im Dateisystemmodus, die in Einzelknotenbereitstellungen für den Speicher von Kundenarbeitslasten verfügbar ist. Im Gegensatz zu local-shared werden diese PVs durch dedizierte physische Partitionen unterstützt und sind nicht logisch überdimensioniert.
  • local-block: Eine ungebundene Rohblockgerätepartition, die für den Speicher von Arbeitslasten und Symcloud Storage-Volumes reserviert ist. Die Größe dieser Partition hängt von der zugrunde liegenden Speicherkapazität der Hardware ab und belegt den verbleibenden Speicherplatz auf der Festplatte, nachdem Speicherplatz für Systempartitionen reserviert wurde. In der Regel reservieren Knoten der Steuerungsebene 200 GiB (100 GiB für die Systempartition und 100 GiB für die etcd-Partition), während Worker-Knoten 100 GiB (für die Systempartition) reservieren. Das Partitionsschema, die Slice-Offsets und die physischen Gerätegrenzen dieser Rohblockgeräte sind festgelegt und unveränderlich.

Die local-shared-PVs der einzelnen Knoten sind für andere Knoten im Cluster nicht zugänglich. Pods, die auf einem Knoten ausgeführt werden, schreiben in separate Verzeichnisse, die sich auf demselben physischen Laufwerk auf diesem Knoten befinden. Wenn Sie Symcloud Storage nicht verwenden, bleiben die ungebundenen local-block-Rohblockgeräte auf jedem Knoten verfügbar.

Die statischen PVs anthos-system und local-shared sind logisch überdimensioniert und werden durch dasselbe physische Dateisystem der Systempartition mit ~105 GB unterstützt, das auf jedem Knoten unter /dev/mapper/shared_lpvs_encrypted bereitgestellt wird. Diese Architektur bietet eine Isolation auf Verzeichnisebene für von Google verwaltete Systemhintergrunddienste wie Logging, Monitoring und Netzwerke, ohne die physische Festplattenkapazität zu verschwenden. Diese System-PVs werden vorab auf ihre maximale nominale Kapazität überdimensioniert, da für die Größenänderung statischer lokaler Volumes eine Datenmigration und die Neuerstellung der betroffenen PVs und PVCs erforderlich ist.

local-shared-PVs nicht für Produktionsarbeitslasten verwenden

Verwenden Sie local-shared-PVs nicht für Produktionsarbeitslasten. Da sich diese PVs auf demselben physischen Laufwerk wie die Distributed Cloud connected-Systemdienste befinden, konkurrieren alle Arbeitslasten, die Sie für die Verwendung dieser PVs bereitstellen, mit dem Distributed Cloud connected-System selbst um Speicherplatz.

Wenn auf dem Systemlaufwerk kein freier Speicherplatz mehr verfügbar ist, passiert Folgendes:

  • Von Google verwaltete Plattformdienste und Monitoring-Pods stürzen ab.
  • Kubernetes löst auf dem Knoten den Status DiskPressure aus.
  • Kubernetes entfernt alle Pods vom Knoten.

Um dies zu verhindern, verwenden Sie für Produktionsarbeitslasten nur Speicherklassen, die von Symcloud Storage angeboten werden.

Fehlerbehebung

Wenn PersistentVolumeClaims unerwartet ausstehend bleiben oder Volumes nicht an Arbeitslasten angehängt werden können, führen Sie die in diesem Abschnitt aufgeführten Schritte zur Fehlerbehebung aus.

PersistentVolumeClaims bleiben ausstehend

Wenn Ihre PersistentVolumeClaims den Status Pending haben, prüfen Sie den volumeBindingMode Ihrer Speicherklasse. Vorkonfigurierte Symcloud Storage-Klassen verwenden volumeBindingMode: WaitForFirstConsumer. Dadurch wird die Volume-Bereitstellung verzögert, bis der Pod geplant ist, der auf den Anspruch verweist. Prüfen Sie, ob Ihr Arbeitslast-Pod erfolgreich geplant wurde.

Wenn die Pod-Planung abgeschlossen ist, der Anspruch aber weiterhin ausstehend ist oder das Anhängen des Volumes fehlschlägt, prüfen Sie den Status der Symcloud Storage-Steuerungsebene und der Daemons auf Knotenebene.

Status der Steuerungsebene prüfen

Prüfen Sie mit dem Befehl kubectl describe, ob die Symcloud Storage-Steuerungsebene fehlerfrei ist und Volumes bereitstellen kann. Prüfen Sie dazu den Status der RobinCluster benutzerdefinierten Ressource:

kubectl describe robinclusters -n robinio

Prüfen Sie in der Befehlsausgabe, ob Phase den Wert Ready hat.

Status des Speicher-Daemons prüfen

Prüfen Sie mit dem Befehl kubectl get, ob alle Speicher-Daemon-Pods auf Knotenebene ausgeführt werden:

kubectl get pods -n robinio

Prüfen Sie in der Befehlsausgabe, ob alle Pods den Status Running haben. Wenn eine Arbeitslast auf einem Knoten mit einem fehlerhaften Speicher-Daemon-Pod geplant wird, hängt das Anhängen des Volumes unabhängig vom zentralen RobinCluster-Status.

Support kontaktieren

Wenn der Status der Symcloud Storage-Steuerungsebene nicht Ready ist oder sich Speicher Daemon-Pods nicht im Status Running befinden, wenden Sie sich an den Google-Support. Geben Sie beim Einreichen eines Supporttickets die Ausgaben der Befehle zur Fehlerbehebung an, die Sie ausgeführt haben.