עשרה טיפים שחייבים ליישם בקוברנטיס

מאת עידו ופנר ואיגור קושצ'יץ

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

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

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

הגבילו את משאבי האפליקציות – כדי לדאוג לאמינות וזמינות של משאבי האפליקציה, מומלץ להגדיר Requests ו-Limits  ברמת כל Pod המיועד לרוץ בקלאסטר. אחד הסיכונים המשמעותיים בתשתיות המבוססות על עקרון שיתוף חומרה הוא "שכנים רועשים", הגדרה נכונה של צריכת משאבים והגדרה של Quotes ברמת Namespaces תקטין משמעותית את הסיכון.

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

השתמשו בבדיקות עצמיות (Liveness and Readiness) – ל קוברנטיס יש יכולת להגדיר בדיקה עצמית לקונטיינרים הרצים, המבוססת על בקשת HTTP, TCP או פקודה, במטרה לבדוק האם הקונטיינר מוכן לשרת בקשות והאם הוא תקין בכל שלב של הריצה. יש חשיבות רבה להגדיר את הבדיקות Liveness and Readiness, על מנת לאפשר Scale תקין ולמנוע כישלונות בדרך לקונטיינר שעדיין לא עלה או לא תקין.

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

הגדירו תהליך פיתוח מקצה לקצה (GitOps) – השתמשו בכלי אוטומציה, המאפשרים פריסה הצהרתית (Declarative) באמצעות GIT. המשמעות היא שמירה של המצב האמיתי במקום אחד שהוא ב-Git, כך תתאפשר פריסה יעילה ובטוחה של אפליקציות לסביבה בשיטה שמוכרת לצוותי הפיתוח, שתמזער את מידת ההתערבות של צוותי ה- DevOps ותחסוך עלויות.

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

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

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

הקשיחו את התשתית והאפליקציות – נוכל להגדיר Admission controls כדי לסנן את כל קריאות API המתרחשות לפני יצירה של אובייקט ולבדוק שהאובייקט תקין בהתאם לרשימה של ה-Controls המוגדרים. יש לפתח Controls מותאמים לארגון, כולל דרישות האבטחה וה-Compliance ולאפשר את הקשחת מידות האבטחה הנדרשות.

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

עידו ופנר, סמנכ"ל טכנולוגיות בקינדריל; איגור קושצ'יץ, ארכיטקט ענן בכיר בארניקס.