Best Practices für den Speicher

Erfahren Sie mehr über Best Practices für Speicher für Cluster, die Sie mit Kubernetes Engine (OKE) erstellt haben.

Dieser Abschnitt enthält Best Practices für Speicher und Kubernetes Engine.

Best Practice: Geeigneten Speichertyp auswählen

Es wird empfohlen, den Workload-Typ zu berücksichtigen, den ein Cluster ausführt, bevor Sie einen Speichertyp auswählen, der für diese Workload geeignet ist.

Wenn Sie ein dauerhaftes, skalierbares und verteiltes Netzwerkdateisystem der Unternehmensklasse benötigen, wird empfohlen, den Oracle Cloud Infrastructure File Storage-Service zu verwenden.

Wenn Sie einen persistenten, dauerhaften und leistungsstarken Blockspeicher benötigen, wird empfohlen, den Oracle Cloud Infrastructure Block Volume-Service zu verwenden.

Best Practice: Speicherklassen erstellen und verwenden, um Anwendungsanforderungen zu definieren

Es wird empfohlen, den erforderlichen Speichertyp mit Kubernetes-Speicherklassen zu definieren und dann die Speicherklassen in Pod- und Deployment-Spezifikationen zu referenzieren. Speicherklassendefinitionen erstellen gemeinsam den entsprechenden Speicher und verbinden ihn mit Pods.

Siehe Speicher für Kubernetes-Cluster einrichten.

Best Practice: Volumes für persistenten Speicher erstellen und verwenden

Es wird empfohlen, Persistent Volumes (PVs) zu erstellen und zu verwenden, um Daten außerhalb von Containern zu speichern und Datenverlust zu vermeiden.

Der Containerspeicher über das Root-Dateisystem eines Containers ist ephemer und kann beim Löschen und Erstellen von Containern verschwinden. Um einen dauerhaften Speicherort anzugeben und zu verhindern, dass Daten verloren gehen, erstellen und verwenden Sie Persistent Volumes, um Daten außerhalb von Containern zu speichern.

Beim Erstellen eines persistenten Volumes wird in der Kubernetes-Dokumentation Folgendes empfohlen:

  • Immer persistente Volume Claims (PVCs) in Containerkonfigurationen einschließen.
  • Definieren Sie immer eine Standardspeicherklasse für ein Cluster. Andernfalls können PVCs, die keine bestimmte Klasse angeben, nicht erfolgreich ausgeführt werden.
  • Geben Sie Speicherklassen immer aussagekräftige Namen.

Siehe Speicher für Kubernetes-Cluster einrichten.

Best Practice: Volumes dynamisch bereitstellen

Es wird empfohlen, persistente Volumes (PVs), die vom Block Volume-Service unterstützt werden, dynamisch bereitzustellen, anstatt Volumes statisch zu erstellen und zuzuweisen. Die dynamische Bereitstellung von Volumes reduziert den Verwaltungsaufwand und ermöglicht die Skalierung.

Es wird auch empfohlen, eine entsprechende Wiederherstellungs-Policy in Speicherklassendefinitionen aufzunehmen, um unnötige Speicherkosten beim Löschen von Pods zu minimieren.

Beachten Sie, dass das dynamische Provisioning für PVs, die vom File Storage-Service gesichert werden, nicht verfügbar ist.

Siehe PVC mit dem CSI-Volume-Plug-in auf einem Block-Volume erstellen.

Best Practice: Verwenden Sie das CSI-Volume-Plug-in anstelle des Volume-Plug-ins FlexVolume

Wir empfehlen, dass Sie das CSI-Volume-Plug-in verwenden, um persistente Volume-Ansprüche auf dem Block Volume-Service bereitzustellen, anstatt das Volume-Plug-in FlexVolume.

Wir empfehlen das CSI-Volume-Plugin aus folgenden Gründen:

  • Neue Funktionen werden nur dem CSI-Volume-Plug-in hinzugefügt, nicht dem Volume-Plug-in FlexVolume (obwohl Kubernetes-Entwickler das Volume-Plug-in FlexVolume weiterhin verwalten werden).
  • Das CSI-Volume-Plug-in setzt keinen Zugriff auf zugrunde liegende Betriebssystem- und Root-Dateisystemabhängigkeiten voraus.

Die für einen PVC angegebene StorageClass steuert, mit welchem Volume-Plug-in eine Verbindung zu Block Volume-Service-Volumes hergestellt werden soll. Standardmäßig werden zwei Speicherklassen definiert: oci-bv für das CSI-Volume-Plug-in und oci für das FlexVolume-Plug-in. Wenn Sie in der YAML-Datei, die PVCs definiert, keinen Wert für storageClassName explizit angeben, wird die Standardspeicherklasse des Clusters verwendet.

Kubernetes Engine legt zunächst die Standardspeicherklasse eines Clusters entsprechend der Kubernetes-Version fest, die beim Erstellen des Clusters angegeben wurde. In Clustern, die von der Kubernetes-Engine zur Ausführung von Kubernetes-Version 1.24 (oder höher) erstellt wurden, wird die Speicherklasse oci-bv anfänglich als Standard festgelegt.

Siehe PVC auf einem Block-Volume mit dem CSI-Volume-Plug-in erstellen (und Standardwert StorageClass ändern in der Kubernetes-Dokumentation).

Best Practice: Speicherressourcenverbrauch begrenzen

Wir empfehlen Ihnen, die Verwendung von Speicher nach Containern einzuschränken, um die tatsächlich im lokalen Data Center verfügbare Speichermenge oder das für Oracle Cloud-Speicherressourcen verfügbare Budget widerzuspiegeln.

Sie können den Verbrauch von Containerspeicher begrenzen, indem Sie Folgendes verwenden:

  • Ressourcenkontingente, um die Ressourcenmenge (einschließlich Speicher, CPU und Arbeitsspeicher) zu begrenzen, die alle Container in einem Kubernetes-Namespace verwenden können.
  • StorageClasses, um die Speichermenge zu begrenzen, die Containern als Reaktion auf einen Persistent Volume Claim (PVC) bereitgestellt wird.

Siehe Speicher für Kubernetes-Cluster einrichten (und Ressourcen-Quotas in der Kubernetes-Dokumentation).

Best Practice: Daten sichern und sichern

Wir empfehlen Ihnen, geeignete Tools zum Sichern und Sichern von Daten zu verwenden.

Best Practice: Verteiltes Dateisystem für ReadWriteMany-Anwendungsfälle verwenden

Es wird empfohlen, beim Provisioning von PVCs für ReadWriteMany-Anwendungsfälle ein verteiltes Dateisystem (wie NFS oder Oracle Cloud Infrastructure File Storage) zu verwenden.

Block-Volume-Speicher mit leistungsstarken Funktionen (wie Oracle Cloud Infrastructure Block Volume Service) eignet sich besser, wenn PVCs für einzelne Lese- und Schreibanwendungsfälle bereitgestellt werden.

Siehe Speicher für Kubernetes-Cluster einrichten.