Spanner Omni-Bereitstellung aktualisieren

In diesem Dokument wird beschrieben, wie Sie ein Upgrade einer Spanner Omni-Bereitstellung von einer früheren auf eine neuere Version durchführen.

Spanner Omni verwendet einen asynchronen, phasenweisen Roll-out-Zustandsautomaten, um sichere Upgrades ohne Dienstunterbrechung zu gewährleisten. Durch die schrittweise Durchführung des Upgrades haben Sie folgende Möglichkeiten:

• Datenbankschema-Updates anwenden:
• Binärkompatibilität während eines fortlaufenden Neustarts prüfen.
• Führen Sie ein Rollback auf die vorherige Version durch, wenn Sie vor der Finalisierung Fehler feststellen.

Workflow für das Upgrade

Der Spanner Omni-Upgradeprozess besteht aus mehreren sequenziellen Phasen:

1. Schema-Phase: Bereitet die Bereitstellung vor, indem interne Datenbankmigrationsschemata mit der Zielbinärversion ausgeführt werden. Schema-Migrationen können nicht rückgängig gemacht werden, sind aber abwärtskompatibel mit der vorherigen binären Version.
2. Binärphase: Aktualisiert das Server-Binärprogramm oder das Container-Image auf allen Servern im Deployment mithilfe eines Rolling Restart. Wenn Sie Fehler feststellen, können Sie das Binär- oder Container-Image jederzeit auf die frühere Version zurücksetzen, bevor die Finalisierung beginnt.
3. Phase „Funktionen aktivieren“: Aktiviert versionskompatible Funktionen und beginnt, nachdem Sie das Binärprogramm auf allen Servern aktualisiert haben. Diese Phase ist möglicherweise nicht erforderlich, wenn das Upgrade keine versionskompatiblen Funktionen enthält. Sie kann mehrere Runden erfordern, wenn Funktionen voneinander abhängig sind. Für optionale Phasen, die Rollback unterstützen, können Sie ein Rollback mit der Spanner Omni CLI initiieren.
4. Abschlussphase: Der Roll-out wird abgeschlossen und die Zielversion wird festgelegt. Nach Beginn der Finalisierungsphase sind keine Rollbacks mehr möglich.

Hinweis

Bevor Sie Ihre Spanner Omni-Bereitstellung aktualisieren, müssen Sie die folgenden Voraussetzungen erfüllen:

• Sie haben eine laufende Spanner Omni-Bereitstellung. Weitere Informationen finden Sie unter Bereitstellung in Kubernetes erstellen oder Bereitstellung auf VMs erstellen.
• Sie haben die Spanner Omni CLI heruntergeladen und installiert.
• Sie haben Netzwerkzugriff auf alle internen Spanner Omni-Ports (TCP 15000 bis 15027) von dem Computer, auf dem Sie die CLI-Befehle ausführen, oder Netzwerkzugriff auf den Bereitstellungsendpunkt.
• Wenn in Ihrer Bereitstellung Transport Layer Security (TLS) oder gegenseitige TLS-Verschlüsselung (mTLS) verwendet wird, müssen gültige Zertifikate in Ihrem Basisverzeichnis unter BASE_DIR/tls verfügbar sein oder in Ihrem Cluster bereitgestellt werden.
• Sie haben die Zielversion angegeben:
  • Für VM-Bereitstellungen: Laden Sie das Zielreleasepaket spanner-omni-server-TARGET_VERSION.tar.gz herunter.
  • Für Helm- und Kubernetes-Bereitstellungen: Identifizieren Sie das Zielcontainer-Image in Artifact Registry, z. B. us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION.

Schritt 1: Schema-Upgrade vorbereiten

Um das Upgrade zu starten, bereiten Sie den Roll-out für die Zielversion vor. In dieser Phase führt Spanner Omni interne Migrationen des Datenbankschemas durch, während vorhandene Server weiterhin Traffic bereitstellen.

Wählen Sie den Tab für Ihre Bereitstellungsumgebung aus:

VM

Laden Sie bei VM-Bereitstellungen das Ziel-Release-Paket herunter und extrahieren Sie es. Verwenden Sie dann die extrahierte Spanner Omni-CLI, um die Rollout-Vorbereitung zu starten.

