Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

מגבלות

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

אם אתם מתכוונים להשתמש בכמה מופעים של Apigee Hybrid, לכל מופע צריך להיות אשכול משלו. הפעלת כמה מופעים של Apigee Hybrid באותו אשכול Kubernetes עלולה לגרום לבעיות של חוסר יציבות, שעלולות להוביל להשבתה.
כל הרישום ביומן מה-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.

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
    selector:
      app: apigee-ingressgateway
      ingress_name: old-ingress-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 NEW_OVERRIDES_FILE/var>.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 NEW_OVERRIDES_FILE.yaml \
  --dry-run=server

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f NEW_OVERRIDES_FILE.yaml

מפעילים את הגישה לכלי הסנכרון בארגון החדש לפי השלבים במאמר הפעלת הגישה לכלי הסנכרון.
כברירת מחדל, כשמתקינים לראשונה את סביבת זמן הריצה של Apigee Hybrid, רכיב הטלמטריה מוגדר עם multiOrgCluster מושבת. כדי להפעיל טלמטריה של כמה ארגונים לכל ארגון באשכול, מבצעים את השלבים הבאים:
1. כדי למחוק את רכיב הטלמטריה הקיים, מריצים את הפקודות הבאות:
```
helm delete telemetry -n APIGEE_NAMESPACE
```
  הערה: מחיקת רכיב הטלמטריה תגרום להפסקת הייצוא של המדדים ל-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
```