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

שדרוג Apigee Hybrid לגרסה 1.8

ההליך זהה לשדרוג גרסה משנית (לדוגמה, מגרסה 1.7 לגרסה 1.8) ולשדרוג גרסת תיקון (לדוגמה, מגרסה 1.8.0 לגרסה 1.8.8).

אם אתם משדרגים מ-Apigee Hybrid גרסה 1.6 או גרסה ישנה יותר, אתם צריכים לשדרג קודם לגרסה 1.7 לפני שתשדרגו לגרסה 1.8.8. אפשר לעיין בהוראות בנושא שדרוג Apigee Hybrid לגרסה 1.7.

אם אתם כבר משתמשים בגרסה 1.8.0 של hybrid ורוצים לעבור מ-Anthos Service Mesh אל Apigee ingress gateway, תוכלו לעיין במאמר מעבר אל Apigee ingress gateway.

חדש: שער כניסה של Apigee

החל מגרסה 1.8, ‏ Apigee Hybrid מציע תכונה חדשה לניהול שער הכניסה להתקנה ההיברידית שלכם, Apigee Ingress Gateway. ‫Anthos Service Mesh כבר לא מהווה דרישה מוקדמת להתקנה היברידית. עם שער הכניסה של Apigee, ‏ Apigee יפסיק לספק הגדרות ניתוב ל-Anthos Service Mesh. אחרי השדרוג, צריך להעביר את התנועה אל שער הכניסה החדש של Apigee לפני שמתחילים להשתמש בתכונה.

‫Apigee משתמש בקבוצת משנה קטנה של תכונות Anthos Service Mesh לשער הכניסה. החל מגרסה 1.8 של Apigee Hybrid,‏ Apigee Hybrid כולל שער כניסה שמותקן ומשודרג כחלק משדרוגים של Apigee Hybrid. לכן, לא צריך לצבור מומחיות ב-Anthos Service Mesh כדי להתקין, לשדרג ולנהל את Apigee hybrid. בעיות שקשורות לגרסאות של שער הכניסה ולתאימות שלהן למהדורות של Apigee Hybrid מטופלות באופן אוטומטי.

שני תרחישים להעברה:

העברה בין כמה אשכולות או בין כמה אזורים (מומלץ):
לפני שמשתמשים ב-Ingress חדש ל-Apigee, צריך להפנות את כל התנועה לאשכול או לאזור אחר מהאשכול שמבצעים ממנו את ההעברה. כך יהיה לכם זמן לבדוק אם שער ה-Ingress החדש של Apigee פועל כמצופה. לאחר מכן, אפשר להפנות את התנועה בחזרה לאשכול המשודרג.
שדרוג במקום (לא מומלץ בסביבות ייצור):
במהלך השדרוג, Apigee יפעיל את שער הכניסה החדש עם כתובת IP שתציינו. אחרי זה תוכלו לבדוק אם שער הכניסה החדש של Apigee פועל כמו שצריך, ואז להעביר את התנועה לשער הכניסה החדש. יכול להיות שיהיה זמן השבתה במהלך השדרוג הזה.

כשמשדרגים את Apigee Hybrid לגרסה 1.8, צריך להגדיר את שער הכניסה של Apigee בקובץ ההחלפות. אחרי השדרוג, אתם קובעים באיזה סוג של שער כניסה ישתמשו האשכולות שלכם. לשם כך, אתם מפנים את רשומות ה-A או ה-CNAME ברשם אל כתובת ה-IP של שער הכניסה של Apigee או של Anthos Service Mesh.

סקירה כללית על שדרוג לגרסה 1.8.8

שדרוג לגרסה 1.8 של Apigee Hybrid עשוי לדרוש השבתה.

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

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

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

ההליכים לשדרוג Apigee hybrid מאורגנים בקטעים הבאים:

הכנות לשדרוג
מתקינים את גרסת זמן הריצה ההיברידית 1.8.8.
בוחרים אחת מהאפשרויות הבאות עבור שער הכניסה:
- (מומלץ) משתמשים בשער הכניסה החדש של Apigee, ופועלים לפי השלבים שמפורטים במאמר העברת תעבורה מ-Anthos Service Mesh לשער הכניסה של Apigee.
- להמשיך להשתמש ב-Anthos Service Mesh בשער הכניסה.

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

ההוראות לשדרוג מניחות שיש לכם את Apigee hybrid בגרסה 1.7.x או בגרסת תיקון קודמת של גרסה 1.8.x, ואתם רוצים לשדרג אותה לגרסה 1.8.8. אם אתם מעדכנים מגרסה קודמת, כדאי לעיין בהוראות שדרוג Apigee Hybrid לגרסה 1.7.

אם אתם מעדיפים להמשיך להשתמש ב-Anthos Service Mesh, אתם צריכים לוודא ששדרגתם את Anthos Service Mesh לגרסה נתמכת. בטבלה פלטפורמות נתמכות מפורטות הגרסאות הנתמכות של Anthos Service Mesh.

הכנה לשדרוג לגרסה 1.8

גיבוי של ההתקנה ההיברידית (מומלץ)

בהוראות האלה נעשה שימוש במשתנה הסביבה APIGEECTL_HOME עבור הספרייה במערכת הקבצים שבה התקנתם את apigeectl. אם צריך, משנים את הספרייה לספרייה apigeectl ומגדירים את המשתנה באמצעות הפקודה הבאה:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
יוצרים עותק גיבוי של ספריית $APIGEECTL_HOME/ בגרסה 1.7. לדוגמה:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
מגבים את מסד הנתונים של Cassandra לפי ההוראות במאמר בנושא גיבוי ושחזור של Cassandra

מוסיפים את התפקיד Cloud Trace Agent לחשבון השירות של זמן הריצה של Apigee. (אופציונלי)

אופציונלי: אם אתם מתכננים להשתמש ב-Cloud Trace ולא ביצעתם את השלב הזה בהתקנת hybrid v1.7, ודאו שלחשבון השירות שלכם בשביל שירותי זמן הריצה של Apigee יש את תפקיד Google‏ Cloud Trace Agent. (roles/cloudtrace.agent).

בסביבות ייצור, זה בדרך כלל חשבון השירות apigee-runtime. בסביבות שאינן סביבות ייצור, זה בדרך כלל apigee-non-prod חשבון השירות.

אפשר להוסיף את התפקיד בממשק המשתמש של מסוף Cloud > ‏IAM ואדמין > חשבונות שירות או באמצעות הפקודות הבאות:

