"Kubernetes הגדילה את ההשהיה פי 10": מי אשם בכך?

הערה. תרגום: מאמר זה, שנכתב על ידי Galo Navarro, המכהן בתפקיד מהנדס תוכנה ראשי בחברת Adevinta האירופית, הוא "חקירה" מרתקת ומלמדת בתחום תפעול התשתיות. הכותרת המקורית שלו הורחבה מעט בתרגום מסיבה שהסופר מסביר כבר בהתחלה.

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

לפני שבועיים, הצוות שלי העביר מיקרו-שירות יחיד לפלטפורמת ליבה שכללה CI/CD, זמן ריצה מבוסס Kubernetes, מדדים ועוד דברים טובים. המהלך היה בעל אופי נסיוני: תכננו לקחת אותו כבסיס ולהעביר כ-150 שירותים נוספים בחודשים הקרובים. כולם אחראים לתפעול של כמה מהפלטפורמות המקוונות הגדולות בספרד (Infojobs, Fotocasa וכו').

לאחר שפרסנו את האפליקציה ל-Kubernetes והפנינו אליה קצת תנועה, חיכתה לנו הפתעה מדאיגה. לְעַכֵּב (חֶבִיוֹן) הבקשות ב-Kubernetes היו גבוהות פי 10 מאשר ב-EC2. באופן כללי, היה צורך למצוא פתרון לבעיה זו, או לנטוש את ההגירה של המיקרו-שירות (ואולי, את כל הפרויקט).

מדוע זמן ההשהיה גבוה בהרבה ב-Kubernetes מאשר ב-EC2?

כדי למצוא את צוואר הבקבוק, אספנו מדדים לאורך כל נתיב הבקשה. הארכיטקטורה שלנו פשוטה: שער API (Zuul) מעביר בקשות למופעי מיקרו-שירות ב-EC2 או Kubernetes. ב-Kubernetes אנו משתמשים בבקר NGINX Ingress, והקנדים האחוריים הם אובייקטים רגילים כמו פְּרִיסָה עם אפליקציית JVM בפלטפורמת Spring.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

נראה שהבעיה קשורה להשהיה הראשונית ב-backend (סימנתי את אזור הבעיה בגרף בתור "xx"). ב-EC2, תגובת האפליקציה ארכה כ-20 אלפיות השנייה. ב-Kubernetes, ההשהיה גדלה ל-100-200 אלפיות השנייה.

פטרנו במהירות את החשודים הסבירים הקשורים לשינוי בזמן הריצה. גרסת JVM נשארת זהה. גם בעיות קונטיינריזציה לא היו קשורות לזה: האפליקציה כבר רצה בהצלחה בקונטיינרים ב-EC2. טוען? אבל צפינו בהשהיות גבוהות אפילו בבקשה אחת לשנייה. אפשר גם להזניח הפסקות לאיסוף אשפה.

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

השערה 1: פתרון שם DNS

עבור כל בקשה, האפליקציה שלנו ניגשת למופע של AWS Elasticsearch פעם עד שלוש פעמים בדומיין כמו elastic.spain.adevinta.com. בתוך המכולות שלנו יש פגז, כדי שנוכל לבדוק אם החיפוש אחר דומיין אכן לוקח הרבה זמן.

שאילתות DNS ממיכל:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

בקשות דומות מאחד ממקרי EC2 שבהם האפליקציה פועלת:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

בהתחשב בכך שהחיפוש ארך כ-30 אלפיות השנייה, התברר שרזולוציית DNS בעת הגישה אל Elasticsearch אכן תרמה לעלייה בהשהיה.

עם זאת, זה היה מוזר משתי סיבות:

1. יש לנו כבר המון יישומי Kubernetes שמקיימים אינטראקציה עם משאבי AWS מבלי לסבול מהשהייה גבוהה. תהיה הסיבה אשר תהיה, היא מתייחסת ספציפית למקרה זה.
2. אנו יודעים שה-JVM מבצע אחסון DNS בזיכרון. בתמונות שלנו, ערך ה-TTL נכתב $JAVA_HOME/jre/lib/security/java.security והגדר ל-10 שניות: networkaddress.cache.ttl = 10. במילים אחרות, ה-JVM צריך לשמור את כל שאילתות ה-DNS למשך 10 שניות.

כדי לאשר את ההשערה הראשונה, החלטנו להפסיק להתקשר ל-DNS לזמן מה ולראות אם הבעיה נעלמה. ראשית, החלטנו להגדיר מחדש את האפליקציה כך שתתקשר ישירות עם Elasticsearch לפי כתובת IP, ולא דרך שם דומיין. זה ידרוש שינויי קוד ופריסה חדשה, אז פשוט מיפינו את הדומיין לכתובת ה-IP שלו ב /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

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

אבחון באמצעות רשת

החלטנו לנתח תנועה מהמכולה באמצעות tcpdumpכדי לראות מה בדיוק קורה ברשת:

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

לאחר מכן שלחנו מספר בקשות והורדנו את הלכידה שלהן (kubectl cp my-service:/capture.pcap capture.pcap) לניתוח נוסף ב Wireshark.

לא היה שום דבר חשוד בשאילתות ה-DNS (חוץ מדבר אחד קטן שעליו אדבר מאוחר יותר). אבל היו מוזרויות מסוימות באופן שבו השירות שלנו טיפל בכל בקשה. להלן צילום מסך של הלכידה המראה שהבקשה מתקבלת לפני תחילת התגובה:

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

הזרם הירוק שמתחיל בחבילה 328 מראה כיצד הלקוח (172.17.22.150) יצר חיבור TCP למיכל (172.17.36.147). לאחר לחיצת היד הראשונית (328-330), חבילה 331 הביאה HTTP GET /v1/.. - בקשה נכנסת לשירות שלנו. כל התהליך ארך 1 אלפית השנייה.

הזרם האפור (מתוך חבילה 339) מראה שהשירות שלנו שלח בקשת HTTP למופע Elasticsearch (אין לחיצת יד של TCP כי הוא משתמש בחיבור קיים). זה לקח 18 אלפיות השנייה.

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

עם זאת, הקטע הכחול לוקח 86 אלפיות השנייה. מה קורה בו? עם חבילה 333, השירות שלנו שלח בקשת HTTP GET אל /latest/meta-data/iam/security-credentials, ומיד אחריו, על אותו חיבור TCP, בקשת GET נוספת אל /latest/meta-data/iam/security-credentials/arn:...

מצאנו שזה חזר על עצמו בכל בקשה לאורך כל המעקב. רזולוציית ה-DNS אכן קצת יותר איטית בקונטיינרים שלנו (ההסבר לתופעה די מעניין, אבל אשמור אותו למאמר נפרד). התברר שהגורם לעיכובים הארוכים היה שיחות לשירות AWS Instance Metadata בכל בקשה.

השערה 2: קריאות מיותרות ל-AWS

שתי נקודות הקצה שייכות ל AWS Instance Metadata API. המיקרו-שירות שלנו משתמש בשירות זה בזמן הפעלת Elasticsearch. שתי השיחות הן חלק מתהליך ההרשאה הבסיסי. נקודת הקצה שניגשת אליה בבקשה הראשונה מנפיקה את תפקיד IAM המשויך למופע.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

הבקשה השנייה מבקשת מנקודת הקצה השנייה הרשאות זמניות עבור מופע זה:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

הלקוח יכול להשתמש בהם לפרק זמן קצר ועליו לקבל מעת לעת תעודות חדשות (לפני כן Expiration). המודל פשוט: AWS מסובב מפתחות זמניים לעתים קרובות מטעמי אבטחה, אך לקוחות יכולים לשמור אותם במטמון למשך מספר דקות כדי לפצות על עונש הביצועים הקשור בהשגת אישורים חדשים.

AWS Java SDK אמור לקחת על עצמו את האחריות לארגון התהליך הזה, אבל מסיבה כלשהי זה לא קורה.

לאחר חיפוש בעיות ב-GitHub, נתקלנו בבעיה #1921. היא עזרה לנו לקבוע את הכיוון שאליו "לחפור" הלאה.

AWS SDK מעדכן אישורים כאשר מתרחש אחד מהתנאים הבאים:

• תאריך תפוגה (Expiration) ליפול לתוך EXPIRATION_THRESHOLD, מקודד עד 15 דקות.
• יותר זמן עבר מאז הניסיון האחרון לחדש תעודות מאשר REFRESH_THRESHOLD, מקודד קשה למשך 60 דקות.

כדי לראות את תאריך התפוגה בפועל של האישורים שאנו מקבלים, הרצנו את פקודות ה-cURL שלעיל הן מהמכולה והן מהמופע של EC2. תקופת התוקף של התעודה שהתקבלה מהמכולה התבררה כקצרה בהרבה: 15 דקות בדיוק.

כעת הכל התברר: לבקשה הראשונה השירות שלנו קיבל תעודות זמניות. מכיוון שהם לא היו תקפים ליותר מ-15 דקות, ה-AWS SDK יחליט לעדכן אותם בבקשה שלאחר מכן. וזה קרה עם כל בקשה.

מדוע תקופת התוקף של התעודות התקצרה?

Metadata של מופע AWS תוכנן לעבוד עם מופעי EC2, לא עם Kubernetes. מצד שני, לא רצינו לשנות את ממשק האפליקציה. בשביל זה השתמשנו קיאם - כלי שבאמצעות סוכנים בכל צומת Kubernetes, מאפשר למשתמשים (מהנדסים הפורסים יישומים לאשכול) להקצות תפקידי IAM לקונטיינרים ב-pods כאילו היו מופעי EC2. KIAM מיירט שיחות לשירות Metadata של מופע AWS ומעבד אותן מהמטמון שלו, לאחר שקיבל אותן בעבר מ-AWS. מנקודת המבט של היישום, שום דבר לא משתנה.

KIAM מספקת תעודות לטווח קצר לתרמילים. זה הגיוני בהתחשב בכך שאורך החיים הממוצע של תרמיל קצר יותר מזה של מופע EC2. תקופת תוקף ברירת מחדל לאישורים שווה לאותן 15 דקות.

כתוצאה מכך, אם אתה מכסה את שני ערכי ברירת המחדל זה על גבי זה, מתעוררת בעיה. כל אישור שניתן לבקשה יפוג לאחר 15 דקות. עם זאת, AWS Java SDK מאלץ חידוש של כל אישור שנותרו לו פחות מ-15 דקות לפני תאריך התפוגה שלו.

כתוצאה מכך, האישור הזמני נאלץ להתחדש עם כל בקשה, דבר הכרוך בכמה שיחות ל-API של AWS וגורם לעלייה משמעותית בהשהיה. ב-AWS Java SDK מצאנו בקשת תכונה, אשר מזכיר בעיה דומה.

הפתרון התברר כפשוט. פשוט הגדרנו מחדש את KIAM לבקש אישורים עם תקופת תוקף ארוכה יותר. ברגע שזה קרה, החלו לזרום בקשות ללא השתתפות של שירות Metadata של AWS, והשהייה ירדה לרמות נמוכות עוד יותר מאשר ב-EC2.

ממצאים

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

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

במקרה שלנו, האחזור הגבוה לא היה תוצאה של באגים או החלטות שגויות ב-Kubernetes, KIAM, AWS Java SDK או המיקרו-שירות שלנו. זה היה תוצאה של שילוב של שתי הגדרות ברירת מחדל עצמאיות: אחת ב-KIAM, השנייה ב-AWS Java SDK. בהתחשב בנפרד, שני הפרמטרים הגיוניים: מדיניות חידוש האישורים הפעילה ב-AWS Java SDK, ותקופת התוקף הקצרה של האישורים ב-KAIM. אבל כאשר אתה מחבר אותם יחד, התוצאות הופכות בלתי צפויות. שני פתרונות עצמאיים והגיוניים אינם חייבים להיות הגיוניים בשילובם.

נ.ב מהמתרגם

תוכל ללמוד עוד על הארכיטקטורה של כלי השירות KIAM לשילוב AWS IAM עם Kubernetes בכתובת מאמר זה מיוצריו.

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

• «3 סיפורים על כישלונות של Kubernetes בייצור: אנטי זיקה, כיבוי חינני, webhook";
• «כיצד סדרי עדיפויות של תרמילים ב-Kubernetes גרמו להשבתה במעבדות Grafana";
• «6 באגי מערכת משעשעים בתפעול של Kubernetes [והפתרון שלהם]";
• «6 סיפורים מעשיים מחיי היומיום שלנו ב-SRE".

מקור: www.habr.com