המסמכים האלה מתייחסים לגרסה העדכנית של Knative serving, שמשתמשת בציים וב-Anthos Service Mesh. מידע נוסף

הגרסה הקודמת (Cloud Run for Anthos) הועברה לארכיון, אבל התיעוד שלה עדיין זמין למשתמשים קיימים.

גרסאות זמינות

הכי חדש
העברה לארכיון

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

שדרוג של מילוי בקשות מסוג Knative ב-VMware לצי

כאן מוסבר איך להעביר את Knative serving ב-VMware לשימוש בציים, כדי שתוכלו לשדרג ל-Anthos גרסה 1.8.

השירות Knative serving הוא עכשיו חוויה נפרדת ממוצר Cloud Run המנוהל, והוא מסופק עכשיו כרכיב של צי בתוך האשכולות שלכם. התקנת Knative serving בתכונות של VMware כרכיב של צי המכונות מאפשרת לכם לנהל ולשדרג את ההתקנה באופן עצמאי מרכיבים אחרים של צי המכונות.

באופן כללי, כדי להעביר את ההתקנה של Knative serving ב-VMware לשימוש בצי, צריך:

מגדירים את ההתקנה של Knative serving ב-VMware בהתאם לדרישות של הצי.
מפעילים את רכיב התכונה Knative serving בצי שלכם.

חשוב לזכור ששרת ה-API של Kubernetes לא מושפע במהלך ההעברה הזו.

פרטים על ביצוע התקנה חדשה של מילוי בקשות מסוג Knative ב-VMware זמינים במאמר התקנת מילוי בקשות מסוג Knative ב-VMware.

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

עליכם לעמוד בדרישות הבאות:

כדי לבצע את השלבים האלה, צריך לרשום את Knative serving באשכול VMware לציוד, והוא צריך להיות גלוי במסוף Google Cloud :

מעבר לאשכולות GKE
ההתקנה של Knative serving ב-VMware נמצאת באשכול שפועל ב-Anthos מגרסה 1.7 או מגרסה מוקדמת יותר.
אין יותר תמיכה ב-Istio ב-Anthos 1.8. צריך להתקין את Cloud Service Mesh בגרסה 1.19 בצי המחשבים, ולהגדיר את ההתקנה של Knative serving לפני שמשדרגים את האשכול לגרסה 1.8.

הוראות מפורטות לגבי התקנה ב-Google Distributed Cloud זמינות במאמר בנושא Cloud Service Mesh.

שימו לב: כדי להשתמש ב-Cloud Service Mesh, האשכול צריך להשתמש בסוג מכונה עם לפחות ארבעה מעבדים וירטואליים (vCPU), כמו e2-standard-4. אם אתם צריכים לשנות את סוג המכונה של האשכול, תוכלו לקרוא את המאמר העברת עומסי עבודה לסוגי מכונות שונים.
יש שתי אפשרויות להעברת Knative serving אל Cloud Service Mesh:
- מקבלים כתובת IP חיצונית חדשה ומגדירים את מאזן העומסים להשתמש בה.
- שימוש חוזר בכתובת ה-IP הקיימת של מאזן העומסים.
  
  אזהרה: תהליך השימוש החוזר בכתובת IP קיימת כדי להגדיר את Cloud Service Mesh גורם להשבתה של החיבור למשך כ-2 דקות. חשוב לתכנן את הפעולות כך שיתאימו לתקופה הזו שבה שירותי Knative serving לא יכולים להתחבר.
מוודאים שסביבת שורת הפקודה מוגדרת ועדכנית.

העברה למאגרי מכשירים

כדי לשדרג את Anthos לגרסה 1.8, קודם צריך לבצע את השלבים הבאים כדי לוודא שההתקנה הקיימת של Knative serving ב-VMware תועבר לשימוש ברכיב fleet.

גישה לאשכול האדמין

מקבלים את הנתיב ואת שם הקובץ של קובץ ה-kubeconfig של אשכול האדמין, ואז יוצרים את משתנה הסביבה ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

