מדריך חזותי לפתרון בעיות Kubernetes

הערה. תרגום: מאמר זה הוא חלק מחומרי הפרויקט המתפרסמים ברשות הציבור learnk8s, הדרכה של חברות ומנהלים בודדים לעבודה עם Kubernetes. בו, דניאל פולנצ'יק, מנהלת פרויקטים, חולקת הנחיות חזותיות לגבי הצעדים שיש לנקוט במקרה של בעיות כלליות עם יישומים הפועלים באשכול K8s.

TL;DR: הנה תרשים שיעזור לך לנפות באגים בפריסה ב-Kubernetes:

תרשים זרימה לאיתור ותיקון שגיאות באשכול. המקור (באנגלית) זמין ב PDF и כתמונה.

בעת פריסת יישום ל-Kubernetes, יש בדרך כלל שלושה רכיבים שעליך להגדיר:

• פְּרִיסָה - זהו סוג של מתכון ליצירת עותקים של האפליקציה, הנקרא תרמילים;
• שֵׁרוּת - מאזן עומסים פנימי המחלק תנועה בין תרמילים;
• Ingress - תיאור של האופן שבו תעבור תנועה מהעולם החיצון לשירות.

להלן תקציר גרפי מהיר:

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

2) המאזן הפנימי נקרא שירות, החיצוני נקרא Ingress.

3) הפריסה יוצרת פודים ומנטרת אותם (הם לא נוצרים באופן ידני).

נניח שאתה רוצה לפרוס יישום פשוט א-לה שלום עולם. תצורת YAML עבורו תיראה כך:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

ההגדרה די ארוכה וקל להתבלבל לגבי האופן שבו הרכיבים קשורים זה לזה.

לדוגמה:

• מתי כדאי להשתמש ביציאה 80 ומתי כדאי להשתמש ב-8080?
• האם עלי ליצור יציאה חדשה עבור כל שירות כדי שהם לא יתנגשו?
• האם שמות התוויות חשובים? האם הם צריכים להיות זהים בכל מקום?

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

הקשר בין פריסה לשירות

תתפלאו, אבל פריסה ושירות לא קשורים בשום צורה. במקום זאת, שירות מצביע ישירות על Pods, עוקף את הפריסה.

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

1. בוחר (selector) עבור השירות חייב להתאים לפחות תווית Pod אחת.
2. targetPort חייב להתאים עם containerPort מיכל בתוך הפוד.
3. port שירות יכול להיות כל דבר. שירותים שונים יכולים להשתמש באותה יציאה מכיוון שיש להם כתובות IP שונות.

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

1) דמיינו שהשירות מפנה תנועה לפוד מסוים:

2) בעת יצירת פוד, עליך לציין containerPort עבור כל מיכל בתרמילים:

3) בעת יצירת שירות, עליך לציין port и targetPort. אבל באיזה מהם משתמשים כדי להתחבר למיכל?

4) דרך targetPort. זה חייב להתאים containerPort.

5) נניח שפורט 3000 פתוח במיכל ואז הערך targetPort צריך להיות זהה.

בקובץ YAML, תוויות ו ports / targetPort חייב להתאים:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

מה לגבי התווית track: canary בחלק העליון של קטע הפריסה? זה צריך להתאים?

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

מה עם הבורר matchLabels?

זה חייב תמיד להתאים לתוויות של הפוד, מכיוון שהוא משמש את Deployment למעקב אחר תרמילים.

נניח שביצעת את העריכות הנכונות. איך בודקים אותם?

אתה יכול לבדוק את תווית הפוד עם הפקודה הבאה:

kubectl get pods --show-labels

לחלופין, אם תרמילים שייכים למספר יישומים:

kubectl get pods --selector any-name=my-app --show-labels

שם any-name=my-app הוא תווית any-name: my-app.

נשארו קשיים?

אתה יכול להתחבר לפוד! לשם כך עליך להשתמש בפקודה port-forward ב- kubectl. הוא מאפשר להתחבר לשירות ולבדוק את החיבור.

kubectl port-forward service/<service name> 3000:80

Здесь:

• service/<service name> - שם השירות; במקרה שלנו זה כן my-service;
• 3000 הוא היציאה שצריך לפתוח במחשב;
• 80 - יציאה שצוינה בשדה port שירות.

