מידע על Private Service Connect

טייס אוטומטי רגילה

בדף הזה יש סקירה כללית של Private Service Connect באשכולות Google Kubernetes Engine ‏ (GKE).

בדף הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את הנושאים הבאים:

• יסודות הרשתות, כמו כתובות IP
• רשתות VPC

סקירה כללית

‫Private Service Connect ‏ (PSC) הוא חלק מתשתית הרשת של Google Cloud, שמאפשרת לאשכולות GKE שלכם לצרוך באופן מאובטח ופרטי שירותים שמארחים ב- Google Cloud או בסביבות מקומיות, בלי לחשוף את השירותים האלה לציבור. עם PSC,‏ Google Cloud מקצה כתובת IP פנימית למישור הבקרה כדי להעביר בקשות ל-GKE cluster management API,‏ וכך מאפשר לכם לנהל את האשכולות בלי שהתנועה תעבור באינטרנט הציבורי. ‫PSC מספק מסגרת עקבית שעוזרת לחבר בין רשתות שונות באמצעות גישה של Service Networking, ומאפשרת לבעלים של שירותים מנוהלים ולצרכני שירותים לתקשר באמצעות כתובות IP פנימיות בתוך VPC.

באשכול GKE שמשתמש בתשתית PSC, כל התקשורת בין מישור הבקרה של האשכול לבין הצמתים מתבצעת באופן פרטי. אתם יכולים גם לבודד את האשכול ברמות של מישור הבקרה ומאגר הצמתים, בלי לנהל הגדרות מורכבות של קישור VPC בין רשתות שכנות (peering).

היתרונות של אשכולות שמופעל בהם Private Service Connect

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

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

יכולת התאמה לעומס (scalability): כדי לעמוד בדרישות גבוהות למשאבים, אתם יכולים ליצור עד 1,000 אשכולות שמופעל בהם PSC. לעומת זאת, אם משתמשים בקישור (peering) בין רשתות VPC שכנות, אפשר ליצור עד 75 אשכולות לכל אזור או אזור משנה.

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

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

מגבלות

למישור הבקרה יש נקודת קצה פנימית ונקודת קצה חיצונית. נקודת הקצה הפנימית של מישור הבקרה לא תומכת בכתובות IP פנימיות בכתובות URL של ווּבּהוקים שאתם מגדירים. אם יש לכם webhook עם כתובת IP פנימית בכתובת ה-URL, תוכלו לפתור את בעיית חוסר התאימות הזו באמצעות השלבים הבאים:

1. יצירת שירות ללא ראש (headless) בלי סלקטור כדי לנהל ידנית את נקודות הקצה שאליהן השירות הזה מפנה תנועה. בדוגמה הבאה מוצג שירות עם webhook שמקשיב ליציאה 3000:

   apiVersion: v1
   kind: Service
   metadata:
     name: <service-name>
   spec:
     clusterIP: None
     ports:
     - port: 3000
       targetPort: 3000
   

2. יוצרים נקודת קצה תואמת ליעד הנדרש. לדוגמה, אם ה-webhook שלכם משתמש בכתובת ה-IP הפנימית 10.0.0.1 בכתובת ה-URL, תוכלו ליצור את נקודת הקצה הבאה:

   apiVersion: v1
   kind: Endpoints
   metadata:
     name: <service-name>
   subsets:
   - addresses:
     - ip: 10.0.0.1
     ports:
     - port: 3000
   

3. מעדכנים את הגדרות ה-webhook: בהגדרות ה-webhook, מוחקים את כתובת ה-URL עם כתובת ה-IP הפנימית ומוסיפים את השירות שיצרתם בשלב הראשון. לדוגמה:

   ...
   kind: ValidatingWebhookConfiguration
   ...
   webhooks:
   - name: <webhook-name>
   ...
     clientConfig:
       service:
         name: <service-name>
         namespace: <namespace>
         path: "/validate"
         port: 3000
   

   בדוגמה הקודמת, ל-webhook יש נתיב של /validate והוא מאזין ליציאה 3000.

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

   ...
   kind: ValidatingWebhookConfiguration
   ...
   webhooks:
   - name: <webhook-name>
   ...
     clientConfig:
       ...
       caBundle: <new-certificate>
   ...
   

ארכיטקטורה

התרשים הבא מציג סקירה כללית של הארכיטקטורה של אשכול באמצעות PSC:

תרשים: ארכיטקטורת Private Service Connect

