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

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

קוברנטיס הוא הסטנדרט בפועל לניהול יישומי קונטיינרים (צילום: Unsplash)

מאת סורין בויאנגיו, מהנדס פתרונות ב-F5

מעטים ישכחו את משבר הקורונה; הסגירה הפתאומית של בתי ספר, עסקים ושירותים ציבוריים הותירה אותנו מבודדים מהקהילות שלנו ובמצב של חוסר ודאות לגבי הביטחון והיציבות הכלכלית. עכשיו דמיינו שהמגפה הייתה מתרחשת בשנת 2000, או אפילו בשנת 2010. ההבדל העיקרי היה הטכנולוגיה: ללא השירותים הדיגיטליים שאנחנו לוקחים כמובנים מאליהם – שירותי בריאות, סטרימינג וכלים לשיתוף פעולה מרחוק – המגיפה הייתה חוויה שונה מאוד ומורכבת אפילו יותר.

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

לפני שנת 2020 גילינו שרוב לקוחותינו כבר החלו לאמץ מיקרו-שירותים כחלק מאסטרטגיית הטרנספורמציה הדיגיטלית שלהם, אך המגיפה האיצה את המודרניזציה של היישומים. סקר שערכנו בקרב משתמשי NGINX בשנת 2020 מצא כי 60% מהנשאלים משתמשים במיקרו-שירותים בייצור, לעומת 40% בשנת 2019. בנוסף, הקונטיינרים פופולריים יותר מפי שתיים לעומת טכנולוגיות יישומים מודרניות אחרות (מכונות וירטואליות, לדוגמה).

המחסום ושברו

קוברנטיס הוא הסטנדרט בפועל לניהול יישומי קונטיינרים, כפי שמראה סקר ה-Cloud Native Computing Foundation (CNCF) משנת 2020, שמצא כי 91% מהנשאלים משתמשים בקוברנטיס, מתוכם 83% בייצור. כאשר הם מאמצים את קוברנטיס, ארגונים רבים מוכנים לשינויי ארכיטקטורה מהותיים, אך הם מופתעים מההשפעות הארגוניות של הפעלת טכנולוגיות יישומים מודרניות בקנה מידה גדול.

אם אתם מריצים קוברנטיס, סביר להניח שנתקלתם בכל שלושת המחסומים המרכזיים:

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

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

ה-CNCF Cloud Native Interactive Landscape הוא המחשה טובה למורכבות התשתית הדרושה לתמיכה ביישומים מבוססי מיקרו-שירותים. ארגונים צריכים להיות בקיאים במגוון רחב של טכנולוגיות, עם השלכות הכוללות נעילת תשתית, Shadow IT, התפשטות כלים ועקומת למידה תלולה לאלה שמוטלת עליהם אחזקת התשתית.

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

הפתרון: קוברנטיס ברמת הייצור

כמו רוב הבעיות הארגוניות, התשובה לאתגרים של קוברנטיס היא שילוב של טכנולוגיה ותהליכים. מכיוון שקוברנטיס היא טכנולוגיית קוד פתוח ישנן דרכים רבות ליישם אותה. בעוד שחלק מהארגונים מעדיפים להשתמש בקוברנטיס הוונילה שלהם, רבים מוצאים ערך בשילוב של גמישות, הנחיות ותמיכה הניתנים על ידי שירותים כגון Google Kubernetes Engine,יAmazon Elastic Kubernetes Service ו-Red Hat OpenShift Container Platform.

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

כדי ליישם קוברנטיס בדרגת ייצור יש להוסיף שלושה רכיבים נוספים, בסדר הזה:

1. נדבך כניסה ויציאה מדרגי (ingress-egress tier) המסייע להניע תעבורה אל תוך הקלאסטר. הדבר נעשה באמצעות Ingress controller – מאזן עומסים המצמצם את המורכבות של רשת קוברנטיס ומגשר בין שירותים בקלאסטר קוברנטיס לבין אלה שמחוצה לו. רכיב זה נכנס לדרגת ייצור כאשר הוא כולל תכונות המגבירות את החוסן (למשל בדיקות תקינות מתקדמות ומדדי Prometheus), המאפשרות יכולת גידול מהירה (רה-קונפיגורציה דינמית) ותומכות בשירות עצמי (בקרת גישה מבוססת תפקידים).

2. אבטחה מובנית להגנה מפני איומים ברחבי הקלאסטר. בעוד שאבטחה “גסה” (coarse-grained) עשויה להספיק מחוץ לקלאסטר, אבטחה “עדינה” (fine-grained) נדרשת בתוכו. בהתאם למורכבות הקלאסטר, ישנם שלושה מיקומים שבהם ייתכן שתצטרכו לפרוס web application firewall (WAF): בבקר Ingress, כ-proxy לשירות וכ-proxy לכל פוד. גמישות זו מאפשרת להחיל בקרות מחמירות יותר על יישומים רגישים, כגון יישומי חיוב, ולרופף בקרות כאשר הסיכון נמוך יותר.

3. נדבך מדרגי לתעבורת מזרח-מערב כדי לייעל את התעבורה בתוך הקלאסטר. יש צורך ברכיב שלישי זה לאחר שיישומי הקוברנטיס שלכם גדלו מעבר לרמת המורכבות וקנה המידה שהכלים הבסיסיים יכולים להתמודד איתם. בשלב זה אתם זקוקים ל-service mesh, כלי תזמור המספק ניהול תעבורה ואבטחה עדינים עוד יותר לשירותי יישומים בתוך הקלאסטר. ה-service mesh אחראי בדרך כלל לניהול ניתוב יישומים בין יישומי קונטיינרים, ומספק ואוכף מדיניות TLS (mTLS) אוטונומית של שירות לשירות, תוך מתן נראות לזמינות ואבטחת היישומים.

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

הכתבה בחסות F5

F5 (NASDAQ: FFIV) הינה חברה לאבטחת יישומים והעברתם בסביבות רב-ענניות, המאפשרת ללקוחות, הכוללים את הארגונים הגדולים בעולם, מוסדות פיננסיים, ספקי שירותים וממשלות – לספק חוויות דיגיטליות יוצאות מהכלל. בשנתיים האחרונות, חברת F5 רכשה את החברות NGINX ו-Shape Security ו-Volterra, ושילבה אותם באופן אורגני עם פתרונותיה. מרכז הפיתוח הישראלי של F5, הממוקם בתל אביב, מעסיק כ-300 עובדים. המרכז אחראי על פיתוח פתרונות אבטחת המידע של החברה. פתרונות החברה הוטמעו בקרב הארגונים הגדולים בישראל.

כתב אורח

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

הגב

4 תגובות על "קוברנטיס ברמת הייצור: איך עושים את זה נכון ומה צריך לדעת"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
Jow
Guest

רמת הייצור?!?! As in production -level?!?!

עד מתי
Guest

“נדבך מדרגי לתעבורת מזרח-מערב כדי לייעל את התעבורה בתוך הקלאסטר.”

לכו כבר עד הסוף, תשתמשו במילה “אשכול” במקום קלאסטר.

מביך..

קלקל
Guest

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

Eran
Guest

בכיינים… אחלה כתבה, תודה רבה

סוף סוף כתבה טכנית לעניין ולא “הסטרטאפ הישראלי ש…. מגייס עוד סבב שמעניין לכולנו את ה###”

wpDiscuz

תגיות לכתבה: