הוספה של כמה ארגונים היברידיים לאשכול

בנושא הזה מוסבר איך להוסיף ארגון (org) שני של Apigee hybrid לאשכול Kubernetes קיים. בהגדרה של כמה ארגונים, שני הארגונים משתמשים באותו Cassandra ring ומשתפים אותו. כל ארגון יכול להגדיר כמה סביבות וכמה קבוצות סביבות.

מגבלות

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

אם אתם מתכוונים להשתמש בכמה מופעים של Apigee Hybrid, לכל מופע צריך להיות אשכול משלו. הפעלת כמה מופעים של Apigee Hybrid באותו אשכול Kubernetes עלולה לגרום לבעיות של חוסר יציבות, שעלולות להוביל להשבתה.
כל הרישום ביומן מה-pods נשלח לפרויקט הראשון בענן של Google שהוגדר. המגבלה הזו בולטת במיוחד בכלי Cloud Logging. היומנים של שאר הארגונים ב-Apigee לא יישלחו לפרויקט התואם ב-Google Cloud. היומנים עדיין נשמרים ברמת ה-Pod ואפשר לאחזר אותם באמצעות פקודות kubectl. עם זאת, הם לא נשלחים לפרויקט הנכון ב-Cloud דרך Cloud Logging.
אי אפשר למחוק נתונים ארגוניים במסד הנתונים של Cassandra רק עבור ארגון אחד. המשמעות היא שאי אפשר להסיר ארגונים באופן סלקטיבי. כל שינוי בהגדרת מסד הנתונים משפיע על כל הארגונים שנפרסו באותו אשכול.
תהליך השדרוג ההיברידי משדרג את כל האשכול בבת אחת.
הגיבוי והשחזור מתבצעים ברמת האשכול, ולא ניתן לבצע אותם עבור ארגון ספציפי.
התכונה 'מעקב אחר ממשקי API' של Apigee (ציר זמן, פעולות אחרונות, חקירה) פועלת רק בארגון הראשון שהוגדר ונפרס. הוא לא יפעל בארגונים אחרים באשכול מרובה ארגונים.

אפשרויות לשימוש בכמה ארגונים

בקטע הזה מוסבר איך צוות התמיכה של Apigee מטפל באשכולות קיימים של כמה ארגונים ובהמלצות לפריסות עתידיות:

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

דרישות מוקדמות

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

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

יצירת ארגון להוספה לאשכול הקיים

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

הגדרת הארגון החדש

בשלבים הבאים תיצרו קובץ חדש של שינויים ותגדירו אותו לארגון החדש. קובץ overrides.yaml יכול להכיל רק מידע של ארגון אחד. לכן, צריך ליצור קובץ overrides.yaml חדש ולהחיל אותו על אשכול Kubernetes הקיים.

יוצרים חשבונות שירות לשימוש בארגון החדש. איך יוצרים חשבונות שירות
שימו לב לקובצי אישור ה-TLS (.key ו-.pem) בספרייה certs. אם צריך ליצור אותם מחדש, אפשר לפעול לפי ההוראות במאמר יצירת אישורי TLS.
מעתיקים את הקובץ הקיים overrides.yaml לקובץ חדש כדי להשתמש בו כנקודת התחלה להגדרת הארגון החדש. לדוגמה: new-overrides.yaml.

עורכים את קובץ ההחלפות החדש עם ההגדרות הבאות:

org: "new-org-name"
instanceID: "instance-id"   ## Must match the instanceID of your existing org.

multiOrgCluster: true ## Enables exporting metrics for this org to the Google Cloud Project named with gcp:projectID

k8sCluster:
  name: "existing-cluster-name"
  region: "existing-cluster-analytics-region"

gcp:
  projectID: "new-project-id"
  name: "new-project-id"
  region: "new-project-default-location"

namespace: namespace ## must be the same for both new and existing orgs

virtualhosts:
  - name: new-environment-group-name
    sslCertPath: ./certs/cert-file-name # .crt or .pem
    sslKeyPath: ./certs/key-file-name # .key

envs:
  - name: new-environment-name
    serviceAccountPaths:
      runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json
      synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json
      udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json

connectAgent:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

mart:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json

metrics:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json

watcher:
  serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json

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