כדי לקבל את כתובת האימייל של חשבון השירות, מריצים את הפקודה הבאה:
ייצור
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
אם הוא תואם לדפוס apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, אפשר להשתמש בדפוס הזה בשלב הבא.
Non-Prod
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
אם הוא תואם לדפוס apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, אפשר להשתמש בדפוס הזה בשלב הבא.

מקצים לחשבון השירות את התפקיד Cloud Trace Agent:

ייצור

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Non-Prod

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

דוגמה

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

כאשר: $PROJECT_ID הוא השם של הפרויקט בענן של Google שבו מותקן Apigee Hybrid.

הערה: אם בהתקנה שלכם נעשה שימוש בשם מותאם אישית לחשבון השירות, צריך להחליף את השם הזה ב-apigee-runtime או ב-apigee-non-prod בפקודה.

הכנה להתקנה של שער כניסה של Apigee

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

תחביר

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

דוגמה

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

‫INGRESS_NAME הוא שם הפריסה של ה-ingress. אפשר לבחור כל שם שעומד בדרישות הבאות:
- האורך המקסימלי הוא 17 תווים
- השם יכול להכיל רק תווים אלפאנומריים באותיות קטנות, '-' או '.'
- מתחילים בתו אלפאנומרי
- התו האחרון חייב להיות אלפאנומרי
מידע נוסף זמין במאמר ingressGateways[].name בנושא מאפייני הגדרות.
‫REPLICAS_MIN ו-REPLICAS_MAX הם המספרים המינימלי והמקסימלי של העותקים המשוכפלים של שער הכניסה של Apigee בהתקנה. למידע נוסף ולהגדרות ברירת המחדל, אפשר לעיין ב-ingressGateways[].replicaCountMin וב-ingressGateways[].replicaCountMax בהפניה למאפייני ההגדרה.
‫CPU_COUNT_REQ ו-MEMORY_REQ הם בקשות לשימוש במעבד ובזיכרון לכל עותק של שער הכניסה של Apigee בהתקנה.
מגדירים את המאפיינים האלה רק אם הגדרתם אותם בעבר לשער הכניסה של Anthos Service Mesh, למשל בקובץ overlay.yaml.

מידע נוסף והגדרות ברירת מחדל זמינים במאמרים ingressGateways[].resources.requests.cpu וingressGateways[].resources.requests.memory בהפניה למאפיין Configuration.
‫CPU_COUNT_LIMIT ו-MEMORY_LIMIT המגבלות המקסימליות של יחידת העיבוד המרכזית (CPU) והזיכרון לכל עותק משוכפל של שער הכניסה של Apigee בהתקנה.
מגדירים את המאפיינים האלה רק אם הגדרתם אותם בעבר בשער הכניסה של Anthos Service Mesh, למשל בקובץ overlay.yaml.

מידע נוסף והגדרות ברירת מחדל זמינים במאמרים ingressGateways[].resources.limits.cpu וingressGateways[].resources.limits.memory בהפניה למאפיין Configuration.
‫SVC_ANNOTATIONS_KEY ו-SVC_ANNOTATIONS_VALUE (אופציונלי):
הערה: השדה ingressGateways[].svcAnnotations ב-overrides.yaml לא פועל כמצופה. בעיה ידועה 243599452

זהו צמד מפתח/ערך שמספק אנוטציות לשירות ברירת המחדל של ה-ingress. ההערות משמשות את פלטפורמת הענן כדי לעזור בהגדרת ההתקנה ההיברידית, למשל הגדרת סוג מאזן העומסים כפנימי או חיצוני. לדוגמה:
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
ההערות משתנות מפלטפורמה לפלטפורמה. במאמרי העזרה של הפלטפורמה מפורטות ההערות הנדרשות והמומלצות.

הערה: אין צורך להגדיר את Annotations אם יוצרים שירות Kubernetes משלכם לפריסת Ingress, כמו שמתואר במאמר חשיפת שער Ingress של Apigee.
מידע נוסף על ingressGateways[].svcAnnotations מופיע במאמר בנושא מאפייני הגדרות.
‫SVC_LOAD_BALANCER_IP (אופציונלי) מאפשר להקצות כתובת IP סטטית למאזן העומסים. בפלטפורמות שתומכות בהגדרת כתובת ה-IP של מאזן העומסים, מאזן העומסים ייווצר עם כתובת ה-IP הזו. בפלטפורמות שלא מאפשרות לציין את כתובת ה-IP של מאזן העומסים, המאפיין הזה מושבת.
אם לא הקציתם כתובת IP סטטית למאזן העומסים, אל תכללו את המאפיין הזה בקובץ ההחלפות.

זהירות: חשוב לוודא שלא מציינים את אותה כתובת IP כמו istio-ingressgateway הנוכחי. הפעולה הזו עלולה לגרום לבעיות בזמן שהשירות הזה עדיין פועל באשכול.

הערה: אין צורך להגדיר את LoadBalancerIP אם יוצרים שירות Kubernetes משלכם לפריסת Ingress, כמו שמתואר במאמר חשיפת שער Apigee Ingress.
מידע נוסף על ingressGateways[].svcLoadBalancerIP

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

כדי להפעיל תכונות חדשות ב-hybrid v1.8, מוסיפים את המאפיינים הבאים לקובץ overrides.yaml: התכונות האלה הן אופציונליות.

התכונה UDCA ברמת הארגון מופעלת עכשיו כברירת מחדל. שימוש בפריסת UDCA יחידה לטיפול בתנועה בכל הסביבות מונע ניצול חלקי של פודים של UDCA ומגדיל את הזמינות של משאבי צמתים לרכיבים אחרים של Apigee. התכונה UDCA ברמת הארגון משתמשת בחשבון שירות יחיד לכל הסביבות, apigee-udca.
אם אתם משתמשים בחשבונות שירות שונים ל-UDCA בסביבות שונות, שימו לב שעכשיו המערכת תשתמש בחשבון השירות שצוין ברמת הארגון בקובץ ההחלפות עם udca:serviceAccountPath, במקום בחשבונות שצוינו ברמת הסביבה עם envs:udca:serviceAccountPath.

‫Apigee Hybrid גרסה 1.8 תומכת ב-UDCA בהיקף הסביבה. כדי לשמור על UDCA לכל סביבה, מגדירים את הערך orgScopedUDCA: false.

