‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שדרוג פריסה של Spanner Omni

במאמר הזה מוסבר איך לשדרג פריסת Spanner Omni מגרסה קודמת לגרסה חדשה יותר.

‫Spanner Omni משתמש במכונת מצבים אסינכרונית ובהשקה מדורגת כדי לוודא שהשדרוגים בטוחים ולא גורמים להפרעה בשירות. שדרוג בשלבים מאפשר לכם:

החלת עדכונים בסכימת מסד הנתונים.
מאמתים את התאימות הבינארית במהלך הפעלה מחדש מתגלגלת.
חזרה לגרסה קודמת אם מזהים שגיאות לפני השלמת התהליך.

תהליך השדרוג

תהליך השדרוג של Spanner Omni מורכב מכמה שלבים עוקבים:

שלב הסכימה: הכנת הפריסה על ידי הפעלת העברות של סכימת מסד נתונים פנימי באמצעות גרסת הקובץ הבינארי של היעד. אי אפשר לבטל העברות של סכימות, אבל הן תואמות לגרסה הבינארית הקודמת.
שלב בינארי: עדכון של הקובץ הבינארי של השרת או של קובץ האימג' של הקונטיינר בכל השרתים בפריסה באמצעות הפעלה מחדש מתגלגלת. אם מזהים שגיאות, אפשר לבטל את השינוי של הקובץ הבינארי או של קובץ אימג' של קונטיינר ולחזור לגרסה הקודמת בכל שלב לפני תחילת השלמת התהליך.
שלב הפעלת התכונות: בשלב הזה מופעלות תכונות שתואמות לגרסה, והוא מתחיל אחרי שמשדרגים את הקובץ הבינארי בכל השרתים. יכול להיות שהשלב הזה לא יחול אם השדרוג לא כולל תכונות שתואמות לגרסה, ויכול להיות שיידרשו כמה סבבים אם התכונות תלויות זו בזו. בשלבים אופציונליים שתומכים בהחזרה למצב הקודם, אפשר להפעיל החזרה למצב הקודם באמצעות Spanner Omni CLI.
שלב ההשלמה: השלב שבו משלימים את ההשקה ומגדירים את גרסת היעד. אחרי שתהליך הסיום יתחיל, לא תהיה אפשרות לבצע החזרה לאחור.

לפני שמתחילים

לפני שמשדרגים את הפריסה של Spanner Omni, צריך לוודא שמתקיימים התנאים המוקדמים הבאים:

יש לכם פריסה פעילה של Spanner Omni. מידע נוסף זמין במאמרים יצירת פריסה ב-Kubernetes או יצירת פריסה במכונות וירטואליות.
הורדתם והתקנתם את Spanner Omni CLI.
יש לכם גישה לרשת לכל הפורטים הפנימיים של Spanner Omni‏ (TCP 15000 עד 15027) מהמכונה שבה אתם מריצים את פקודות ה-CLI, או גישה לרשת לנקודת הקצה של הפריסה.
אם הפריסה שלכם משתמשת בהצפנה מסוג Transport Layer Security ‏ (TLS) או mutual TLS ‏ (mTLS), צריך לוודא שיש אישורים תקפים בספריית הבסיס שלכם בתיקייה BASE_DIR/tls או שהם מותקנים באשכול.
זיהיתם את גרסת היעד:
- לפריסות של מכונות וירטואליות: מורידים את חבילת הגרסה של היעד spanner-omni-server-TARGET_VERSION.tar.gz.
- בפריסות של Helm ו-Kubernetes: מזהים את תמונת מאגר היעד ב-Artifact Registry, למשל us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION.

שלב 1: מכינים את שדרוג הסכימה

כדי להתחיל את השדרוג, צריך להכין את ההשקה לגרסת היעד. בשלב הזה, Spanner Omni מריץ העברות פנימיות של סכימת מסד הנתונים, בזמן שהשרתים הקיימים ממשיכים להציג תנועה.