אם החיבור נוצר, אז ההגדרות נכונות.

אם החיבור נכשל, יש בעיה עם התוויות או שהיציאות אינן תואמות.

הקשר בין שירות ל-Ingress

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

בתיאור של Ingress ו-Service חייבים להתאים שני פרמטרים:

1. servicePort ב-Ingress חייב להתאים לפרמטר port בשירות;
2. serviceName ב-Ingress חייב להתאים לשדה name בשירות.

התרשים הבא מסכם את חיבורי היציאה:

1) כפי שאתה כבר יודע, שירות מקשיב למשהו מסוים port:

2) ל-Ingress יש פרמטר שנקרא servicePort:

3) פרמטר זה (servicePort) חייב תמיד להתאים port בהגדרת השירות:

4) אם פורט 80 מצוין בשירות, אז זה הכרחי servicePort היה שווה גם ל-80:

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

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

איך בודקים אם Ingress פועל?

אתה יכול להשתמש בשיטה עם kubectl port-forward, אבל במקום השירות אתה צריך להתחבר לבקר Ingress.

ראשית עליך לברר את שם הפוד עם בקר Ingress:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

מצא את הפוד של Ingress (ייתכן שהוא נמצא במרחב שמות אחר) והפעל את הפקודה describeכדי לגלות את מספרי היציאה:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

לבסוף, התחבר לתרמיל:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

כעת בכל פעם שאתה שולח בקשה ליציאה 3000 במחשב שלך, היא תועבר ליציאה 80 של הפוד עם בקר Ingress. בכך שתלך ל http://localhost:3000, אתה אמור לראות את הדף שנוצר על ידי היישום.

סיכום יציאות

בואו נזכור שוב אילו יציאות ותוויות חייבות להתאים:

1. הבורר בהגדרת השירות חייב להתאים לתווית התרמיל;
2. targetPort בהגדרה השירות חייב להתאים containerPort מיכל בתוך תרמיל;
3. port בהגדרה שירות יכול להיות כל דבר. שירותים שונים יכולים להשתמש באותה יציאה מכיוון שיש להם כתובות IP שונות;
4. servicePort הכניסה חייבת להתאים port בהגדרת שירות;
5. שם השירות חייב להתאים לשדה serviceName ב-Ingress.

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

מה קורה כשדברים משתבשים?

ייתכן שהפוד לא יתחיל או שהוא עלול לקרוס.

3 שלבים לאבחון בעיות יישומים ב-Kubernetes

לפני שתתחיל לנפות באגים בפריסה שלך, אתה צריך להבין טוב איך Kubernetes עובד.

מכיוון שלכל אפליקציה שהורדה ב-K8s יש שלושה רכיבים, יש לבצע ניפוי באגים בסדר מסוים, החל מלמטה.

1. ראשית עליך לוודא שהתרמילים פועלים, ואז...
2. בדוק אם השירות מספק תעבורה לתרמילים, ולאחר מכן...
3. בדוק אם Ingress מוגדר כהלכה.

ייצוג ויזואלי:

1) כדאי להתחיל לחפש בעיות מלמטה. תחילה בדוק שלפודים יש סטטוסים Ready и Running:

2) אם התרמילים מוכנים (Ready), עליך לברר אם השירות מפיץ תעבורה בין תרמילים:

3) לבסוף, עליך לנתח את הקשר בין השירות ל-Ingress:

1. אבחון תרמילים

ברוב המקרים הבעיה קשורה לתרמיל. ודא כי תרמילים מופיעים בתור Ready и Running. אתה יכול לבדוק זאת באמצעות הפקודה:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

בפלט הפקודה למעלה, הפוד האחרון רשום בתור Running и Readyעם זאת, זה לא המקרה עבור השניים האחרים.

איך להבין מה השתבש?

ישנן ארבע פקודות שימושיות לאבחון תרמילים:

1. kubectl logs <имя pod'а> מאפשר לך לחלץ יומנים ממיכלים בתרמיל;
2. kubectl describe pod <имя pod'а> מאפשר לך להציג רשימה של אירועים הקשורים לתרמיל;
3. kubectl get pod <имя pod'а> מאפשר לך לקבל את תצורת YAML של פוד המאוחסן ב-Kubernetes;
4. kubectl exec -ti <имя pod'а> bash מאפשר לך להפעיל מעטפת פקודה אינטראקטיבית באחד ממיכלי הפוד