הערה: תמיכה ב-UDCA בהיקף סביבה לא תהיה זמינה בגרסאות עתידיות של Apigee hybrid.

מידע נוסף זמין במאמר בנושא orgScopedUDCA בהפניה למאפיינים של מערך הגדרות אישיות.
מפעילים את האפשרות validateOrg כדי לדרוש אימות קפדני של הארגון והסביבה ב-Apigee, ולוודא שהם פעילים ועובדים עם הפרויקט ב-Google Cloud Platform שצוין בקובץ overrides.
```
validateOrg: true
```
הערה: ב-Apigee hybrid יש תמיכה באי-שימוש באימות ארגון מחמיר. כדי להשבית את התכונה, מגדירים את validateOrg: false.

מידע נוסף זמין במאמר validateOrg בנושא מאפייני הגדרות אישיות.

התקנת זמן הריצה של Apigee Hybrid 1.8.8

חשוב לוודא שאתם נמצאים בספריית הבסיס של ההיברידי (הספרייה הראשית שבה נמצא קובץ ההפעלה apigeectl):
```
cd $APIGEECTL_HOME/..
```

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

Linux

‫Linux 64 bit:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

Mac OS

‫Mac 64 bit:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows 64 bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

משנים את השם של ספריית apigeectl/ הנוכחית לשם של ספריית גיבוי. לדוגמה:
Linux
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/
```
Mac OS
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 
```
Windows
```
rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 
```
מחלצים את תוכן קובץ ה-gzip שהורד אל ספריית הבסיס ההיברידית. ספריית הבסיס ההיברידית היא הספרייה שבה נמצאת הספרייה apigeectl-v1.7 ששמה שונה:
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
כברירת מחדל, התוכן של קובץ ה-tar מורחב לספרייה עם הגרסה והפלטפורמה בשם שלה. לדוגמה: ./apigeectl_1.8.8-xxxxxxx_linux_64. משנים את שם הספרייה ל-apigeectl באמצעות הפקודה הבאה:
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
עוברים לספרייה apigeectl:
```
cd ./apigeectl
```
הספרייה הזו היא ספריית הבית apigeectl. זה המקום שבו נמצאת הפקודה להפעלה apigeectl.
בהוראות האלה נעשה שימוש במשתנה הסביבה $APIGEECTL_HOME עבור הספרייה במערכת הקבצים שבה מותקן כלי השירות apigeectl. אם צריך, משנים את הספרייה לספרייה apigeectl ומגדירים את המשתנה באמצעות הפקודה הבאה:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
כדי לוודא את הגרסה של apigeectl, מריצים את הפקודה version:
```
./apigeectl version
```
```
Version: 1.8.8
```
עוברים לספרייה hybrid-base-directory/hybrid-files. בספרייה hybrid-files נמצאים קובצי תצורה כמו קובץ ההחלפות, האישורים וחשבונות השירות. לדוגמה:
```
cd $APIGEECTL_HOME/../hybrid-files
```
מריצים את הפקודה הבאה כדי לוודא שההקשר הנכון מוגדר ל-kubectl. ההקשר הנוכחי צריך להיות מוגדר לאשכול שבו משדרגים את Apigee hybrid.
```
kubectl config get-contexts | grep \*
```
בספרייה hybrid-files:
1. מעדכנים את הקישורים הסמליים הבאים לכתובת $APIGEECTL_HOME. הקישורים האלה מאפשרים להריץ את הפקודה apigeectl שהותקנה לאחרונה מתוך הספרייה hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. כדי לוודא שהקישורים הסמליים נוצרו בצורה נכונה, מריצים את הפקודה הבאה ומוודאים שנתיבי הקישורים מצביעים על המיקומים הנכונים:
```
ls -l | grep ^l
```
מבצעים הפעלה ללא שינוי כדי לבדוק אם יש שגיאות:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
כאשר OVERRIDES_FILE הוא שם קובץ ההגדרות שלכם, למשל ./overrides/overrides.yaml.

טיפ: אפשר להחליף את OVERRIDES_FILE בקוד לדוגמה שלמעלה בשם ובנתיב של קובץ ההחלפות, וכל מופע בדף הזה יוחלף.
אם אין שגיאות, מפעילים את hybrid 1.8.8. הפקודה הזו גם מתקינה ומגדירה את שער הכניסה של Apigee:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
בודקים את סטטוס ההפעלה:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
אם הפעולה בוצעה ללא שגיאות, הפלט ייראה כך: All containers ready.

בעיה ידועה: אחרי שמריצים את הפקודה init ומאשרים שהפקודה check-ready הצליחה, יכול להיות שתבחינו, אם תציגו את ה-pods, שהאימות של סכימת Cassandra נמצא במצב שגיאה. המצב הזה נחשב לבעיה מוכרת (מספר 245664917) והוא לא מזיק. אפשר להתעלם מהשגיאה ולעבור לשלב הבא: apigeectl apply.

כדי לבדוק את הסטטוס של ApigeeDataStore, אפשר להריץ גם את הפקודה הבאה:
```
kubectl describe apigeeds -n apigee
```
בפלט, מחפשים את State: running.
כדי לבדוק אם יש שגיאות, מריצים הרצה יבשה של הפקודה apply באמצעות הדגל --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
אם אין שגיאות, מחילים את שינויי ברירת המחדל. בוחרים את ההוראות לסביבות ייצור או לסביבות שאינן סביבות ייצור, בהתאם להתקנה.
במהלך תהליך השדרוג, כל רכיב יבצע הפעלה מחדש מתגלגלת. לכן, בסביבות ייצור, מומלץ להחיל את השדרוג על רכיב אחד בכל פעם.
ייצור

בסביבות ייצור, צריך לשדרג כל רכיב היברידי בנפרד ולבדוק את הסטטוס של הרכיב המשודרג לפני שממשיכים לרכיב הבא.
1. חשוב לוודא שאתם נמצאים בספרייה hybrid-files.
2. מחילים את ההחלפות כדי לשדרג את Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. השלמת הבדיקה:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  טיפ: אם הפקודה check-ready נכשלת, אפשר לקבל מידע נוסף על ה-pods באמצעות הפקודה:
  kubectl -n NAMESPACE get pods
  
  כאשר NAMESPACE הוא מרחב השמות של Apigee Hybrid.
  ממשיכים לשלב הבא רק כשהפודים מוכנים.
