שיטות עבודה מומלצות של Kubernetes. אימות חיים של Kubernetes עם מבחני מוכנות וחיוניות

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

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

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

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

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

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

מבחן Liveness אומר ל-Kubernetes אם האפליקציה שלך חיה או מתה. במקרה הראשון, Kubernetes תשאיר אותו לבד, במקרה השני הוא ימחק את הפוד המת ויחליף אותו בחדש.

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

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

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

הבה נבחן כיצד נבדקות המוכנות והכדאיות. ישנן שלוש שיטות בדיקה - HTTP, Command ו-TCP. אתה יכול להשתמש בכל אחד מהם כדי לבדוק. הדרך הנפוצה ביותר לבדוק משתמש היא בדיקת HTTP.

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

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

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

ניתן להגדיר בדיקות בכמה דרכים עם פרמטרים שונים. אתה יכול לציין באיזו תדירות יש לבצע אותם, מהם ספי ההצלחה והכישלון וכמה זמן לחכות לתגובות. למידע נוסף, עיין בתיעוד למבחני המוכנות והחיות. עם זאת, יש נקודה אחת חשובה מאוד בהגדרת מבחן Liveness - ההגדרה הראשונית של ה-testing delay initialDelaySeconds. כפי שציינתי, כישלון בבדיקה זו יביא להפעלה מחדש של המודול. אז אתה צריך לוודא שהבדיקה לא תתחיל עד שהאפליקציה תהיה מוכנה להפעלה, אחרת היא תתחיל לעבור את ההפעלה מחדש. אני ממליץ להשתמש בזמן ההפעלה של P99 או בזמן ההפעלה הממוצע של היישום מהמאגר. זכור להתאים ערך זה מכיוון שזמן האתחול של האפליקציה שלך נעשה מהיר יותר או איטי יותר.

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

המשך בקרוב מאוד...

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com