פתרון בעיות ב-Config Controller

בדף הזה מוסבר איך לפתור בעיות ב-Config Controller.

פתרון בעיות בהתקנה

אין רשת בשם default

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

Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n  on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"

השגיאה הזו מתרחשת אם לא ציינתם רשת קיימת באמצעות הדגל --network, ורשת ברירת המחדל שלכם ב- Google Cloudנמחקה או הושבתה. כברירת מחדל, Config Controller יוצר את אשכול Google Kubernetes Engine שתומך במופע Config Controller ברשת ברירת המחדל.

אם רוצים ליצור את המופע ברשת קיימת, מוסיפים את הדגל --network=NETWORK כשיוצרים את מופע Config Controller. מחליפים את NETWORK בשם של רשת קיימת.

אם רוצים ליצור את מכונת Config Controller ברשת שמוגדרת כברירת מחדל, צריך ליצור מחדש את הרשת שמוגדרת כברירת מחדל באמצעות הפקודה הבאה:

gcloud compute networks create default --subnet-mode=auto

כדי שהפקודה הזו תפעל, צריך להפעיל רשתות משנה אוטומטיות באמצעות הדגל --subnet-mode=auto.

אחרי שיוצרים מחדש את רשת ברירת המחדל, אפשר להשמיט את הדגל --network כשיוצרים את מופע Config Controller.

ערך לא תקין של MasterIpv4CidrBlock

יצירת Config Controller משתמשת ברשת משנה שמוגדרת כברירת מחדל 172.16.0.128/28 עבור CIDR של IPv4 במישור הבקרה. אם יש התנגשות בבלוק ה-CIDR של IPv4, יצירת Config Controller נכשלת עם השגיאה הבאה:

Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.

אם השגיאה הזו מופיעה, צריך לבחור CIDR פרטי אחר של IPv4 ולהשתמש בו באמצעות הדגל --master-ipv4-cidr-block בפקודה gcloud anthos config controller create.

כדי למצוא בלוקים של כתובות IPv4 CIDR שכבר נמצאים בשימוש, מבצעים את השלבים הבאים:

מאתרים את שם ה-peering:

gcloud compute networks peerings list --network=NETWORK

מחליפים את NETWORK בשם הרשת שרוצים לחפש.

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

NAME                                    NETWORK   PEER_PROJECT               PEER_NETWORK                            PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
gke-n210ce17a4dd120e16b6-7ebf-959a-peer  default  gke-prod-us-central1-59d2  gke-n210ce17a4dd120e16b6-7ebf-0c27-net            False                 False                 ACTIVE  [2021-06-08T13:22:07.596-07:00]: Connected.

הצגת ה-CIDR של IPv4 שנעשה בו שימוש בקישור בין רשתות שכנות (peering):
```
gcloud compute networks peerings list-routes PEERING_NAME \
    --direction=INCOMING \
    --network=NETWORK \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PEERING_NAME: השם של ה-peering שרוצים לחפש
- ‫NETWORK: השם של הרשת שרוצים לחפש
- ‫REGION: השם של האזור שבו נמצא מופע Config Controller

פתרון בעיות במהלך הפעלת Config Controller

נגמרו כתובות ה-IP במאגר הצמתים

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

Can't scale up because instances in managed instance groups hosting node pools ran out of IPs

הבעיה הזו יכולה לקרות אם לא מציינים את הדגל --cluster-ipv4-cidr-block. כשלא מציינים את ה-flag הזה, Config Controller משתמש כברירת מחדל בטווח ה-CIDR של ה-Pod‏ /20. הטווח הזה מאפשר להשתמש ב-16 צמתים לכל היותר.

אם אתם צריכים יותר צמתים, תצטרכו למחוק את מופע Config Controller כי אי אפשר לשנות את בלוק ה-CIDR אחרי שהוא נוצר. כשיוצרים מחדש את מופע Config Controller, משתמשים בפרמטר האופציונלי --cluster-ipv4-cidr-block ומציינים את CIDR range or netmask size.

חסר מידע בלוח הבקרה

אם לא מוצגים פרטים לגבי Config Controller בלוח הבקרה של המסוף Google Cloud , יכול להיות שלחשבון השירות שמוגדר כברירת מחדל ומשמש את Config Controller אין את ההרשאות הנדרשות ב-Google Cloud Observability.

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

# Cloud Monitoring metrics permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/monitoring.metricWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/stackdriver.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/opsconfigmonitoring.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Logging permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/logging.logWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Trace permissions\
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudtrace.agent \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

מחליפים את מה שכתוב בשדות הבאים:

‫PROJECT_ID: מזהה הפרויקט שבו יצרתם את מופע Config Controller
‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud

פתרון בעיות ברכיבים

מכיוון שמופע Config Controller מגיע עם Policy Controller,‏ סנכרון תצורות ו-Config Connector שמותקנים מראש, יכול להיות שתיתקלו בבעיות ברכיבים האלה. כדי ללמוד איך לפתור בעיות שקשורות לרכיבים האלה, כדאי לעיין בדפים הבאים:

בקטעים הבאים מפורטות הצעות לפתרון חלק מהבעיות הנפוצות יותר שאתם עשויים להיתקל בהן כשאתם משתמשים ב-Config Controller עם הרכיבים האלה.

שגיאות בסנכרון

ההגדרות במקור האמת (לדוגמה, מאגר Git או תמונת OCI) מסונכרנות עם מופע Config Controller באמצעות סנכרון תצורות. כדי לבדוק אם יש שגיאות בתהליך הסנכרון הזה, משתמשים בפקודה nomos status:

nomos status  --contexts $(kubectl config current-context)

פתרון בעיות במשאבים של Config Connector

שדות ומשאבים שלא ניתן לשנות

חלק מהשדות במשאבי Google Cloud הבסיסיים לא ניתנים לשינוי, כמו מזהי פרויקטים או השם של רשת ה-VPC. ‫Config Connector חוסם עריכות בשדות כאלה ולא יכול להפעיל שינויים. אם רוצים לערוך אחד מהשדות האלה שלא ניתן לשינוי, צריך למחוק את המשאב המקורי (דרך Git) לפני שמוסיפים אותו מחדש עם הערכים הרצויים.

משאבים תקועים

לפעמים, יכול להיות שהמשאבים לא יימחקו כמו שצריך (כפי שמדווח ב-nomos status). כדי לפתור את הבעיה, אפשר להסיר את ה-finalizers מהמשאב ואז למחוק את המשאב באופן ידני.

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

kubectl patch IAMPolicyMember logging-sa-iam-permissions \
    -p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

פתרון בעיות ב-Config Controller קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.