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

פריסת PostgreSQL ב-GKE באמצעות Zalando

Autopilot Standard

במדריך הזה מוסבר איך להשתמש באופרטור Zalando Postgres כדי לפרוס אשכולות Postgres ב-Google Kubernetes Engine ‏ (GKE).

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

המדריך הזה מיועד לאדמינים של פלטפורמות, למומחי Cloud Architect ולמומחי תפעול שרוצים להריץ את PostgreSQL כאפליקציה של מסד נתונים ב-GKE במקום להשתמש ב-Cloud SQL ל-PostgreSQL.

מטרות

תכנון ופריסה של תשתית GKE ל-Postgres
פריסה והגדרה של Zalando Postgres operator
הגדרת Postgres באמצעות האופרטור כדי להבטיח זמינות, אבטחה, יכולת צפייה וביצועים

יתרונות

היתרונות של Zalando:

דרך דקלרטיבית (הצהרתית) וספציפית ל-Kubernetes לניהול ולהגדרה של אשכולות PostgreSQL
זמינות גבוהה באמצעות Patroni
תמיכה בניהול גיבויים באמצעות קטגוריות של Cloud Storage
עדכונים מתגלגלים בשינויים של אשכול Postgres, כולל עדכונים מהירים של גרסאות משניות
ניהול משתמשים דקלרטיבי עם יצירת סיסמאות ורוטציה באמצעות משאבים בהתאמה אישית
תמיכה ב-TLS, ברוטציית אישורים ובמאגרי חיבורים
שיבוט של אשכולות ושכפול נתונים

ארכיטקטורת פריסה

במדריך הזה נשתמש באופרטור Zalando Postgres כדי לפרוס ולהגדיר אשכול Postgres עם זמינות גבוהה ב-GKE. לאשכול יש רפליקה ראשית אחת ושתי רפליקות המתנה (לקריאה בלבד) שמנוהלות על ידי Patroni. ‫Patroni הוא פתרון קוד פתוח שמתוחזק על ידי Zalando כדי לספק זמינות גבוהה ויכולות מעבר אוטומטי לגיבוי (auto-failover) ל-Postgres. אם יש כשל בשרת הראשי, אחת מהרפליקות במצב המתנה מקודמת אוטומטית לתפקיד של שרת ראשי.

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

בתרשים הבא מוצג אשכול Postgres שפועל בכמה צמתים ואזורים באשכול GKE:

בתרשים, Postgres StatefulSet נפרס על פני שלושה צמתים בשלושה אזורים שונים. כדי לקבוע איך GKE יפרוס את הצמתים, אתם יכולים להגדיר את כללי הקרבה והריחוק הנדרשים של Pod במפרט המשאב המותאם אישית של postgresql. אם אזור אחד נכשל, מערכת GKE מתזמנת מחדש את ה-Pods בצמתים זמינים אחרים באשכול, באמצעות ההגדרה המומלצת. כדי לשמור נתונים, משתמשים בדיסקים מסוג SSD‏ (premium-rwo StorageClass), שמומלצים ברוב המקרים למסדי נתונים עם עומס גבוה בגלל זמן האחזור הנמוך ומספר ה-IOPS הגבוה שלהם.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

ב-Cloud Shell מותקן מראש התוכנה שדרושה למדריך הזה, כולל kubectl,‏ ה-CLI של gcloud,‏ Helm ו-Terraform. אם אתם לא משתמשים ב-Cloud Shell, אתם צריכים להתקין את ה-CLI של gcloud.

נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

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

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים פרויקט ב- Google Cloud .

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

מפעילים את ממשקי ה-API של Compute Engine,‏ IAM,‏ GKE ו-Backup for GKE, אם הם עדיין לא מופעלים:

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com

התקינו את ה-CLI של Google Cloud.

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

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

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

יוצרים או בוחרים פרויקט ב- Google Cloud .

תפקידים שנדרשים כדי לבחור או ליצור פרויקט

Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?

יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

מוודאים שהחיוב מופעל בפרויקט Google Cloud .

מפעילים את ממשקי ה-API של Compute Engine,‏ IAM,‏ GKE ו-Backup for GKE, אם הם עדיין לא מופעלים:

תפקידים שנדרשים להפעלת ממשקי API

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com gkebackup.googleapis.com

מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM: roles/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט.
- ‫USER_IDENTIFIER: המזהה של חשבון המשתמש . לדוגמה, myemail@example.com.
- ‫ROLE: תפקיד ה-IAM שאתם מקצים לחשבון המשתמש.

מגדירים את הסביבה

כדי להגדיר את הסביבה, מבצעים את השלבים הבאים

הגדרת משתני סביבה:
```
export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=postgres
export REGION=us-central1
```
מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

משכפלים את המאגר ב-GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

עוברים לספריית העבודה:

cd kubernetes-engine-samples/databases/postgres-zalando

יצירת תשתית האשכול

בקטע הזה מריצים סקריפט של Terraform כדי ליצור אשכול GKE פרטי, אזורי וזמין מאוד.

אפשר להתקין את האופרטור באמצעות אשכול סטנדרטי או במצב Autopilot.

רגילה

בתרשים הבא מוצג אשכול GKE פרטי אזורי מסוג Standard שנפרס בשלושה אזורים שונים:

פריסת התשתית הזו:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

כשמופיעה בקשה, כותבים yes. יכול להיות שיעברו כמה דקות עד שהפקודה תסתיים והאשכול יופיע בסטטוס "מוכן".

‫Terraform יוצר את המשאבים הבאים:

רשת VPC ורשת משנה פרטית לצמתים של Kubernetes
נתב לגישה לאינטרנט דרך NAT
אשכול GKE פרטי באזור us-central1
מאגר צמתים עם קנה מידה אוטומטי מופעל (צומת אחד עד שני צמתים לכל אזור, צומת אחד לכל אזור לכל הפחות)
ServiceAccount עם הרשאות רישום ביומן ומעקב
גיבוי ל-GKE לתוכנית התאוששות מאסון (DR)
השירות המנוהל של Google Cloud ל-Prometheus לניטור אשכולות

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

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...

טייס אוטומטי

הדיאגרמה הבאה מציגה אשכול GKE פרטי אזורי ב-Autopilot:

פורסים את התשתית:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

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

‫Terraform יוצר את המשאבים הבאים:

רשת VPC ורשת משנה פרטית לצמתים של Kubernetes
נתב לגישה לאינטרנט דרך NAT
אשכול GKE פרטי באזור us-central1
ServiceAccount עם הרשאת רישום ביומן ומעקב
השירות המנוהל של Google Cloud ל-Prometheus לניטור אשכולות

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

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
...

התחברות לאוסף

מגדירים את kubectl לתקשורת עם האשכול:

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

פריסת אופרטור Zalando באשכול

פורסים את האופרטור של Zalando באשכול Kubernetes באמצעות Helm chart.

מוסיפים את מאגר תרשימי Helm של Zalando:

helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator

יוצרים מרחב שמות לאופרטור Zalando ולאשכול Postgres:
```
kubectl create ns postgres
kubectl create ns zalando
```
פורסים את האופרטור של Zalando באמצעות כלי שורת הפקודה של Helm:
```
helm install postgres-operator postgres-operator-charts/postgres-operator -n zalando \
    --set configKubernetes.enable_pod_antiaffinity=true \
    --set configKubernetes.pod_antiaffinity_preferred_during_scheduling=true \
    --set configKubernetes.pod_antiaffinity_topology_key="topology.kubernetes.io/zone" \
    --set configKubernetes.spilo_fsgroup="103"
```
אי אפשר להגדיר את ההגדרות של podAntiAffinity ישירות במשאב המותאם אישית שמייצג את אשכול Postgres. במקום זאת, מגדירים את podAntiAffinityההגדרות באופן גלובלי לכל אשכולות Postgres בהגדרות האופרטור.