4. מחילים את ההחלפות כדי לשדרג את רכיבי הטלמטריה ובודקים שהשדרוג הושלם:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. מפעילים את רכיבי Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. מחילים את השינויים כדי לשדרג את הרכיבים ברמת הארגון (MART, ‏ Watcher ו-Apigee Connect) ובודקים שהשדרוג הושלם:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. מחילים את השינויים כדי לשדרג את הסביבות. יש שתי אפשרויות:
  - סביבה אחרי סביבה: מחילים את השינויים על סביבה אחת בכל פעם ובודקים שהפעולה הושלמה. חוזרים על השלב הזה לכל סביבה:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    כאשר ENV_NAME הוא שם הסביבה שמשדרגים.
  - כל הסביבות בבת אחת: אפשר להחיל את השינויים על כל הסביבות בבת אחת ולבדוק שהפעולה הושלמה:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. מחילים את ההחלפות כדי לשדרג את הרכיבים של virtualhosts ובודקים שהשדרוג הושלם:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Non-prod

ברוב הסביבות שאינן סביבות ייצור, הדגמה או ניסוי, אפשר להחיל את הביטולים על כל הרכיבים בבת אחת. אם הסביבה שלכם שהיא לא סביבת ייצור גדולה ומורכבת או שהיא דומה מאוד לסביבת ייצור, כדאי לפעול לפי ההוראות לשדרוג סביבות ייצור.
1. חשוב לוודא שאתם נמצאים בספרייה hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. בודקים את הסטטוס:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

שדרוג גרסת Kubernetes

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

כאן אפשר ללחוץ כדי להרחיב את רשימת הפלטפורמות הנתמכות

	גרסאות Apigee Hybrid
פלטפורמות	‫1.6 ⁽³⁾	‪1.7 ⁽³⁾	‫1.8 ⁽³⁾	‫1.9	‫1.10
‫Anthos (Google Cloud – GKE)	‫1.19.x 1.20.x 1.21.x	‫1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	‫1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	‫1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	‫1.24.x 1.25.x 1.26.x
‫Anthos (AWS)	‫1.7.x 1.8.x 1.9.3+ 1.10.x	‫1.9.x ‫1.10.x ‫1.12.x ^{(‎≥ 1.7.2)}	‫1.10.x ‫1.11.x ‫1.12.x ‫1.13.x ‫1.25⁽¹³⁾	‪1.12.x 1.13.x 1.25⁽¹³⁾	‫1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
‫Anthos (Azure)	‫1.8.x	‫1.9.x ‫1.10.x ‫1.12.x ^{(‎≥ 1.7.2)}	‫1.10.x ‫1.11.x ‫1.12.x ‫1.13.x ‫1.14.x	‫1.12.x 1.13.x 1.14.x	‫1.13.x 1.14.x 1.15.x
‫Anthos (on-premises – VMware)⁽¹⁾	‫1.7.x 1.8.x 1.9.3+ 1.10.x	‫1.9.x ⁽⁴⁾ ‫ 1.10.x ⁽⁴⁾ ‫ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} ‫ 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	‫1.10.x ⁽⁴⁾ ‫1.11.x ⁽⁴⁾ ‫1.12.x ⁽⁴⁾ ⁽⁵⁾ ‫ 1.13.x ⁽⁵⁾ ‫ 1.14.x ⁽⁵⁾ ‫ 1.15.x	‫1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	‫1.13.x 1.14.x 1.15.x 1.16.x
‫Anthos (Bare Metal)⁽¹⁾	‫1.7.x 1.8.2+ 1.9.3+ 1.10.x	‫1.9.x ⁽⁴⁾ ‫1.10.x ⁽⁴⁾ ‫1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} ‫1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	‫1.10.x ⁽⁴⁾ ‫1.11.x ⁽⁴⁾ ‫1.12.x ⁽⁴⁾ ⁽⁵⁾ ‫1.13.x ⁽⁵⁾ ‫1.14.x ⁽⁵⁾ ‫1.15.x	‫1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	‫1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	‫1.19.x 1.20.x 1.21.x	‫1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	‫1.22.x ^{(≤ 1.8.3)} ‫ 1.23.x ^{(≤ 1.8.4)} ‫ 1.24.x ^{(≥ 1.8.4)} ‫ 1.25.x ^{(≥ 1.8.4)}	‫1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	‫1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	‫1.19.x 1.20.x 1.21.x	‫1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	‫1.22.x ^{(≤ 1.8.3)} ‫ 1.23.x ^{(≤ 1.8.4)} ‫ 1.24.x ^{(≥ 1.8.4)} ‫ 1.25.x ^{(≥ 1.8.4)}	‫1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	‫1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	‫4.7 4.8	4.8 4.9 4.10	4.10 4.11	‫4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	לא רלוונטי	לא רלוונטי	לא רלוונטי	1.3.8	‫v1.26.2+rke2r1
רכיבים	‫1.6 ⁽³⁾	‪1.7 ⁽³⁾	1.8	‫1.9	‫1.10
Anthos Service Mesh (ASM)	‫1.9.x ‫1.10.x ‫1.12.x ‫1.13.x	‫1.10.x ‫1.11.x ‫1.12.x ‫1.13.x ^{(≥ 1.7.2)} ‫1.14.x ‫1.15.x ^{(≥ 1.7.6)}	‫1.11.x ‫1.12.x ‫1.13.x ‫1.14.x ‫1.15.x	‫1.17.x⁽¹¹⁾	‫1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	‫1.7.x	‫1.7.x ‫1.8.x ‫1.9.x ‫1.10.x ‫1.11.x	‫1.10.x 1.11.x	‫‎1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
^‫(1) בגרסאות Anthos‏ 1.8,‏ 1.9 ו-1.10, צריך לפעול לפי ההוראות במסמכים האלה כדי למנוע התנגשות עם `cert-manager`: ‫Anthos 1.8.2 ואילך: יש התנגשות עם `cert-manager` כשמשדרגים לגרסה 1.8.2 ואילך. ‫Anthos 1.9: מתרחש עימות עם `cert-manager` כשמשדרגים לגרסה 1.9.0 או 1.9.1. ‫Anthos מגרסה 1.10 ואילך: התקנה `cert-manager` שמתנגשת עם התקנה אחרת. ^‫(2) התמיכה זמינה בגרסה 1.7.2 ואילך של Apigee Hybrid. ‫⁽³⁾ הגיעו תאריכי סוף החיים הרשמיים של Apigee hybrid בגרסה 1.8 ובגרסאות ישנות יותר. תיקונים חודשיים רגילים לא זמינים יותר. הגרסאות האלה לא נתמכות יותר באופן רשמי, למעט לקוחות עם חריגים רשמיים ומפורשים להמשך התמיכה. לקוחות אחרים צריכים לשדרג. ^‫(4)הסתיימה התמיכה בגרסאות 1.12 ואילך של Anthos בשרת פיזי ו-VMWare. אפשר לעיין ב מדיניות התמיכה בגרסאות של Anthos בשרת פיזי וב גרסאות של אשכולות Anthos ב-VMware. ^‫(5)‫Anthos בשרת פיזי ו-VMWare דורשים ASM 1.14 ואילך. מומלץ לשדרג ל-hybrid v1.8 ולעבור ל-Apigee ingress gateway, שכבר לא דורש התקנה של ASM באשכול ההיברידי. ^‫(6) תמיכה זמינה ב-Apigee Hybrid גרסה 1.8.4 ואילך. ^‫(7) לא נדרשיםאשכולות מצורפים ל-Apigee Hybrid בגרסה 1.8 ואילך, אם משתמשים ב- Apigee ingressgateway. ‫⁽⁸⁾ לא נתמך ב-Apigee Hybrid בגרסה 1.8.4 ואילך. ^‫(9) תמיכה זמינה בגרסה 1.7.6 ואילך של Apigee Hybrid. ^‫(10) לא נתמך ב-Apigee Hybrid בגרסה 1.8.5 ואילך. ‫⁽¹¹⁾ ASM מותקן באופן אוטומטי עם Apigee Hybrid בגרסה 1.9 ואילך. ^‫(12) התמיכה זמינה ב-Apigee Hybrid בגרסה 1.9.2 ואילך. ^‫(13) מספרי הגרסאות של אשכולות Anthos ב-AWS (Multi-Cloud) משקפים עכשיו את גרסאות Kubernetes. פרטים על הגרסה ותיקוני תוכנה מומלצים זמינים במאמר בנושא תמיכה בגרסאות ובשדרוגים של Anthos.

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