בוחרים את הכרטיסייה של סביבת הפריסה:

VM

בפריסות של מכונות וירטואליות, מורידים את חבילת הגרסה הרצויה ומחלצים אותה, ואז משתמשים ב-CLI של Spanner Omni שחולץ כדי להתחיל בהכנות להשקה.

נכנסים לשרת בפריסה שיש לו גישה לרשת לכל היציאות הפנימיות של Spanner Omni‏ (TCP 15000 עד 15027).
מורידים ומחלצים את חבילת גרסת היעד:
```
tar -xzf spanner-omni-server-TARGET_VERSION.tar.gz -C EXTRACT_DIR
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה, 2026.r4-lts.
- ‫EXTRACT_DIR: הספרייה שבה חילצתם את חבילת הגרסה, לדוגמה /tmp/target_spanner/.
מריצים את הפקודה rollouts prepare מתוך ה-CLI שחולץ כדי להתחיל בהכנות להשקה:
```
EXTRACT_DIR/bin/spanner deployment rollouts prepare \
  --target-server-binary=EXTRACT_DIR/bin/spanner_server \
  --root-server=ROOT_SERVERS \
  --base-dir=BASE_DIR
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫EXTRACT_DIR: ספריית החילוץ שמכילה את קובץ ה-CLI של bin/spanner ואת הקובץ הבינארי של bin/spanner_server.
- ‫ROOT_SERVERS: נקודת קצה של שרת בסיס אחד או רשימה מופרדת בפסיקים של כמה שרתי בסיס, לדוגמה, localhost:15000 או server1:15000,server2:15000,server3:15000.
- ‫BASE_DIR: ספריית הבסיס של Spanner Omni, לדוגמה, /spanner.
- אם הפריסה משתמשת בהצפנת TLS או mTLS, מוסיפים את --ca-certificate-file=CA_CERT_FILE ואת --client-certificate-directory=CERT_DIR שמפנים לאישורים תקפים.

Helm

בפריסות של Helm, הכנת הסכימה תלויה בסוג הפריסה שמריצים: פריסה של כמה שרתים או פריסה של שרת יחיד:

פריסות של כמה שרתים (זמינות גבוהה / ייצור): ‫Helm מטפל אוטומטית בהכנת הסכימה. כשמריצים את הפקודה helm upgrade בשלב 3: עדכון הקובץ הבינארי או קובץ אימג' של קונטיינר, תרשים Helm מפעיל את משימת ה-hook spanner-prepare-for-upgrade pre-upgrade כדי להריץ העברות סכימה לפני עדכון של StatefulSets. אפשר לעבור ישירות אל שלב 2: בדיקת סטטוס ההשקה הפעיל.
פריסות של שרת יחיד (deployment.singleServer=true): מכיוון שמצב שרת יחיד קושר שירותים פנימיים באופן קפדני לממשק הלולאה החוזרת (127.0.0.1), משימות רשת לא יכולות להגיע אליהם. מריצים את העברת הסכימה באופן מקומי בתוך הפוד הפועל באמצעות קונטיינר זמני לניפוי באגים עם קובץ האימג' של היעד:
```
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
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POD_NAME: השם של פוד השרת, לדוגמה, spanner-a-0.
- ‫NAMESPACE: מרחב השמות של Kubernetes בפריסה. לדוגמה, spanner-ns.
- ‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה 2026.r4-lts.

‫Kubernetes עצמאי

אם אתם פורסים את Spanner Omni ב-Kubernetes בלי Helm, מריצים משימת אצווה עצמאית של Kubernetes כדי לבצע העברות סכימה מול שרת הבסיס הפעיל באמצעות תמונת היעד.

יוצרים קובץ בשם spanner-prepare-upgrade.yaml עם מניפסט העבודה הבא:

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: {}

מחליפים את מה שכתוב בשדות הבאים:

‫NAMESPACE: מרחב השמות של Kubernetes בפריסה. לדוגמה, spanner-ns.
‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה 2026.r4-lts.
‫ROOT_SERVER_ENDPOINT: נקודת הקצה של פוד שרת שורש פעיל, לדוגמה, spanner-a-0.pod.spanner-ns.

מחילים את המניפסט כדי להריץ את עבודת ההכנה:
```
kubectl apply -f spanner-prepare-upgrade.yaml
```

שלב 2: בודקים את סטטוס ההשקה הפעיל

אחרי ששלב ההכנה מסתיים, בודקים שההשקה נוצרה ומסתכלים על סטטוס השלב שלה.

כדי לאחזר את מזהה הפריסה, מציגים את רשימת הפריסות הפעילות:
```
spanner deployment rollouts list \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT
```
מחליפים את DEPLOYMENT_ENDPOINT בנקודת הקצה של שרת בפריסה, לדוגמה, localhost:15000 או spanner-a-0.pod.spanner-ns:15000.

הפלט אמור להיראות כך:
```
NAME                         STATE          TARGET_VERSION    START_TIME                     END_TIME
rollouts/1788942172101727    IN_PROGRESS    2026.r3-beta      2026-09-09T08:22:52.101727Z    -
```
בודקים את הסטטוס המפורט של שלב ההשקה:
```
spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROLLOUT_ID: מזהה ההשקה המספרי, לדוגמה, 1788942172101727.
- ‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.
הפלט אמור להיראות כך:
```
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
```
לפני שממשיכים, צריך לוודא שסטטוס השלב הוא:
- schema: מוצג SUCCEEDED, שמציין שההעברות של סכימת מסד הנתונים הפנימי הסתיימו.
- ‫binary: מוצג IN_PROGRESS, שמציין שמנוע ההפצה מוכן לעדכונים בינאריים.
- ‫finalize: מוצג PENDING, בהמתנה לסיום השלב הבינארי.

שלב 3: מעדכנים את הקובץ הבינארי או את קובץ האימג' של הקונטיינר

אחרי ששלב הסכימה מסתיים בהצלחה, מעדכנים את הקובץ הבינארי או את תמונת הקונטיינר של השרת הפועל בכל הצמתים בפריסה לגרסת היעד.

בוחרים את הכרטיסייה של סביבת הפריסה:

VM

בפריסות של מכונות וירטואליות, מעדכנים את הקובץ הבינארי spanner_server בכל המכונות הווירטואליות באמצעות הפעלה מחדש מתגלגלת:

עדכון של אזור או דומיין כשל אחד בכל פעם: בפריסות מרובות אזורים, צריך לעדכן את השרתים באזור אחד ולאמת את היציבות לפני שמעדכנים את האזור הבא. כך אפשר לוודא שקבוצת ההסכמה של Paxos תשמור על קוורום.
הפעלה מחדש הדרגתית: מפעילים מחדש עד 5% מהשרתים בו-זמנית כדי לשמור על זמינות רציפה של השאילתות.
אימות תקינות השרת: מוודאים שכל השרתים שהופעלו מחדש תקינים ושחזרו לאשכול לפני שמעדכנים את דומיין הכשל הבא.

Helm

בפריסות של Helm, מריצים את הפקודה helm upgrade תוך שמירה על ערכי ההגדרות הקיימים באמצעות העברת --reuse-values או באמצעות קובץ ערכים:

פריסות של כמה שרתים (ייצור / זמינות גבוהה):
```
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 מריץ אוטומטית את שלב 1 באמצעות ה-hook שלפני השדרוג, ואז מתחיל עדכון הדרגתי רציף של StatefulSets (rollout.staggered: true) באזורים.
פריסות של שרת יחיד (deployment.singleServer=true):

צריך להעביר באופן מפורש את --set skipPrepareUpgrade=true כדי שמשימת ה-hook שלפני השדרוג תדלג על Helm, כי כבר השלמתם את שלב 1 באופן מקומי:
```
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
```

מחליפים את מה שכתוב בשדות הבאים:

‫CHART_VERSION: גרסת תרשים Helm של היעד, לדוגמה, 1.0.0.
‫NAMESPACE: מרחב השמות של Kubernetes בפריסה. לדוגמה, spanner-ns.
‫TARGET_VERSION: תג קובץ האימג' של הקונטיינר, לדוגמה, 2026.r4-lts.

‫Kubernetes עצמאי

בפריסות מותאמות אישית של Kubernetes ללא Helm, מעדכנים את קובץ האימג' של הקונטיינר במפרטים של StatefulSet או Deployment ל-TARGET_VERSION.

מבצעים עדכון בהדרגה (rolling) בדומיינים של כשלים, מעדכנים אזור אחד בכל פעם ומפעילים מחדש עד 5% מה-Pods בו-זמנית כדי לשמור על קוורום.

שלב 4: בדיקת ההתקדמות של השלב הבינארי

אחרי שמעדכנים את כל השרתים או הפודים לגרסת היעד, צריך לוודא שהשלב הבינארי מסתיים בהצלחה.

בודקים את הסטטוס של שלב ההשקה:

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

מחליפים את מה שכתוב בשדות הבאים:

‫ROLLOUT_ID: מזהה ההשקה המספרי, לדוגמה, 1788942172101727.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

הפלט אמור להיראות כך:

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

מוודאים שהסטטוס של שלב binary משתנה לSUCCEEDED. המצב הכללי של ההשקה יישאר IN_PROGRESS עד שכל השלבים שנותרו יושלמו. אחרי שסטטוס הפריסה משתנה מ-phases/binary ל-SUCCEEDED, אפשר להמשיך לשלבים הבאים.

שלב 5: מתזמנים ומבצעים את השלבים שנותרו

אם שלב הבינארי עובר בהצלחה ומוודאים שהפריסה יציבה, מתזמנים את השלבים הנותרים של ההשקה עד לשלב finalize. בשלב finalize (השלב האחרון בהשקה), הגרסה החדשה נסגרת בכל הפריסה. אפשר להריץ את הפקודה הזו מכל מכונה שיש לה גישה לרשת לשירות Spanner Omni, על ידי ציון --deployment-endpoint.

לכל שלב שנותר במצב PENDING (למשל enable_features אם הוא קיים, ואז finalize), מבצעים את השלבים הבאים:

תזמון השלב:

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

מחליפים את מה שכתוב בשדות הבאים:

‫PHASE_NAME: השם של השלב שרוצים לתזמן, לדוגמה, finalize או enable_features.
‫ROLLOUT_ID: מזהה ההשקה המספרי, לדוגמה, 1788942172101727.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

הפלט מציין שהשלב המתוזמן הוא IN_PROGRESS:

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

מחכים שהשלב יסתיים בהצלחה, ובודקים את הסטטוס שלו:

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

חוזרים על השלבים האלה לכל שלב שנותר עד שכל השלבים עד finalize כולל מסתיימים.

אחרי שהשלב האחרון (finalize) מסתיים, כל השלבים והמצב הכולל של ההשקה משתנים לSUCCEEDED:

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

מאשרים שהסטטוס הוא 'הושלם' ברשימת ההשקות:

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

הפלט מאשר שההשקה הושלמה:

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

חזרה לגרסה קודמת אחרי שדרוג

אם נתקלתם בבעיות במהלך השדרוג, האפשרות לחזור לגרסה הקודמת תלויה בשלב ההשקה הנוכחי של השדרוג:

שלב הסכימה: אי אפשר לחזור לגרסה קודמת. העברות של סכימת מסד נתונים פנימיות שמוחלות במהלך ההכנה הן קדימה בלבד ואי אפשר לבטל אותן. עם זאת, העברות סכימה תואמות לאחור עם גרסת המקור, מה שמאפשר לקבצים בינאריים קודמים של השרת להמשיך לפעול כרגיל.
שלב בינארי: אפשר לחזור לגרסה הקודמת בכל שלב לפני תחילת השלב הסופי. מידע נוסף זמין במאמר בנושא חזרה לגרסה קודמת של קובץ בינארי או קובץ אימג' של קונטיינר.
שלבים אופציונליים להשקה: בשלבים אופציונליים שתומכים בהחזרה אוטומטית (כמו הפעלת תכונות), מתחילים את ההחזרה באמצעות Spanner Omni CLI.
שלב הסיום: אי אפשר לבטל את השינויים. אחרי שהתהליך מתחיל, הגרסה המיועדת ננעלת באופן סופי בכל הפריסה, ואי אפשר לבצע חזרה לגרסה קודמת.

החזרה של קובץ בינארי או קובץ אימג' של קונטיינר לגרסה קודמת

כדי לבטל את השדרוג של השלב הבינארי לפני שהתהליך מסתיים, מבצעים הפעלה מחדש מתגלגלת בכל השרתים או הפודים כדי לשחזר את הגרסה הקודמת (גרסת המקור).

VM

בפריסות של מכונות וירטואליות, מבצעים Rollback של קובץ ה-spanner_server הבינארי בכל המכונות הווירטואליות:

פורסים את הגרסה הבינארית הקודמת של spanner_server במארחים.
מפעילים מחדש את השרתים בהדרגה בדומיינים של כשלים, מעדכנים אזור אחד בכל פעם ומפעילים מחדש עד 5% מהשרתים בו-זמנית כדי לשמור על קוורום של Paxos.
לפני שממשיכים לדומיין הכשל הבא, צריך לוודא שכל השרתים שהופעלו מחדש תקינים ושחזרו לאשכול.

Helm

בפריסות של Helm, מעדכנים את התג של קובץ האימג' של הקונטיינר בחזרה לגרסה הקודמת:

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

מחליפים את מה שכתוב בשדות הבאים:

‫CHART_VERSION: גרסת תרשים Helm, לדוגמה, 1.0.0.
‫NAMESPACE: מרחב השמות של Kubernetes בפריסה. לדוגמה, spanner-ns.
‫SOURCE_VERSION: התג הקודם של קובץ אימג' של קונטיינר שאליו רוצים לחזור, לדוגמה, 2026.r2-beta.3.

‫Kubernetes עצמאי

בפריסות מותאמות אישית של Kubernetes ללא Helm, מעדכנים את קובץ האימג' של הקונטיינר במפרטים של StatefulSet או Deployment בחזרה ל-SOURCE_VERSION.

חזרה לשלבי השקה אופציונליים

לשלבי השקה אופציונליים שתומכים בהחזרה למצב הקודם (כמו שלבי הפעלת תכונות), מריצים את הפקודה rollouts rollback כדי להתחיל את החזרה למצב הקודם:

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

מחליפים את מה שכתוב בשדות הבאים:

‫ROLLOUT_ID: מזהה ההשקה המספרי.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

שדרוג פריסה של Spanner Omni קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

תהליך השדרוג

לפני שמתחילים

שלב 1: מכינים את שדרוג הסכימה

VM

Helm

‫Kubernetes עצמאי

שלב 2: בודקים את סטטוס ההשקה הפעיל

שלב 3: מעדכנים את הקובץ הבינארי או את קובץ האימג' של הקונטיינר

VM

Helm

‫Kubernetes עצמאי

שלב 4: בדיקת ההתקדמות של השלב הבינארי

שלב 5: מתזמנים ומבצעים את השלבים שנותרו

חזרה לגרסה קודמת אחרי שדרוג

החזרה של קובץ בינארי או קובץ אימג' של קונטיינר לגרסה קודמת

VM

Helm

‫Kubernetes עצמאי

חזרה לשלבי השקה אופציונליים

המאמרים הבאים

שדרוג פריסה של Spanner Omni