בודקים את סטטוס הפריסה של Zalando Operator באמצעות Helm:

helm ls -n zalando

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

NAME                 NAMESPACE    REVISION    UPDATED                                STATUS      CHART                       APP VERSION
postgres-operator    zalando     1           2023-10-13 16:04:13.945614 +0200 CEST    deployed    postgres-operator-1.10.1    1.10.1

פריסת Postgres

ההגדרה הבסיסית של מופע אשכול Postgres כוללת את הרכיבים הבאים:

שלוש רפליקות של Postgres: רפליקה אחת ראשית ושתי רפליקות במצב המתנה.
הקצאת משאבי מעבד (CPU) של בקשת מעבד אחת ושתי מגבלות מעבד, עם בקשות ומגבלות זיכרון של 4GB.
הגדרנו Tolerations‏ (nodeAffinities) ו-topologySpreadConstraints לכל עומס עבודה, כדי להבטיח חלוקה נכונה בין צמתי Kubernetes, תוך שימוש במאגרי הצמתים המתאימים ובאזורי זמינות שונים.

ההגדרה הזו מייצגת את ההגדרה המינימלית שנדרשת ליצירת אשכול Postgres שמוכן לייצור.

קובץ המניפסט הבא מתאר אשכול Postgres:

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  dockerImage: ghcr.io/zalando/spilo-15:3.0-p1
  teamId: "my-team"
  numberOfInstances: 3
  users:
    mydatabaseowner:
    - superuser
    - createdb
    myuser: []
  databases:
    mydatabase: mydatabaseowner
  postgresql:
    version: "15"
    parameters:
      shared_buffers: "32MB"
      max_connections: "10"
      log_statement: "all"
      password_encryption: scram-sha-256
  volume:
    size: 5Gi
    storageClass: premium-rwo
  enableShmVolume: true
  podAnnotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "true"
  tolerations:
  - key: "app.stateful/component"
    operator: "Equal"
    value: "postgres-operator"
    effect: NoSchedule
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: "app.stateful/component"
          operator: In
          values:
          - "postgres-operator"
  resources:
    requests:
      cpu: "1"
      memory: 4Gi
    limits:
      cpu: "2"
      memory: 4Gi
  sidecars:
    - name: exporter
      image: quay.io/prometheuscommunity/postgres-exporter:v0.14.0
      args:
      - --collector.stat_statements
      ports:
      - name: exporter
        containerPort: 9187
        protocol: TCP
      resources:
        limits:
          cpu: 500m
          memory: 256M
        requests:
          cpu: 100m
          memory: 256M
      env:
      - name: "DATA_SOURCE_URI"
        value: "localhost/postgres?sslmode=require"
      - name: "DATA_SOURCE_USER"
        value: "$(POSTGRES_USER)"
      - name: "DATA_SOURCE_PASS"
        value: "$(POSTGRES_PASSWORD)"

קובץ המניפסט הזה כולל את השדות הבאים:

‫spec.teamId: תחילית לאובייקטים של האשכול שבוחרים
‫spec.numberOfInstances: המספר הכולל של המופעים באשכול
‫spec.users: רשימת המשתמשים עם הרשאות
‫spec.databases: רשימת מסדי הנתונים בפורמט dbname: ownername
‫spec.postgresql: פרמטרים של postgres
‫spec.volume: פרמטרים של Persistent Disk
‫spec.tolerations: תבנית ה-Pod של ה-tolerations שמאפשרת לתזמן את ה-Pods של האשכול בצמתים של pool-postgres
‫spec.nodeAffinity: תבנית ה-Pod‏ nodeAffinity שמציינת ל-GKE שעדיף לתזמן את ה-Pods באשכול בצמתים pool-postgres.
‫spec.resources: בקשות ומגבלות לפודים באשכול
‫spec.sidecars: רשימה של קונטיינרים מסוג sidecar, שמכילה את הפרטים הבאים: postgres-exporter

מידע נוסף זמין במאמר Cluster manifest reference במסמכי התיעוד של Postgres.