Wichtig: Das Ziel-Releasepaket für Spanner Omni enthält sowohl die spanner-CLI als auch die spanner_server-Binärdatei (in der Regel unter bin/). Laden Sie das Ziel-Releasepaket auf den Host herunter und entpacken Sie es, bevor Sie die Vorbereitungsphase ausführen.

1. Melden Sie sich auf einem Server in Ihrer Bereitstellung an, der Netzwerkzugriff auf alle internen Ports von Spanner Omni (TCP 15000 bis 15027) hat.

2. Laden Sie das Ziel-Release-Paket herunter und extrahieren Sie es:

   tar -xzf spanner-omni-server-TARGET_VERSION.tar.gz -C EXTRACT_DIR
   

   Ersetzen Sie Folgendes:

   • TARGET_VERSION: Die Zielversion, auf die aktualisiert werden soll, z. B. 2026.r4-lts.
   • EXTRACT_DIR: Das Verzeichnis, in das Sie das Release-Paket extrahieren, z. B. /tmp/target_spanner/.

3. Starten Sie die Vorbereitung des Roll-outs, indem Sie den Befehl rollouts prepare über die extrahierte CLI ausführen:

   EXTRACT_DIR/bin/spanner deployment rollouts prepare \
     --target-server-binary=EXTRACT_DIR/bin/spanner_server \
     --root-server=ROOT_SERVERS \
     --base-dir=BASE_DIR
   

   Ersetzen Sie Folgendes:

   • EXTRACT_DIR: Das Extraktionsverzeichnis mit der Ziel-bin/spanner-CLI und dem bin/spanner_server-Binärprogramm.
   • ROOT_SERVERS: Ein Stammserverendpunkt oder eine durch Kommas getrennte Liste mit mehreren Stammservern, z. B. localhost:15000 oder server1:15000,server2:15000,server3:15000.
   • BASE_DIR: Das Basisverzeichnis für Spanner Omni, z. B. /spanner.
   • Wenn in Ihrer Bereitstellung TLS- oder mTLS-Verschlüsselung verwendet wird, hängen Sie --ca-certificate-file=CA_CERT_FILE und --client-certificate-directory=CERT_DIR an, die auf gültige Zertifikate verweisen.

Helm

Bei Helm-Bereitstellungen hängt die Schemavorbereitung davon ab, ob Sie eine Bereitstellung mit mehreren Servern oder mit einem einzelnen Server ausführen:

• Bereitstellungen auf mehreren Servern (Hochverfügbarkeit / Produktion): Helm übernimmt automatisch die Vorbereitung des Schemas. Wenn Sie helm upgrade in Schritt 3: Binärdatei oder Container-Image aktualisieren ausführen, löst das Helm-Diagramm den spanner-prepare-for-upgrade-Hook-Job vor dem Upgrade aus, um Schemamigrationen auszuführen, bevor StatefulSets aktualisiert werden. Fahren Sie direkt mit Schritt 2: Aktiven Roll-out-Status prüfen fort.

• Bereitstellungen auf einem einzelnen Server (deployment.singleServer=true): Da im Einzelservermodus interne Dienste streng an die Loopback-Schnittstelle (127.0.0.1) gebunden sind, können Netzwerkjobs nicht auf sie zugreifen. Führen Sie die Schemamigration lokal im laufenden Pod mit einem kurzlebigen Debug-Container mit dem Ziel-Container-Image aus:

  kubectl debug pod/POD_NAME -n NAMESPACE \
    --image=us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION \
    --container=upgrade-prepare -i \
    -- /google/spanner/bin/spanner_server prepare_for_upgrade --root_server=127.0.0.1
  

  Ersetzen Sie Folgendes:

  • POD_NAME: Der Name des Server-Pods, z. B. spanner-a-0.
  • NAMESPACE: Der Kubernetes-Namespace der Bereitstellung, z. B. spanner-ns.
  • TARGET_VERSION: Die Zielversion, auf die aktualisiert werden soll, z. B. 2026.r4-lts.

