דרישות לפיתוח אפליקציה ב-Kubernetes

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

הרצאה זו היא חלק מ"Slurm Night School ב- Kubernetes" ניתן לצפות בהרצאות התיאורטיות הפתוחות של בית הספר הערב ב-YouTube, מקובצים לפלייליסט. למי שמעדיף טקסט ולא וידאו, הכנו מאמר זה.

שמי פאבל סליוונוב, כרגע אני מהנדס DevOps המוביל ב-Mail.ru Cloud Solutions, אנחנו מייצרים עננים, אנחנו מייצרים kubernetes לניהול וכן הלאה. המשימות שלי כוללות כעת סיוע בפיתוח, הפעלת העננים הללו, הפעלת האפליקציות שאנו כותבים ופיתוח ישיר של הכלים שאנו מספקים למשתמשים שלנו.

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

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

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

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

כי, בגדול, המידע הזה הוא "ctrl+c, ctrl+v", בין היתר מהוויקי שלנו במדור DevOps, שם יש לנו דרישות כתובות למפתחים: "חבר'ה, כדי שנשיק את האפליקציה שלכם ב- Kubernetes, זה זה צריך להיות ככה."

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

מה אנחנו הולכים להסתכל עליו עכשיו:

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

יומנים

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

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

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

מסתבר שאם אנחנו מדברים על Kubernetes, המקום הנכון לכתוב לוגים איפשהו ממיכל docker הוא פשוט לכתוב אותם מהאפליקציה למה שנקרא Stdout/Stderr, כלומר, זרמי הפלט הסטנדרטיים של מערכת ההפעלה, פלט השגיאה הסטנדרטי. זו הדרך הנכונה, הפשוטה וההגיונית ביותר לשים יומנים עקרונית ב-Docker ובמיוחד ב-Kubernetis. כי אם האפליקציה שלך כותבת יומנים ל-Stdout/Stderr, אז זה תלוי ב-Docker ובתוסף Kubernetes להחליט מה לעשות עם היומנים האלה. Docker כברירת מחדל יבנה את הקבצים המיוחדים שלו בפורמט JSON.

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

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

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

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

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

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

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

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

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

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

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

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

תְצוּרָה

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

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

והדבר הזה - השתמשנו בו בעבר, הוא פשוט הפך פופולרי במיוחד עם הופעת הקונטיינרים - הדבר הזה נקרא משתני ENV (סביבה), כלומר משתני סביבה שנמצאים במערכת ההפעלה שלך. זו בדרך כלל דרך אידיאלית להגדיר את האפליקציה שלך, כי אם יש לך יישומים ב-JAVA, Python, Go, Perl, חלילה, וכולם יכולים לקרוא את מארח מסד הנתונים, משתמש מסד הנתונים, משתני סיסמת מסד הנתונים, אז זה אידיאלי. יש לך יישומים בארבע שפות שונות המוגדרות בתוכנית מסד הנתונים באותו אופן. אין יותר הגדרות שונות.

