פתרון בעיות בהקצאת הרשאות לתוכנה

בדף הזה מוסבר איך לפתור בעיות נפוצות בהקצאת תוכנות.

פתרון בעיות בהפעלה של מישור הבקרה

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

1. בודקים את ה-Pod של anthos-cluster-operator:

   kubectl logs deployment/anthos-cluster-operator -c operator -n kube-system
   

2. בודקים את המשאבים AddOn:

   kubectl get AddOn -A
   

   אפשר גם להשתמש בפקודה gpc-addons כדי לראות את המשאבים ולקבל מידע נוסף.

3. כדאי לעיין במקורות המידע הבאים: AddOnSet

   kubectl get AddOnSet -A
   

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

   kubectl get secret root-admin-kubeconfig -n root -o jsonpath="{.data.value}" | base64 -d > /root/path/to/root-admin-kubeconfig.yaml
   

פתרון בעיות ביצירת אשכול

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

1. בודקים את השלב הנוכחי של האשכול, מוודאים שהאובייקט Harbor-operator או Harbor קיימים ובודקים את הסטטוס שלהם במשאב AddOnSet של אשכול KIND על ידי הרצת הפקודה הבאה:

   kubectl get addonset -n fleet-root root-admin -o yaml
   

   אחרי שמריצים את הפקודה הזו, אפשר לראות את השלב הנוכחי ב-status.currentStage.

2. באשכול התשתית של הארגון, בודקים את המשאבים במרחב השמות harbor-system. אם פרסתם את האובייקט HarborCluster באמצעות הפקודה kubectl get harborcluster harbor -n harbor-system, זה מצביע על כך שההתקנה עברה לשלב השני, שלב Harbor.

3. בודקים את השדה status באובייקט HarborCluster:

   kubectl -n harbor-system get harborcluster harbor
   

   אם הסטטוס הוא healthy, צריך לוודא שהפונקציונליות שלו תקינה דרך פורטל האינטרנט באמצעות הפקודה docker push.

4. נכנסים לפורטל האינטרנטי בכתובת ה-URL שדווחה. לדוגמה: https://10.200.0.36:10443.

5. ב-bootstrapper, מריצים את הפקודה docker push.

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

   kubectl -n harbor-system get harborcluster harbor -o yaml
   

   אם הסטטוס הוא healthy, עוברים אל הקטע בדיקת הסטטוס של Istio. אם הסטטוס לא מופיע healthy, ממשיכים לקטע הבא, הערכת משאבים במרחב השמות של Harbor.

הערכה של משאבי מרחב שמות ב-Harbor

צריך לבצע את השלבים האלה רק אם למשאבי harbor-system אין סטטוס של healthy. כדי לבדוק את הסטטוס של harbor-system המשאבים, אפשר לעיין במאמר פתרון בעיות ביצירת אשכולות.

1. בודקים את המשאבים במרחב השמות harbor-system:

   kubectl get all -n harbor-system
   

2. בודקים את הסטטוס של משאבים שקשורים לאופרטור Harbor, כולל האופרטורים PostgreSQL ו-Redis שנבנים כתרשימי משנה במהלך השלב השני של תהליך יצירת אשכול התשתית של הארגון. מוודאים שהאופרטורים הבאים נמצאים במצב Running:

   deployment/harbor-operator-harbor-operator
   deployment/harbor-operator-postgres-operator
   deployment/harbor-operator-redisoperator
   

3. מוודאים שלרכיבים של PostgreSQL,‏ Redis ו-Harbor יש סטטוס של healthy. אם חלק מה-Pods לא במצב healthy, כדאי לבדוק את הפרטים של ה-Pod שנכשל באמצעות הפקודות הבאות:

   kubectl get pod -o wide
   kubectl describe pod
   

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

   kubectl logs -f deploy/harbor-operator-postgres-operator
   

4. כדי לבדוק את משאב PostgreSQL, אפשר לעיין ב-statefulset/postgresql-harbor-system-harbor.

5. כדי לבדוק את משאב Redis, אפשר לעיין ב:

   1. מכונת Redis:‏statefulset/rfr-harbor-redis
   2. ‫Redis sentinel:deployment/rfs-harbor-redis

   רכיבי הליבה של Harbor נפרסים רק כששני הרכיבים מוכנים.

   אם חלק מה-Pods של רכיב הליבה של Harbor נכשלים, בודקים את היומנים מה-Pod שנכשל. במקרים מסוימים, יש בעיה בתקשורת עם מכונות PostgreSQL או Redis.

   לדוגמה, אם רכיב הליבה של Harbor לא יכול להתחבר ל-PostgreSQL או ל-Redis עם פרטי הכניסה שסופקו, יכול להיות שיש בעיה ב-Harbor Operator, שאחראי להגדרת פרטי הכניסה לפני פריסת רכיבי הליבה של Harbor.

בדיקת הסטטוס של Istio

כדי לוודא שהסטטוס של ה-Pod הוא istio, כמו istio-system ו-service/istio-ingressgateway, בודקים אם יציאה 10443 חשופה.