באיזה מהם כדאי לבחור?

העובדה היא שאין פקודה אוניברסלית. יש להשתמש בשילוב של אלה.

בעיות תרמילים אופייניות

ישנם שני סוגים עיקריים של שגיאות פוד: שגיאות הפעלה ושגיאות זמן ריצה.

שגיאות הפעלה:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

שגיאות זמן ריצה:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

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

ImagePullBackOff

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

1. שם התמונה שגוי - למשל, טעית בה, או שהתמונה לא קיימת;
2. צוין תג לא קיים עבור התמונה;
3. התמונה מאוחסנת ברישום פרטי ול-Kubernetes אין הרשאה לגשת אליה.

קל לבטל את שתי הסיבות הראשונות - פשוט תקן את שם התמונה והתג. במקרה של האחרון, עליך להזין אישורים עבור הרישום הסגור ב-Secret ולהוסיף קישורים אליו בפודים. בתיעוד של Kubernetes יש דוגמה כיצד ניתן לעשות זאת.

Crash Loop Back Off

Kubenetes זורק שגיאה CrashLoopBackOff, אם המיכל אינו יכול להתחיל. זה קורה בדרך כלל כאשר:

1. יש באג באפליקציה שמונע ממנו להפעיל;
2. מכולה מוגדר בצורה שגויה;
3. מבחן Liveness נכשל יותר מדי פעמים.

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

kubectl logs <pod-name> --previous

הוא מציג הודעות שגיאה מהגלגול הקודם של המכולה.

RunContainerError

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

• ניסיון להעלות אמצעי אחסון לא קיים כגון ConfigMap או Secrets;
• ניסיון להעלות אמצעי אחסון לקריאה בלבד כקריאה-כתיבה.

הצוות מתאים היטב לניתוח טעויות כאלה kubectl describe pod <pod-name>.

התרמילים נמצאים במצב המתנה

לאחר היצירה, התרמיל נשאר במצב Pending.

למה זה קורה?

להלן הסיבות האפשריות (אני מניח שהמתזמן עובד בסדר):

1. לאשכול אין מספיק משאבים, כגון כוח עיבוד וזיכרון, כדי להפעיל את הפוד.
2. האובייקט מותקן במרחב השמות המתאים ResourceQuota ויצירת פוד תגרום למרחב השמות לחרוג מהמכסה.
3. הפוד חייב להמתנה PersistentVolumeClaim.

במקרה זה, מומלץ להשתמש בפקודה kubectl describe ותבדוק את הסעיף Events:

kubectl describe pod <pod name>

במקרה של שגיאות הקשורות ל ResourceQuotas, מומלץ להציג את יומני האשכול באמצעות הפקודה

kubectl get events --sort-by=.metadata.creationTimestamp

התרמילים אינם מוכנים

אם הפוד מופיע בתור Running, אבל הוא לא במצב Ready, פירושו בדיקת מוכנותו (בדיקת מוכנות) נכשל.

כאשר זה קורה, הפוד לא מתחבר לשירות ולא זורמת אליו תעבורה. כישלון בדיקת המוכנות נגרם מבעיות באפליקציה. במקרה זה, כדי למצוא את השגיאה, עליך לנתח את הסעיף Events בפלט הפקודה kubectl describe.

2. אבחון שירות

אם תרמילים מופיעים בתור Running и Ready, אך עדיין אין תגובה מהאפליקציה, עליך לבדוק את הגדרות השירות.

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

kubectl describe service <service-name> | grep Endpoints

נקודת קצה היא צמד ערכים של הטופס <IP-адрес:порт>, ולפחות זוג אחד כזה חייב להיות קיים בפלט (כלומר, לפחות פוד אחד עובד עם השירות).

אם סעיף Endpoins ריק, שתי אפשרויות אפשריות:

1. אין תרמילים עם התווית הנכונה (רמז: בדוק אם מרחב השמות נבחר כהלכה);
2. ישנה שגיאה בתוויות השירות בבורר.

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

איך בודקים את הפונקציונליות של השירות?

