‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

מעבר מ-In-cluster ל-Managed Canonical Service Controller

הערה: שירותים קנוניים נתמכים באופן אוטומטי ב-Cloud Service Mesh מגרסה 1.6.8 ואילך.

במדריך הזה מוסבר איך לבצע מיגרציה מ-Canonical Service Controller בתוך האשכול אל Managed Canonical Service Controller.

הוצאנו משימוש את Canonical Service Controller בתוך האשכול, והוא לא יקבל יותר עדכונים. פריסות קיימות של בקר בתוך האשכול ימשיכו לפעול, אבל מומלץ מאוד לבצע מיגרציה לבקר שירות Canonical מנוהל כדי להבטיח תאימות לגרסאות עתידיות, גישה לתכונות העדכניות ותמיכה רציפה. כל ההתקנות של Cloud Service Mesh עם asmcli מגרסה 1.25 יוקצו עם בקר השירות המנוהל של Canonical.

1. הפעלת התכונה Cloud Service Mesh fleet

הבקר של שירות קנוני מנוהל מותקן כחלק מתכונת הצי של Cloud Service Mesh, שמופעלת באמצעות הפקודה הבאה:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

מחליפים את FLEET_PROJECT_ID במזהה של פרויקט המארח של Fleet. בדרך כלל, השם של FLEET_PROJECT_ID זהה לשם הפרויקט.

הערה: אם אתם מתכננים לרשום כמה אשכולות, הפעלת Cloud Service Mesh מתבצעת ברמת הצי, כך שצריך להריץ את הפקודה הזו רק פעם אחת.

מתן הרשאות לחשבונות השירות ב-Cloud Service Mesh

אם הפרויקט של האשכול שונה מפרויקט המארח של ה-Fleet, צריך לאפשר לחשבונות השירות של Cloud Service Mesh בפרויקט ה-Fleet גישה לפרויקט האשכול.

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

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

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

מחליפים את CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול ואת FLEET_PROJECT_NUMBER במספר הפרויקט של צי הרכבים.

כדי לברר את מספר הפרויקט של הצי, אפשר לעיין בהוראות במאמר בנושא פרויקטים ב-Google Cloud.

2. השבתה של Canonical Service Controller בתוך האשכול

אי אפשר להשתמש ב-Managed Canonical Service Controller לצד In-cluster Canonical Service controller. לכן, צריך להשבית את בקר ה-in-cluster.

בודקים אם יש בקר באשכול: מוודאים שהבקר הקנוני באשכול קיים.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
מחיקת בקר בתוך האשכול: אם הפריסה נמצאה, אפשר למחוק אותה (ואת כל מרחב השמות asm-system) על ידי הפעלת הפקודה הבאה:
```
kubectl delete namespace asm-system
```

3. איך בודקים שהבקר הקנוני המנוהל פועל

הסטטוס של בקר השירות הקנוני המנוהל מדווח במצב התכונה, כך שאפשר לוודא שההתקנה פועלת בצורה תקינה על ידי בדיקת מצב התכונה:

בדיקת סטטוס התכונה: כדי לאחזר את סטטוס התכונה, מריצים את הפקודה הבאה:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
סטטוס האימות: בודקים את המצב של האשכול ומוודאים שהערך של state.code הוא OK.
- חשוב: יכול להיות שיחלפו עד 15 דקות עד שהסטטוס ישתנה ל-OK. מחכים ומריצים מחדש את הפקודה.
- עוברים לשלב הבא רק כשstate.code הוא OK.
- אם אחרי 15 דקות הסמל state.code לא משתנה ל-OK, אפשר לעיין במאמר פתרון בעיות בבקר שירות קנוני מנוהל לקבלת הנחיות לפתרון בעיות.
פלט לדוגמה:
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
בדיקה שהבקר הקנוני המנוהל פועל: כדי לוודא שהבקר הקנוני המנוהל פועל בצורה תקינה, צריך לפרוס pod עם sidecar מוזרק ולבדוק אם הבקר יוצר באופן אוטומטי את השירות הקנוני המתאים.
1. יוצרים מרחב שמות עם הזרקה אוטומטית של sidecar:
```
kubectl create namespace NAMESPACE_NAME
```
  פועלים לפי ההוראות שבקטע הפעלת הוספה אוטומטית של sidecar כדי להפעיל הוספה אוטומטית של sidecar במרחב השמות החדש שנוצר.
2. יוצרים קובץ YAML בשם simple_pod.yaml עם התוכן הבא:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  הלייבל app קובע את השם של השירות הקנוני. מידע נוסף זמין במאמר הגדרת שירות קנוני.
3. מפעילים את הפקודה הבאה כדי לפרוס את ה-Pod. מחליפים את NAMESPACE_NAME בשם של מרחב השמות שבו הפעלתם הזרקה אוטומטית של sidecar.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. בודקים שה-pod נוצר:
```
kubectl get pods -n NAMESPACE_NAME
```
  פלט לדוגמה:
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  ‫Note: מוודאים שבטור READY מופיע הערך 2/2. המשמעות היא שגם מאגר הנתונים הראשי וגם ה-sidecar proxy פועלים בצורה תקינה. אם מופיע ערך אחר, סביר להניח שהזרקת sidecar אוטומטית לא מופעלת במרחב השמות.
5. מאמתים את יצירת השירות הרשמי: מריצים את הפקודה הבאה כדי להציג את כל השירותים הרשמיים במרחב השמות. מוודאים שנוצר Canonical Service my-app.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  פלט לדוגמה:
```
  NAME          AGE
  my-app        3s
```
6. ניקוי: מוחקים את ה-Pod, את השירות הקנוני ואת מרחב השמות:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
פתרון בעיות:
- אם שירות קנוני נדרש לא נוצר, אפשר לעיין במאמר בנושא פתרון בעיות שקשורות לשירות קנוני ב-Cloud Service Mesh.
- אם הבעיה נמשכת, אפשר לחזור לשימוש בבקר בתוך האשכול. לחזור לגרסה קודמת של In-Cluster Canonical Service Controller

חזרה ל-In-Cluster Canonical Service Controller

אם נתקלים בבעיות ב-Managed Canonical Service Controller, אפשר להתקין מחדש את בקר האשכול באמצעות הפקודה הבאה:

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.28/asm/canonical-service/controller.yaml

המאמרים הבאים

מידע על: