העברת אירועים מ-Cloud Storage ל-GKE

טריגר של Eventarc הוא הצהרה על כך שיש לכם עניין באירוע או בקבוצת אירועים. אתם יכולים להגדיר ניתוב אירועים על ידי ציון מסננים לטריגר, כולל מקור האירוע ושירות היעד של Google Kubernetes Engine ‏ (GKE) שפועל באשכול GKE. שימו לב: יעדים יכולים לכלול רק שירותים שפועלים באשכולות GKE (ציבוריים או פרטיים) עם נקודות קצה ציבוריות. כדי לטרגט שירותים באשכולות GKE עם נקודות קצה פרטיות, צריך לנתב אירועים אל נקודות קצה פנימיות של HTTP.

‫Eventarc מעביר אירועים למקבל האירועים בפורמט CloudEvents באמצעות בקשת HTTP.

ההוראות האלה מסבירות איך להגדיר ניתוב אירועים לשירות GKE שמופעל על ידי אירועCloud Storage ישיר. פרטים נוספים זמינים ברשימה של אירועים ישירים נתמכים.

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

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

ארכיטקטורה של אירועים ב-Eventarc שמכוונים ליעדים ב-GKE

איחוד זהויות של עומסי עבודה ל-GKE

יכול להיות שאפליקציות שפועלות ב-GKE יצטרכו גישה ל-Google Cloud APIs. איחוד זהויות של עומסי עבודה ל-GKE מאפשר לחשבון שירות של Kubernetes באשכול GKE לפעול כחשבון שירות של IAM. פודים שמשתמשים בחשבון השירות המוגדר של Kubernetes מאמתים באופן אוטומטי כחשבון השירות של IAM כשהם ניגשים לממשקי ה-API של Google Cloud . באמצעות איחוד זהויות של עומסי עבודה ל-GKE, אתם יכולים להקצות זהויות והרשאות נפרדות ומפורטות לכל אפליקציה באשכול. חשוב לשים לב שצריך להעניק הרשאות ספציפיות לחשבון השירות של טריגר Eventarc. במאמר הזה מוסבר איך יוצרים חשבון שירות.

מידע נוסף על הפעלה והגדרה של איחוד זהויות של עומסי עבודה ל-GKE באשכולות GKE זמין במאמר אימות ל- Google Cloud APIs מתוך עומסי עבודה של GKE.

העברת אירועים

הכלי להעברת אירועים של Eventarc מושך אירועים חדשים מ-Eventarc ומעביר אותם ליעד GKE. הרכיב הזה משמש כמתווך בין שכבת התעבורה של Pub/Sub לבין שירות GKE. הוא פועל בשירותים קיימים ותומך גם בשירותי איתות (כולל שירותים שלא נחשפים מחוץ לאשכול שמנוהל במלואו), תוך פישוט ההגדרה והתחזוקה. ברמת הרשת, כדי לקבל אירועים בשירות GKE, לא צריך לפתוח את השירות לתעבורה חיצונית כי כל האירועים מועברים ממקור שנמצא באותו אשכול GKE.

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

לכל טריגר שמפנה ליעד ב-GKE, מעביר האירועים (pod של gke-forwarder שהוגדר באופן ספציפי) מבצע את הפעולות הבאות:

  1. הוא משתמש ב-Pub/Sub API כדי לפתוח חיבור StreamingPull לטרנספורטר של הטריגר (נושא ומינוי ב-Pub/Sub), ומקבל אירועים כשהם זמינים.

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

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

פתרון בעיות

כדי לפתור בעיות שבהן אתם עלולים להיתקל כשאתם משתמשים ב-Eventarc ל-GKE, קראו את המאמר פתרון בעיות ב-Eventarc ל-Google Kubernetes Engine (GKE).

הכנה ליצירת טריגר

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

