התקנה של AlloyDB Omni באמצעות כלי לתזמור קונטיינרים

בחירת גרסה של מאמר העזרה:

בדף הזה מובאת סקירה כללית על אופרטור AlloyDB Omni Kubernetes, עם הוראות לשימוש בו כדי לפרוס את AlloyDB Omni באשכול Kubernetes. בדף הזה אנחנו מניחים שיש לכם היכרות בסיסית עם הפעולה של Kubernetes.

הוראות להתקנת AlloyDB Omni בסביבת Linux רגילה מופיעות במאמר התקנת AlloyDB Omni.

סקירה כללית

כדי לפרוס את AlloyDB Omni באשכול Kubernetes, צריך להתקין את אופרטור AlloyDB Omni Kubernetes, תוסף ל-Kubernetes API שסופק על ידי Google.

כדי להגדיר ולשלוט באשכול מסדי נתונים של AlloyDB Omni שמבוסס על Kubernetes, משייכים קובצי מניפסט הצהרתיים לכלי kubectl, בדיוק כמו בכל פריסה אחרת שמבוססת על Kubernetes. אתם לא משתמשים ב-AlloyDB Omni CLI, שמיועד לפריסות במכונות Linux בודדות ולא באשכולות Kubernetes.

תמונת הבסיס

החל מגרסה 1.5.0, תמונות Kubernetes של אופרטור AlloyDB Omni מבוססות על Universal Base Image‏ (UBI) 9 של Red Hat. המעבר הזה משפר את האבטחה, העקביות והתאימות של הפריסות שלכם.

תמונות לדוגמה של תמצית SHA

כדי למנוע מתקפות על שרשרת האספקה ולעמוד בדרישות האישור של OpenShift, אופרטור AlloyDB Omni משתמש בסיכומי SHA-256 במקום בתגי גרסה לכל ההפניות לקובצי אימג' של קונטיינרים.

  • שדרוגים אוטומטיים: האופרטור AlloyDB Omni משתמש ב-ImageCatalog פנימי כדי לנהל את הגיבובים האלה וכדי להבטיח שחזורי נתונים מהימנים במהלך שדרוגים שנכשלו.

  • הפעלה: למרות שההגדרה הזו מופעלת כברירת מחדל בחבילה OpenShift Certified, משתמשים בחבילות OLM או Helm יכולים להפעיל ידנית הפניות ל-digest על ידי הגדרת משתנה הסביבה ENABLE_DIGEST_IMAGE_REFS לערך true באמצעות הגדרת המינוי ל-OLM או הערך enableDigestImageRefs בתרשים Helm.

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

לפני שמתקינים את AlloyDB Omni באשכול Kubernetes עם אופרטור AlloyDB Omni, צריך לוודא שאתם עומדים בדרישות הבאות.

בחירת אפשרות להורדה או להתקנה

כשמנהלים עומסי עבודה באשכול Kubernetes כללי, אפשר להשתמש ב-Helm או ב-OLM. ‫Helm הוא מנהל חבילות אוניברסלי שמשתמש בתרשימי Helm כדי להתקין כל עומס עבודה, כולל אופרטורים, בכל הווריאציות של Kubernetes. OLM – הבחירה המועדפת והסטנדרטית בפלטפורמות OpenShift – מנהל את מחזורי החיים של האופרטורים באמצעות חבילות OLM ייעודיות.

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

מדיה מיקומי הורדה ומדריכי התקנה פריסה אל
אופרטור AlloyDB Omni עם תרשים Helm התקנת AlloyDB Omni ב-Kubernetes סביבת קונטיינרים של Kubernetes משלכם – למשל, בארגון, בעננים ציבוריים, ב-GKE, ב-Amazon EKS וב-Azure AKS.

טיפ: אם כלי ה-CD (פיתוח רציף) שלכם משולבים עם Helm, כדאי להשתמש באפשרות הזו.
אופרטור AlloyDB Omni עם חבילת OLM OperatorHub.io סביבת קונטיינרים של Kubernetes משלכם – למשל, מקומית, בעננים ציבוריים, ב-Google Kubernetes Engine, ב-Amazon EKS וב-Azure AKS.

כדי להשתמש בחבילת OLM, צריך להתקין את OLM באשכול Kubernetes לפני שמתקינים את האופרטור. מידע נוסף זמין בכתובת olm.operatorframework.io.