Eigenständiges Kubernetes

Wenn Sie Spanner Omni in Kubernetes ohne Helm bereitstellen, führen Sie einen eigenständigen Kubernetes-Batchjob aus, um Schemamigrationen für den aktiven Stammserver mit dem Ziel-Image auszuführen.

1. Erstellen Sie eine Datei mit dem Namen spanner-prepare-upgrade.yaml und dem folgenden Job-Manifest:

   apiVersion: batch/v1
   kind: Job
   metadata:
     namespace: NAMESPACE
     name: spanner-prepare-for-upgrade
   spec:
     # Fail fast on the first error to stop the rollout immediately.
     backoffLimit: 0
     template:
       metadata:
         namespace: NAMESPACE
       spec:
         restartPolicy: Never
         containers:
           - name: spanner-upgrade
             image: us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION
             command: ["/google/spanner/bin/spanner_server"]
             args:
               - "prepare_for_upgrade"
               - "--root_server=ROOT_SERVER_ENDPOINT"
             volumeMounts:
               - name: tls-certs
                 mountPath: "/spanner/tls"
                 readOnly: true
               - name: spanner-data
                 mountPath: /spanner
         volumes:
           - name: tls-certs
             secret:
               secretName: tls-certs
               optional: true
               defaultMode: 256
           - name: spanner-data
             emptyDir: {}
   

   Ersetzen Sie Folgendes:

   • NAMESPACE: Der Kubernetes-Namespace der Bereitstellung, z. B. spanner-ns.
   • TARGET_VERSION: Die Zielversion, auf die aktualisiert werden soll, z. B. 2026.r4-lts.
   • ROOT_SERVER_ENDPOINT: Der Endpunkt eines aktiven Root-Server-Pods, z. B. spanner-a-0.pod.spanner-ns.

2. Wenden Sie das Manifest an, um den Vorbereitungsjob auszuführen:

   kubectl apply -f spanner-prepare-upgrade.yaml
   

Schritt 2: Aktiven Roll-out-Status prüfen

Prüfen Sie nach Abschluss des Vorbereitungsschritts, ob die Einführung erstellt wurde, und sehen Sie sich den Phasenstatus an.

Hinweis: Bei Helm-Bereitstellungen mit mehreren Servern erstellt Helm den Rollout während helm upgrade in Schritt 3. Sie können den Rollout-Status während oder nach der Ausführung dieses Schritts überprüfen.

1. Listen Sie die aktiven Roll-outs auf, um die Roll-out-ID abzurufen:

   spanner deployment rollouts list \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   Ersetzen Sie DEPLOYMENT_ENDPOINT durch den Endpunkt eines Servers in Ihrem Deployment, z. B. localhost:15000 oder spanner-a-0.pod.spanner-ns:15000.

   Die Ausgabe sieht etwa so aus:

   NAME                         STATE          TARGET_VERSION    START_TIME                     END_TIME
   rollouts/1788942172101727    IN_PROGRESS    2026.r3-beta      2026-09-09T08:22:52.101727Z    -
   

2. Detaillierten Status der Roll-out-Phase ansehen:

   spanner deployment rollouts describe ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   Ersetzen Sie Folgendes:

   • ROLLOUT_ID: Die numerische Rollout-ID, z. B. 1788942172101727.
   • DEPLOYMENT_ENDPOINT: Der Endpunkt eines Servers in Ihrer Bereitstellung.

   Die Ausgabe sieht etwa so aus:

   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: IN_PROGRESS
       - name: rollouts/1788942172101727/phases/finalize
         state: PENDING
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: IN_PROGRESS
   targetVersion: 2026.r3-beta
   

   Prüfen Sie die folgenden Phasenstatus, bevor Sie fortfahren:

   • schema: Zeigt SUCCEEDED an, was darauf hinweist, dass die Migrationen des internen Datenbankschemas abgeschlossen sind.
   • binary: Zeigt IN_PROGRESS an. Das bedeutet, dass die Rollout-Engine für Binärupdates bereit ist.
   • finalize: Zeigt PENDING an, bis die Binärphase abgeschlossen ist.

Schritt 3: Binärdatei oder Container-Image aktualisieren