המסוף

  1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- או יוצרים Google Cloud אותו.

    כניסה לדף לבחירת הפרויקט

  2. מפעילים את ממשקי ה-API של Eventarc,‏ Eventarc Publishing,‏ Google Kubernetes Engine ומנהל המשאבים.

    הפעלת ממשקי ה-API

  3. אם רלוונטי, מפעילים את ה-API שקשור לאירועים הישירים. לדוגמה, כדי להשתמש ב Cloud Storage אירועים, צריך להפעיל אתCloud Storage API.

  4. אם עדיין אין לכם חשבון שירות בניהול המשתמש, צרו חשבון כזה והקצו לו את התפקידים וההרשאות שנדרשים כדי ש-Eventarc יוכל לנהל אירועים בשירות היעד.

    1. במסוף Google Cloud , נכנסים לדף Create service account.

      כניסה לדף Create service account

    2. בוחרים את הפרויקט הרצוי.

    3. כותבים שם בשדה Service account name. השדה Service account ID ימולא במסוף Google Cloud בהתאם לשם הזה.

      כותבים תיאור בשדה Service account description. לדוגמה, Service account for event trigger.

    4. לוחצים על Create and continue.

    5. כדי לספק גישה מתאימה, ברשימה Select a role בוחרים את התפקידים הנדרשים בניהול זהויות והרשאות גישה (IAM) שרוצים לתת לחשבון השירות. מידע נוסף זמין במאמר תפקידים והרשאות ליעדי GKE.

      כדי להוסיף עוד תפקידים, לוחצים על Add another role ומוסיפים אותם אחד אחרי השני.

    6. לוחצים על Continue.

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

  5. מקצים את התפקיד "פרסום הודעות ב-Pub/Sub" לסוכן השירות של Cloud Storage. בדרך כלל זה הנתיב service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com. אפשר לאחזר את כתובת האימייל של סוכן השירות של Cloud Storage.

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM

    2. בשורה של סוכן השירות של Cloud Storage, לוחצים על Edit principal. (אם סוכן השירות לא מופיע, עוברים לשלב הבא). החלונית עריכת הרשאת גישה נפתחת.

      1. לוחצים על Add another role ואז מחפשים את התפקיד Pub/Sub Publisher.
      2. בוחרים את התפקיד.
      3. לוחצים על Save.

    3. אם סוכן השירות לא מופיע ברשימה, לוחצים על Grant access. החלונית הענקת גישה תיפתח.

      1. בשדה New principals, מזינים את כתובת האימייל של סוכן השירות.
      2. ברשימה Select a role, מחפשים את התפקיד Pub/Sub Publisher.
      3. בוחרים את התפקיד.
      4. לוחצים על שמירה.

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מפעילים את ממשקי ה-API של Eventarc,‏ Eventarc Publishing,‏ Google Kubernetes Engine ומנהל המשאבים.

    gcloud services enable eventarc.googleapis.com \
    eventarcpublishing.googleapis.com \
    container.googleapis.com \
    cloudresourcemanager.googleapis.com

  3. אם רלוונטי, מפעילים את ממשק ה-API שקשור לאירועים הישירים. לדוגמה, לאירועים של Cloud Storage , מפעילים את storage.googleapis.com.

  4. אם עדיין אין לכם חשבון שירות שמנוהל על ידי המשתמש, אתם צריכים ליצור אותו ולהקצות לו את התפקידים וההרשאות הנדרשים כדי ש-Eventarc יוכל לנהל אירועים ביעד GKE.

    1. יוצרים את חשבון השירות:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      מחליפים את SERVICE_ACCOUNT_NAME בשם של חשבון השירות. הוא צריך להיות באורך שבין 6 ל-30 תווים, והוא יכול לכלול תווים אלפאנומריים ומקפים. אחרי שיוצרים חשבון שירות, אי אפשר לשנות את השם שלו.

    2. מעניקים את התפקידים או ההרשאות הנדרשים לניהול זהויות והרשאות גישה (IAM). מידע נוסף זמין במאמר תפקידים והרשאות ליעדי GKE.

  5. מקצים לחשבון השירות של Cloud Storage את התפקיד pubsub.publisher:

    SERVICE_ACCOUNT="$(gcloud storage service-agent --project=PROJECT_ID)"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/pubsub.publisher"