הכל יכול להיות מוגדר באמצעות משתני ENV. כשאנחנו מדברים על Kubernetes, יש דרך מצוינת להכריז על משתני ENV ממש בתוך הפריסה. בהתאם לכך, אם אנחנו מדברים על נתונים סודיים, אז נוכל מיד לדחוף נתונים סודיים ממשתני ENV (סיסמאות לבסיסי נתונים וכו') לתוך סוד, ליצור אשכול סודי ולציין בתיאור ENV ב-Deployment שאנחנו לא מצהירים ישירות הערך של משתנה זה, והערך של משתנה סיסמת מסד נתונים זה ייקרא מהסוד. זוהי התנהגות סטנדרטית של Kubernetes. וזו האפשרות האידיאלית ביותר להגדיר את היישומים שלך. רק ברמת הקוד, שוב זה חל על מפתחים. אם אתם DevOps, אתם יכולים לשאול: "חבר'ה, אנא למדו את האפליקציה שלכם לקרוא משתני סביבה. וכולנו נהיה מאושרים".

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

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

השאלה היחידה היא שתצורות הן לא מה שאתה חושב. Config.pi אינו תצורה שנוחה לשימוש. או תצורה כלשהי בפורמט שלך, לחילופין מחונן - זו גם לא התצורה שאני מתכוון.

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

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

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

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

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

בדיקת בריאות

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

כאשר ניגשים לכתובת האתר הזו, בהתאם, האפליקציה שלנו אומרת "כן, בסדר, הכל בסדר איתי, 200" או "לא, הכל לא בסדר איתי, איזה 500." בהתאם לכך, אם האפליקציה שלנו היא לא http, לא אפליקציית אינטרנט, אנחנו מדברים עכשיו על סוג של דמון, אנחנו יכולים להבין איך לעשות בדיקות בריאות. כלומר, אין צורך, אם האפליקציה אינה http, אז הכל עובד ללא בדיקת תקינות ואי אפשר לעשות זאת בשום אופן. אתה יכול מדי פעם לעדכן מידע מסוים בקובץ, אתה יכול להמציא איזו פקודה מיוחדת עבור הדמון שלך, כמו, daemon status, שיאמר "כן, הכל בסדר, הדמון עובד, הוא חי."

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

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

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

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

והנה נקודה חשובה שברצוני להזכיר: מבחינה מעשית, מבחן המוכנות משמש בדרך כלל לעתים קרובות יותר ויש צורך יותר מבדיקת החיות. כלומר, פשוט להצהיר ללא מחשבה גם על בדיקות מוכנות וגם מבחני חיוניות, כי Kubernetes יכול לעשות את זה, ובואו נשתמש בכל מה שהוא יכול לעשות, זה לא רעיון טוב במיוחד. אני אסביר למה. כי נקודה מספר שתיים בבדיקה היא שזה יהיה רעיון טוב לבדוק את השירות הבסיסי בבדיקות הבריאות שלך. זה אומר שאם יש לך אפליקציית אינטרנט שמספקת מידע מסוים, שבתורו, כמובן, הוא חייב לקחת מאיפשהו. במסד נתונים, למשל. ובכן, זה שומר את המידע שנכנס לתוך REST API זה באותו מסד נתונים. ואז, בהתאם, אם בדיקת הבריאות שלך מגיבה בפשטות כמו slashhealth שפנו אליו, האפליקציה אומרת "200, בסדר, הכל בסדר", ובאותו הזמן מסד הנתונים של האפליקציה שלך אינו נגיש, ואפליקציית Healthcheck אומרת "200, בסדר, הכל בסדר " - זו בדיקת בריאות גרועה. לא כך זה אמור לעבוד.

כלומר, הבקשה שלך, כשמגיעה אליה בקשה /health, הוא לא רק מגיב "200, בסדר", הוא קודם, למשל, למסד הנתונים, מנסה להתחבר אליו, עושה שם משהו מאוד בסיסי, כמו לבחור אחד, רק בודק שיש חיבור ב- מסד הנתונים ואתה יכול לשאול את מסד הנתונים. אם כל זה הצליח, אז התשובה היא "200, בסדר." אם זה לא מצליח, זה אומר שיש שגיאה, מסד הנתונים אינו זמין.

לכן, בהקשר זה, אני חוזר שוב למבחני מוכנות/חיות - מדוע סביר להניח שצריך בדיקת מוכנות, אך מדובר בבדיקת חיוניות. כי אם תתאר בדיקות בריאות בדיוק כמו שאמרתי זה עתה, אז יתברר שזה לא זמין בחלק המופעв или со всех instanceבמסד נתונים, למשל. כשהצהרת על בדיקת מוכנות, בדיקות הבריאות שלנו החלו להיכשל, ובהתאם כל האפליקציות שמהן לא נגיש בסיס הנתונים, הן פשוט מנותקות מאיזון ולמעשה "נתלות" רק במצב מוזנח ומחכות לבסיסי הנתונים שלהן עֲבוֹדָה.

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

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

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

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

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

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

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

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

אם הכל הלך כשורה, אז הגיבו בתשובה המאתיים. באופן עקרוני, כל תשובה מאתיים תתאים לך. אם אתה קורא סמרטוטי טוב מאוד ויודע שסטטוסים מסוימים של תגובות שונים מאחרים, ענו עם המתאימים: 204, 5, 10, 15, מה שלא יהיה. אם זה לא מאוד טוב, אז פשוט "שניים אפס אפס." אם הכל מסתדר ובדיקת הבריאות לא מגיבה, אז תענה בכל חמש מאיות. שוב, אם אתה מבין איך להגיב, במה נבדלים סטטוסי תגובה שונים זה מזה. אם אתה לא מבין, אז 502 היא האפשרות שלך להגיב לבדיקות בריאות אם משהו משתבש.

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

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

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

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

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

כיבוי חינני

באופן כללי, מהי כיבוי חינני ומדוע הוא נחוץ? זה בערך כאשר היישום שלך קורס מסיבה כלשהי, אתה צריך לעשות app stop - או שאתה מקבל, למשל, אות ממערכת ההפעלה, היישום שלך חייב להבין אותו ולעשות משהו בנידון. התרחיש הגרוע ביותר, כמובן, הוא כאשר האפליקציה שלך מקבלת SIGTERM והיא כמו "SIGTERM, בוא נחזיק מעמד, נעבוד, לא נעשה כלום." זו אופציה גרועה לחלוטין.

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

איזו אפשרות טובה? הנקודה הראשונה היא לקחת בחשבון את השלמת הפעולות. אפשרות טובה היא שהשרת שלך עדיין ייקח בחשבון מה הוא עושה אם הוא מקבל SIGTERM.

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

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

שם נוכל לומר ספציפית כמה זמן עלינו לחכות בין הזמן שאנו שולחים את SIGTERM לאפליקציה ועד שנבין שנראה שהאפליקציה השתגעה ממשהו או "תקועה" ואינה עומדת להסתיים - ואנחנו צריכים שלח לו SIGKILL, כלומר, קשה להשלים את עבודתו. כלומר, בהתאם, יש לנו איזה דמון שרץ, הוא מעבד פעולות. אנו מבינים שבממוצע הפעולות שלנו שהדמון עובד עליהן לא נמשכות יותר מ-30 שניות בכל פעם. בהתאם לכך, כאשר SIGTERM מגיע, אנו מבינים שהדמון שלנו יכול, לכל היותר, לסיים 30 שניות לאחר SIGTERM. אנחנו כותבים את זה, למשל, 45 שניות ליתר בטחון ואומרים ש-SIGTERM. לאחר מכן נחכה 45 שניות. בתיאוריה, במהלך הזמן הזה השד היה צריך להשלים את עבודתו ולסיים את עצמו. אבל אם פתאום זה לא היה יכול, זה אומר שסביר להניח שהוא תקוע - זה כבר לא מעבד את הבקשות שלנו כרגיל. ותוך 45 שניות אתה יכול בבטחה, למעשה, לתקוע אותו.

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

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

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

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

Ресурсы

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

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

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

מגבלה מציבה גבול עליון על האופן שבו ניתן להשתמש במשאב ביישום שלך. כלומר, בהתאם, אם אתה אומר 1GB RAM במגבלות, אז האפליקציה שלך לא תוכל להשתמש ביותר מ-1GB של RAM. ואם הוא פתאום ירצה וינסה לעשות זאת, אז תהליך שנקרא oom killer, מחוץ לזיכרון, כלומר, יבוא ויהרוג את האפליקציה שלך - כלומר, היא פשוט תתחיל מחדש. אפליקציות לא יופעלו מחדש על סמך מעבד. מבחינת CPU, אם אפליקציה מנסה להשתמש בהרבה, יותר מהמצוין במגבלות, המעבד פשוט ייבחר בקפדנות. זה לא מוביל להפעלה מחדש. זה הגבול - זה הגבול העליון.

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

למה צריך בקשות ולמה בלי בקשות, אני חושב שאין צורך להשיק שום דבר ב- Kubernetes? בואו נדמיין מצב היפותטי. אתה משיק את האפליקציה שלך ללא בקשות, Kubernetes לא יודע כמה ממה יש לך, לאילו צמתים אתה יכול לדחוף אותו. ובכן, הוא דוחף, דוחף, דוחף אל הצמתים. בשלב מסוים, תתחיל לקבל תנועה לאפליקציה שלך. ואחת האפליקציות פתאום מתחילה להשתמש במשאבים עד לגבולות שיש לה לפי המגבלות. מסתבר שיש עוד אפליקציה בקרבת מקום וגם היא זקוקה למשאבים. הצומת למעשה מתחיל להיגמר פיזית מהמשאבים, למשל, OP. הצומת למעשה מתחיל להיגמר פיזית מהמשאבים, למשל, זיכרון גישה אקראית (RAM). כשנגמר החשמל לצומת, קודם כל ה-docker יפסיק להגיב, אחר כך ה-cubelet, ואז מערכת ההפעלה. הם פשוט ייעלמו מחוסר הכרה והכל בהחלט יפסיק לעבוד בשבילך. כלומר, זה יוביל לכך שהצומת שלך יתקע ותצטרך להפעיל אותו מחדש. בקיצור, המצב לא ממש טוב.

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

אחסון נתונים

הנקודה הבאה שלנו היא על אחסון נתונים. מה לעשות איתם ובכלל, מה לעשות עם התמדה ב- Kubernetes?

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

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

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

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

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

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

יהיה לנו קורס על Ceph, אתה יכול הכירו את התכנית והגישו בקשה.

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

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

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

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

אילו בעיות יש למיניו? הבעיה העיקרית עם Minio היא שכדי שהדבר הזה יעבוד, הוא צריך לפעול איפשהו, וחייבת להיות איזושהי מערכת קבצים, כלומר אחסון. וכאן אנו נתקלים באותן בעיות שיש ל-Ceph. כלומר, מיניו חייבת לאחסן את הקבצים שלה איפשהו. זה פשוט ממשק HTTP לקבצים שלך. יתרה מכך, הפונקציונליות בבירור גרועה מזו של ה-S3 של אמזון. בעבר, זה לא היה מסוגל לאשר את המשתמש כראוי. עכשיו, למיטב ידיעתי, הוא כבר יכול ליצור דליים עם הרשאות שונות, אבל שוב, נראה לי שהבעיה העיקרית היא, כביכול, מערכת האחסון הבסיסית לכל הפחות.

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

עננות

ותת הנושא האחרון הוא מה זה Cloudnative. למה זה נחוץ? עננות וכדומה.

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

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

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

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

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

אבל מניסיוני, שוב, זה הדבר הכי מגניב שראיתי אי פעם. כאשר קנה המידה של אשכול Cloudnative מבוסס על השעה ביום. זה היה שירות אחורי ששימש אנשים במשרד האחורי. כלומר, הם מגיעים לעבודה ב-9 בבוקר, מתחילים להיכנס למערכת, ובהתאם, אשכול ה-Cloudnative, שבו הכל פועל, מתחיל לתפוח, משיק פודים חדשים כך שכל מי שמגיע לעבודה יוכל לעבוד עם האפליקציה. כשהם עוזבים את העבודה ב-8:6 או ב-30:XNUMX, אשכולות Kubernetes מבחינים שאף אחד כבר לא משתמש באפליקציה ומתחילים להתכווץ. מובטח חסכון של עד XNUMX אחוז. זה עבד באמזון באותה תקופה; באותה תקופה לא היה אף אחד ברוסיה שיכול לעשות את זה כל כך טוב.

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

יש נקודה אחרונה שגם אליה אני רוצה להסב את תשומת לבך. כדי שהאפליקציה שלך, התשתית שלך תהיה Cloudnative, הגיוני להתחיל סוף סוף להתאים את הגישה שנקראת Infrastructure as a Code. כלומר, זה אומר שהאפליקציה שלך, או יותר נכון התשתית שלך, נחוצה בדיוק באותו אופן כמו האפליקציה שלך. קוד תאר את היישום שלך, ההיגיון העסקי שלך בצורה של קוד. ותעבוד עם זה כקוד, כלומר, בדוק אותו, גלגל אותו, אחסן אותו ב-git, החל עליו CICD.

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

כל הנושאים הללו נדונים ביתר פירוט ב קורסי וידאו של Kubernetes: Junior, Basic, Mega. בלחיצה על הקישור תוכלו להכיר את התכנית והתנאים. הדבר הנוח הוא שאתה יכול לשלוט ב- Kubernetes על ידי לימוד מהבית או העבודה במשך 1-2 שעות ביום.

מקור: www.habr.com