Amazon EKS Windows ב-GA יש באגים, אבל הוא המהיר ביותר

צהריים טובים, אני רוצה לחלוק איתכם את הניסיון שלי בהגדרה והשימוש בשירות AWS EKS (Elastic Kubernetes Service) עבור קונטיינרים של Windows, או ליתר דיוק על חוסר האפשרות להשתמש בו, ועל הבאג שנמצא בקונטיינר של מערכת AWS, עבור אלה המעוניינים בשירות זה עבור מיכלי Windows, אנא תחת cat.

אני יודע שמיכלי Windows הם לא נושא פופולרי, ומעט אנשים משתמשים בהם, אבל בכל זאת החלטתי לכתוב את המאמר הזה, מכיוון שהיו כמה מאמרים על Habré על kubernetes ו-Windows ועדיין יש אנשים כאלה.

החל

הכל התחיל כשהוחלט להעביר את השירותים בחברה שלנו ל-kubernetes, שהם 70% ווינדוס ו-30% לינוקס. לצורך כך, שירות הענן AWS EKS נחשב כאחת האפשרויות האפשריות. עד ה-8 באוקטובר 2019, AWS EKS Windows היה ב-Public Preview, התחלתי איתו, נעשה שימוש בגרסת 1.11 הישנה של kubernetes, אבל החלטתי לבדוק את זה בכל זאת ולראות באיזה שלב היה שירות הענן הזה, האם הוא עובד בכלל, כפי שהתברר, לא, זה היה באג עם תוספת של הסרת פודים, בעוד הישנים הפסיקו להגיב דרך ip פנימי מאותה רשת משנה כמו צומת העובד של Windows.

לכן, הוחלט לנטוש את השימוש ב-AWS EKS לטובת אשכול משלנו על kubernetes באותו EC2, רק שנצטרך לתאר את כל האיזון וה-HA בעצמנו דרך CloudFormation.

תמיכת אמזון EKS Windows Container זמינה כעת באופן כללי

מאת מרטין ביבי | ב-08 באוקטובר 2019

לפני שהספקתי להוסיף תבנית ל-CloudFormation עבור האשכול שלי, ראיתי את החדשות האלה תמיכת אמזון EKS Windows Container זמינה כעת באופן כללי

כמובן, שמתי את כל העבודה שלי בצד והתחלתי ללמוד מה הם עשו עבור GA, ואיך הכל השתנה עם Public Preview. כן, AWS, כל הכבוד, עדכנה את התמונות עבור Windows worker node לגרסה 1.14, כמו גם האשכול עצמו, גרסה 1.14 ב-EKS, תומך כעת בצמתי Windows. פרויקט מאת Public Preview ב github הם כיסו את זה ואמרו עכשיו השתמש בתיעוד הרשמי כאן: תמיכה של EKS Windows

שילוב של אשכול EKS ב-VPC וברשתות המשנה הנוכחיות

בכל המקורות, בקישור שלמעלה בהודעה כמו גם בתיעוד, הוצע לפרוס את האשכול או דרך כלי השירות הקנייני eksctl או דרך CloudFormation + kubectl לאחר, רק באמצעות רשתות משנה ציבוריות באמזון, כמו גם יצירת VPC נפרד לאשכול חדש.

אפשרות זו אינה מתאימה לרבים; ראשית, VPC נפרד פירושו עלויות נוספות עבור העלות שלו + תעבורת הצצה ל-VPC הנוכחי שלך. מה צריך לעשות למי שכבר יש לו תשתית מוכנה ב-AWS עם מספר חשבונות AWS משלהם, VPC, רשתות משנה, טבלאות מסלולים, שער מעבר וכדומה? כמובן, אתה לא רוצה לשבור או לעשות מחדש את כל זה, ואתה צריך לשלב את אשכול ה-EKS החדש בתשתית הרשת הנוכחית, באמצעות ה-VPC הקיים, ולצורך הפרדה, לכל היותר ליצור רשתות משנה חדשות עבור האשכול.

במקרה שלי, הנתיב הזה נבחר, השתמשתי ב-VPC הקיים, הוספתי רק 2 תת-רשתות ציבוריות ו-2 תת-רשתות פרטיות לאשכול החדש, כמובן, כל הכללים נלקחו בחשבון לפי התיעוד צור VPC של Cluster EKS של Amazon.

היה גם תנאי אחד: אין צמתי עובדים ברשתות משנה ציבוריות המשתמשות ב-EIP.

eksctl לעומת CloudFormation

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

אני אראה דוגמה רק באמצעות eksctl מכיוון שהקוד כאן יהיה קצר יותר. באמצעות eksctl, פרוס את האשכול ב-3 שלבים:

1. אנו יוצרים את האשכול עצמו + צומת העבודה של Linux, שיארח מאוחר יותר קונטיינרים של מערכת ואת אותו בקר vpc אכזרי.

eksctl create cluster 
--name yyy 
--region www 
--version 1.14 
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx 
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx 
--asg-access 
--nodegroup-name linux-workers 
--node-type t3.small 
--node-volume-size 20 
--ssh-public-key wwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami auto 
--node-private-networking

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

כדי להבטיח שצמתי העבודה שלך ייפרסו רק לרשת משנה פרטית, עליך לציין --node-private-networking עבור קבוצת צומתים.

2. אנו מתקינים את vpc-controller באשכול שלנו, אשר לאחר מכן יעבד את צמתי העובדים שלנו, סופר את מספר כתובות ה-IP הפנויות, כמו גם את מספר ה-ENIs במופע, מוסיף ומסיר אותם.

eksctl utils install-vpc-controllers --name yyy --approve

