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

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

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

בנוסף, רוב התמונות ב-Docker משתמשות בדביאן או באובונטו עבור תמונת הבסיס, ולמרות שזה מספק תאימות מצוינת והתאמה אישית קלה (קובץ Docker לוקח רק שתי שורות קוד), תמונות בסיס יכולות להוסיף מאות מגה-בייט של עומס נוסף למכולה שלך. לדוגמה, קובץ node.js פשוט עבור יישום Go "hello-world" הוא בערך 700 מגה-בייט, בעוד שהאפליקציה שלך בפועל היא בגודל של כמה מגה-בייט בלבד.

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

הראשון הוא השימוש בתמונות בסיס קטנות, השני הוא השימוש ב-Builder Pattern. שימוש בתמונות בסיס קטנות יותר הוא כנראה הדרך הקלה ביותר להקטין את גודל המיכל שלך. סביר להניח שהשפה או הערימה שבה אתה משתמש מספקת תמונת אפליקציה מקורית שהיא קטנה בהרבה מתמונת ברירת המחדל. בואו נסתכל על מיכל node.js שלנו.

כברירת מחדל ב-Docker, גודל התמונה הבסיסי של node:8 הוא 670 מגה-בייט, והצומת: גודל תמונה 8-אלפיני הוא רק 65 מגה-בייט, כלומר קטן פי 10. על ידי שימוש בתמונת הבסיס האלפיני הקטנה יותר, תקטין משמעותית את גודל המיכל שלך. Alpine היא הפצת לינוקס קטנה וקלת משקל שפופולרית מאוד בקרב משתמשי Docker מכיוון שהיא תואמת ליישומים רבים תוך שמירה על מיכלים קטנים. בניגוד לתמונת ה"צומת" הרגילה של Docker, "node:alpine" מסיר הרבה קבצי שירות ותוכניות, ומשאיר רק את אלה שמספיקים להפעלת האפליקציה שלך.

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

כעת, בניגוד לתמונת ה-onbuild הישנה, ​​עליך להעתיק את הקוד שלך לקונטיינר ולהתקין את כל התלות. ב-Dockerfile חדש, הקונטיינר מתחיל בתמונת node:alpine, ואז יוצר ספרייה עבור הקוד, מתקין תלות באמצעות מנהל החבילות של NPM, ולבסוף מריץ את server.js.

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

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

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

ב-Dockerfile החדש, הקונטיינר מתחיל בתמונת golang:alpine. לאחר מכן הוא יוצר ספרייה עבור הקוד, מעתיק אותו לקוד המקור, בונה את קוד המקור הזה ומפעיל את היישום. קונטיינר זה קטן בהרבה ממיכל ה-onbuild, אבל הוא עדיין מכיל את המהדר וכלי Go אחרים שאנחנו לא באמת צריכים. אז בואו פשוט נחלץ את התוכנית הקומפילית ונכניס אותה למיכל משלה.

ייתכן שתבחין במשהו מוזר בקובץ ה-Docker הזה: הוא מכיל שתי שורות FROM. החלק הראשון של 4 השורות נראה בדיוק אותו הדבר כמו ה-Dockerfile הקודם אלא שהוא משתמש במילת המפתח AS כדי לתת שם לשלב הזה. בחלק הבא יש שורת FROM חדשה כדי להתחיל תמונה חדשה, שבה במקום תמונת golang:alpine נשתמש ב- Raw alpine כתמונת הבסיס.

ל-Raw Alpine Linux לא מותקנות תעודות SSL, מה שיגרום לרוב קריאות ה-API דרך HTTPS להיכשל, אז בואו נתקין כמה אישורי CA שורש.

עכשיו מגיע החלק המהנה: כדי להעתיק את הקוד הקומפילציה מהמיכל הראשון לשני, אתה יכול פשוט להשתמש בפקודה COPY הממוקמת בשורה 5 של החלק השני. זה יעתיק רק קובץ יישום אחד ולא ישפיע על כלי השירות Go. הקובץ הרב-שלבי החדש של Docker יכיל תמונת קונטיינר בגודל של 12 מגה-בייט בלבד, לעומת תמונת הקונטיינר המקורית שהייתה 700 מגה-בייט, וזה הבדל גדול!
אז שימוש בתמונות בסיס קטנות ובתבנית Builder הן דרכים נהדרות ליצור קונטיינרים קטנים בהרבה בלי הרבה עבודה.
יתכן שבהתאם לערימת האפליקציה, ישנן דרכים נוספות להקטין את גודל התמונה והמיכל, אך האם למכולות קטנות באמת יש יתרון מדיד? בואו נסתכל על שני תחומים שבהם מיכלים קטנים הם יעילים ביותר – ביצועים ואבטחה.

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

Docker ישמור את השכבות במטמון כך שהבנייה הבאה תהיה מהירה מאוד. עם זאת, מערכות CI רבות המשמשות לבנייה ולבדיקת קונטיינרים אינן מאחסנות שכבות במטמון, כך שיש חיסכון משמעותי בזמן. כפי שאתה יכול לראות, הזמן לבניית מיכל גדול, בהתאם לעוצמת המכונה שלך, הוא בין 34 ל-54 שניות, ובשימוש במיכל מופחת באמצעות תבנית ה-Builder - מ-23 ל-28 שניות. בפעולות מסוג זה העלייה בפריון תהיה 40-50%. אז רק תחשוב כמה פעמים אתה בונה ובודק את הקוד שלך.

לאחר בניית הקונטיינר, עליך לדחוף את התמונה שלו (תמונת מיכל) לתוך רישום המכולה כדי שתוכל להשתמש בה באשכול Kubernetes שלך. אני ממליץ להשתמש ב-Google Container Registry.

עם Google Container Registry (GCR), אתה משלם רק עבור אחסון גולמי ורשת, ואין עמלות נוספות לניהול קונטיינר. זה פרטי, מאובטח ומהיר מאוד. GCR משתמש בטריקים רבים כדי להאיץ את פעולת המשיכה. כפי שניתן לראות, הכנסת מיכל Docker Container Image באמצעות go:onbuild תיקח בין 15 ל-48 שניות, תלוי בביצועי המחשב, ואותה פעולה עם מיכל קטן יותר תיקח בין 14 ל-16 שניות, ולמכונות פחות פרודוקטיביות היתרון במהירות הפעולה גדל פי 3. עבור מכונות גדולות יותר, הזמן בערך זהה, מכיוון ש-GCR משתמש במטמון גלובלי עבור מסד נתונים משותף של תמונות, כלומר אינך צריך לטעון אותן כלל. במחשב בעל הספק נמוך, ה-CPU הוא צוואר הבקבוק, כך שהיתרון בשימוש במיכלים קטנים הוא הרבה יותר גדול כאן.

אם אתה משתמש ב-GCR, אני ממליץ בחום להשתמש ב-Google Container Builder (GCB) כחלק ממערכת הבנייה שלך.

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

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

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

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

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

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

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

שיטות עבודה מומלצות של 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