הפעלת יעדים ב-GKE

כדי לאפשר ל-Eventarc לנהל משאבים באשכול GKE, צריך להפעיל יעדי GKE ולקשר את סוכן השירות של Eventarc לתפקידים הנדרשים.

  1. מפעילים יעדי GKE ל-Eventarc:

    gcloud eventarc gke-destinations init

  2. בהנחיה לקשירת התפקידים הנדרשים, מזינים y.

    התפקידים הבאים מקושרים:

    • roles/compute.viewer
    • roles/container.developer
    • roles/iam.serviceAccountAdmin

יצירת טריגר

אפשר ליצור טריגר Eventarc באמצעות Google Cloud CLI או דרך מסוף Google Cloud .

המסוף

  1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

    כניסה לדף Triggers

  2. לוחצים על Create trigger (יצירת ביטוי להפעלה).
  3. מקלידים Trigger name.

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

  4. בשדה Trigger type, בוחרים באפשרות Google sources.
  5. ברשימה Event provider בוחרים באפשרות Cloud Storage.

    שימו לב: יכול להיות שלשם של ספק האירועים שמופיע Google Cloud במסמכי התיעוד המשויכים אין את הקידומת Cloud או Google Cloud. לדוגמה, במסוף, Memorystore for Redis נקרא Google Cloud Memorystore for Redis.

  6. ברשימה סוג האירוע, מתוך האירועים ישירים, בוחרים סוג אירוע:
    • ‫google.cloud.storage.object.v1.archived: האירוע נשלח כשגרסה פעילה של אובייקט הופכת לגרסה לא עדכנית. מידע נוסף זמין במאמר ניהול גרסאות של אובייקטים.
    • ‫google.cloud.storage.object.v1.delete: האירוע נשלח כשמתבצעת מחיקה רכה של אובייקט. מידע נוסף זמין במאמר בנושא מחיקה זמנית.
    • ‫google.cloud.storage.object.v1.finalized: האירוע נשלח כשנוצר אובייקט חדש (או כשמתבצעת החלפה של אובייקט קיים ונוצרת גנרציה חדשה של האובייקט הזה) בדלי.
    • ‫google.cloud.storage.object.v1.metadataUpdated: האירוע נשלח כש[המטא-נתונים](/storage/docs/metadata) של אובייקט קיים משתנים.
  7. ברשימה סוג התוכן של נתוני האירועים, בוחרים את הקידוד של מטען הייעודי (payload) של האירוע.

    עבור אירועים ישירים מ Cloud Storage, הערך צריך להיות application/json.

  8. מציינים את המזהה הייחודי הגלובלי של הקטגוריה של Cloud Storage, או מחפשים אותו.

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

  9. בוחרים Region.

    טריגרים של Cloud Storage ל-Eventarc זמינים במיקומים של אזור יחיד, שני אזורים ומספר אזורים. שימו לב שהקטגוריה של Cloud Storage והטריגר של Eventarc חייבים להיות שייכים לאותו Google Cloudפרויקט ולאותו אזור או אזור גיאוגרפי נרחב.

    האירועים מועברים באמצעות התראות Pub/Sub מ-Cloud Storage. יכול להיות שתיגמר מכסת ההתראות לקטגוריה אם תגדירו יותר מדי התראות שרשומות באותה קטגוריה, כפי שמצוין בשגיאה Cloud Storage bucket ...: Pub/Sub notification limit reached. אפשר להגדיר עד 10 הגדרות של התראות בקטגוריה מסוימת, ועד 10 הגדרות של התראות להפעלה של אירוע ספציפי. מידע נוסף על מכסות ומגבלות זמין בדף מכסות ומגבלות ב-Cloud Storage.

  10. בוחרים את חשבון השירות שיפעיל את השירות או את תהליך העבודה.

    אפשר גם ליצור חשבון שירות חדש.

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

  11. ברשימה Event destination, בוחרים באפשרות Kubernetes Engine.
  12. בוחרים שירות.

    זה השם של השירות שמקבל את האירועים של הטריגר. השירות צריך להיות באותו פרויקט כמו הטריגר, והוא יקבל אירועים כבקשות HTTP POST שנשלחות לנתיב של כתובת ה-URL הבסיסית שלו (/), בכל פעם שהאירוע נוצר.

  13. אפשר גם לציין את נתיב כתובת ה-URL של השירות שאליו תישלח הבקשה הנכנסת.

    זהו הנתיב היחסי בשירות היעד שאליו צריך לשלוח את האירועים של הטריגר. לדוגמה: /, /route, route, route/subroute.

  14. אם רוצים להוסיף תווית, לוחצים על Add label. תוויות הן צמדי מפתח/ערך שעוזרים לכם לארגן אתGoogle Cloud המשאבים. מידע נוסף זמין במאמר מהן תוויות?
  15. לוחצים על יצירה.

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