מחליפים את [ADMIN_CLUSTER_KUBECONFIG] בנתיב ובשם הקובץ של קובץ ה-kubeconfig של אשכול האדמין.

הגדרת כל אשכול משתמשים

יוצרים את משתני הסביבה המקומיים הבאים עבור אשכול המשתמשים:
1. יוצרים את משתנה הסביבה USER_KUBECONFIG עם הנתיב של קובץ ה-kubeconfig של אשכול המשתמש:
```
export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
```
  מחליפים את [USER_CLUSTER_KUBECONFIG] בנתיב ובשם הקובץ של קובץ ה-kubeconfig של אשכול המשתמשים.
2. יוצרים משתני סביבה להגדרות הבאות:
  - המזהה של פרויקט Google Cloud .
  - המיקום של המשאבים Google Cloud .
  - השם של אשכול המשתמשים.
```
export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}")
export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}")
export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
```

מסירים את ההגדרה cloudrun מהמשאב המותאם אישית OnPremUserCluster של אשכול המשתמשים:

מוודאים שהערך cloudRun מוגדר ב-OnPremUserCluster:

$ kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"

תוצאה:

{"enabled":true}

הסרת cloudRun מהחשבון OnPremUserCluster:

kubectl patch onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --type="merge" \
  --patch '{"spec": {"cloudRun": null}}'

כדי לוודא שהסרתם את cloudRun מ-OnPremUserCluster, מריצים את אותה פקודה get ומוודאים שלא מוחזרת הגדרה:

kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"

לא אמור להיות פלט בטרמינל.

מעדכנים את הסוד של create-config באשכול המשתמשים:
1. יוצרים עותק מקומי של קובץ ה-YAML של create-config:
```
kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}" \
  --output=jsonpath={.data.cfg} \
  | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
```
2. פותחים את קובץ ${CLUSTER_NAME}_create_secret.yaml שיצרתם בעורך ומסירים את השדה cloudrun מתחת ל-spec.
3. מקודדים את הקובץ ${CLUSTER_NAME}_cluster_create_secret.yaml בקידוד Base64 לקובץ .b64:
```
cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
```
4. בעורך, פותחים את הקובץ המקומי .b64 שיצרתם זה עתה ומעתיקים את המחרוזת מתחת למאפיין data.cfg לשימוש בשלב הבא.
  
  חשוב להקפיד להעתיק רק את התוכן מהמאפיין cfg. לדוגמה, אין לכלול מעברי שורה (\n).
5. מריצים את הפקודה הבאה כדי לערוך את ה-Secret באשכול המשתמשים:
```
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"
```
6. בכלי העריכה שנפתח, מחליפים את השדה data[cfg] במחרוזת שהעתקתם מקובץ .b64 המקומי, ואז שומרים את השינויים.
7. מוודאים שהשינויים נפרסו באשכול המשתמשים ושהמאפיין cloudrun הוסר בהצלחה מהסודות create-config:
```
kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace ${CLUSTER_NAME} \
  --output=jsonpath={.data.cfg} \
  | base64 -d
```

מגדירים את מרחב השמות knative-serving באשכול המשתמשים:

מוחקים את האופרטור cloudrun-operator ממרחב השמות knative-serving:

kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator

מבצעים תיקון של ה-configmap‏ config-network במרחב השמות knative-serving:

kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'

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

הגדרת רכיב הצי

מפעילים את רכיב Knative serving בצי:
```
gcloud container fleet cloudrun enable --project=$PROJECT_ID
```
פרטים ואפשרויות נוספות מופיעים במאמר בנושא gcloud container fleet cloudrun enable.
אופציונלי: מוודאים שרכיב התכונה Knative serving מופעל:
המסוף
כדי לראות אם רכיב Knative serving מופעל במסוףGoogle Cloud :

מעבר אל Feature Manager
שורת הפקודה
בודקים אם הסטטוס של appdevexperience הוא ENABLED:
gcloud container fleet features list --project=$PROJECT_ID
פרטים ואפשרויות נוספות מופיעים במאמר רשימת התכונות של gcloud container fleet.