Aktualisieren Sie nach erfolgreicher Schemaphase die laufende Serverbinärdatei oder das Container-Image auf allen Knoten der Bereitstellung auf die Zielversion.

Tipp: Wenn Sie Fehler oder Leistungseinbußen feststellen, können Sie das Binär- oder Container-Image jederzeit vor der Finalisierung auf die vorherige Version zurücksetzen. Weitere Informationen finden Sie unter Upgrade zurücksetzen.

Wählen Sie den Tab für Ihre Bereitstellungsumgebung aus:

VM

Aktualisieren Sie bei VM-Bereitstellungen die spanner_server-Binärdatei auf allen VMs mit einem rollierenden Neustart:

• Eine Fehlerdomain oder Zone nach der anderen aktualisieren: Aktualisieren Sie in Bereitstellungen mit mehreren Zonen die Server in einer Zone und prüfen Sie die Stabilität, bevor Sie die nächste Zone aktualisieren. So wird sichergestellt, dass die Paxos-Konsensgruppe das Quorum beibehält.
• Progressiv neu starten: Starten Sie nicht mehr als 5% der Server gleichzeitig neu, um die kontinuierliche Verfügbarkeit von Anfragen aufrechtzuerhalten.
• Serverstatus prüfen: Prüfen Sie, ob alle neu gestarteten Server fehlerfrei sind und dem Cluster wieder beigetreten sind, bevor Sie die nächste Fehlerdomain aktualisieren.

Helm

Führen Sie bei Helm-Bereitstellungen helm upgrade aus und behalten Sie Ihre vorhandenen Konfigurationswerte bei, indem Sie --reuse-values übergeben oder eine Datei mit Werten angeben:

• Bereitstellungen auf mehreren Servern (Produktion / HA):

  helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
    --version CHART_VERSION \
    -n NAMESPACE \
    --reuse-values \
    --set image.tag=TARGET_VERSION \
    --timeout 30m
  

  Helm führt Phase 1 automatisch mit dem Pre-Upgrade-Hook aus und startet dann ein sequenzielles, zonenweises Rolling Update der StatefulSets (rollout.staggered: true).

• Bereitstellungen auf einem einzelnen Server (deployment.singleServer=true):

  Übergeben Sie --set skipPrepareUpgrade=true explizit, damit Helm den Pre-Upgrade-Hook-Job überspringt, da Sie Phase 1 bereits lokal abgeschlossen haben:

  helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
    --version CHART_VERSION \
    -n NAMESPACE \
    --reuse-values \
    --set skipPrepareUpgrade=true \
    --set image.tag=TARGET_VERSION \
    --timeout 30m
  

Ersetzen Sie Folgendes:

• CHART_VERSION: Die Zielversion des Helm-Diagramms, z. B. 1.0.0.
• NAMESPACE: Der Kubernetes-Namespace der Bereitstellung, z. B. spanner-ns.
• TARGET_VERSION: Das Tag des Zielcontainer-Images, z. B. 2026.r4-lts.

Eigenständiges Kubernetes

Aktualisieren Sie bei benutzerdefinierten Kubernetes-Bereitstellungen ohne Helm das Container-Image in den Spezifikationen von StatefulSet oder Deployment auf TARGET_VERSION.

Führen Sie ein Rolling Update über Fehlerdomains hinweg durch, indem Sie jeweils eine Zone aktualisieren und nicht mehr als 5% der Pods gleichzeitig neu starten, um das Quorum aufrechtzuerhalten.

Schritt 4: Binärphasenfortschritt prüfen

Nachdem Sie alle Server oder Pods auf die Zielversion aktualisiert haben, prüfen Sie, ob die binäre Phase erfolgreich abgeschlossen wurde.

Hinweis: Nachdem alle Server in der Bereitstellung aktualisiert wurden, verfolgt Spanner Omni den Serverstatus über einen Beobachtungszeitraum von bis zu 15 Minuten, bevor die Phase binary als SUCCEEDED markiert wird.

Status der Roll-out-Phase prüfen:

spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

Ersetzen Sie Folgendes:

• ROLLOUT_ID: Die numerische Rollout-ID, z. B. 1788942172101727.
• DEPLOYMENT_ENDPOINT: Der Endpunkt eines Servers in Ihrer Bereitstellung.

Die Ausgabe sieht etwa so aus:

name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/finalize
      state: PENDING
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: IN_PROGRESS
targetVersion: 2026.r3-beta

Prüfen Sie, ob sich der Status der Phase binary in SUCCEEDED ändert. Der allgemeine Roll-out-Status bleibt IN_PROGRESS, bis alle verbleibenden Phasen abgeschlossen sind. Nachdem phases/binary in SUCCEEDED übergegangen ist, kann die Bereitstellung mit den verbleibenden Phasen fortgesetzt werden.

Schritt 5: Verbleibende Phasen planen und ausführen

Wenn die Binärphase erfolgreich ist und Sie bestätigen, dass Ihr Deployment stabil ist, planen Sie die verbleibenden Phasen für die Einführung bis zur Phase finalize. In der finalize-Phase (der letzten Phase eines Rollouts) wird die neue Version für die Bereitstellung freigegeben. Sie können diesen Befehl auf jedem Computer ausführen, der Netzwerkzugriff auf den Spanner Omni-Dienst hat, indem Sie --deployment-endpoint angeben.

Achtung: Ein Rollback ist nicht möglich, nachdem die Finalisierung begonnen hat. Schließen Sie die Einführung erst ab, wenn Sie die Bereitstellung ausreichend lange beobachtet und bestätigt haben, dass sie unter typischen Arbeitslasten stabil und fehlerfrei ist. Weitere Informationen finden Sie unter Upgrade zurücksetzen.

Führen Sie für jede verbleibende Phase im Status PENDING (z. B. enable_features, falls vorhanden, gefolgt von finalize) die folgenden Schritte aus:

1. Phase planen:

   spanner deployment rollouts phases schedule PHASE_NAME \
     --rollout=ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   Ersetzen Sie Folgendes:

   • PHASE_NAME: Der Name der zu planenden Phase, z. B. finalize oder enable_features.
   • ROLLOUT_ID: Die numerische Rollout-ID, z. B. 1788942172101727.
   • DEPLOYMENT_ENDPOINT: Der Endpunkt eines Servers in Ihrer Bereitstellung.

   Die Ausgabe gibt an, dass die geplante Phase IN_PROGRESS ist:

   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/finalize
         state: IN_PROGRESS
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: IN_PROGRESS
   targetVersion: 2026.r3-beta
   

2. Warten Sie, bis die Phase abgeschlossen ist, und prüfen Sie ihren Status:

   spanner deployment rollouts describe ROLLOUT_ID \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   Wiederholen Sie diese Schritte für jede verbleibende Phase, bis alle Phasen bis einschließlich finalize abgeschlossen sind.

   Nach Abschluss der letzten Phase (finalize) werden alle Phasen und der gesamte Roll-out-Status in SUCCEEDED geändert:

   endTime: "2026-09-09T08:45:43.949702Z"
   name: rollouts/1788942172101727
   phases:
       - name: rollouts/1788942172101727/phases/schema
         startTime: "2026-09-09T08:22:52.101727Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/binary
         startTime: "2026-09-09T08:23:29.585375Z"
         state: SUCCEEDED
       - name: rollouts/1788942172101727/phases/finalize
         startTime: "2026-09-09T08:45:43.898111Z"
         state: SUCCEEDED
   sourceVersion: 2026.r2-beta.3
   startTime: "2026-09-09T08:22:52.101727Z"
   state: SUCCEEDED
   targetVersion: 2026.r3-beta
   

3. Prüfen Sie in der Liste der Roll-outs, ob der Status „Abgeschlossen“ angezeigt wird:

   spanner deployment rollouts list \
     --deployment-endpoint=DEPLOYMENT_ENDPOINT
   

   Die Ausgabe bestätigt, dass die Einführung abgeschlossen ist:

   NAME                         STATE        TARGET_VERSION    START_TIME                     END_TIME
   rollouts/1788942172101727    SUCCEEDED    2026.r3-beta      2026-09-09T08:22:52.101727Z    2026-09-09T08:45:43.949702Z
   