3. לאחר שהמכולות של המערכת שלך הושקו בהצלחה בצומת העבודה של Linux שלך, כולל vpc-controller, כל שנותר הוא ליצור קבוצת צומת נוספת עם עובדי Windows.

eksctl create nodegroup 
--region www 
--cluster yyy 
--version 1.14 
--name windows-workers 
--node-type t3.small 
--ssh-public-key wwwwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami-family WindowsServer2019CoreContainer 
--node-ami ami-0573336fc96252d05 
--node-private-networking

לאחר שהצומת שלך התחבר בהצלחה לאשכול שלך ונראה שהכל בסדר, הוא במצב Ready, אבל לא.

שגיאה ב-vpc-controller

אם ננסה להפעיל פודים על צומת עבודה של Windows, נקבל את השגיאה:

NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]

אם נסתכל לעומק, נראה שהמופע שלנו ב-AWS נראה כך:

וזה צריך להיות ככה:

מכאן ברור שה-vpc-controller לא מילא את חלקו משום מה ולא הצליח להוסיף כתובות IP חדשות למופע כדי שהפודים יוכלו להשתמש בהן.

בואו נסתכל על היומנים של ה-vpc-controller pod וזה מה שאנחנו רואים:

יומן kubectl -n kube-system

I1011 06:32:03.910140       1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162       1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238       1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423       1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock  pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211       1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229       1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302       1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313       1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.

חיפושים בגוגל לא הובילו לכלום, מכיוון שככל הנראה אף אחד עדיין לא תפס באג כזה, או לא פרסם בו בעיה, הייתי צריך לחשוב על אפשרויות בעצמי קודם. הדבר הראשון שעלה בראש הוא שאולי ה-vpc-controller לא יכול לפתור את ip-10-xxx.ap-xxx.compute.internal ולהגיע אליו ולכן מתרחשות שגיאות.

כן, אכן, אנו משתמשים בשרתי DNS מותאמים אישית ב-VPC ובאופן עקרוני, איננו משתמשים בשרתי אמזון, כך שאפילו העברה לא הוגדרה עבור תחום ap-xxx.compute.internal זה. בדקתי את האפשרות הזו, והיא לא הביאה תוצאות, אולי הבדיקה לא הייתה נקייה, ולכן, בהמשך, כשתקשרתי עם תמיכה טכנית, נכנעתי לרעיון שלהם.

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

יתרה מכך, אם אתה פורס צומת עובד לרשת משנה ציבורית מבלי להשתמש ב-node-private-networking, הצומת הזה עודכן מיד על ידי ה-vpc-controller והכל עבד כמו שעון.

היו שתי אפשרויות:

1. תוותר על זה וחכה עד שמישהו יתאר את הבאג הזה ב-AWS והוא יתקן את זה, ואז אתה יכול להשתמש בבטחה ב-AWS EKS Windows, מכיוון שהם שוחררו זה עתה ב-GA (חלפו 8 ימים בזמן כתיבת מאמר זה), רבים כנראה יעשו זאת ללכת באותה דרך כמוני.
2. כתבו לתמיכה של AWS וספרו להם את מהות הבעיה עם חבורה שלמה של יומנים מכל מקום ותוכיחו להם שהשירות שלהם לא עובד כשמשתמשים ב-VPC וברשתות המשנה שלכם, לא בכדי הייתה לנו תמיכה עסקית, כדאי להשתמש זה לפחות פעם אחת :)

תקשורת עם מהנדסי AWS

לאחר שיצרתי כרטיס בפורטל, בחרתי בטעות להגיב לי דרך Web - מייל או מרכז תמיכה, דרך אפשרות זו הם יכולים לענות לך לאחר מספר ימים בכלל, למרות שהכרטיס שלי היה בעל חומרה - מערכת לקויה, אשר התכוון לתגובה תוך <12 שעות, ומכיוון שלתוכנית התמיכה העסקית יש תמיכה 24/7, קיוויתי לטוב, אבל זה יצא כמו תמיד.

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

ביצענו איתו באגים באינטרנט במשך 3 שעות ברציפות, העברנו יומנים, פרסו את אותו אשכול במעבדת ה-AWS כדי לחקות את הבעיה, יצרנו מחדש את האשכול מצידי וכו', הדבר היחיד שהגענו אליו הוא שמ ביומנים היה ברור שה-resol לא עובד עם שמות דומיינים פנימיים של AWS, עליהם כתבתי למעלה, והרשאד מדהב ביקש ממני ליצור העברה, לכאורה אנו משתמשים ב-DNS מותאם אישית וזו עלולה להיות בעיה.

שילוח

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

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

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

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

סופי

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

מתי הגענו לנקודה של הפעלת -stderrthreshold=debug ב-vpc-controller שלהם, ומה קרה אחר כך? כמובן שזה לא עובד) הפוד פשוט לא מתחיל עם האפשרות הזו, רק -stderrthreshold=info עובד.

סיימנו כאן וארון ב' אמר שהוא ינסה לשחזר את הצעדים שלי כדי לקבל את אותה שגיאה. למחרת אני מקבל תשובה מארון ב' הוא לא זנח את התיק הזה, אלא לקח את קוד הביקורת של ה-vpc-controller שלהם ומצא את המקום שבו הוא נמצא ולמה זה לא עובד:

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

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

אני מקווה שארון בי באמת ידווח על הבאג הזה למפתחי EKS ונראה גרסה חדשה של vpc-controller שבה הכל יעבוד מהקופסה. כרגע הגרסה העדכנית ביותר היא: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
יש את הבעיה הזו.

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

מקור: www.habr.com