תוצאה:
NAME STATE appdevexperience ENABLED
פורסים את המשאב המותאם אישית CloudRun כדי להתקין את Knative serving ב-VMware בכל אחד מאשכולות המשתמשים. כברירת מחדל, נפרסת גרסה latest של Knative serving.

חשוב: אם יש לכם ריבוי משתמשים, צריך לחזור על השלב הזה עבור כל אשכול משתמשים.

מריצים את הפקודה הבאה kubectl apply כדי לפרוס את הגדרת ברירת המחדל של המשאב המותאם אישית CloudRun:
```
cat <<EOF | kubectl apply -f -
apiVersion: operator.run.cloud.google.com/v1alpha1
kind: CloudRun
metadata:
  name: cloud-run
spec:
  metricscollector:
    stackdriver:
      projectid: $PROJECT_ID
      gcpzone: $CLUSTER_LOCATION
      clustername: $CLUSTER_NAME
      secretname: "stackdriver-service-account-key"
      secretkey: "key.json"
EOF
```

הגדרת Cloud Service Mesh

מגדירים את מאזן העומסים של Cloud Service Mesh לכל אחד מאשכולות המשתמשים.

אפשר להגדיר את שער הכניסה של Cloud Service Mesh באמצעות הגדרה של כתובת IP חיצונית חדשה או שימוש חוזר בכתובת ה-IP הקיימת:

בעזרת כתובת ה-IP החיצונית החדשה שקיבלתם, אתם מגדירים את מאזן העומסים לפי השלבים שמפורטים במסמכי Cloud Service Mesh.

חשוב לדעת: האפשרות הזו מבטיחה שהשירותים שלכם ב-Knative serving יופעלו מחדש ללא הפרעה.

אפשרות חלופית: מבצעים את השלבים הבאים כדי להגדיר את מאזן העומסים של Cloud Service Mesh לכתובת ה-IP הקיימת.

מגדירים את השער של השירותים ל-Cloud Service Mesh באמצעות הפקודות הבאות:

export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}')
kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}"
kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"

מסירים את ההגדרות הנוכחיות של Istio:

kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}'
kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'

אימות ההעברה

כדי לוודא שההעברה של Knative serving ב-VMware לצי שלכם בוצעה בהצלחה, אתם יכולים לבדוק אם appdevexperience-operator פועל.

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

 kubectl get deployment -n appdevexperience appdevexperience-operator

appdevexperience-operator האופרטור צריך להופיע כשהוא מוכן, לדוגמה: 1/1

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

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

מעבר לעומסי עבודה (workload) של Google Kubernetes Engine

שדרוג האשכול

עכשיו, אחרי שהעברתם את ההתקנה של Knative serving ב-VMware לשימוש ברכיב fleet, אתם יכולים לשדרג את האשכול ל-Anthos גרסה 1.8. פועלים לפי ההוראות המפורטות במאמר בנושא שדרוג GKE On-Prem.

פתרון בעיות

תהליך השדרוג של אשכול המשתמשים לא הושלם

יכול להיות שה-pod‏ cluster-local-gateway במרחב השמות gke-system ימנע מאשכול המשתמשים להשלים את השדרוג לגרסה 1.8 של Anthos. אין יותר צורך ב-cluster-local-gateway pod ואפשר להסיר אותו בבטחה.

כדי לעזור בתהליך השדרוג באופן ידני, אפשר להסיר ידנית את הפוד cluster-local-gateway על ידי הקטנת מספר העותקים של הפריסה ל-0. לדוגמה:

הקטנת המידה של cluster-local-gateway:
```
kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
```
ה-pod‏ cluster-local-gateway במרחב השמות gke-system וכל עומסי העבודה במרחב השמות knative-serving מוסרים.
ממתינים עד שתהליך השדרוג יסתיים.

מידע נוסף על הרחבת פריסות