‫ בגרסאות Apigee hybrid‏ 1.7.x ומגרסאות ישנות יותר, צריך להשתמש באשכולות מצורפים של Anthos אם רוצים להפעיל את Apigee hybrid בהקשר של כמה עננים ב-Elastic Kubernetes Service‏ (EKS), ב-Azure Kubernetes Service‏ (AKS) או בספק אחר של שירות Kubernetes נתמך של צד שלישי. צירוף אשכולות מאפשר ל-Google למדוד את השימוש ב-Anthos Service Mesh‏ (ASM). הרשמה של אשכול צד שלישי היא אופציונלית. צריך להירשם רק אם רוצים לראות את האשכול המצורף ב- Google Cloud console. מידע נוסף זמין במאמר בנושא צירוף אשכולות Kubernetes של צד שלישי ל-Google Cloud.

ב-Apigee hybrid גרסה 1.8.x, נדרשים אשכולות Anthos מצורפים אם משתמשים ב-Anthos Service Mesh בשביל שער הכניסה. אם אתם משתמשים בשער כניסה של Apigee, אשכולות Anthos מצורפים הם אופציונליים.

העברת תעבורה מ-Anthos Service Mesh אל שער הכניסה של Apigee

כדי להעביר את התנועה לשער כניסה של Apigee:

חשיפת שער הכניסה של Apigee. פועלים לפי השלבים שמפורטים במאמר בנושא חשיפת שער כניסה של Apigee.
כדי לבדוק את שער הכניסה החדש, צריך להתקשר לפרוקסי. מומלץ לבדוק את כל הפרוקסיים החשובים שפרסתם כרגע.
כדי להעביר את התנועה, צריך לעדכן את רשומות ה-DNS כך שיפנו לכתובת ה-IP של שער הכניסה החדש של Apigee. בהתאם לספק ה-DNS שלכם, יכול להיות שתוכלו להעביר את התעבורה בהדרגה לנקודת הקצה החדשה.
טיפ: אפשר למצוא את כתובת ה-IP החיצונית של שער הכניסה של Apigee באמצעות הפקודה הבאה:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
הפלט אמור להיראות כך:
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
כדי לוודא שכל התנועה בזמן הריצה פועלת, צריך לעקוב אחרי לוחות הבקרה. רק אם הכול פועל כצפוי, ממשיכים לשלב הבא. חשוב לוודא שלא עוברת תנועה דרך שער הכניסה הישן (Anthos Service Mesh), כי יכול להיות שעדכון ה-DNS יתבצע לאט בגלל שמירת ה-DNS במטמון.
כדי להפסיק את אספקת ההגדרות מ-Apigee ל-Anthos Service Mesh, פועלים לפי השלבים במאמר הפסקת אספקת ההגדרות ל-ASM במדריך בנושא ניהול שער הכניסה של Apigee.
בודקים מחדש את תעבורת הנתונים של proxy ל-API ועוקבים אחריה.
פועלים לפי ההוראות שבתיעוד של Anthos Service Mesh כדי להסיר את Anthos Service Mesh מהאשכול.

שדרוג Anthos Service Mesh לגרסה 1.15

מבצעים את הפעולות באמצעות מסמכי התיעוד של Anthos Service Mesh שמתאימים לפלטפורמה שלכם:

ההוראות להתקנה ולהגדרה של Anthos Service Mesh משתנות בהתאם לפלטפורמה. הפלטפורמות מחולקות לקטגוריות הבאות:

‫GKE: אשכולות Google Kubernetes Engine שפועלים ב-Google Cloud.
מחוץ ל-Google Cloud: אשכולות Anthos שפועלים ב:
- אשכולות Anthos ב-VMware‏ (GKE On-Prem)
- Anthos בשרת פיזי
- אשכולות Anthos ב-AWS
- Amazon EKS
פלטפורמות אחרות של Kubernetes: אשכולות תואמים שנוצרו ופועלים ב:
- AKS
- EKS
- OpenShift

GKE

רצף הפעולות לשדרוג ל-Anthos Service Mesh גרסה 1.17.8 בהתקנה היברידית:

מתכוננים לשדרוג.
מתקינים את הגרסה החדשה של Anthos Service Mesh.
מוחקים מההתקנה הנוכחית את הפריסות, השירותים וה-webhook של הגרסה הקודמת של Anthos Service Mesh.
שדרגו את השערים והגדירו את ה-webhook החדשים.

הכנה לשדרוג Anthos Service Mesh לגרסה 1.17.8