ללא קשר לסוג השירות, אתה יכול להשתמש בפקודה kubectl port-forward כדי להתחבר אליו:

kubectl port-forward service/<service-name> 3000:80

Здесь:

• <service-name> - שם השירות;
• 3000 הוא היציאה שאתה פותח במחשב;
• 80 - יציאה בצד השירות.

3. אבחון כניסה

אם קראת עד כאן, אז:

• תרמילים מופיעים בתור Running и Ready;
• השירות מפיץ בהצלחה תעבורה בין פודים.

עם זאת, אתה עדיין לא יכול להגיע לאפליקציה.

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

אבל לפני שתפנה להשתמש בכלים מיוחדים כדי להגדיר את Ingress, אתה יכול לעשות משהו מאוד פשוט. שימושים ב-Ingress serviceName и servicePort כדי להתחבר לשירות. אתה צריך לבדוק אם הם מוגדרים כהלכה. אתה יכול לעשות זאת באמצעות הפקודה:

kubectl describe ingress <ingress-name>

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

• הגדרות נגישות כניסה מהאינטרנט הציבורי;
• הגדרות נגישות לאשכול מהאינטרנט הציבורי.

אתה יכול לזהות בעיות בתשתית על ידי חיבור ישירות לפוד Ingress. כדי לעשות זאת, מצא תחילה את הפוד של Ingress Controller (ייתכן שהוא נמצא במרחב שמות אחר):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

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

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

לבסוף, התחבר לתרמיל:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

כעת כל הבקשות ליציאה 3000 במחשב יופנו ליציאה 80 של הפוד.

זה עובד עכשיו?

• אם כן, אז הבעיה היא בתשתית. יש צורך לברר כיצד בדיוק התנועה מנותבת לאשכול.
• אם לא, אז הבעיה היא בבקר Ingress.

אם אינך מצליח לגרום לבקר Ingress לעבוד, תצטרך לבצע ניפוי באגים.

ישנם סוגים רבים של בקרי Ingress. הפופולריים ביותר הם Nginx, HAProxy, Traefik וכו'. (למידע נוסף על פתרונות קיימים, ראה הסקירה שלנו - משוער. תרגום) עליך לעיין במדריך לפתרון בעיות בתיעוד הבקר הרלוונטי. בגלל ה Ingress Nginx הוא בקר ה-Ingress הפופולרי ביותר, כללנו כמה טיפים במאמר לפתרון בעיות הקשורות אליו.

איתור באגים בבקר Ingress Nginx

לפרויקט Ingress-nginx יש גורם רשמי תוסף עבור kubectl. קְבוּצָה kubectl ingress-nginx יכול לשמש עבור:

• ניתוח של יומנים, backends, אישורים וכו';
• קשרים ל-Ingress;
• לומד את התצורה הנוכחית.

שלוש הפקודות הבאות יעזרו לך בכך:

• kubectl ingress-nginx lint - צ'קים nginx.conf;
• kubectl ingress-nginx backend - חוקר את הקצה האחורי (בדומה ל kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - בודק את היומנים.

שים לב שבמקרים מסוימים ייתכן שיהיה עליך לציין את מרחב השמות הנכון עבור בקר Ingress באמצעות הדגל --namespace <name>.

תקציר

פתרון בעיות של Kubernetes יכול להיות מאתגר אם אינך יודע מאיפה להתחיל. תמיד כדאי לגשת לבעיה מלמטה למעלה: התחל עם תרמילים, ולאחר מכן המשך לשירות ול-Ingress. ניתן ליישם את טכניקות ניפוי הבאגים המתוארות במאמר זה על אובייקטים אחרים, כגון:

• משרות סרק ו-CronJobs;
• StatefulSets ו-DaemonSets.

אני מביע את תודתי גרגלי ריסקו, דניאל וייבל и צ'רלס קריסטיראג' להערות ותוספות חשובות.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «תוסף kubectl-debug לניפוי באגים בתרמילים של Kubernetes";
• «6 באגי מערכת משעשעים בתפעול של Kubernetes [והפתרון שלהם]";
• «כלים למפתחי אפליקציות הפועלות על Kubernetes";
• «6 סיפורים מעשיים מחיי היומיום שלנו ב-SRE ".

מקור: www.habr.com