בדף הזה מוסבר איך להגדיר חיבור מאפליקציה שפועלת ב-Google Kubernetes Engine (GKE) למופע Cloud SQL.
הוראות מפורטות להפעלת אפליקציית אינטרנט לדוגמה של Google Kubernetes Engine שמחוברת ל-Cloud SQL זמינות במדריך לתחילת העבודה בנושא התחברות מ-Google Kubernetes Engine.
Cloud SQL הוא שירות מנוהל של מסד נתונים, שבעזרתו אפשר ליצור, לתחזק ולנהל מסדי נתונים רלציוניים בענן.
Google Kubernetes Engine היא דרך פשוטה לפרוס, לשנות את קנה המידה ולנהל את Kubernetes באופן אוטומטי.
מידע על חיבור של Google Kubernetes Engine ל-Cloud SQL
כדי לגשת למכונת Cloud SQL מאפליקציה שפועלת ב-Google Kubernetes Engine, אפשר להשתמש בשרת proxy ל-Cloud SQL Auth (עם כתובת IP ציבורית או פרטית) או להתחבר ישירות באמצעות כתובת IP פרטית.
שרת proxy ל-Cloud SQL Auth הוא הדרך המומלצת להתחבר ל-Cloud SQL, גם כשמשתמשים בכתובת IP פרטית. הסיבה לכך היא ששרת ה-proxy ל-Cloud SQL Auth מספק הצפנה חזקה ואימות באמצעות IAM, שיכולים לעזור לשמור על אבטחת מסד הנתונים.
חיבורים למסדי נתונים צורכים משאבים בשרת ובאפליקציה שמבצעת את החיבור. כדי לצמצם את טביעת הרגל של האפליקציה ולהקטין את הסיכוי לחרוג ממגבלות החיבור ב-Cloud SQL, מומלץ תמיד להשתמש בשיטות טובות לניהול חיבורים. איך מנהלים חיבורים למסדי נתונים
לפני שמתחילים
כדי להתחבר ל-Cloud SQL, צריך:
אשכול GKE, עם כלי שורת הפקודה
kubectlמותקן ומוגדר לתקשורת עם האשכול.לקבלת עזרה בתחילת העבודה עם GKE, אפשר לעיין במאמר פריסת אפליקציות לאשכולות GKE.
כדי להתחבר באמצעות כתובת IP פרטית, אשכול GKE צריך להיות VPC-native ומקושר לאותה רשת ענן וירטואלי פרטי (VPC) כמו מכונת Cloud SQL.
נוצרה מכונה.
למידע נוסף על יצירת מכונה של Cloud SQL, תוכלו לקרוא את המאמר יצירת מכונות.
חשבון משתמש ב-PostgreSQL שהוגדר במופע.
האפליקציה תשתמש בחשבון הזה כדי להתחבר למסד הנתונים. לקבלת עזרה ביצירת חשבון משתמש, אפשר לקרוא את המאמר יצירת משתמש.
מידע על Kubernetes Secrets
ב-Kubernetes, Secrets הם דרך מאובטחת להעברת פרטי הגדרה לאפליקציה. אפשר ליצור סוד עם פרטים כמו שם מסד הנתונים, המשתמש והסיסמה, שאפשר להחדיר לאפליקציה כמשתני סביבה.
יש הרבה דרכים שונות להשתמש ב-Secrets, בהתאם לסוג החיבור:
- סוד של פרטי כניסה למסד נתונים כולל את שם משתמש מסד הנתונים שאליו מתחברים ואת הסיסמה של המשתמש למסד הנתונים.
- אם מתחברים באמצעות שרת proxy ל-Cloud SQL Auth, אפשר להשתמש ב-Secret כדי לשמור את קובץ פרטי הכניסה של חשבון השירות.
- אם מתחברים באמצעות כתובת IP פרטית, אפשר להשתמש ב-Secret כדי לציין את כתובת ה-IP הפרטית של מכונת Cloud SQL.
דוגמאות מלאות לשימוש ב-Secrets מופיעות במאגרי GitHub שמפורטים בהמשך הדף.
יצירת אובייקט Secret
יוצרים את אובייקטי הסוד באמצעות הפקודה
kubectl create secret.כדי ליצור סוד של פרטי כניסה למסד נתונים:
kubectl create secret generic <YOUR-DB-SECRET> \ --from-literal=username=<YOUR-DATABASE-USER> \ --from-literal=password=<YOUR-DATABASE-PASSWORD> \ --from-literal=database=<YOUR-DATABASE-NAME>אחרי שיוצרים את האובייקטים, אפשר לראות אותם בקטע Configuration בדף Google Kubernetes Engine בCloud de Confiance מסוף.
התחברות ל-Cloud SQL באמצעות שרת proxy ל-Cloud SQL Auth
כשמתחברים באמצעות שרת proxy ל-Cloud SQL Auth, שרת ה-proxy ל-Cloud SQL Auth מתווסף ל-pod באמצעות תבנית מאגר sidecar. קונטיינר שרת ה-proxy ל-Cloud SQL Auth נמצא באותו פוד כמו האפליקציה, מה שמאפשר לאפליקציה להתחבר לשרת ה-proxy ל-Cloud SQL Auth באמצעות localhost, וכך לשפר את האבטחה והביצועים.
מידע נוסף על שרת proxy ל-Cloud SQL Auth זמין במאמר מידע על שרת proxy ל-Cloud SQL Auth. מידע נוסף על עבודה עם פודים זמין במאמר סקירה כללית על פודים במסמכי Kubernetes.
כדי להתחבר באמצעות שרת proxy ל-Cloud SQL Auth, צריך את הדברים הבאים:
שם החיבור של המכונה של Cloud SQL.
שם החיבור של המופע זמין בדף Cloud SQL Instance details במסוף Cloud de Confiance או בפקודה
gcloud sql instances describe INSTANCE_ID.המיקום של קובץ המפתח שמשויך לחשבון שירות עם ההרשאות המתאימות למכונה שלכם ב-Cloud SQL.
מידע נוסף זמין במאמר יצירת חשבון שירות.
Cloud SQL Admin API מופעל.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.
ציון חשבון השירות לשרת ה-proxy ל-Cloud SQL Auth
השלב הראשון בהפעלת Cloud SQL Auth Proxy ב-Google Kubernetes Engine הוא יצירת חשבון שירות של Google (GSA) שייצג את האפליקציה שלכם. מומלץ ליצור חשבון שירות ייחודי לכל אפליקציה, במקום להשתמש באותו חשבון שירות בכל מקום. המודל הזה מאובטח יותר כי הוא מאפשר להגביל את ההרשאות לכל אפליקציה בנפרד.
חשבון השירות של האפליקציה צריך לעמוד בקריטריונים הבאים:
- שייכים לפרויקט שבו מופעל Cloud SQL Admin API
- קיבל את תפקיד הלקוח ב-IAM של Cloud SQL (או תפקיד מקביל) בפרויקט שמכיל את המופע שאליו רוצים להתחבר
- אם מתחברים באמצעות כתובת IP פרטית, צריך להשתמש באשכול GKE מקורי של VPC, באותו VPC כמו מכונת Cloud SQL
צריך להגדיר את GKE כך שיספק את חשבון השירות ל-Cloud SQL Auth Proxy. יש שתי דרכים מומלצות לעשות זאת: Workload Identity או קובץ מפתח של חשבון שירות.
Workload Identity
אם אתם משתמשים ב-Google Kubernetes Engine, השיטה המומלצת היא להשתמש בתכונה Workload Identity של GKE. השיטה הזו מאפשרת לקשר חשבון שירות של Kubernetes (KSA) לחשבון שירות של Google (GSA). לאחר מכן, האפליקציות יוכלו לגשת ל-GSA באמצעות ה-KSA התואם.
חשבון שירות של Google (GSA) הוא זהות IAM שמייצגת את האפליקציה שלכם ב-Google Cloud. באופן דומה, חשבון שירות של Kubernetes (KSA) הוא זהות שמייצגת את האפליקציה שלכם באשכול Google Kubernetes Engine.
Workload Identity מקשר בין KSA ל-GSA, כך שכל פריסה עם ה-KSA הזה תאומת כ-GSA באינטראקציות שלה עם Google Cloud.
- הפעלת Workload Identity באשכול
בדרך כלל, לכל אפליקציה יש זהות משלה שמיוצגת על ידי צמד של KSA ו-GSA. כדי ליצור KSA לאפליקציה, מריצים את הפקודה
kubectl apply -f service-account.yaml:מפעילים את קישור ה-IAM בין YOUR-GSA-NAME לבין YOUR-KSA-NAME:
gcloud iam service-accounts add-iam-policy-binding \ --role="roles/iam.workloadIdentityUser" \ --member="serviceAccount:YOUR-GOOGLE-CLOUD-PROJECT.s3ns.svc.id.goog[YOUR-K8S-NAMESPACE/YOUR-KSA-NAME]" \ YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.s3ns.iam.gserviceaccount.com
כדי להשלים את הקישור, מוסיפים הערה ל-YOUR-KSA-NAME:
kubectl annotate serviceaccount \ YOUR-KSA-NAME \ iam.gke.io/gcp-service-account=YOUR-GSA-NAME@YOUR-GOOGLE-CLOUD-PROJECT.s3ns.iam.gserviceaccount.com
לסיום, חשוב לציין את חשבון השירות לאובייקט k8s.
קובץ מפתח של חשבון שירות
לחלופין, אם אי אפשר להשתמש ב-Workload Identity, התבנית המומלצת היא להטמיע קובץ מפתח של חשבון שירות ב-pod של Cloud SQL Auth Proxy ולהשתמש בדגל --credentials-file.
יוצרים קובץ פרטי כניסה למפתח של חשבון השירות:
gcloud iam service-accounts keys create ~/key.json \ --iam-account=YOUR-SA-NAME@project-id.s3ns.iam.gserviceaccount.com
הופכים את המפתח של חשבון השירות לסוד ב-k8s:
kubectl create secret generic YOUR-SA-SECRET \ --from-file=service_account.json=~/key.json
מציבים את הסוד כנפח מתחת ל-
spec:לאובייקט k8s:פועלים לפי ההוראות בקטע הבא כדי לגשת לנפח מה-pod של Cloud SQL Auth Proxy.
הפעלת שרת proxy ל-Cloud SQL Auth בתבנית sidecar
מומלץ להפעיל את שרת ה-proxy ל-Cloud SQL Auth בתבנית sidecar (כמאגר נוסף שמשתף פוד עם האפליקציה). אנחנו ממליצים על האפשרות הזו במקום להפעיל את התוסף כשירות נפרד, מכמה סיבות:
- מונע חשיפה מקומית של תעבורת ה-SQL. שרת ה-proxy ל-Cloud SQL Auth מספק הצפנה בחיבורים יוצאים, אבל צריך להגביל את החשיפה בחיבורים נכנסים.
- מונעים נקודת כשל יחידה. הגישה של כל אפליקציה למסד הנתונים שלכם היא נפרדת מהגישה של האפליקציות האחרות, ולכן המערכת עמידה יותר.
- הגישה לשרת ה-proxy ל-Cloud SQL Auth מוגבלת, כך שאתם יכולים להשתמש בהרשאות IAM לכל אפליקציה במקום לחשוף את מסד הנתונים לכל האשכול.
התבנית הזו מאפשרת לכם להגדיר את היקף הבקשות למשאבים בצורה מדויקת יותר, כי Cloud SQL Auth Proxy צורך משאבים באופן לינארי בהתאם לשימוש. כך תוכלו להגדיר את היקף הבקשות למשאבים בהתאם לאפליקציות שלכם, ככל שהאפליקציה תגדל.
מוסיפים את שרת ה-proxy ל-Cloud SQL Auth להגדרת ה-pod בקטע
initContainers, אלא אם אתם משתמשים ב-Cloud Service Mesh או ב-Istio.אם אתם משתמשים ב-Cloud Service Mesh או ב-Istio, צריך להוסיף את שרת ה-proxy ל-Cloud SQL Auth בקטע
containers.initContainerscontainersאם אתם משתמשים במפתח של חשבון שירות, צריך לציין את נפח הסוד ולהוסיף את הדגל
--credentials-fileלפקודה:
אם אתם משתמשים באימות מסד נתונים ב-IAM, אתם צריכים להוסיף לחשבון השירות קשרי מדיניות של IAM. נותנים לחשבון השירות שבו נעשה שימוש בשרת ה-proxy לאימות של Cloud SQL את התפקידים 'משתמש במופע Cloud SQL' (
roles/cloudsql.instanceUser) ו'לקוח Cloud SQL' (roles/cloudsql.client).כדי להתחבר למכונה באמצעות אימות מסד נתונים של IAM באופן אוטומטי, מפעילים את Cloud SQL Auth Proxy עם הדגל
--auto-iam-authn.
- לבסוף, מגדירים את האפליקציה להתחבר באמצעות
127.0.0.1בכל DB_PORT שהוגדר בקטע הפקודה.
קובצי הגדרות לדוגמה מלאים:
Workload Identity
מפתח לחשבון השירות
התחברות ל-Cloud SQL בלי שרת proxy לאימות של Cloud SQL
אפשר להתחבר מאשכול GKE מקורי של VPC למכונת Cloud SQL באותו VPC באמצעות כתובת IP פרטית ללא שרת proxy ל-Cloud SQL Auth, אבל זה פחות מאובטח.
יוצרים סוד עם כתובת ה-IP הפרטית של המכונה:
kubectl create secret generic <YOUR-PRIVATE-IP-SECRET> \ --from-literal=db_host=<YOUR-PRIVATE-IP-ADDRESS>לאחר מכן, מוסיפים את הסוד למאגר התגים של האפליקציה:
לבסוף, מגדירים את האפליקציה להתחבר באמצעות כתובת ה-IP מתוך משתנה הסביבה
DB_HOST. תצטרכו להשתמש ביציאה הנכונה עבור PostgreSQL: 5432
קובץ תצורה לדוגמה מלא:
כתובת IP פרטית
פתרון בעיות
דרושה לך עזרה? לקבלת עזרה בפתרון בעיות בשרת ה-proxy, אפשר לעיין במאמר בנושא פתרון בעיות בחיבורים של שרת proxy ל-Cloud SQL Auth או בדף תמיכה ב-Cloud SQL.