בודקים את הדרישות במאמר שדרוג Anthos Service Mesh, אבל לא מבצעים את השדרוג עדיין.
לפני שמתקינים את הגרסה החדשה, צריך לקבוע את הגרסה הנוכחית. תצטרכו את המידע הזה כדי למחוק מההתקנה הנוכחית את הפריסות, השירותים וה-webhook של הגרסה הקודמת של Anthos Service Mesh. כדי לאחסן את הגרסה הנוכחית של istiod במשתנה סביבתי, משתמשים בפקודה הבאה:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
הפלט אמור להיראות בערך כך: 1.16

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

יוצרים קובץ overlay.yaml חדש או מוודאים שהקובץ overlay.yaml הקיים מכיל את התוכן הבא:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

פועלים לפי ההוראות בקטעים הבאים במסמכי התיעוד של Anthos Service Mesh:
חשוב: הקפידו לפעול לפי ההוראות לשדרוג Anthos Service Mesh עם תכונות אופציונליות, ולכלול את overlay.yaml.
1. הורדה של asmcli
2. הענקת הרשאות אדמין של אשכול
3. אימות הפרויקט והאשכול
4. שדרוג עם תכונות אופציונליות עוצרים לפני שמתחילים את הקטע 'שדרוג שערים'.
מעבר למישור הבקרה החדש:
1. קבלת תווית הגרסה שמופיעה ב-istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  הפלט של הפקודה אמור להיראות כך:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. מקצים את התווית של הגרסה החדשה למשתנה סביבה.
  בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. מוסיפים את תווית הגרסה למרחב השמות istio-system ומסירים את התווית istio-injection (אם היא קיימת) באמצעות הפקודה הבאה.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  אם מופיע "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההזרקה האוטומטית נכשלת אם במרחב השמות יש גם את התווית istio-injection וגם את תווית הגרסה, ולכן כל הפקודות kubectl label בתיעוד של Anthos Service Mesh כוללות הסרה של התווית istio-injection.
4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.
```
kubectl rollout restart deployment -n istio-system
```
5. בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
6. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי לתייג את מרחב השמות ולהפעיל מחדש את ה-Pods.

מחיקת הגרסאות הקודמות:

עוברים לספרייה שבה התקנתם את asmcli.
מאחסנים את ספריית הפלט של התקנת Anthos Service Mesh במשתנה הסביבה DIR_PATH. זו אותה ספרייה שציינתם בהליך שדרוג עם תכונות אופציונליות.
```
export DIR_PATH=OUTPUT_DIR
```

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

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

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

מחוץ ל-Google Cloud

ההוראות האלה מתייחסות לשדרוג של Anthos Service Mesh ב:

אשכולות Anthos ב-VMware‏ (GKE On-Prem)
Anthos בשרת פיזי
אשכולות Anthos ב-AWS
Amazon EKS

רצף הפעולות לשדרוג ל-Anthos Service Mesh גרסה 1.17.8 בהתקנה היברידית:

מתכוננים לשדרוג.
מתקינים את הגרסה החדשה של Anthos Service Mesh.
מוחקים מההתקנה הנוכחית את הפריסות, השירותים וה-webhook של הגרסה הקודמת של Anthos Service Mesh.
שדרגו את השערים והגדירו את ה-webhook החדשים.

הכנה לשדרוג Anthos Service Mesh לגרסה 1.17.8

בודקים את הדרישות במאמר שדרוג Anthos Service Mesh, אבל לא מבצעים את השדרוג עדיין.
לפני שמתקינים את הגרסה החדשה, צריך לקבוע את הגרסה הנוכחית. תצטרכו את המידע הזה כדי למחוק מההתקנה הנוכחית את הפריסות, השירותים וה-webhook של הגרסה הקודמת של Anthos Service Mesh. כדי לאחסן את הגרסה הנוכחית של istiod במשתנה סביבתי, משתמשים בפקודה הבאה:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
הפלט אמור להיראות בערך כך: 1.16

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

יוצרים קובץ overlay.yaml חדש או מוודאים שהקובץ overlay.yaml הקיים מכיל את התוכן הבא:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

פועלים לפי ההוראות בקטעים הבאים במסמכי התיעוד של Anthos Service Mesh:
חשוב: הקפידו לפעול לפי ההוראות לשדרוג Anthos Service Mesh עם תכונות אופציונליות, ולכלול את overlay.yaml.
1. הורדה של asmcli
2. הענקת הרשאות אדמין של אשכול
3. אימות הפרויקט והאשכול
4. שדרוג עם תכונות אופציונליות עוצרים לפני שמתחילים את הקטע 'שדרוג שערים'.
מעבר למישור הבקרה החדש:
1. קבלת תווית הגרסה שמופיעה ב-istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  הפלט של הפקודה אמור להיראות כך:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. מקצים את התווית של הגרסה החדשה למשתנה סביבה.
  בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. מוסיפים את תווית הגרסה למרחב השמות istio-system ומסירים את התווית istio-injection (אם היא קיימת) באמצעות הפקודה הבאה.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  אם מופיע "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההזרקה האוטומטית נכשלת אם במרחב השמות יש גם את התווית istio-injection וגם את תווית הגרסה, ולכן כל הפקודות kubectl label בתיעוד של Anthos Service Mesh כוללות הסרה של התווית istio-injection.
4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.
```
kubectl rollout restart deployment -n istio-system
```
5. בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
6. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי לתייג את מרחב השמות ולהפעיל מחדש את ה-Pods.

מחיקת הגרסאות הקודמות:

עוברים לספרייה שבה התקנתם את asmcli.
מאחסנים את ספריית הפלט של התקנת Anthos Service Mesh במשתנה הסביבה DIR_PATH. זו אותה ספרייה שציינתם בהליך שדרוג עם תכונות אופציונליות.
```
export DIR_PATH=OUTPUT_DIR
```

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

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

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

AKS / EKS

התהליך שמתואר בהוראות האלה לשדרוג Anthos Service Mesh (Anthos Service Mesh) מגרסה 1.17.8-asm.4-distroless באשכולות שמצורפים ל-Anthos זהה לתהליך של התקנה חדשה.

הכנות להתקנת Anthos Service Mesh

