‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

מגבלות

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

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

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

בקטע הזה מוסבר איך צוות התמיכה של 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.

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`	קבוצת הסביבות החדשה שיצרתם עבור הארגון החדש.
‫`cert-file-name` ו- `key-file-name`	קובצי המפתח והאישור של TLS עבור האשכול שבדקתם או יצרתם בשלב 1 בקטע הזה.
`new-environment-name`	השם של הסביבה שיצרתם לארגון החדש.
`new-service-accounts-directory`	הספרייה שבה נמצאים קובצי המפתחות של חשבונות השירות שיצרתם עבור הארגון החדש.

שימוש בתצורה

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

מבצעים התקנה לצורך בדיקה כדי לבדוק אם יש בעיות:
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
הערה: מומלץ לבצע הרצה יבשה לפני שמחילים את ההגדרה, כדי לזהות בעיות.
אם אין בעיות, מחילים את הרכיבים ברמת הארגון. בשלב הזה מותקנים התהליכים של Cassandra (משתמש וסכימה), Apigee Connect, ‏ Apigee Watcher ושירותי MART:
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
מתקינים את הסביבה. בשלב הזה מותקנים הרכיבים apigee-runtime, ‏ synchronizer ו-UDCA, לכל סביבה:
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
```
הערה: אם יש כמה סביבות בארגון החדש, צריך לחזור על השלב הזה לכל סביבה.
מחילים את השינויים במאזן העומסים. בשלב הזה מגדירים את הכניסה כך שתאזין למארחים הווירטואליים החדשים של הארגון השני:
חשוב: אל תשכפלו שמות מארחים או שמות דומיינים בין שני ארגונים, כי זה עלול לגרום לניתוב בלתי צפוי.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
מפעילים את הגישה לכלי הסנכרון בארגון החדש לפי השלבים במאמר הפעלת הגישה לכלי הסנכרון.