תגית: K8S

לקצר דרכים – ולסבול מאוחר יותר

כיועצת עצמאית, יוצא לי במקרים רבים לתת יעוץ לגבי תשתיות קיימות בענן או On Prem או במעבר מתשתיות מקומיות לעננים ציבוריים. לשמחתי אני יכולה לאמר ממה שראיתי – זה שחברות רבות נוהגות בתבונה ולא מעבירות בצורה מיידית את כל התשתיות שלהן מ-On Prem לענן אלא בצורה מדורגת, וגם אז – רק מה שצריך.

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

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

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

אחד הנזקים, לדוגמא, קשור לשדרוג. אם מישהו הקים מערכת Kubernetes והוא ינסה לשדרג אותה – סביר להניח שהוא יתקל במספר שגיאות, שאם הוא לא מבין בתחזוקה והקמת הפלטפורמה, יכולים פשוט להשבית לו את המערכת, וכנ"ל לגבי הרצה של כל מיני קונטיינרים חיצוניים תוך שימוש בקבצי YAML שאיש מהחברה לא עבר עליהם: צריך לזכור שקוברנטיס לא שואל יותר מדי שאלות לפני הטמעה של קבצים כאלו (kubectl apply -f something.yaml).

ולכן, ההמלצה שלי לכל איש IT – כשזה מגיע ללינוקס, כשזה מגיע לקוברנטיס או כל פלטפורמה אחרת – אם צריך להקים מערכת פרודקשן/טסטים/פיתוח, לא מומלץ להשתמש בסקריפטים האוטומטיים או קיצורי דרך אחרים להקים את הדברים (שוב, למעט POC) – אלא להשקיע וללמוד איך עובדת הקמת הפלטפורמה, התלויות והתשתיות הנצרכות. נכון, זה לוקח יותר זמן ואין תמיד חשק ללמוד כל פיפס, אך לימוד הזה זו השקעה שמחזירה את עצמה כשיש תקלה, או מאוחר יותר אם מחפשים מקום עבודה אחר – ובראיון (ובקורות החיים) ניתן לציין שאתם מכירים הכרות די עמוקה את פלטפורמה X או Y. זיכרו: הדבר האחרון שאתם רוצים זה מערכת שהקמתם במהירות, כולם בנו ובונים עליה ולפתע היא קורסת ואין איש שמכיר אותה. כולם יצפו ממך לפתור זאת ובמהירות.

חג שמח.

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

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

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

השוואה: PKS מול OpenShift

יצא לי לשוחח עם לא מעט חברות שרוצות להשתמש בקונטיינרים. רבים כבר התחילו ממזמן להשתמש ב-Docker (הערה: לא הגיע הזמן להכיר ולהשתמש ב-cri-o?) והם החלו להשתמש ב-Docker-compose להרמת מספר קונטיינרים במכה אחת. חלקם מתחילים להשתמש בשרותים המנוהלים לקונטיינרים בעננים הציבוריים וחלקם רוצים פתרון On Prem ומטבע הדברים הם מתחילים לקרוא על Kubernetes וכשהם מתחילים להבין כמה הוא מורכב לתפעול (ומגירסה לגירסה זה נהיה יותר ויותר מורכב) – הם מבקשים המלצות על פתרון קל יותר להקים ולנהל אשכול Kubernetes (ובקיצור בשמו החביב: K8S).

רוב מוחלט של החברות הבינוניות והגדולות משתמשות ב-VMWare (מי שמשתמש ב-Hyper-V וירצה פתרון קל להתקנה וניהול ל-K8S – בהצלחה עם זה) ומטבע הדברים הם מעדיפים משהו מחברה גדולה וידועה כמו VMWare, ששמחה מאוד למכור להם את PKS. המוצר עצמו נמכר בשתי תמחורים שונים – פר POD (כאשר POD הוא מעין "קבוצה" כאשר כל POD מכיל קונטיינר אחד או יותר, ברוב המקרים יריצו קונטיינר עם אפליקציה ועוד קונטיינרים שמכילים אפליקציות נסמכות תחת POD אחד ואז יש גם תקשורת בין הקונטיינרים בקבוצה) או פר ליבות. זה מתחיל ב-50 PODS או ליבות. (המלצה: לא לרכוש פר POD. בכל ליבה אפשר להריץ עשרות PODs).