לפני שמתקינים את הגרסה החדשה, צריך לקבוע את הגרסה הנוכחית. תצטרכו את המידע הזה כדי למחוק את ה-webhook של האימות ואת ה-webhook של השינוי מההתקנה הנוכחית של Anthos Service Mesh. משתמשים בפקודה הבאה כדי לאחסן את הגרסה הנוכחית של istiod במשתנה סביבתי:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
הפלט אמור להיראות בערך כך: 1.16

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

Linux

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests/profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה /bin אל PATH:

export PATH=$PWD/bin:$PATH

Mac OS

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests/profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה /bin אל PATH:

export PATH=$PWD/bin:$PATH

Windows

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-win.zip

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests\profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה ‎\bin לנתיב:

set PATH=%CD%\bin:%PATH%

אחרי שמתקינים את Anthos Service Mesh Istio, בודקים את הגרסה של istioctl:
```
istioctl version
```
יוצרים מרחב שמות בשם istio-system לרכיבי מישור הבקרה:
```
kubectl create namespace istio-system
```

התקנה של Anthos Service Mesh

עורכים את קובץ overlay.yaml או יוצרים קובץ חדש עם התוכן הבא:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

מתקינים את Anthos Service Mesh עם istioctl באמצעות פרופיל asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlay.yaml
```
הפלט אמור להיראות כך:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
הארגומנט --set revision מוסיף תווית של עדכון בפורמט istio.io/rev=asm-1178-1 ל-istiod. תווית התיקון משמשת את ה-webhook של מנגנון הזרקת ה-sidecar האוטומטי כדי לשייך sidecars מוזרקים לistiodתיקון מסוים. כדי להפעיל הזרקה אוטומטית של sidecar למרחב שמות, צריך להוסיף לו תווית עם revision שזהה לתווית ב-istiod.

מוודאים שההתקנה הושלמה:

kubectl get svc -n istio-system

הפלט אמור להיראות כך:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

מעבר למישור הבקרה החדש:
1. קבלת תווית הגרסה שמופיעה ב-istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  הפלט של הפקודה אמור להיראות כך:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. מקצים את התווית של הגרסה החדשה למשתנה סביבה.
  בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. מוסיפים את תווית הגרסה למרחב השמות istio-system ומסירים את התווית istio-injection (אם היא קיימת) באמצעות הפקודה הבאה.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  אם מופיע "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההזרקה האוטומטית נכשלת אם במרחב השמות יש גם את התווית istio-injection וגם את תווית הגרסה, ולכן כל הפקודות kubectl label בתיעוד של Anthos Service Mesh כוללות הסרה של התווית istio-injection.
4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.
```
kubectl rollout restart deployment -n istio-system
```
5. בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
6. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי לתייג את מרחב השמות ולהפעיל מחדש את ה-Pods.

מחיקת הגרסאות הקודמות:

עוברים לספרייה שבה התקנתם את asmcli.

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

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

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

OpenShift

הכנות להתקנת Anthos Service Mesh

לפני שמתקינים את הגרסה החדשה, צריך לקבוע את הגרסה הנוכחית. תצטרכו את המידע הזה כדי למחוק את ה-webhook של האימות ואת ה-webhook של השינוי מההתקנה הנוכחית של Anthos Service Mesh. משתמשים בפקודה הבאה כדי לאחסן את הגרסה הנוכחית של istiod במשתנה סביבתי:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
הפלט אמור להיראות בערך כך: 1.16

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

Linux

נותנים את אילוץ ההקשר הביטחוני (SCC) ‏anyuid ל-istio-system באמצעות הפקודה הבאה של OpenShift CLI ‏ (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests/profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה /bin אל PATH:

export PATH=$PWD/bin:$PATH

Mac OS

נותנים את אילוץ ההקשר הביטחוני (SCC) ‏anyuid ל-istio-system באמצעות הפקודה הבאה של OpenShift CLI ‏ (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests/profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה /bin אל PATH:

export PATH=$PWD/bin:$PATH

Windows

נותנים את אילוץ ההקשר הביטחוני (SCC) ‏anyuid ל-istio-system באמצעות הפקודה הבאה של OpenShift CLI ‏ (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

מורידים את קובץ ההתקנה של Anthos Service Mesh לספריית העבודה הנוכחית:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

מורידים את קובץ החתימה ומשתמשים ב-OpenSSL כדי לאמת את החתימה:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

tar xzf 1.17.8-asm.4-distroless-win.zip

הפקודה יוצרת ספריית התקנה בספריית העבודה הנוכחית בשם 1.17.8-asm.4-distroless, שמכילה:

אפליקציות לדוגמה בספרייה samples.
כלי שורת הפקודה שמשמש להתקנת Anthos Service Mesh נמצא בספרייה bin.istioctl
פרופילי ההגדרות של Anthos Service Mesh נמצאים בספרייה manifests\profiles.

מוודאים שאתם נמצאים בספריית השורש של ההתקנה של Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

כדי שיהיה לכם נוח, כדאי להוסיף את הכלים בספרייה ‎\bin לנתיב:

set PATH=%CD%\bin:%PATH%

אחרי שמתקינים את Anthos Service Mesh Istio, בודקים את הגרסה של istioctl:
```
istioctl version
```
יוצרים מרחב שמות בשם istio-system לרכיבי מישור הבקרה:
```
kubectl create namespace istio-system
```

הגדרת ה-webhook לאימות

כשמתקינים את Anthos Service Mesh, מגדירים תווית של גרסה ב-istiod. צריך להגדיר את אותה גרסה ב-webhook של האימות.

יוצרים קובץ בשם istiod-service.yaml עם התוכן הבא:

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1178-1
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1178-1
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

משתמשים ב-kubectl כדי להחיל את ההגדרות האישיות לתגובה לפעולה מאתר אחר (Webhook) לצורך אימות:
```
kubectl apply -f istiod-service.yaml
```

כדי לוודא שההגדרה הוחלה:

kubectl get svc -n istio-system

התגובה אמורה להיראות כך:

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

התקנה של Anthos Service Mesh

עורכים את קובץ overlay.yaml או יוצרים קובץ חדש עם התוכן הבא:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

מתקינים את Anthos Service Mesh עם istioctl באמצעות פרופיל asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlayfile.yaml
```
הפלט אמור להיראות כך:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
הארגומנט --set revision מוסיף תווית של עדכון בפורמט istio.io/rev=1.6.11-asm.1 ל-istiod. תווית התיקון משמשת את ה-webhook של מנגנון הזרקת ה-sidecar האוטומטי כדי לשייך sidecars מוזרקים לistiodתיקון מסוים. כדי להפעיל הזרקה אוטומטית של sidecar למרחב שמות, צריך להוסיף לו תווית עם revision שזהה לתווית ב-istiod.