gcloud

כדי ליצור טריגר, מריצים פקודת gcloud eventarc triggers create עם דגלים נדרשים ואופציונליים.

gcloud eventarc triggers create TRIGGER \
    --location=LOCATION \
    --destination-gke-cluster=DESTINATION_GKE_CLUSTER \
    --destination-gke-location=DESTINATION_GKE_LOCATION \
    --destination-gke-namespace=DESTINATION_GKE_NAMESPACE \
    --destination-gke-service=DESTINATION_GKE_SERVICE \
    --destination-gke-path=DESTINATION_GKE_PATH \
    --event-filters="type=EVENT_FILTER_TYPE" \
    --event-filters="bucket=BUCKET" \
    --service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com"

מחליפים את מה שכתוב בשדות הבאים:

  • TRIGGER: המזהה של הטריגר או מזהה מוגדר במלואו
  • ‫LOCATION: המיקום של הטריגר של Eventarc. לחלופין, אפשר להגדיר את המאפיין eventarc/location, לדוגמה gcloud config set eventarc/location us-central1.

    הקטגוריה של Cloud Storage חייבת להיות באותו Google Cloud פרויקט ואזור או אזור גיאוגרפי נרחב יותר שכולל מספר אזורים כמו הטריגר של Eventarc. מידע נוסף זמין במאמר מיקומי Eventarc.

  • ‫DESTINATION_GKE_CLUSTER: השם של אשכול GKE שבו פועל שירות היעד של GKE שמקבל אירועים.
  • ‫DESTINATION_GKE_LOCATION: (אופציונלי) האזור ב-Compute Engine של אשכול GKE שבו פועל שירות היעד של GKE. אם לא מציינים את האזור, המערכת מניחה שהאשכול הוא אזורי ונמצא באותו אזור של הטריגר.
  • ‫DESTINATION_GKE_NAMESPACE: (אופציונלי) מרחב השמות שבו פועל שירות היעד של GKE. אם לא מציינים מרחב שמות, המערכת משתמשת במרחב השמות default.
  • ‫DESTINATION_GKE_SERVICE: השם של שירות GKE שמקבל את האירועים להפעלת הטריגר. השירות יכול להיות בכל אחד מהמיקומים שנתמכים ב-GKE, והוא לא צריך להיות באותו מיקום כמו הטריגר. עם זאת, השירות צריך להיות באותו פרויקט כמו הטריגר והוא יקבל אירועים כבקשות HTTP POST שנשלחות לנתיב כתובת ה-URL הבסיסית שלו (/), בכל פעם שהאירוע נוצר.
  • ‫DESTINATION_GKE_PATH: (אופציונלי) הנתיב היחסי שאתם מציינים בשירות היעד של GKE, שאליו יישלחו האירועים של הטריגר. לדוגמה: /, /route, route, route/subroute.
  • ‫EVENT_FILTER_TYPE: המזהה של האירוע ב-Cloud Storage, שיכול להיות אחד מהבאים:
    • ‫google.cloud.storage.object.v1.finalized: האירוע נשלח כשנוצר אובייקט חדש בקטגוריה (או כשאובייקט קיים מוחלף ונוצר דור חדש של האובייקט הזה)
    • ‫google.cloud.storage.object.v1.archived: האירוע נשלח כשגרסה פעילה של אובייקט הופכת לגרסה לא עדכנית. מידע נוסף זמין במאמר בנושא ניהול גרסאות של אובייקטים.
    • ‫google.cloud.storage.object.v1.deleted: האירוע נשלח כשאובייקט נמחק באופן זמני. מידע נוסף זמין במאמר מחיקה רכה.
    • ‫google.cloud.storage.object.v1.metadataUpdated: האירוע נשלח כשהמטא-נתונים של אובייקט קיים משתנים.
  • ‫BUCKET הוא המזהה הייחודי הגלובלי של קטגוריית Cloud Storage.
  • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות שמנוהל על ידי המשתמש.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