המתחרה העיקרי והיותר גדול ומיועד ל-Enterprise להרצת Kubernetes היא מערכת Openshift. גם היא תומכת באופן טבעי ומלא ב-VMWare (כן, כולל תמיכה ב-NSX-T), רק שבניגוד ל-PKS, היא לא מיועדת רק להקמה וניהול של Kubernetes במובן הסיסטמטי, אלא היא יותר מיועד לכל השרשרת – מרמת ההנהלה, אנשי אבטחת מידע, ומפתחים. ב-PKS אם אני רוצה להקים אפליקציה, אני צריך להשתמש ב-Cloud Foundry (או דרך ה-cli ב-kubectl), צריך במקרים רבים לכתוב קבצי YAML (ימח שמו וזכרו עם כל הקטע של רווחים!) שמצריכים ידע מספק ב-K8S. עם Openshift – יש לך Template (שתמיד אפשר לכתוב נוספים) והמתכנת עושה הכל דרך ה-Web UI. יש קטלוג מובנה שמאפשר להתחבר לאינטרנט ולהוריד אוטומטית templates נוספים והקמה של אפליקציות נוספות בכמה קליקים, יש אבטחת מידע הרבה יותר רצינית מ-PKS (בגלל זה רוב הקונטיינרים הזמינים לציבור לא ירוצו על Openshift אלא אם משנים הגדרת אבטחה שבחברה עלולים לפטר אותך אם תשנה אותה), יש גרפים וניטור מובנה, קל מאוד לשייך בין אפליקציה לשרות (נניח אפליקציית JAVA לקונטיינר אחר שמריץ MySQL – משתמשים ב-BIND בתפריט ותוך שניות ספורות המערכת תבנה את הכל) ויש עוד תוספות רבות שכלל לא קיימות ב-PKS. בקיצור, מי שיקים מערכת Openshift (קראו בהמשך על כך למי שמעוניין להתנסות אישית במחיר יקר של 0 שקלים) ויקים מערכת PKS, יראה את ההבדלים מהר מאוד. אגב, אחת האפשרויות שכיום אין ב-PKS ומאוד חשובה כשרוצים להוסיף ולהוריד מכונות וירטואליות המריצות קונטיינרים – כלל לא קיימת ב-PKS, אך קיימת בגירסת Openshift האחרונה.

וכאן אני מגיע להמלצה לא פופולרית שאני ממליץ: אל תרכשו PKS.

לא, זה לא קשור למחיר. מי שישווה בין Openshift ל-PKS יראה כי המחיר של Openshift ל-On Premise יותר יקר מ-PKS (בחלק מהמקרים, תלוי בחישובי ליבות, כמויות וכו')

הבעיה קשורה יותר ל-VMWare ולזמן הנוכחי. VMWare מציעה את PKS (גרסאות Essential, Enterprise) אבל אותה חברה גם מציעה את Tanzu Kubernetes Grid. היא מדברת על ניהול אשכולות של Kubernetes עם Tanzu Mission Control – אל תחפשו לרכוש או להוריד, זה מוצר של חברת Heptio (ש-VMWare רכשה) שעושים בו שינויים והוא כרגע בבטא ללקוחות VMware ולא זמין להורדה. יש גם את עניין ה-Health אשכול ה-K8S שלך והחלק הזה ממוצר וקוד מחברות ש-VMWare רכשה: Wavefront ו-CloudHealth.

בקיצור, VMWare מכינה איזה משהו גדול שמשולב מקוד ממקורות שונים שאמור לתת לך מענה מבחינת הקמת וניהול אשכולות K8S שונים הן מקומית והן בענן, אבל עד שזה יהיה מוכן ויציב – יקח זמן. כ-Enterprise, היציבות מאוד חשובה והדבר האחרון שאתם רוצים לעשות זה לעבור למשהו אחר השנה או שנה הבאה ולך תדע כמה זה תואם אחורה והאם המיגרציה תעבוד חלק…

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

לאלו שכן רוצים לנסות את Openshift על הדסקטופ שלהם (לא על ESXI או פתרון וירטואליזציה מרכזי, כל עוד יש לך 32 ג'יגהבייט זכרון, הגירסה המצומצמת שניתנת להורדה תופסת 16 ג'יגהבייט זכרון, לגמרי), מוזמנים לגלוש לקישור הבא. תצטרכו להירשם ל-רד-האט כדי להוריד "קוד סודי" ולהדביק אותו בזמן ההתקנה. האפליקציה נקראת Code Ready Containers והיא יכולה לרוץ על לינוקס, מק ו-Windows. המערכת משתמשת בוירטואליזציה במחשב המקומי כך שב-Windows היא תפעיל את אופציית Hyper-V. טיפ קטן: אם אתם מחוברים ל-Active Directory, תתחברו למכונה שלכם עם שם משתמש מקומי. באג ידוע.

לסיכום: VMWare, כמו בשוק הוירטואליזציה, רוצה מטבע הדברים "לקחת שליטה" על השוק ולפיכך היא מפזרת כספים על ימין ועל שמאל לרכוש חברות שונות שמציעות מוצרים עם חלקים שיכול לעזור לכלי העתידי שלה כדי להקים ולנהל אשכולות K8S באופן מקומי ובענן. המוצר שהם מוכרים כרגע (PKS), כפי שאני רואה זאת, הוא לא יותר מאשר לתפוס אחוזי שוק והמוצר ה"אמיתי" הגדול שיצא – יצא בעתיד, שנה הבאה אולי, ולכן אני לא יכול להמליץ על PKS כפתרון קבוע לחברות שרוצות להקים ולנהל אשכולות K8S, ולפיכך אני ממליץ להסתכל על פתרונות אלטרנטיביים, שתיהם נותנים תמיכה ושרות מסחריים, וכדאי לבדוק מה מהם מתאים לכם.