יצירת אשכול Postgres בסיסי

יוצרים אשכול Postgres חדש באמצעות ההגדרה הבסיסית:
```
kubectl apply -n postgres -f manifests/01-basic-cluster/my-cluster.yaml
```
הפקודה הזו יוצרת משאב מותאם אישית של PostgreSQL של Zalando operator עם:
- בקשות ומגבלות של מעבד (CPU) וזיכרון
- כתמי צבע וזיקות כדי להפיץ את הרפליקות של ה-Pod שהוקצו בין צומתי GKE.
- מסד נתונים
- שני משתמשים עם הרשאות בעלים של מסד נתונים
- משתמש ללא הרשאות
מחכים ש-GKE יתחיל את עומסי העבודה הנדרשים:
```
kubectl wait pods -l cluster-name=my-cluster  --for condition=Ready --timeout=300s -n postgres
```
יכול להיות שיחלפו כמה דקות עד שהפקודה הזו תסתיים.

מוודאים ש-GKE יצר את עומסי העבודה של Postgres:

kubectl get pod,svc,statefulset,deploy,pdb,secret -n postgres

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

NAME                                    READY   STATUS  RESTARTS   AGE
pod/my-cluster-0                        1/1     Running   0         6m41s
pod/my-cluster-1                        1/1     Running   0         5m56s
pod/my-cluster-2                        1/1     Running   0         5m16s
pod/postgres-operator-db9667d4d-rgcs8   1/1     Running   0         12m

NAME                        TYPE        CLUSTER-IP  EXTERNAL-IP   PORT(S)   AGE
service/my-cluster          ClusterIP   10.52.12.109   <none>       5432/TCP   6m43s
service/my-cluster-config   ClusterIP   None        <none>      <none>  5m55s
service/my-cluster-repl     ClusterIP   10.52.6.152 <none>      5432/TCP   6m43s
service/postgres-operator   ClusterIP   10.52.8.176 <none>      8080/TCP   12m

NAME                        READY   AGE
statefulset.apps/my-cluster   3/3   6m43s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgres-operator   1/1     1           1           12m

NAME                                                MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/postgres-my-cluster-pdb   1              N/A             0                   6m44s

NAME                                                            TYPE                DATA   AGE
secret/my-user.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m45s
secret/postgres.my-cluster.credentials.postgresql.acid.zalan.do   Opaque            2   6m44s
secret/sh.helm.release.v1.postgres-operator.v1                  helm.sh/release.v1   1      12m
secret/standby.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m44s
secret/zalando.my-cluster.credentials.postgresql.acid.zalan.do  Opaque              2   6m44s

המפעיל יוצר את המשאבים הבאים:

‫Postgres StatefulSet, ששולט בשלושה עותקים של Pod ל-Postgres
‫PodDisruptionBudgets, כדי להבטיח שיש לפחות עותק זמין אחד
שירות my-cluster, שמטרגט רק את העותק המשוכפל הראשי
השירות my-cluster-repl, שחושף את יציאת Postgres לחיבורים נכנסים ולרפליקציה בין רפליקות של Postgres
‫my-cluster-config headless Service, כדי לקבל את רשימת העותקים של Postgres Pod שפועלים
סודות עם פרטי כניסה של משתמש לגישה למסד הנתונים ולשכפול בין צמתי Postgres

אימות ל-Postgres

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

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  users:
    mydatabaseowner:
    - superuser
    - createdb
    myuser: []
  databases:
    mydatabase: mydatabaseowner

במניפסט הזה:

למשתמש mydatabaseowner יש את התפקידים SUPERUSER ו-CREATEDB, שמאפשרים לו זכויות אדמין מלאות (כלומר, ניהול ההגדרה של Postgres, יצירת מסדי נתונים, טבלאות ומשתמשים חדשים). אל תשתפו את המשתמש הזה עם לקוחות. לדוגמה, ב-Cloud SQL הלקוחות לא יכולים לקבל גישה למשתמשים עם התפקיד SUPERUSER.
לא הוקצו תפקידים למשתמש myuser. השיטה הזו תואמת לשיטה המומלצת של שימוש ב-SUPERUSER כדי ליצור משתמשים עם הרשאות מינימליות. mydatabaseowner מעניק ל-myuser הרשאות פרטניות. כדי לשמור על האבטחה, צריך לשתף את פרטי הכניסה של myuser רק עם אפליקציות לקוח.