אלה הרכיבים העיקריים של אשכול שמופעל בו PSC:

מישור הבקרה: לכל אשכול GKE יש שרת Kubernetes API שמנוהל על ידי מישור הבקרה. מישור הבקרה פועל במכונה וירטואלית (VM) שנמצאת ברשת VPC בפרויקט שמנוהל על ידי Google. ל клаסטר אזורי יש כמה עותקים משוכפלים של מישור הבקרה, וכל אחד מהם פועל במכונה וירטואלית משלו.

למישור הבקרה יש נקודת קצה פנימית (נקודת קצה של Private Service Connect) לתקשורת פנימית בין אשכולות ונקודת קצה חיצונית. אפשר להשבית את נקודת הקצה החיצונית. התנועה בין הצמתים לבין מישור הבקרה מנותבת באופן מלא באמצעות כתובות IP פנימיות. מידע על הגדרת האשכול זמין במאמר אימות ההגדרה של מישור הבקרה.

רשת VPC: רשת וירטואלית שבה יוצרים רשתות משנה עם טווחי כתובות IP פנימיות, במיוחד לצמתים ול-Pods של האשכול.

נקודת קצה מסוג Private Service Connect: זוהי נקודת הקצה הפנימית במישור הבקרה של האשכול, שנמצאת ברשת ה-VPC של הפרויקט. נקודת הקצה של ה-PSC משמשת כנקודת הכניסה למישור הבקרה של האשכול.

צירוף שירות: צירוף השירות הוא משאב שיוצר חיבור פרטי ומאובטח בין רשת ה-VPC שלכם לבין רשת ה-VPC של היצרן. כפי שמוצג בתרשים הקודם, נקודת הקצה (endpoint) של PSC ניגשת לקובץ המצורף לשירות דרך חיבור פרטי ומאפשרת תנועה בין הצמתים לבין מישור הבקרה.

הגדרת גישה לאשכול

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

גישה למישור הבקרה

• גישה למישור הבקרה באמצעות נקודת קצה (endpoint) מבוססת-DNS בלבד (מומלץ). אפשר לאשר בקשות לגישה למישור הבקרה על ידי יצירת כללי מדיניות הרשאה ב-IAM.

• גישה למישור הבקרה באמצעות נקודות קצה מבוססות-IP בלבד. אתם יכולים להשתמש בנקודות הקצה החיצוניות והפנימיות של מישור הבקרה, או להשבית את נקודת הקצה החיצונית כדי לאפשר גישה רק מכתובות IP שמורות של Google (למטרות ניהול אשכולות) ומכתובות IP פנימיות של אשכולות GKE.

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

• גישה למישור הבקרה עם נקודות קצה מבוססות DNS ונקודות קצה מבוססות IP.

גישה לצומת באשכול

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

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

• במקרים של אשכולות רגילים, אתם יכולים להקצות לחלק מהצמתים כתובות IP פנימיות, ולחלק מהצמתים כתובות IP חיצוניות.

אשכולות עם Private Service Connect

כדי לבדוק אם האשכול משתמש ב-Private Service Connect, מריצים את הפקודה gcloud container clusters describe. אם באשכול שלכם נעשה שימוש ב-Private Service Connect, למשאב privateClusterConfig יש את הערכים הבאים:

• השדה peeringName ריק או לא קיים.
• לשדה privateEndpoint הוקצה ערך.

כדי להפעיל את ה-PSC באשכול, צריך ליצור את האשכול בגרסה 1.29 ואילך. בגרסאות 1.28 ומטה, צריך ליצור את האשכול בלי להפעיל צמתים פרטיים. תמיד אפשר לעדכן את ההגדרה הזו ולהפעיל צמתים פרטיים אחרי יצירת האשכול.

אזהרה: באשכולות עם Private Service Connect שמשתמשים בצמתים ציבוריים שנוצרו לפני 30 בינואר 2022, נעשה שימוש בנקודת קצה (endpoint) ובכלל העברה של Private Service Connect. שני המשאבים נקראים gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe ומאפשרים למישור הבקרה ולצמתים להתחבר באופן פרטי. מערכת GKE יוצרת את המשאבים האלה באופן אוטומטי ללא עלות. אם תסירו את המשאבים האלה, יתרחשו בעיות ברשת של האשכול, כולל השבתה.

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

• מידע נוסף על התאמה אישית של בידוד רשת ב-GKE