Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Cluster-Datenspeicher

Die Fähigkeit, Kubernetes mit einem anderen Datenspeicher als etcd auszuführen, hebt K3s von anderen Kubernetes-Distributionen ab. Dieses Feature bietet Flexibilität für Kubernetes-Betreiber. Die verfügbaren Datenspeicheroptionen ermöglichen es Ihnen, einen Datenspeicher auszuwählen, der am besten zu Ihrem Anwendungsfall passt. Beispiel:

  • Wenn Ihr Team keine Erfahrung im Betrieb von etcd hat, können Sie eine unternehmensgerechte SQL-Datenbank wie MySQL oder PostgreSQL wählen.

  • Wenn Sie einen einfachen, kurzlebigen Cluster in Ihrer CI/CD-Umgebung ausführen müssen, können Sie die eingebettete SQLite-Datenbank verwenden.

  • Wenn Sie Kubernetes am Edge bereitstellen möchten und eine hochverfügbare Lösung benötigen, aber die Betriebskosten für die Verwaltung einer Datenbank am Edge nicht tragen können, können Sie den eingebetteten HA-Datenspeicher von K3s verwenden, der auf dem eingebetteten etcd basiert.

K3s unterstützt die folgenden Datenspeicheroptionen:

  • Eingebettete SQLite
    SQLite kann nicht auf Clustern mit mehreren Servern verwendet werden.
    SQLite ist der Standarddatenspeicher und wird verwendet, wenn keine andere Datenspeicher-Konfiguration vorhanden ist und keine eingebetteten etcd-Datenbankdateien auf der Festplatte vorhanden sind.

  • Eingebettetes etcd
    Siehe die Dokumentation zur hohen Verfügbarkeit von eingebettetetem etcd für weitere Informationen zur Verwendung von eingebettetem etcd mit mehreren Servern. Eingebettetes etcd wird automatisch ausgewählt, wenn K3s so konfiguriert ist, dass ein neues etcd-Cluster initialisiert, einem bestehenden etcd-Cluster beigetreten wird oder wenn etcd-Datenbankdateien während des Starts auf der Festplatte vorhanden sind.

  • Externe Datenbank
    Siehe die Dokumentation zur hohen Verfügbarkeit von externen DB für weitere Informationen zur Verwendung externer Datenspeicher mit mehreren Servern.
    Die folgenden externen Datenspeicher werden unterstützt:

    • etcd (zertifiziert gegen Version 3.5.21)

    • MySQL (zertifiziert für die Versionen 5.7 und 8.0)

    • MariaDB (zertifiziert für die Versionen 10.11 und 11.4)

    • PostgreSQL (zertifiziert für die Versionen 15.12, 16.7 und 17.3)

Unterstützung für vorbereitete Anweisungen

K3s erfordert Unterstützung für vorbereitete Anweisungen von der Datenbank. Das bedeutet, dass Verbindungspooler wie PgBouncer zusätzliche Konfiguration benötigen, um mit K3s zu arbeiten.
Multimaster-Setups

Multi-Master-Datenbanken, bei denen auto_increment_increment oder auto_increment_offset auf einen Wert größer als 1 gesetzt werden, werden nicht unterstützt. Kine erwartet, dass die Revision bei 0 beginnt und immer genau um 1 vorwärts bewegt wird, wenn ein Schlüssel erfolgreich eingefügt wird. Dies betrifft Produkte wie Galera für MySQL/MariaDB.

Externe Datenspeicherkonfigurationsparameter

Wenn Sie einen externen Datenspeicher wie PostgreSQL, MySQL oder etcd verwenden möchten, müssen Sie den datastore-endpoint Parameter festlegen, damit K3s weiß, wie es sich damit verbinden kann. Sie können auch Parameter angeben, um die Authentifizierung und Verschlüsselung der Verbindung zu konfigurieren. Die folgende Tabelle fasst diese Parameter zusammen, die entweder als CLI-Flags oder Umgebungsvariablen übergeben werden können.

CLI-Flag Umgebungsvariable Beschreibung

--datastore-endpoint

K3S_DATASTORE_ENDPOINT

Geben Sie eine Verbindungszeichenfolge für PostgreSQL, MySQL oder etcd an. Dies ist eine Zeichenfolge, die verwendet wird, um die Verbindung zum Datenspeicher zu beschreiben. Die Struktur dieser Zeichenfolge ist spezifisch für jedes Backend und wird im Folgenden detailliert beschrieben.

--datastore-cafile

K3S_DATASTORE_CAFILE

TLS-Zertifizierungsstelle (CA)-Datei, die verwendet wird, um die Kommunikation mit dem Datenspeicher zu sichern. Wenn Ihr Datenspeicher Anfragen über TLS mit einem von einer benutzerdefinierten Zertifizierungsstelle signierten Zertifikat bedient, können Sie diese CA mit diesem Parameter angeben, damit der K3s-Client das Zertifikat ordnungsgemäß überprüfen kann.

--datastore-certfile

K3S_DATASTORE_CERTFILE

TLS-Zertifikatdatei, die für die clientzertifikatbasierte Authentifizierung zu Ihrem Datenspeicher verwendet wird. Um diese Funktion zu nutzen, muss Ihr Datenspeicher so konfiguriert sein, dass er die clientzertifikatbasierte Authentifizierung unterstützt. Wenn Sie diesen Parameter angeben, müssen Sie auch den datastore-keyfile Parameter angeben.

--datastore-keyfile

K3S_DATASTORE_KEYFILE

TLS-Schlüsseldatei, die für die clientzertifikatbasierte Authentifizierung zu Ihrem Datenspeicher verwendet wird. Siehe den vorherigen datastore-certfile Parameter für weitere Details.

Als bewährte Methode empfehlen wir, diese Parameter als Umgebungsvariablen anstelle von Befehlszeilenargumenten festzulegen, damit Ihre Datenbankanmeldeinformationen oder andere sensible Informationen nicht als Teil der Prozessinformationen offengelegt werden.

Format und Funktionalität des Datenspeicherendpunkts

Wie bereits erwähnt, hängt das Format des Wertes, der an den datastore-endpoint Parameter übergeben wird, vom Backend des Datenspeichers ab. Die folgenden Details beschreiben dieses Format und die Funktionalität für jeden unterstützten externen Datenspeicher.

  • PostgreSQL

  • MySQL / MariaDB

  • etcd

In seiner häufigsten Form hat der Datenspeicher-Endpunktparameter für PostgreSQL das folgende Format:

postgres://username:password@hostname:port/database-name

Es sind erweiterte Konfigurationsparameter verfügbar. Für weitere Informationen hierzu siehe bitte https://godoc.org/github.com/lib/pq..

Wenn Sie einen Datenbanknamen angeben und dieser nicht existiert, wird der Server versuchen, ihn zu erstellen.

Wenn Sie nur postgres:// als Endpunkt angeben, wird K3s versuchen, Folgendes zu tun:

  • Mit localhost verbinden, wobei postgres als Benutzername und Passwort verwendet wird.

  • Eine Datenbank mit dem Namen kubernetes erstellen.

In seiner häufigsten Form hat der datastore-endpoint-Parameter für MySQL und MariaDB das folgende Format:

mysql://username:password@tcp(hostname:3306)/database-name

Es sind erweiterte Konfigurationsparameter verfügbar. Für weitere Informationen hierzu siehe bitte https://github.com/go-sql-driver/mysql#dsn-data-source-name.

Bitte beachten Sie, dass aufgrund eines bekannten Problems in K3s der tls Parameter nicht gesetzt werden kann. TLS-Kommunikation wird unterstützt, aber Sie können diesen Parameter beispielsweise nicht auf "skip-verify" setzen, um K3s zu veranlassen, die Zertifikatsüberprüfung zu überspringen.

Wenn Sie einen Datenbanknamen angeben und dieser nicht existiert, wird der Server versuchen, ihn zu erstellen.

Wenn Sie nur mysql:// als Endpunkt angeben, wird K3s versuchen, Folgendes zu tun:

  • Stellen Sie eine Verbindung zum MySQL-Socket unter /var/run/mysqld/mysqld.sock mit dem Benutzer root und ohne Passwort her.

  • Erstellen Sie eine Datenbank mit dem Namen kubernetes

In seiner häufigsten Form hat der datastore-endpoint-Parameter für etcd das folgende Format:

https://etcd-host-1:2379,https://etcd-host-2:2379,https://etcd-host-3:2379\

Das oben Genannte geht von einem typischen etcd-Cluster mit drei Knoten aus. Der Parameter kann eine oder mehrere durch Kommas getrennte etcd-URLs akzeptieren.