שמירת סיסמאות

כדאי להשתמש בscram-sha-256 שיטה המומלצת לאחסון סיסמאות. לדוגמה, המניפסט הבא מתאר משאב בהתאמה אישית שמציין הצפנה של scram-sha-256 באמצעות השדה postgresql.parameters.password_encryption:

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  postgresql:
    parameters:
      password_encryption: scram-sha-256

עדכון של פרטי הכניסה של המשתמש

אתם יכולים לשנות את פרטי הכניסה של המשתמשים שמאוחסנים ב-Kubernetes Secrets באמצעות Zalando. לדוגמה, המניפסט הבא מתאר משאב מותאם אישית שמגדיר רוטציה של פרטי הכניסה של המשתמש באמצעות השדה usersWithSecretRotation:

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-cluster
spec:
  ...
  usersWithSecretRotation:
  - myuser
  - myanotheruser
  - ...

דוגמה לאימות: חיבור ל-Postgres

בקטע הזה נסביר איך לפרוס לקוח Postgres לדוגמה ולהתחבר למסד הנתונים באמצעות הסיסמה מ-Kubernetes Secret.

מריצים את ה-Pod של הלקוח כדי ליצור אינטראקציה עם אשכול Postgres:
```
kubectl apply -n postgres -f manifests/02-auth/client-pod.yaml
```
פרטי הכניסה של המשתמשים myuser ו-mydatabaseowner נלקחים מהסודות הקשורים ומותקנים כמשתני סביבה ב-Pod.

מתחברים ל-Pod כשהוא מוכן:

kubectl wait pod postgres-client --for=condition=Ready --timeout=300s -n postgres
kubectl exec -it postgres-client -n postgres -- /bin/bash

מתחברים ל-Postgres ומנסים ליצור טבלה חדשה באמצעות myuser פרטי הכניסה:
```
PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);"
```
הפקודה אמורה להיכשל עם שגיאה דומה לזו:
```
ERROR:  permission denied for schema public
LINE 1: CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR...
```
הפקודה נכשלת כי כברירת מחדל, משתמשים שלא הוקצו להם הרשאות יכולים רק להיכנס ל-Postgres ולרשום מסדי נתונים.

צור טבלה עם פרטי הכניסה של mydatabaseowner והענק ל-myuser את כל ההרשאות בטבלה:

PGPASSWORD=$OWNERPASSWORD psql \
  -h my-cluster \
  -U $OWNERUSERNAME \
  -d mydatabase \
  -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);GRANT ALL ON test TO myuser;GRANT ALL ON SEQUENCE test_id_seq TO myuser;"

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

CREATE TABLE
GRANT
GRANT

מוסיפים נתונים אקראיים לטבלה באמצעות פרטי הכניסה של myuser:

for i in {1..10}; do
  DATA=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 13)
  PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "INSERT INTO test(randomdata) VALUES ('$DATA');"
done

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

INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1

מקבלים את הערכים שהזנתם:

PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "SELECT * FROM test;"

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

id |  randomdata
----+---------------
  1 | jup9HYsAjwtW4
  2 | 9rLAyBlcpLgNT
  3 | wcXSqxb5Yz75g
  4 | KoDRSrx3muD6T
  5 | b9atC7RPai7En
  6 | 20d7kC8E6Vt1V
  7 | GmgNxaWbkevGq
  8 | BkTwFWH6hWC7r
  9 | nkLXHclkaqkqy
 10 | HEebZ9Lp71Nm3
(10 rows)

יוצאים מהמעטפת של Pod:
```
exit
```

איך Prometheus אוסף מדדים עבור אשכול Postgres