מוודאים שההתקנה הושלמה:

kubectl get svc -n istio-system

הפלט אמור להיראות כך:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

מעבר למישור הבקרה החדש:
1. קבלת תווית הגרסה שמופיעה ב-istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  הפלט של הפקודה אמור להיראות כך:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. מקצים את התווית של הגרסה החדשה למשתנה סביבה.
  בפלט, בעמודה REV, מציינים את הערך של תווית הגרסה החדשה. בדוגמה הזו, הערך הוא asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. מוסיפים את תווית הגרסה למרחב השמות istio-system ומסירים את התווית istio-injection (אם היא קיימת) באמצעות הפקודה הבאה.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  אם מופיע "istio-injection not found" בפלט, אפשר להתעלם ממנו. כלומר, במרחב השמות לא הייתה קודם התווית istio-injection. ההזרקה האוטומטית נכשלת אם במרחב השמות יש גם את התווית istio-injection וגם את תווית הגרסה, ולכן כל הפקודות kubectl label בתיעוד של Anthos Service Mesh כוללות הסרה של התווית istio-injection.
4. מפעילים מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.
```
kubectl rollout restart deployment -n istio-system
```
5. בודקים את האפליקציה כדי לוודא שעומסי העבודה פועלים בצורה תקינה.
6. אם יש לכם עומסי עבודה במרחבי שמות אחרים, חוזרים על השלבים כדי לתייג את מרחב השמות ולהפעיל מחדש את ה-Pods.

מחיקת הגרסאות הקודמות:

עוברים לספרייה שבה התקנתם את asmcli.

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

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

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

החזרה למצב הקודם של שדרוג

כדי לחזור לשדרוג קודם:

מנקים את המשימות שהושלמו במרחב השמות של זמן הריצה ההיברידי, כאשר NAMESPACE הוא מרחב השמות שצוין בקובץ ההחלפות, אם צוין מרחב שמות. אם לא, מרחב השמות שמוגדר כברירת מחדל הוא apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

ניקוי משימות שהושלמו במרחב השמות apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

משנים את המשתנה APIGEECTL_HOME כך שיצביע על הספרייה שמכילה את הגרסה הקודמת של apigeectl. לדוגמה:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
מבטלים את השינויים שבוצעו בקובץ overrides:
1. מסירים את ingressGateways ואת כל המאפיינים שלו או מוסיפים אותם כהערה.
2. מגדירים את הערך של virtualhosts.selector.app לערך הקודם, לדוגמה:
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. מסירים את ao.args.disableIstioConfigInAPIServer או הופכים אותו לתגובה.
בתיקיית הבסיס של ההתקנה שרוצים לחזור אליה, מריצים את הפקודה apigeectl apply, בודקים את הסטטוס של ה-pods ואז מריצים את הפקודה apigeectl init. חשוב להשתמש בקובץ ההחלפות המקורי של הגרסה שרוצים לחזור אליה:
1. בספרייה hybrid-files, מריצים את apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  ‫ORIGINAL_OVERRIDES_FILE הוא הנתיב היחסי ושם הקובץ של קובץ ההחלפות להתקנה ההיברידית של הגרסה הקודמת, לדוגמה, ./overrides/overrides1.7.yaml.
2. בודקים את הסטטוס של ה-Pods:
```
kubectl -n NAMESPACE get pods
```
  כאשר NAMESPACE הוא מרחב השמות של Apigee Hybrid.
3. בודקים את הסטטוס של apigeeds:
```
kubectl describe apigeeds -n apigee
```
  הפלט אמור להיראות כך:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  ממשיכים לשלב הבא רק אם ה-pod‏ apigeeds פועל.
4. מריצים את הפקודה הבאה כדי לרשום את הערכים החדשים של מספר העותקים של מעבד ההודעות אחרי השדרוג.אם הערכים האלה לא תואמים לערכים שהגדרתם קודם, משנים את הערכים בקובץ ההגדרות החלופיות כך שיתאימו להגדרה הקודמת.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  הפלט אמור להיראות כך:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. אם אתם מבצעים חזרה לגרסה 1.8.4 או לגרסה קודמת של Hybrid, אתם צריכים למחוק את פריסת בקר ה-Hybrid שבה השתמשתם בגרסה 1.8.5 או בגרסה חדשה יותר:
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. מריצים את apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
מוחקים את פריסת מנהל שער הכניסה של Apigee. הרכיב הזה רלוונטי רק לגרסאות Apigee Hybrid 1.8 ואילך.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
כאשר NAMESPACE הוא מרחב השמות של Apigee Hybrid.

שדרוג Apigee Hybrid לגרסה 1.8 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

חדש: שער כניסה של Apigee

סקירה כללית על שדרוג לגרסה 1.8.8

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

הכנה לשדרוג לגרסה 1.8

גיבוי של ההתקנה ההיברידית (מומלץ)

Linux

Mac OS

Windows

מוסיפים את התפקיד Cloud Trace Agent לחשבון השירות של זמן הריצה של Apigee. (אופציונלי)

ייצור

Non-Prod

ייצור

Non-Prod

דוגמה

הכנה להתקנה של שער כניסה של Apigee

תחביר

דוגמה

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

התקנת זמן הריצה של Apigee Hybrid 1.8.8

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

ייצור

Non-prod

שדרוג גרסת Kubernetes

כאן אפשר ללחוץ כדי להרחיב את רשימת הפלטפורמות הנתמכות

פלטפורמות

רכיבים

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

העברת תעבורה מ-Anthos Service Mesh אל שער הכניסה של Apigee

שדרוג Anthos Service Mesh לגרסה 1.15

GKE

הכנה לשדרוג Anthos Service Mesh לגרסה 1.17.8

מחוץ ל-Google Cloud

הכנה לשדרוג Anthos Service Mesh לגרסה 1.17.8

AKS / EKS

הכנות להתקנת Anthos Service Mesh

Linux

Mac OS

Windows

התקנה של Anthos Service Mesh

OpenShift

הכנות להתקנת Anthos Service Mesh

Linux

Mac OS

Windows

הגדרת ה-webhook לאימות

התקנה של Anthos Service Mesh

החזרה למצב הקודם של שדרוג

שדרוג Apigee Hybrid לגרסה 1.8