In diesem Thema werden die Speicherkonzepte von GKE On-Prem beschrieben.
Fazit
GKE On-Prem lässt sich über VMware vSphere-Speicher, integrierte Kubernetes Volume-Plug-ins (oder „Treiber“) und Container Storage Interface (CSI)-Treiber in externe Block- oder Dateispeichersysteme integrieren.
GKE On-Prem-Cluster verwenden eine standardmäßige Kubernetes StorageClass, um Speicher für zustandsorientierte Arbeitslasten in einem vSphere-Datenspeicher bereitzustellen. Sie können auch eine StorageClass verwenden, um verschiedene Speicher-Volumes bereitzustellen.
vSphere-Speicher
Standardmäßig verwenden GKE On-Prem-Cluster den vSphere-Speicher. Der Administratorcluster erfordert einen vorab bereitgestellten vSphere-Datenspeicher für seine etcd-Daten.
Wenn Sie einen Nutzercluster erstellen, verwendet GKE On-Prem das vSphere Kubernetes-Volume-Plug-in, um neue VM-Laufwerke (VMDKs) in einem vSphere Datenspeicher dynamisch bereitzustellen. (Beachten Sie, dass Nutzercluster vor Version 1.2 denselben Datenspeicher verwendet haben wie Administratorcluster.)
Die von den Administrator- und Nutzerclustern verwendeten vSphere-Datenspeicher können durch NFS, vSAN oder VMFS auf einem blockorientierten Gerät, z. B. einem externen Speicherarray, gesichert werden. In einer Umgebung mit mehreren Hosts muss jedes blockorientierte Gerät mit allen Hosts in der Umgebung verbunden sein und der Datenspeicher muss auf jedem Host über die Option Datastore auf zusätzlichen Hosts bereitstellen konfiguriert werden.
Standardspeicher
GKE On-Prem-Cluster enthalten eine standardmäßige StorageClass von Kubernetes, die bestimmt, wie Kubernetes Speicher bereitstellen soll. Nachdem Kubernetes Speicher-Volumes bereitgestellt hat, werden diese durch Kubernetes-PersistentVolumes dargestellt.
Die standardmäßige StorageClass für einen Nutzercluster verweist auf einen vSphere-Datenspeicher, der im Feld datastore der StorageClass-Konfiguration festgelegt wird. Standardmäßig sind Kubernetes-PersistentVolumes, die für den Nutzercluster bereitgestellt werden, VMDKs, die diesen Datenspeicher enthalten. Dies ist nicht unbedingt derselbe Datenspeicher, der vom Administratorcluster verwendet wird.
In GKE On-Prem verwenden StatefulSets von Kubernetes (zustandsorientierte Arbeitslasten, die normalerweise nichtflüchtigen Speicher benötigen) PersistentVolumeClaims, die von StorageClasses unterstützt werden und standardmäßig auf vSphere-Speicher verweisen.
Integrierte Kubernetes-Volume-Plug-ins
Kubernetes wird mit zahlreichen integrierten Volume-Plug-ins ausgeliefert. Sie können eine dieser Optionen verwenden, um Block- oder Dateispeicher für Ihre zustandsorientierten Arbeitslasten bereitzustellen. Mit integrierten Plug-ins können Arbeitslasten direkt mit dem Speicher verbunden werden, ohne den vSphere-Speicher nutzen zu müssen.
Während vSphere-Speicher automatisch die dynamische Bereitstellung von Volumes innerhalb eines Datenspeichers ermöglicht, der durch ein beliebiges iSCSI-, FC- oder NFS-Speichergerät gesichert wird, unterstützen viele der integrierten Plug-ins keine dynamische Bereitstellung. Sie erfordern, dass Sie PersistentVolumes manuell erstellen.
In der folgenden Tabelle werden mehrere integrierte Volume-Plug-ins beschrieben:
| Integriertes Kubernetes-Volume-Plug-in | Beschreibung | Unterstützte Zugriffsmodi | Dynamische Bereitstellung |
|---|---|---|---|
| Fibre Channel | Generisches Speicher-Plug-in | Einzelnen Pod lesen/schreiben | Nein |
| iSCSI | Generisches Speicher-Plug-in | Einzelnen Pod lesen/schreiben | Nein |
| NFS | Generisches Speicher-Plug-in | Mehrere Pods lesen/schreiben | Nein |
| Ceph RBD | Softwaredefinierter Open-Source-Speicher | Einzelnen Pod lesen/schreiben | Ja |
| CephFS | Softwaredefinierter Open-Source-Speicher | Mehrere Pods lesen/schreiben | Nein |
| Portworx | Proprietärer, softwaredefinierter Speicher | Mehrere Pods lesen/schreiben | Ja |
| Quobyte | Proprietärer, softwaredefinierter Speicher | Einzelnen Pod lesen/schreiben | Ja |
| StorageOS | Proprietärer, softwaredefinierter Speicher | Einzelnen Pod lesen/schreiben | Ja |
Container Storage Interface
Container Storage Interface (CSI) ist eine API mit offenen Standards, mit der Kubernetes beliebige Speichersysteme an containerisierte Arbeitslasten anhängen kann. Wenn Sie einen CSI-kompatiblen Volumetreiber in einem GKE On-Prem-Cluster bereitstellen, können Arbeitslasten direkt mit einem kompatiblen Speichergerät verbunden werden, ohne den vSphere-Speicher verwenden zu müssen.
GKE On-Prem unterstützt CSI v1.0. Wenn Sie CSI in Ihrem Cluster verwenden möchten, müssen Sie den CSI-Treiber Ihres Speicheranbieters bereitstellen. Anschließend können Sie Arbeitslasten für die Verwendung der StorageClass des Treibers konfigurieren oder als Standard-StorageClass festlegen.
Clusterspeicher konfigurieren
Wenn Sie andere Speicher-Volumes als vSphere-Datenspeicher bereitstellen möchten, können Sie eine neue StorageClass in einem Cluster erstellen, der einen anderen Speichertreiber verwendet. Anschließend können Sie die StorageClass als Standardcluster festlegen oder Ihre Arbeitslasten mithilfe der StorageClass konfigurieren (StatefulSet-Beispiel).
Problembehebung
Siehe Fehlerbehebung für Speicher.