פריסה לאשכול Google Kubernetes Engine

במאמר הזה מוסבר איך לפרוס את האפליקציות שלכם באשכולות של Google Kubernetes Engine.

באמצעות Cloud Deploy אפשר לפרוס את עומסי העבודה שמבוססים על קונטיינרים בכל אשכול של Google Kubernetes Engine. כל התכונות של Cloud Deploy נתמכות כשפורסים ליעדי GKE.

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

בקובץ skaffold.yaml הזה, ה-stanza‏ deploy כולל את kubectl, שמציין ש-Skaffold מבצע עיבוד עבור Kubernetes‏ (GKE) ופריסה אל Kubernetes‏ (GKE). מתחת לזה מופיעים קובצי המניפסט שבהם אתם משתמשים באפליקציה הזו.

יצירת הגדרת היעד

אפשר להגדיר כל יעד בקובץ ה-YAML של צינור ההפצה, או בקובץ נפרד. בנוסף, אפשר להגדיר יותר מיעד אחד באותו קובץ, אבל הם צריכים להיות בפסקאות kind: Target שונות.

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

בהגדרת היעד, יוצרים קטע gke כדי להפנות לאשכול GKE:

gke:
 cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

מזהה משאב GKE הזה כולל את הרכיבים הבאים:

  • ‫[project_name] הוא שם הפרויקט Google Cloud שבו מריצים את האשכול הזה.

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

  • ‫[location] הוא האזור שבו נוצר האשכול.

  • ‫[cluster_name] הוא השם שניתן לאשכול כשהוא נוצר.

    אפשר למצוא את השם הזה ברשימת האשכולות של הפרויקט בGoogle Cloud מסוף.

    רשימת האשכולות במסוף Google Cloud

הדוגמה הבאה היא של הגדרת יעד שמפנה לאשכול GKE:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development cluster
      gke:
       cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster

יצירת הגדרת Skaffold

בקטע הזה מוסבר על דוגמה להגדרת Skaffold פשוטה שאפשר להשתמש בה כשפורסים לאשכול GKE.

הקובץ הבא הוא דוגמה לקובץ skaffold.yaml לפריסה באשכול GKE:

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: gke-application
manifests:
  rawYaml:
  - deployment.yaml
deploy:
  kubectl: {}

במאמר שימוש ב-Skaffold עם Cloud Deploy מוסבר בפירוט איך להשתמש ב-Skaffold עם צינור העברת הנתונים.

הכנת מניפסטים של Kubernetes

כדי לפרוס את האפליקציה ב-GKE, מספקים ל-Cloud Deploy מניפסט Kubernetes אחד או יותר, שעובר רינדור ואז מוחל על אשכול היעד או על האשכולות כדי לפרוס את האפליקציה.

אם אין לכם את קובצי המניפסט האלה, תצטרכו ליצור אותם לפני שתנסו לפרוס באמצעות צינור העברת נתונים של Cloud Deploy.

אתם יכולים להשתמש ב-Kustomize או ב-Helm כדי ליצור מניפסטים. אפשר גם להשתמש ב-Kustomize או ב-Helm אם המניפסטים שלכם מבוססים על תבניות וצריך לעבד אותם.

איך הכל משתלב יחד

אחרי שיש לכם מניפסטים של Kubernetes, הגדרות של skaffold.yaml והגדרות של יעדים ב-Cloud Deploy, ורשמתם את היעדים כמשאבים ב-Cloud Deploy, אתם יכולים להפעיל את צינור האספקה כדי ליצור גרסת הפצה ולהעביר אותה דרך התקדמות היעדים שהוגדרו בצינור.

פריסה באמצעות שרת proxy

אפשר לציין proxy לאשכול היעד של GKE. ההגדרה הזו מיועדת לארגונים שהוגדרה להם גישה לאשכולות רק דרך שרת proxy של HTTP.

כדי לעשות זאת, מוסיפים את המאפיין proxyUrl ל-stanza‏ gke בהגדרת היעד:

gke:
 cluster: projects/my-app/locations/us-central1/clusters/my-app-dev-cluster
 proxyUrl: [URL]

כאשר URL היא כתובת ה-URL של ה-proxy.

פריסה לאשכול פרטי

אפשר לפרוס את האפליקציה לאשכול GKE פרטי, באחת משלוש דרכים:

שימוש בנקודת קצה של DNS

זו הדרך הפשוטה ביותר להתחבר לאשכול פרטי.

  1. הפעלת נקודת הקצה מבוססת ה-DNS באשכול.

  2. בהגדרת היעד, בקטע gke, מגדירים את הערך dnsEndpoint ל-true.

    אם לא מוגדרת לכם נקודת קצה מבוססת-IP באשכול, אתם יכולים לדלג על השלב הזה. Cloud Deploy יתחבר לנקודת הקצה של ה-DNS כברירת מחדל, כי זו נקודת הקצה היחידה של מישור הבקרה.

שימוש ברשת של ענן וירטואלי פרטי (VPC)

אפשר להגדיר יעד לפריסה באשכול GKE פרטי שמחובר לרשת ענן וירטואלי פרטי:

  1. יצירת אשכול פרטי

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

    אם אתם מתכננים להשתמש בכתובת ה-IP הפנימית של יעד האשכול הפרטי, אתם צריכים להגדיר את internalIp ל-true בקטע gke בהגדרת היעד.

  2. ב-Cloud Build, יוצרים מאגר פרטי של סביבות עבודה שאפשר להשתמש בו כדי לפרוס לאשכול הפרטי הזה.

  3. הגדרת סביבת ההפעלה לשימוש במאגר הפרטי הזה.

    חובה להשתמש במאגר הזה בשביל RENDER. אפשר להשתמש בו גם למשך DEPLOY וגם למשך VERIFY. דוגמה לשימוש בתגי RENDER ו-DEPLOY:

    executionConfigs:
- usages:
  - RENDER
  - DEPLOY
  workerPool: "projects/p123/locations/us-central1/workerPools/wp123"

מידע נוסף זמין במאמרים גישה לאשכולות פרטיים של GKE ממאגרי Cloud Build פרטיים באמצעות Identity Service for GKE וגישה לאשכולות פרטיים של GKE באמצעות מאגרי Cloud Build פרטיים.

שיקולים לגבי פרויקטים והרשאות

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

  • כש-Cloud Deploy ומאגר העובדים נמצאים בפרויקטים נפרדים

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

לחשבון השירות של ההרצה צריכות להיות גם הרשאות גישה לקטגוריה של Cloud Storage.

  • כאשר מאגר העובדים והאשכול נמצאים בפרויקטים נפרדים

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

שימוש ביעדים של אשכולות GKE מצורפים וחיבור לשער

אפשר להגדיר יעד לפריסה באשכול GKE פרטי עם יעדים שמשתמשים באשכולות שמצורפים ל-GKE ובשער Connect.

בגישה הזו לא צריך להשתמש בחיבורים של ענן וירטואלי פרטי או של רשת וירטואלית פרטית.

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