בתרשים הבא אפשר לראות איך מתבצע איסוף מדדים של Prometheus:

בתרשים, אשכול פרטי של GKE מכיל:

‫Postgres Pod שאוסף מדדים בנתיב / ובפורט 9187
כלי איסוף שמבוססים על Prometheus ומעבדים את המדדים מ-Pod של Postgres
משאב PodMonitoring ששולח מדדים ל-Cloud Monitoring

השירות המנוהל של Google Cloud ל-Prometheus תומך באיסוף מדדים בפורמט Prometheus. ב-Cloud Monitoring יש לוח בקרה משולב למדדים של Postgres.

‫Zalando חושף מדדי אשכולות בפורמט Prometheus באמצעות הרכיב postgres_exporter כקונטיינר משני (sidecar).

יוצרים את המשאב PodMonitoring כדי לגרד מדדים לפי labelSelector:
```
kubectl apply -n postgres -f manifests/03-prometheus-metrics/pod-monitoring.yaml
```
נכנסים לדף GKE Clusters Dashboard במסוף Google Cloud .

כניסה ללוח הבקרה של GKE Clusters

במרכז הבקרה מוצג שיעור הטמעה של מדדים שאינו אפס.
נכנסים לדף Dashboards במסוף Google Cloud .

מעבר אל Dashboards
פותחים את לוח הבקרה PostgreSQL Prometheus Overview. בלוח הבקרה מוצג מספר השורות שאוחזרו. יכול להיות שיחלפו כמה דקות עד שהדשבורד יוקצה אוטומטית.

מתחברים ל-Pod של הלקוח:

kubectl exec -it postgres-client -n postgres -- /bin/bash

הוספת נתונים אקראיים:

for i in {1..100}; do
  DATA=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 13)
  PGPASSWORD=$CLIENTPASSWORD psql \
  -h my-cluster \
  -U $CLIENTUSERNAME \
  -d mydatabase \
  -c "INSERT INTO test(randomdata) VALUES ('$DATA');"
done

יש לרענן את הדף. התרשימים Rows ו-Blocks מתעדכנים כדי להציג את המצב בפועל של מסד הנתונים.
יוצאים מהמעטפת של Pod:
```
exit
```

הסרת המשאבים

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:

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

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

כדי למחוק Google Cloud פרויקט:

gcloud projects delete PROJECT_ID

מחיקת משאבים בודדים

מגדירים משתני סביבה.

export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=postgres
export REGION=us-central1

מריצים את הפקודה terraform destroy:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform  -chdir=terraform/FOLDER destroy \
  -var project_id=${PROJECT_ID} \
  -var region=${REGION} \
  -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

מחליפים את FOLDER ב-gke-autopilot או ב-gke-standard.

כשמופיעה בקשה, כותבים yes.

כדי למצוא את כל הדיסקים שלא צורפו:

export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")

מוחקים את הדיסקים:

for i in $disk_list; do
  disk_name=$(echo $i| cut -d'|' -f1)
  disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
  echo "Deleting $disk_name"
  gcloud compute disks delete $disk_name --zone $disk_zone --quiet
done

מחיקת המאגר ב-GitHub:
```
rm -r ~/kubernetes-engine-samples/
```

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

כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.

פריסת PostgreSQL ב-GKE באמצעות Zalando קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מטרות

יתרונות

ארכיטקטורת פריסה

עלויות

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

מגדירים את הסביבה

יצירת תשתית האשכול

רגילה

טייס אוטומטי

התחברות לאוסף

פריסת אופרטור Zalando באשכול

פריסת Postgres

יצירת אשכול Postgres בסיסי

אימות ל-Postgres

שמירת סיסמאות

עדכון של פרטי הכניסה של המשתמש

דוגמה לאימות: חיבור ל-Postgres

איך Prometheus אוסף מדדים עבור אשכול Postgres

הסרת המשאבים

מחיקת הפרויקט

מחיקת משאבים בודדים

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

פריסת PostgreSQL ב-GKE באמצעות Zalando