בדף הזה מתועדת גרסה 18.4.0 של AlloyDB Omni באמצעות אפשרות הפריסה container orchestrator. בוחרים אפשרות פריסה אחרת.

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

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

בוחרים גרסת תיעוד:

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

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

סקירה כללית

כדי לפרוס את 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 יכולים להפעיל אותן ידנית על ידי הגדרת משתנה הסביבה 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, שבו פועלת התוכנה הבאה:
- ‫Kubernetes בגרסה 1.21 ואילך.
- השירות cert-manager, שמותקן באמצעות Helm.
הערה: באשכולות GKE Autopilot, מתקינים את cert-manager עם הדגל הזה: --set global.leaderElection.namespace=cert-manager

מרוץ תהליכים ידוע ב-cert-manager עלול לגרום לכשל בהנפקת אישור. כדי להקטין את הסיכוי שהבעיה הזו תקרה, צריך להגדיר את הבקר cert-manager עם ההגדרות המומלצות. מידע נוסף זמין במאמר פתרון בעיות בהנפקת אישורים ב-cert-manager.
הכלי kubectl.
מנהל החבילות helm או מנהל מחזור החיים של האופרטורים.

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

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

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

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

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

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

הגה

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

מתקינים את אופרטור AlloyDB Omni ממרשם ה-OCI:

helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
--version 1.9.0 \
--create-namespace \
--namespace alloydb-omni-system \
$(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--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:

נכנסים לדף AlloyDB Omni Operator.
לוחצים על התקנה. אם עדיין לא עשיתם את זה, בצעו את ההוראות להתקנת האופרטור OLM וקטלוג OperatorHub.io בלבד.
יוצרים את מרחב השמות alloydb-omni-system אם הוא לא קיים.
```
kubectl create ns alloydb-omni-system
```

מגדירים את 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

מתקינים את האופרטור באמצעות משאב של מינוי ל-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

מתקינים את אישור ברירת המחדל 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:

נכנסים למסוף האינטרנט של Red Hat OpenShift.
למשתמשים במצב אופליין או במצב מנותק, צריך לשקף באופן ידני את קובצי האימג' הנדרשים למאגר הפרטי באמצעות כלים ששומרים על תקצירי SHA, כמו oc image mirror. צריך להגדיר ImageDigestMirrorSet כדי להפנות בקשות לשליפת קובצי אימג' מהמאגר הציבורי של gcr.io למאגר הפרטי שלכם. כך מוודאים שאופרטור AlloyDB Omni יכול לשלוף את התמונות הנדרשות באמצעות תקצירי ה-SHA256 הבלתי משתנים שלהן.
במסוף האינטרנט של OpenShift, עוברים אל Operators > OperatorHub. אופרטור AlloyDB Omni מופיע בקטלוגים Certified ו-Community.
בחלונית של אופרטור AlloyDB Omni, לוחצים על Install (התקנה).
כדי להתקין את אישור ברירת המחדל 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 במצב מחובר לא מוגדרת מחלקת אחסון כברירת מחדל. צריך להגדיר סוג אחסון כברירת מחדל לפני שיוצרים אשכול מסד נתונים של AlloyDB Omni.

איך מגדירים את Symcloud Storage כסוג האחסון שמוגדר כברירת מחדל

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

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

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

חשוב: אל תיצרו אשכול מסדי נתונים במרחב השמות alloydb-omni-system. אם לא משתמשים במרחב השמות הזה, הבידוד והאבטחה משתפרים ונמנעים עימותים בין המפעיל לבין משאבי מסד הנתונים באותו אשכול Kubernetes.

אחרי שמתקינים את אופרטור 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.4.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: כמות הזיכרון לכל מופע של מסד נתונים באשכול מסדי הנתונים הזה. מומלץ להגדיר את הערך הזה ל-8GB לכל מעבד (CPU). לדוגמה, אם הגדרתם את cpu ל-2 מוקדם יותר במניפסט הזה, מומלץ להגדיר את memory ל-16Gi.
‫DISK_SIZE: גודל הדיסק לכל מופע של מסד נתונים, לדוגמה 10Gi.

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

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

סודות לשליפת תמונות

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

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

spec:
  primarySpec:
    serviceAccount:
      imagePullSecrets:
      - name: PULL_SECRET_NAME

מחליפים את PULL_SECRET_NAME בשם של סוד משיכת האימג'.

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

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

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

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

שינוי גודל עם זמן השבתה נמוך

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

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

הפעלת שינוי גודל עם זמן השבתה קצר. מוסיפים את ההערה enableLDTM לאשכול מסד הנתונים:
```
kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME dbcluster.dbadmin.goog/enableLDTM=true
```
מחליפים את DB_CLUSTER_NAME בשם של אשכול מסד הנתונים.
מחילים את מפרטי ההתאמה המעודכנים. מעדכנים את הערכים של cpu ו-memory בקטע primarySpec.resources במניפסט, ומחילים את השינויים:
```
kubectl apply -f db-cluster.yaml
```
עוקבים אחרי תהליך ההרחבה. כדי לעקוב אחרי הפעולה, בודקים את התנאי של הסטטוס 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 נכשלת, צריך לבצע החזרה ידנית לגרסה הקודמת.