משתנה	תיאור
`new-org-name`	השם של הארגון החדש.
`instance-id`	לכל הארגונים באשכול הזה צריך להיות אותו מזהה מופע. לכן, הערך הזה חייב להיות זהה לערך `instanceID` בקובץ ההגדרות שמוגדרות מחדש בארגון המקורי. בהתקנות במספר אזורים, כל אזור דורש אשכול משלו, כי אשכולות נפרדים לא משתרעים על פני אזורים. לכן, לכל אשכול צריך להיות מזהה מופע ייחודי משלו, שמשותף לכל הארגונים באשכול.
`existing-cluster-name`	השם של האשכול שאליו רוצים להוסיף את הארגון. הוא צריך להיות זהה לערך `k8sCluster.name` בקובץ ההחלפות של האשכול המקורי.
`existing-cluster-analytics-region`	האזור שבו האשכול המקורי הוקצה. היא צריכה להיות זהה לערך `k8sCluster.region` בקובץ ההחלפות של האשכול המקורי.
`new-project-id`	מזהה הפרויקט החדש. מזהה הפרויקט ושם הארגון זהים.
`new-project-default-location`	האזור של ניתוח הנתונים שציינתם כשפתחתם את הארגון החדש. הוא לא חייב להיות זהה לאזור של הארגון הקיים.
`namespace`	לכל הארגונים באשכול צריך להיות אותו מרחב שמות. חשוב להקפיד להשתמש באותו מרחב שמות שבו השתמשתם בארגון המקורי. מרחב השמות ברוב ההתקנות הוא `apigee`.
`new-environment-group-name`	קבוצת הסביבות החדשה שיצרתם לארגון החדש. זהירות: השמות של קבוצות הסביבות בארגון החדש לא יכולים להיות זהים לשמות של קבוצות הסביבות בארגון אחר. שמות הגרסאות של Helm עבור סביבות יהיו זהים, ולכן יהיה קשה לנהל את התרשימים.
‫`cert-file-name` ו `key-file-name`	קובצי המפתח והאישור של TLS עבור האשכול שבדקתם או יצרתם בשלב 1 בקטע הזה.
`new-environment-name`	השם של הסביבה שיצרתם לארגון החדש. שימו לב: השמות של הסביבות בארגון החדש לא יכולים להיות זהים לשמות של סביבות בארגון אחר.
`new-service-accounts-directory`	הספרייה שבה נמצאים קובצי המפתחות של חשבונות השירות שיצרתם עבור הארגון החדש.

שימוש בתצורה

מחילים את ההגדרה החדשה של הארגון על האשכול:

כדי לבדוק אם יש בעיות, מבצעים הרצת בדיקה של ההתקנה:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run=server
```
הערה: מומלץ לבצע הרצה יבשה לפני שמחילים את ההגדרה, כדי לזהות בעיות.
אם אין בעיות, צריך להחיל את הרכיבים ברמת הארגון. בשלב הזה מותקנים שירותי Cassandra (משתמש וסכימה), Apigee Connect, ‏ Apigee Watcher ו-MART:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```

מתקינים את הסביבה. בשלב הזה מותקנים הרכיבים apigee-runtime, ‏ synchronizer ו-UDCA, לכל סביבה:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run=server

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml

מחילים את השינויים במאזן העומסים. בשלב הזה מגדירים את ה-ingress להאזנה למארחים הווירטואליים החדשים עבור הארגון השני:
חשוב: אל תשכפלו שמות מארחים או שמות דומיינים בין שני ארגונים, כי זה עלול לגרום לניתוב בלתי צפוי.
```
helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml \
  --dry-run=server
```
```
helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml
```
מפעילים את הגישה של הכלי לסנכרון לארגון החדש לפי השלבים במאמר הפעלת גישה למישור הבקרה.
כברירת מחדל, כשמתקינים את זמן הריצה של Apigee Hybrid בפעם הראשונה, רכיב הטלמטריה מוגדר עם multiOrgCluster מושבת. כדי להפעיל טלמטריה של כמה ארגונים לכל ארגון באשכול, פועלים לפי השלבים הבאים:
1. כדי למחוק את רכיב הטלמטריה הקיים, מריצים את הפקודות הבאות:
```
helm delete telemetry
```
  הערה: מחיקת רכיב הטלמטריה תגרום להפסקת הייצוא של המדדים ל-Google Monitoring. כדי להפעיל מחדש את המדדים, צריך לבצע את השלבים הבאים.
2. מוסיפים את השורה הבאה לקובץ overrides.yaml של הארגון הקיים.
```
multiOrgCluster: true
```
3. מחילים את השינויים כדי להתקין את רכיב הטלמטריה בארגון.
  קודם מבצעים הרצת בדיקה:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  אם ההרצה היבשה מצליחה, מחילים את השינויים ומתקינים את רכיב הטלמטריה:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. מוודאים שהשורה הבאה נמצאת בקובץ overrides.yaml לכל ארגון חדש.
```
multiOrgCluster: true
```
5. מחילים את השינויים כדי להתקין את רכיב הטלמטריה בכל ארגון חדש. חוזרים על הפעולה לכל ארגון חדש באשכול מרובה הארגונים.
  קודם מבצעים הרצת בדיקה:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run=server
```
  אם ההרצה היבשה מצליחה, מחילים את השינויים ומתקינים את רכיב הטלמטריה:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```