Auf dieser Seite wird beschrieben, wie Sie den Speicher für verbundene Cluster von Distributed Cloud konfigurieren. Dazu gehören:
Distributed Cloud Connected für Symcloud Storage konfigurieren
Der lokale Speicher von mit Distributed Cloud verbundenen Knoten wird Ihren Arbeitslasten nicht direkt zur Verfügung gestellt. Stattdessen wird in Distributed Cloud Connected Rakuten Symcloud Storage verwendet. Das ist eine Drittanbieterlösung, die als lokale Abstraktionsebene für den Speicher fungiert. Sie wird auf jedem Distributed Cloud Connected-Knoten ausgeführt und stellt den lokalen Speicher für Arbeitslasten zur Verfügung, die auf allen Distributed Cloud Connected-Knoten in einem Cluster ausgeführt werden.
Das 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 für die Verwendung der entsprechenden Speicherklasse konfigurieren.
Symcloud Storage wird über den Google Cloud Marketplace bereitgestellt und unterliegt den dort angegebenen 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 mit Verbindung zu Distributed Cloud enthalten.
Diese Version von Distributed Cloud Connected wird mit Symcloud Storage 6.0.0-226 ausgeliefert und unterstützt diese Version. In dieser Version von Distributed Cloud Connected wird keine andere Version von Symcloud Storage unterstützt.
Symcloud Storage-Lizenz erwerben
Sie müssen eine Symcloud Storage-Lizenz im YAML-Format vom Google Cloud Marketplace beziehen:
Vorbereitung
Führen Sie zuerst die folgenden Schritte aus:
- Logging und Monitoring für das verbundene Zielprojekt von Distributed Cloud konfigurieren.
- Zielcluster für Distributed Cloud Connected erstellen
- Konfigurieren Sie Ihr Distributed Cloud-Netzwerk so, dass Pods im verbundenen Zielcluster von Distributed Cloud das Rechenzentrum Google Cloud erreichen können.
- Binden Sie jedes
local-block-Persistent Volume auf jedem Distributed Cloud-Knoten, das nicht von Symcloud Storage abstrahiert werden soll. Wenn Sie ein gebundenes nichtflüchtigeslocal-block-Volume entbinden, werden bei der Installation von Symcloud Storage die Inhalte dieses nichtflüchtigen Volumes gelöscht. Eine Anleitung finden Sie in der Kubernetes-Dokumentation unter Binding.
Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten installieren
So installieren Sie Symcloud Storage auf einem mit Distributed Cloud verbundenen Knoten:
Verwenden Sie den folgenden Befehl, um die Symcloud Storage-Lizenz auf Ihren Cluster anzuwenden. Ersetzen Sie
LICENSE_FILEdurch den vollständigen Pfad und Namen der Symcloud Storage-Lizenzdatei.kubectl apply -f LICENSE_FILE -n robin-admin
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-Speicherklassen.
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-Speicherklassen finden Sie unter Robin CNS in Kubernetes verwenden.
Speicherklasse robin
Die Speicherklasse robin ist eine einfache RWO-Speicherklasse (Read Write-Once). Das folgende Beispiel zeigt 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 Speicherklasse robin-immediate ist dieselbe wie robin, mit der Ausnahme, dass das nichtflüchtige Volume sofort nach dem Erstellen des entsprechenden Anspruchs auf ein nichtflüchtiges Volume 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 abstrahiertem 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 Anspruch auf ein persistentes Volume für ein RWO-Volume im Dateisystemmodus mit dem ext4-Dateisystem konfigurieren. Ersetzen Sie STORAGE_CLASS durch eine der Symcloud-Speicherklassen.
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-Speicherklassen.
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
Im folgenden Beispiel wird veranschaulicht, wie Sie die Konfiguration eines vorhandenen LZ4-komprimierten RWO-Volumes von Symcloud Storage mithilfe von Annotationen ändern.
Ersetzen Sie STORAGE_CLASS durch eine der Symcloud-Speicherklassen.
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 zeigt, 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-Speicherklassen.
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 CLI-Client (Befehlszeile), mit dem Sie Ihre Symcloud Storage-Konfiguration verwalten können. Führen Sie die folgenden Schritte aus, um den Client in Ihrem mit Distributed Cloud verbundenen Cluster zu konfigurieren:
Rufen Sie den Symcloud Storage-Imagepfad ab, der von der
RobinCluster-Dienstinstanz verwendet wird, die in Ihrem mit Distributed Cloud verbundenen Cluster bereitgestellt wird, 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"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_IMAGEdurch den vollständigen Repository-Pfad und den Namen des Images, das Sie in Schritt 1 abgerufen haben.Wenden Sie die
robincli-Ressource auf Ihren mit Distributed Cloud verbundenen Cluster an.Bei der Erstinstallation generiert Symcloud Storage ein
default-admin-user-Secret im Namespacerobiniomit einem zufälligen Passwort. Verwenden Sie die folgenden Befehle, um diese Anmeldedaten zu erhalten:Rufen Sie den Nutzernamen ab:
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -dPasswort abrufen:
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d
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
Im folgenden Beispiel wird gezeigt, wie Sie in einer StatefulSet-Arbeitslast auf eine Symcloud Storage-Speicherklasse 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: Für ein StatefulSet ist ein zugehöriger monitorloser Dienst erforderlich, der dem Feld
serviceNameentspricht. Ein Headless Service ist ein Dienst mitclusterIP: None. Dieser Dienst weist jedem Pod im Set stabile DNS-Hostnamen zu. - Pod-Anti-Affinität: Wenn Sie eine replizierte Speicherklasse wie
robin-repl-3verwenden, werden Ihre Daten sicher auf mehreren Worker-Knoten gespiegelt. Wenn Kubernetes jedoch alle Anwendungs-Pods auf demselben Worker-Knoten plant, kann ein einzelner Knotenausfall Ihre Anwendung zum Absturz bringen. Wenn Sie die Pod-Anti-Affinität konfigurieren, werden Ihre Pods auf separate Worker-Knoten verteilt. So wird die Verfügbarkeit Ihrer Compute-Ressourcen an die Redundanz Ihres Speichers angepasst.
Das folgende Beispiel zeigt eine vollständige Konfiguration, die den Headless Service (nginx) und ein StatefulSet mit Pod-Anti-Affinität enthält, das 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 eine Hochverfügbarkeit erreichen, wenn Ihr Distributed Cloud Connected-Cluster aus mindestens drei Distributed Cloud Connected-Knoten besteht.
Knoten, die Symcloud Storage verwenden, aus einem Cluster entfernen
Symcloud Storage-Volumenreplikate werden auf Worker-Knoten in Ihrem verbundenen Distributed Cloud-Cluster gespeichert. Wenn Sie einen Knoten aus dem Cluster entfernen, sind die auf diesem Knoten gespeicherten Symcloud Storage-Volumedaten nicht mehr verfügbar. Um dies zu verhindern, müssen Sie einen der folgenden Schritte ausführen:
- Wenn Sie den gesamten Cluster entfernen, entfernen Sie die Arbeitslasten und die zugehörigen persistenten 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 evakuieren.
Schemas für den lokalen Speicher konfigurieren
Ein Speicherschema ist eine logische Gruppierung von einer oder mehreren Partitionen. Jede Partition ist eine logisch unabhängige Speichereinheit. Partitionen werden sequenziell in Ihrem Cluster erstellt, bis der physische Festplattenspeicher 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. Nachdem 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 und dann die Erstellung eines neuen Schemas als Ersatz beantragen.
Partitionen für ein lokales Speicherschema definieren
Bevor Sie ein Schema für den lokalen Speicher 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 Bytes angeben oder die Partition den gesamten verbleibenden Speicherplatz auf der lokalen Festplatte verwenden lassen.
- Typ: Sie können eine Partition entweder als nichtflüchtiges Kubernetes-Volume (Persistent Volume, PV) oder als lokales Linux-Volume auf der lokalen Festplatte konfigurieren.
- Modus: Sie können das in der Partition gespeicherte Volume entweder als Block- oder als Dateisystemvolume konfigurieren. Bei Partitionen nichtflüchtiger Volumes ist die Speicherklasse der Partition entweder
local-blockoderlocal-disks. Für Partitionen lokaler Volumes können Sie die Bindungs- und Bereitstellungspunkte für die enthaltenen Dateisysteme angeben.
Schema für lokalen Speicher 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 für jede Partition, die Sie im Schema erstellen möchten, die Größe, den Typ, den Modus und optional die Bereitstellungs- und Bindungspunkte an.
Wenn wir Ihre Anfrage erhalten, führen wir eine Reihe von Tests durch, um die Robustheit des Schemas zu gewährleisten. Anschließend erstellen wir es in Ihrem mit Distributed Cloud verbundenen Cluster.
Standardschemas für den lokalen Speicher
Distributed Cloud Connected wird mit den folgenden Standardschemas für den lokalen Speicher ausgeliefert:
default_control_plane_node: In diesem Schema werden die folgenden Partitionen definiert:- Eine lokale Volume-Partition mit 100 GB im Dateisystemmodus.
- Eine Partition für ein nichtflüchtiges Volume im Blockmodus, die den verbleibenden freien Speicherplatz belegt.
default_worker_node: Dieses Schema definiert eine 410 GB große Partition für nichtflüchtige Volumes im Blockmodus.
Lokales Speicherschema auf einen Cluster anwenden
Wenn Sie ein lokales Speicherschema auf Ihren mit Distributed Cloud verbundenen Cluster anwenden möchten, haben Sie folgende Möglichkeiten:
Wenn Sie ein lokales Speicherschema auf die Steuerungsebenenknoten 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
--node-storage-schema, wenn Sie einen Knotenpool für den Cluster erstellen. Weitere Informationen finden Sie unter Knotenpool erstellen.
Bei Distributed Cloud Connected werden die in Ihrem lokalen Speicherschema definierten Partitionen nach erfolgreicher Erstellung des Clusters oder Knotenpools erstellt.
Fehlerbehebung
Wenn PersistentVolumeClaims unerwartet ausstehend bleiben oder Arbeitslasten keine Volumes anhängen können, führen Sie die Schritte zur Fehlerbehebung in diesem Abschnitt aus.
PersistentVolumeClaims bleiben ausstehend
Wenn Ihre PersistentVolumeClaims im Status Pending verbleiben, prüfen Sie die volumeBindingMode Ihrer Speicherklasse. Vorkonfigurierte Symcloud Storage-Klassen verwenden volumeBindingMode: WaitForFirstConsumer, wodurch die Volume-Bereitstellung verzögert wird, bis der Pod, der auf den Anspruch verweist, geplant ist. Prüfen Sie, ob der Pod für Ihre Arbeitslast erfolgreich geplant wurde.
Wenn die Pod-Planung abgeschlossen ist, der Anspruch aber weiterhin aussteht oder das Anhängen des Volumes fehlschlägt, prüfen Sie den Zustand der Symcloud Storage-Steuerungsebene und der Daemons auf Knotenebene.
Integrität der Steuerungsebene prüfen
Führen Sie den Befehl kubectl describe aus, um zu prüfen, ob die Symcloud Storage-Steuerungsebene fehlerfrei ist und bereit ist, Volumes bereitzustellen. Prüfen Sie dazu den Status der benutzerdefinierten Ressource RobinCluster:
kubectl describe robinclusters -n robinio
Prüfen Sie in der Befehlsausgabe, ob Phase auf Ready gesetzt ist.
Status des Speicherdemons prüfen
Prüfen Sie, ob alle Storage-Daemon-Pods auf Knotenebene ausgeführt werden, indem Sie den Befehl kubectl get ausführen:
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 Storage-Daemon-Pod geplant wird, bleibt die Volume-Einbindung unabhängig vom zentralen RobinCluster-Status hängen.
Support kontaktieren
Wenn der Status der Symcloud Storage-Steuerungsebene nicht Ready ist oder Storage-Daemon-Pods nicht den Status Running haben, wenden Sie sich an den Google-Support.
Geben Sie beim Einreichen eines Support-Tickets die Ausgaben der von Ihnen ausgeführten Befehle zur Fehlerbehebung an.