הערות:

  • חובה להשתמש בדגלים הבאים:
    • --event-filters="type=EVENT_FILTER_TYPE"
    • --event-filters="bucket=BUCKET"
  • לכל טריגר יכולים להיות כמה מסנני אירועים, שמופרדים בפסיקים בדגל אחד --event-filters=[ATTRIBUTE=VALUE,...] או שאפשר לחזור על הדגל כדי להוסיף עוד מסננים. רק אירועים שתואמים לכל המסננים נשלחים ליעד. אין תמיכה בתווים כלליים לחיפוש ובביטויים רגולריים.
  • אחרי שיוצרים טריגר, אי אפשר לשנות את סוג המסנן של האירועים. כדי להגדיר סוג אירוע אחר, צריך ליצור טריגר חדש ולמחוק את הטריגר הישן.
  • האירועים נשלחים באמצעות התראות Pub/Sub מ-Cloud Storage. אם תגדירו יותר מדי התראות לאותה קטגוריה, יכול להיות שתחרגו ממגבלת ההתראות לקטגוריה, כפי שמצוין בשגיאה Cloud Storage bucket ...: Pub/Sub notification limit reached. אפשר להגדיר עד 10 הגדרות של התראות בקטגוריה מסוימת להפעלה של אירוע ספציפי. מידע נוסף על מכסות ומגבלות אפשר למצוא בדף המכסות והמגבלות של Cloud Storage.
  • באירועים ישירים מ- Cloud Storage, הקידוד של המטען הייעודי (payload) של האירוע הוא application/json.
  • הדגל --service-account משמש לציון כתובת האימייל בחשבון השירות בניהול זהויות והרשאות גישה (IAM) שמשויך לטריגר.

דוגמה:

gcloud eventarc triggers create helloworld-trigger \
    --location=us-central1 \
    --destination-gke-cluster=gke-events-cluster \
    --destination-gke-location=us-central1-a \
    --destination-gke-namespace=default \
    --destination-gke-service=helloworld-events \
    --destination-gke-path=/ \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=my-bucket" \
    --service-account=${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

הפקודה הזו יוצרת טריגר בשם helloworld-trigger לקטגוריית Cloud Storage‏ my-bucket ולאירוע שמזוהה כ-google.cloud.storage.object.v1.finalized.

Terraform

אפשר ליצור טריגר ליעד GKE באמצעות Terraform. פרטים נוספים זמינים במאמר יצירת טריגר באמצעות Terraform.

הצגת טריגר

אפשר לאשר את יצירת הטריגר באמצעות רשימת הטריגרים של Eventarc ב-Google Cloud CLI או במסוף Google Cloud .

המסוף

  1. נכנסים לדף Triggers ב-Eventarc במסוף Google Cloud .

    כניסה לדף Triggers

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

  2. כדי לסנן את הטריגרים:

    1. לוחצים על מסנן או על השדה הפעלת מסנן.
    2. ברשימה Properties, בוחרים אפשרות לסינון הטריגרים.

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

  3. כדי למיין את הטריגרים, לוחצים על מיון ליד כותרת של עמודה נתמכת.

gcloud

מריצים את הפקודה הבאה כדי להציג את הטריגרים:

gcloud eventarc triggers list --location=-

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

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