כדאי לדעת: אם כלי ה-CD (פיתוח רציף) שלכם כבר משתמשים ב-OLM, בוחרים באפשרות הזו.
OpenShift Operator with OLM Bundle מסוף האינטרנט של Openshift Container Platform סביבת OpenShift

‫OpenShift, גרסה של Kubernetes, משתמשת ב-OLM כשיטה סטנדרטית ומובנית לאריזה ולפריסה של אופרטורים.

אימות הגישה

ודאו שיש לכם גישה ל:

עמידה בדרישות החומרה והתוכנה

לכל צומת באשכול Kubernetes צריכים להיות:

  • לפחות שני מעבדי x86 או AMD64.
  • זיכרון RAM בנפח 8GB לפחות.
  • גרסת הליבה של Linux‏ 4.18 ואילך.
  • הופעל cgroup (קבוצת בקרה) v2.

התקנת אופרטור AlloyDB Omni

אם רוצים לפרוס את AlloyDB Omni בסביבת הייצור, אפשר לעיין במאמר הפעלת AlloyDB Omni בסביבת ייצור.

אפשר להתקין את אופרטור AlloyDB Omni בשיטות שונות, כולל Helm ו-Operator Lifecycle Manager‏ (OLM).

Helm

כדי להתקין את אופרטור AlloyDB Omni, מבצעים את השלבים הבאים:

  1. מתקינים את אופרטור AlloyDB Omni ממאגר OCI: 
    helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.8.0 \
--create-namespace \
--namespace alloydb-omni-system \
--atomic \
--timeout 5m

    אם ההתקנה בוצעה בהצלחה, הפלט הבא יוצג:

    NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 1
TEST SUITE: None

OLM

כדי להתקין את האופרטור AlloyDB Omni באמצעות Operator Lifecycle Manager, מבצעים את השלבים הבאים:

  1. עוברים לדף אופרטור AlloyDB Omni.

  2. לוחצים על התקנה. אם עדיין לא עשיתם זאת, אתם צריכים לפעול לפי ההוראות להתקנה של OLM operator ושל קטלוג OperatorHub.io בלבד.

  3. יוצרים את מרחב השמות alloydb-omni-system אם הוא לא קיים.

    kubectl create ns alloydb-omni-system

  4. מגדירים את OLM OperatorGroup כדי לוודא שהאופרטור הוא ברמת האשכול.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operator-sdk-og
  namespace: alloydb-omni-system
spec:
  upgradeStrategy: Default
EOF

  5. מתקינים את האופרטור באמצעות משאב מינוי OLM.

    kubectl apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-alloydb-omni-operator
  namespace: alloydb-omni-system
spec:
  channel: stable
  name: alloydb-omni-operator
  source: operatorhubio-catalog
  sourceNamespace: olm
EOF

  6. מתקינים את אישור ברירת המחדל ClusterIssuer. השלב הזה הוא אופציונלי אם משתמשים בגורמים מנפיקים של אישורים בהתאמה אישית.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

OLM

כדי להתקין את האופרטור AlloyDB Omni בסביבת Red Hat OpenShift באמצעות OLM, מבצעים את השלבים הבאים:

  1. נכנסים למסוף האינטרנט של Red Hat OpenShift.
  2. משתמשים במצב אופליין או משתמשים שלא מחוברים לאינטרנט צריכים לשכפל ידנית את התמונות הנדרשות למאגר הפרטי שלהם באמצעות כלים ששומרים על תקצירי SHA, כמו oc image mirror. צריך להגדיר ImageDigestMirrorSet כדי להפנות משיכות של תמונות ממאגר gcr.io ציבורי אל הרישום הפרטי שלכם. כך מוודאים שאופרטור AlloyDB Omni יכול למשוך את התמונות הנדרשות באמצעות תקצירי SHA256 קבועים.

  3. במסוף האינטרנט של OpenShift, עוברים אל Operators > OperatorHub. אופרטור AlloyDB Omni מופיע בקטלוגים Certified ו-Community.

  4. בחלונית של אופרטור AlloyDB Omni, לוחצים על Install (התקנה).

  5. כדי להתקין את אישור ברירת המחדל ClusterIssuer, מריצים את הפקודות הבאות. השלב הזה הוא אופציונלי אם משתמשים בגורמים מנפיקים של אישורים בהתאמה אישית.

    kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: alloydbomni-selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF

הגדרת אחסון ב-GDC במודל מחובר

כדי להתקין את האופרטור AlloyDB Omni ב-GDC במודל מחובר, צריך לבצע שלבים נוספים להגדרת האחסון כי באשכולות GDC במודל מחובר לא מוגדר סוג אחסון (storage class) כברירת מחדל. צריך להגדיר סוג אחסון כברירת מחדל לפני שיוצרים אשכול מסד נתונים של AlloyDB Omni.

מידע נוסף על הגדרת Symcloud Storage כסוג האחסון שמוגדר כברירת מחדל מופיע במאמר הגדרת Symcloud Storage כסוג האחסון שמוגדר כברירת מחדל.

מידע נוסף על שינוי ברירת המחדל של כל סוגי האחסון האחרים מופיע במאמר שינוי ברירת המחדל של StorageClass.

יצירת אשכול של מסדי נתונים

אשכול מסדי נתונים ב-AlloyDB Omni מכיל את כל משאבי האחסון והמחשוב שנדרשים להפעלת שרת AlloyDB Omni, כולל השרת הראשי, כל העותקים המשוכפלים וכל הנתונים שלכם.

אחרי התקנת האופרטור AlloyDB Omni באשכול Kubernetes, אפשר ליצור אשכול מסד נתונים של AlloyDB Omni באשכול Kubernetes על ידי החלת מניפסט שדומה לזה שמופיע בהמשך:

apiVersion: v1
kind: Secret
metadata:
  name: db-pw-DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE

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

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים הזה, לדוגמה my-db-cluster.

  • ‫ENCODED_PASSWORD: סיסמת ההתחברות למסד הנתונים עבור תפקיד המשתמש שמוגדר כברירת מחדל postgres, בקידוד base64. לדוגמה, Q2hhbmdlTWUxMjM= עבור ChangeMe123.

  • ‫CPU_COUNT: מספר המעבדים הזמינים לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה.

  • ‫MEMORY_SIZE: כמות הזיכרון לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה. מומלץ להגדיר את הערך הזה ל-8 גיגה-בייט לכל מעבד. לדוגמה, אם הגדרתם את cpu ל-2 קודם במניפסט הזה, מומלץ להגדיר את memory ל-16Gi.

  • ‫DISK_SIZE: גודל הדיסק לכל מופע של מסד נתונים, לדוגמה 10Gi.

אחרי שמחילים את המניפסט הזה, אשכול Kubernetes מכיל אשכול מסד נתונים של AlloyDB Omni עם הזיכרון, המעבד והגדרות האחסון שצוינו. כדי ליצור חיבור בדיקה עם אשכול מסד הנתונים החדש, אפשר לעיין במאמר בנושא חיבור באמצעות psql שהותקן מראש.

מידע נוסף על מניפסטים של Kubernetes ועל אופן היישום שלהם זמין במאמר ניהול משאבים.

שינוי הגודל של אשכול מסדי נתונים

כדי להגדיל את משאבי המחשוב של אשכול מסד הנתונים, מעדכנים את הערכים cpu ו-memory במניפסט db-cluster.yaml ומחילים את השינויים. תהליך ההתאמה תלוי בסוג ההתאמה שבחרתם: התאמה רגילה או התאמה עם זמן השבתה קצר.

שינוי גודל רגיל

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

שינוי גודל עם זמן השבתה קצר

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

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

  1. הפעלת שינוי גודל עם זמן השבתה קצר. מוסיפים את ההערה enableLDTM לאשכול מסד הנתונים:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true

    מחליפים את DB_CLUSTER_NAME בשם של אשכול מסדי הנתונים.

  2. החלת מפרט ההתאמה המעודכן. מעדכנים את הערכים של cpu ו-memory בקטע primarySpec.resources במניפסט ומחילים את השינויים:

    kubectl apply -f db-cluster.yaml

  3. עוקבים אחרי תהליך ההרחבה. בודקים את תנאי הסטטוס LDTMScalingInProgress כדי לעקוב אחרי הפעולה:

    kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "LDTMScalingInProgress")'

    מחליפים את DB_CLUSTER_NAME בשם של אשכול מסדי הנתונים.

    במהלך התהליך, הסטטוס הוא true. כשההתאמה לגודל מסתיימת, הסטטוס של התנאי משתנה לfalse.

מגבלות

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

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