Rollback eines Upgrade durchführen

Ob Sie ein Upgrade zurücksetzen können, hängt von der aktuellen Roll-out-Phase ab:

• Schema-Phase: kann nicht rückgängig gemacht werden. Interne Datenbankmigrations, die während der Vorbereitung angewendet werden, sind nur vorwärts gerichtet und können nicht rückgängig gemacht werden. Schemamigrationen sind jedoch abwärtskompatibel mit der Quellversion, sodass frühere Server-Binärdateien weiterhin normal funktionieren.
• Binärphase: Ein Rollback zur vorherigen Version ist jederzeit möglich, bevor die Finalisierung beginnt. Weitere Informationen finden Sie unter Binärdatei oder Container-Image zurücksetzen.
• Optionale Einführungsphasen: Bei optionalen Phasen, die automatisches Rollback unterstützen (z. B. Aktivierung von Funktionen), initiieren Sie das Rollback mit der Spanner Omni CLI.
• Abschlussphase: kann nicht rückgängig gemacht werden. Sobald die Finalisierung beginnt, ist die Zielversion für die Bereitstellung dauerhaft festgelegt und Rollbacks sind nicht mehr möglich.

Binärdatei oder Container-Image zurücksetzen

Wenn Sie die binäre Phase zurücksetzen möchten, bevor die Finalisierung beginnt, führen Sie einen rollierenden Neustart auf allen Servern oder Pods durch, um die frühere (Quell-)Version wiederherzustellen.

VM

Führen Sie bei VM-Bereitstellungen ein Rollback der spanner_server-Binärdatei auf allen VMs durch:

1. Stellen Sie die frühere Binärdatei spanner_server auf Ihren Hosts bereit.
2. Server werden nach und nach in den Fehlerdomains neu gestartet. Dabei wird jeweils nur eine Zone aktualisiert und es werden nicht mehr als 5% der Server gleichzeitig neu gestartet, um das Paxos-Quorum aufrechtzuerhalten.
3. Prüfen Sie, ob alle neu gestarteten Server fehlerfrei sind und dem Cluster wieder beigetreten sind, bevor Sie mit der nächsten Fehlerdomain fortfahren.

Helm

Aktualisieren Sie in Helm-Bereitstellungen das Container-Image-Tag wieder auf die vorherige Version:

helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
  --version CHART_VERSION \
  -n NAMESPACE \
  --reuse-values \
  --set image.tag=SOURCE_VERSION \
  --timeout 30m

Ersetzen Sie Folgendes:

• CHART_VERSION: Die Helm-Diagrammversion, z. B. 1.0.0.
• NAMESPACE: Der Kubernetes-Namespace der Bereitstellung, z. B. spanner-ns.
• SOURCE_VERSION: Das frühere Container-Image-Tag, zu dem zurückgekehrt werden soll, z. B. 2026.r2-beta.3.

Eigenständiges Kubernetes

Aktualisieren Sie in benutzerdefinierten Kubernetes-Bereitstellungen ohne Helm das Container-Image in den Spezifikationen von StatefulSet oder Deployment wieder auf SOURCE_VERSION.

Führen Sie ein Rolling Update über Fehlerdomains hinweg durch, indem Sie jeweils eine Zone aktualisieren und nicht mehr als 5% der Pods gleichzeitig neu starten, um das Quorum aufrechtzuerhalten.

Rollback für optionale Roll-out-Phasen durchführen

Bei optionalen Roll-out-Phasen, die das Zurücksetzen unterstützen (z. B. Phasen zur Aktivierung von Funktionen), starten Sie das Zurücksetzen mit dem Befehl rollouts rollback:

spanner deployment rollouts rollback ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

Ersetzen Sie Folgendes:

• ROLLOUT_ID: Die numerische Rollout-ID.
• DEPLOYMENT_ENDPOINT: Der Endpunkt eines Servers in Ihrer Bereitstellung.

Nächste Schritte

• Bereitstellung verwalten
• Kubernetes-Deployment skalieren oder VM-Deployment skalieren
• Übersicht über Monitoring