במדריך הזה מוסבר איך לפרוס אשכולות PostgreSQL ב-Google Kubernetes Engine (GKE) באמצעות האופרטור CloudNativePG.
PostgreSQL הוא מסד נתונים יחסי-אובייקטיבי בקוד פתוח, שנמצא בפיתוח פעיל כבר כמה עשורים, ולכן הוא מבטיח ביצועים יציבים של הלקוח. הוא מציע מגוון תכונות, כולל שכפול, שחזור לנקודת זמן מסוימת, תכונות אבטחה ויכולת הרחבה. PostgreSQL תואם למערכות הפעלה מרכזיות ועומד באופן מלא בתקני ACID (אטומיות, עקביות, בידוד, עמידות).
המדריך הזה מיועד לאדמינים של פלטפורמות, למומחי Cloud Architect ולמומחי תפעול שרוצים לפרוס אשכולות של Postgres ב-GKE. הפעלת Postgres ב-GKE במקום שימוש ב- Cloud SQL יכולה להעניק גמישות רבה יותר ושליטה בהגדרות לאדמינים מנוסים של מסדי נתונים.
יתרונות
CloudNativePG הוא אופרטור בקוד פתוח שפותח על ידי EDB ברישיון Apache 2. הוא מספק את התכונות הבאות לפריסת PostgreSQL:
- דרך דקלרטיבית (הצהרתית) וספציפית ל-Kubernetes לניהול ולהגדרה של אשכולות PostgreSQL
- ניהול הגיבוי באמצעות תמונות מצב של נפח האחסון או Cloud Storage
- חיבור TLS מוצפן במעבר, אפשרות להשתמש ברשות אישורים משלכם ושילוב עם Certificate Manager להנפקה אוטומטית של אישורי TLS ורוטציה שלהם
- עדכונים בהדרגה (rolling) לגרסאות משניות של PostgreSQL
- שימוש בשרת Kubernetes API כדי לשמור על סטטוס של אשכול PostgreSQL ומעבר לגיבוי לשמירה על זמינות גבוהה, בלי שנדרשים כלים נוספים
- הגדרה מובנית של כלי לייצוא נתונים של Prometheus באמצעות מדדים בהגדרת המשתמש שנכתבו ב-SQL
מטרות
- תכנון ופריסה של תשתית GKE ל-Postgres
- פריסה והגדרה של CloudNativePG Postgres operator באמצעות Helm
- פריסת אשכול PostgreSQL
- הגדרת אימות וניראות (observability) ב-PostgreSQL
ארכיטקטורת פריסה
ל-PostgreSQL יש אפשרויות פריסה שונות, החל משרת מסד נתונים עצמאי ועד לאשכול משוכפל עם זמינות גבוהה. המדריך הזה מתמקד בפריסת אשכולים עם זמינות גבוהה ב-GKE.
בפריסה הזו, עומסי העבודה של אשכול PostgreSQL מפוזרים על פני כמה אזורי זמינות באשכול GKE האזורי, כדי להבטיח זמינות גבוהה ויתירות. מידע נוסף זמין במאמר בנושא אשכולות אזוריים.
התרשים הבא מציג אשכול Postgres שפועל בכמה צמתים ואזורים באשכול GKE:
ההגדרה שמוגדרת כברירת מחדל כוללת שרת PostgreSQL ראשי אחד ושני שרתי גיבוי שמוכנים להשתלט על השרת הראשי במקרה של כשל, כדי להבטיח זמינות רציפה של מסד הנתונים.
משאבי האופרטור CloudNativePG משתמשים במרחב שמות נפרד של אשכול GKE כדי לשפר את הבידוד של המשאבים, ומומלץ להשתמש בגישת המיקרו-שירותים של מסד נתונים אחד לכל אשכול PostgreSQL. מסד הנתונים והמשתמש התואם שלו (משתמש באפליקציה) מוגדרים במשאב המותאם אישית של Kubernetes שמייצג את האשכול.
אחסון הוא רכיב חיוני כשמדברים על מסדי נתונים. האחסון צריך להיות יעיל, להבטיח זמינות רציפה ולשמור על עקביות הנתונים. לכן אנחנו ממליצים על מחלקת האחסון
premium-rwoשמבוססת על דיסקים מסוג SSD. האופרטור CloudNativePG יוצר באופן אוטומטי אתPersistentVolumeClaimsלפי הצורך כשמגדירים Pods לאשכול PostgreSQL.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.
כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.
לפני שמתחילים
ב-Cloud Shell מותקן מראש התוכנה שדרושה למדריך הזה, כולל kubectl, ה-CLI של gcloud, Helm ו-Terraform. אם אתם לא משתמשים ב-Cloud Shell, אתם צריכים להתקין את ה-CLI של gcloud.
- נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
-
התקינו את ה-CLI של Google Cloud.
-
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
-
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init -
יוצרים או בוחרים Google Cloud פרויקט.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
-
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (
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 .
מפעילים את ממשקי ה-API של Compute Engine, IAM, GKE ומנהל המשאבים:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (
roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאהserviceusage.services.enable. איך מקצים תפקידיםgcloud services enable compute.googleapis.com
iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com -
התקינו את ה-CLI של Google Cloud.
-
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
-
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init -
יוצרים או בוחרים Google Cloud פרויקט.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
-
יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (
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 .
מפעילים את ממשקי ה-API של Compute Engine, IAM, GKE ומנהל המשאבים:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (
roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאהserviceusage.services.enable. איך מקצים תפקידיםgcloud services enable compute.googleapis.com
iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com -
מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM:
roles/compute.securityAdmin, roles/compute.viewer, roles/container.clusterAdmin, roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUsergcloud 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/postgresql-cloudnativepg
יצירת תשתית האשכול
בקטע הזה מריצים סקריפט של Terraform כדי ליצור אשכול GKE פרטי, אזורי וזמין מאוד.
אפשר להתקין את האופרטור באמצעות אשכול Standard או 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 - מאגר צמתים עם קנה מידה אוטומטי מופעל (צומת אחד עד שני צמתים לכל אזור, צומת אחד לכל אזור לכל הפחות)
הפלט אמור להיראות כך:
...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...
טייס אוטומטי
התרשים הבא מציג אשכול פרטי אזורי של Autopilot GKE:
כדי לפרוס את התשתית, מריצים את הפקודות הבאות:
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}
פריסת האופרטור CloudNativePG
פורסים את CloudNativePG באשכול Kubernetes באמצעות תרשים Helm:
מוסיפים את מאגר התרשימים של CloudNativePG operator Helm:
helm repo add cnpg https://cloudnative-pg.github.io/chartsפורסים את האופרטור CloudNativePG באמצעות כלי שורת הפקודה Helm:
helm upgrade --install cnpg \ --namespace cnpg-system \ --create-namespace \ cnpg/cloudnative-pgהפלט אמור להיראות כך:
Release "cnpg" does not exist. Installing it now. NAME: cnpg LAST DEPLOYED: Fri Oct 13 13:52:36 2023 NAMESPACE: cnpg-system STATUS: deployed REVISION: 1 TEST SUITE: None ...
פריסת Postgres
המניפסט הבא מתאר אשכול PostgreSQL כפי שמוגדר על ידי המשאב המותאם אישית של אופרטור CloudNativePG:
קובץ המניפסט הזה כולל את השדות הבאים:
-
spec.instances: מספר ה-Pods באשכול -
spec.primaryUpdateStrategy: שיטת העדכון בהדרגה:-
Unsupervised: עדכון אוטונומי של הצומת הראשי באשכול אחרי הצמתים המשוכפלים -
Supervised: נדרש מעבר ידני לצומת הראשי של האשכול
-
-
spec.postgresql: החלפת פרמטרים של קובץpostgres.conf, כמו כללי pg-hba, LDAP ודרישות לסנכרון רפליקות. -
spec.storage: הגדרות שקשורות לאחסון, כמו סוג האחסון, גודל הנפח והגדרות של יומן פעולות מקדים. -
spec.bootstrap: פרמטרים של מסד הנתונים הראשוני שנוצר באשכול, פרטי הכניסה של המשתמש ואפשרויות לשחזור מסד הנתונים -
spec.resources: בקשות ומגבלות לגבי פודים באשכול -
spec.affinity: כללי זיקה ואנטי-זיקה של עומסי העבודה של האשכול
יצירת אשכול Postgres בסיסי
יוצרים מרחב שמות:
kubectl create ns pg-nsיוצרים את אשכול PostgreSQL באמצעות המשאב המותאם אישית:
kubectl apply -n pg-ns -f manifests/01-basic-cluster/postgreSQL_cluster.yamlיכול להיות שיעברו כמה דקות עד שהפקודה הזו תסתיים.
בודקים את הסטטוס של האשכול:
kubectl get cluster -n pg-ns --watchמחכים עד שהפלט יציג את הסטטוס
Cluster in healthy stateלפני שעוברים לשלב הבא.NAME AGE INSTANCES READY STATUS PRIMARY gke-pg-cluster 2m53s 3 3 Cluster in healthy state gke-pg-cluster-1
בדיקת המשאבים
מוודאים ש-GKE יצר את המשאבים לאשכול:
kubectl get cluster,pod,svc,pvc,pdb,secret,cm -n pg-ns
הפלט אמור להיראות כך:
NAME AGE INSTANCES READY STATUS PRIMARY
cluster.postgresql.cnpg.io/gke-pg-cluster 32m 3 3 Cluster in healthy state gke-pg-cluster-1
NAME READY STATUS RESTARTS AGE
pod/gke-pg-cluster-1 1/1 Running 0 31m
pod/gke-pg-cluster-2 1/1 Running 0 30m
pod/gke-pg-cluster-3 1/1 Running 0 29m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/gke-pg-cluster-r ClusterIP 10.52.11.24 <none> 5432/TCP 32m
service/gke-pg-cluster-ro ClusterIP 10.52.9.233 <none> 5432/TCP 32m
service/gke-pg-cluster-rw ClusterIP 10.52.1.135 <none> 5432/TCP 32m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/gke-pg-cluster-1 Bound pvc-bbdd1cdd-bdd9-4e7c-8f8c-1a14a87e5329 2Gi RWO standard 32m
persistentvolumeclaim/gke-pg-cluster-2 Bound pvc-e7a8b4df-6a3e-43ce-beb0-b54ec1d24011 2Gi RWO standard 31m
persistentvolumeclaim/gke-pg-cluster-3 Bound pvc-dac7f931-6ac5-425f-ac61-0cfc55aae72f 2Gi RWO standard 30m
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
poddisruptionbudget.policy/gke-pg-cluster 1 N/A 1 32m
poddisruptionbudget.policy/gke-pg-cluster-primary 1 N/A 0 32m
NAME TYPE DATA AGE
secret/gke-pg-cluster-app kubernetes.io/basic-auth 3 32m
secret/gke-pg-cluster-ca Opaque 2 32m
secret/gke-pg-cluster-replication kubernetes.io/tls 2 32m
secret/gke-pg-cluster-server kubernetes.io/tls 2 32m
secret/gke-pg-cluster-superuser kubernetes.io/basic-auth 3 32m
NAME DATA AGE
configmap/cnpg-default-monitoring 1 32m
configmap/kube-root-ca.crt 1 135m
המפעיל יוצר את המשאבים הבאים:
- משאב בהתאמה אישית של אשכול שמייצג את אשכול PostgreSQL שמנוהל על ידי האופרטור
- משאבי PersistentVolumeClaim עם נפחי אחסון מתמידים (Persistent Volumes) תואמים
- סודות עם פרטי כניסה של משתמש לגישה למסד הנתונים ולשכפול בין צמתי Postgres.
- שלושה שירותים של נקודות קצה של מסד נתונים:
<name>-rw,<name>-roו-<name>-rלחיבור לאשכול. מידע נוסף זמין במאמר בנושא ארכיטקטורה של PostgreSQL.
אימות ל-Postgres
אתם יכולים להתחבר למסד הנתונים של PostgreSQL ולבדוק את הגישה דרך נקודות קצה שונות של שירותים שנוצרו על ידי האופרטור. כדי לעשות את זה, משתמשים ב-Pod נוסף עם לקוח PostgreSQL ופרטי כניסה מסונכרנים של משתמש האפליקציה שמוגדרים כמשתני סביבה.
מריצים את ה-Pod של הלקוח כדי ליצור אינטראקציה עם אשכול Postgres:
kubectl apply -n pg-ns -f manifests/02-auth/pg-client.yamlמריצים פקודת
execב-Podpg-clientונכנסים לשירותgke-pg-cluster-rw:kubectl wait --for=condition=Ready -n pg-ns pod/pg-client --timeout=300s kubectl exec -n pg-ns -i -t pg-client -- /bin/shמתחברים למסד הנתונים באמצעות שירות
gke-pg-cluster-rwכדי ליצור חיבור עם הרשאות קריאה וכתיבה:psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-rw.pg-ns/appהטרמינל מתחיל עם שם מסד הנתונים:
app=>יצירת טבלה:
CREATE TABLE travel_agency_clients ( client VARCHAR ( 50 ) UNIQUE NOT NULL, address VARCHAR ( 50 ) UNIQUE NOT NULL, phone VARCHAR ( 50 ) UNIQUE NOT NULL);מוסיפים נתונים לטבלה:
INSERT INTO travel_agency_clients(client, address, phone) VALUES ('Tom', 'Warsaw', '+55555') RETURNING *;צפייה בנתונים שיצרתם:
SELECT * FROM travel_agency_clients ;הפלט אמור להיראות כך:
client | address | phone --------+---------+--------- Tom | Warsaw | +55555 (1 row)יציאה מהסשן הנוכחי במסד הנתונים:
exitמתחברים למסד הנתונים באמצעות השירות
gke-pg-cluster-roכדי לאמת גישה לקריאה בלבד. השירות הזה מאפשר לשלוח שאילתות לגבי נתונים, אבל מגביל פעולות כתיבה:psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-ro.pg-ns/appניסיון להוסיף נתונים חדשים:
INSERT INTO travel_agency_clients(client, address, phone) VALUES ('John', 'Paris', '+55555') RETURNING *;הפלט אמור להיראות כך:
ERROR: cannot execute INSERT in a read-only transactionניסיון לקרוא נתונים:
SELECT * FROM travel_agency_clients ;הפלט אמור להיראות כך:
client | address | phone --------+---------+--------- Tom | Warsaw | +55555 (1 row)יציאה מהסשן הנוכחי במסד הנתונים:
exitיוצאים מהמעטפת של ה-Pod:
exit
איך Prometheus אוסף מדדים עבור אשכול Postgres
בתרשים הבא אפשר לראות איך מתבצע איסוף מדדים של Prometheus:
בתרשים, אשכול פרטי של GKE מכיל:
- Pod של Postgres שאוסף מדדים בנתיב
/ובפורט9187 - כלי איסוף שמבוססים על Prometheus ומעבדים את המדדים מ-Pod של Postgres
- משאב
PodMonitoringששולח מדדים ל-Cloud Monitoring
כדי לאפשר איסוף מדדים מה-Pods, פועלים לפי השלבים הבאים:
יצירת משאב
PodMonitoring:kubectl apply -f manifests/03-observability/pod-monitoring.yaml -n pg-nsנכנסים לדף Metrics explorer במסוף Google Cloud :
במרכז הבקרה מוצג שיעור הטמעה של מדדים שגדול מאפס.
בקטע Select a metric (בחירת מדד), מזינים Prometheus Target (יעד פרומתיאוס).
בקטע Active Metric Categories בוחרים באפשרות Cnpg.
יצירת לוח בקרה של מדדים
כדי להציג את המדדים שייצאתם, אתם יכולים ליצור לוח בקרה של מדדים.
פריסת מרכז בקרה:
gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file manifests/03-observability/gcp-pg.jsonנכנסים לדף Dashboards במסוף Google Cloud .
בוחרים את מרכז הבקרה PostgresQL Prometheus Overview.
כדי לבדוק איך מרכזי בקרה עוקבים אחרי פונקציות, אפשר לעשות שימוש חוזר בפעולות מהקטע אימות מסד נתונים, להחיל בקשות קריאה וכתיבה במסד הנתונים ואז לבדוק את ההדמיה של המדדים שנאספו במרכז הבקרה.
מתחברים ל-Pod של הלקוח:
kubectl exec -n pg-ns -i -t pg-client -- /bin/shהוספת נתונים אקראיים:
psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-rw.pg-ns/app -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);INSERT INTO test (randomdata) VALUES (generate_series(1, 1000));"מרעננים את מרכז הבקרה. הגרפים מתעדכנים עם מדדים בפועל.
יוצאים מהמעטפת של ה-Pod:
exit
הסרת המשאבים
מחיקת הפרויקט
כדי למחוק 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
המאמרים הבאים
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.