יום שישי, 10 במאי 2019

368 Kubernetes and Dyploma at outbrain

פודקאסט מספר 368 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור בערב חג הפועלים את שחף ואת אלכס להמשך סדרת Outbrain ושיחה על Kubernetes (להלן k8s) ו - Dyploma (בהמשך).

הפרק בחסות Applied Materials, שהם (גם) ספונסרים של Reversim Summit 2019 (שוב רמז, כן. שריינו תאריכים ובואו בהמוניכם, יש אג’נדה).
  • אפלייד מטריאלס היא מובילה עולמית בתחום ייצור השבבים והיחידה העסקית הישראלית שלה, בפארק המדע ברחובות, עוסקת בבקרת תהליך הייצור. 
  • קבוצת התוכנה בישראל מונה כ – 350 מפתחים העוסקים במגוון רחב של תחומים (DSP , deep learning , עיבוד תמונה , UI/UX , Frontend & Backend ) ובמגוון רחב של שפות (python, Java, C++ ועוד). יחד הם מתמודדים מול אתגרים בחזית הטכנולוגיה, פתרון בעיות מורכבות וחשיבה מחוץ לקופסא. 
  • הסיפוק של להיות חלק ממוצר פיזי, המורכב כולו כאן ומשלב תוכנה וחומרה שלבסוף מגיע ליצרניות המעבדים המובילות בעולם, הוא עצום. רב הסיכויים שהנייד דרכו אתם מאזינים לנו עכשיו עבר במהלך ייצורו במכונות הייצור והבדיקה של אפלייד מטריאלס. 
  • באפלייד שמים דגש על עבודת צוות, אפשרויות להתפתחות אישית וצמיחה והכל תוך איזון בין קריירה לחיים אישיים. 

לפני הכל - 
  • אלכס - 5 וחצי שנים ב - Outbrain, מוביל את קבוצת ה  -Core Services: אחראים “מהרצפה שמחזיקה את השרתים” דרך Networking מערכות הפעלה, Provisioning ועד Deployment Pipeline - שזה שחף . . .
  • שחף - ראש צוות Delivery ב - Outbrain (חלק מהקבוצה של אלכס), אחראי על כל מה שקשור ב  -Build & Deploy, שילוב של DevOps ו - Backend.

לא מזמן (יותר משנה, אבל עבר מהר) היה פרק שהתרכז ב Networking עם k8s ב - Outbrain; הפעם אנחנו מתמקדים יותר ברגע שלפני - למה בכלל לשקול k8s? איך זה קרה?
  • בתור התחלה - זה לא קרה . . . במשך תקופה ארוכה היה רצון אבל כנראה שהיה חסר תמריץ מתאים; ככה חלפו משהו כמו שנתיים עם נסיונות שונים שלא צלחו.
  • בסופו של דבר הגיע שילוב תמריצים מספיק טוב, למספיק בעלי עניין - 
    • מחיר - ציפייה לחסכון משמעותי בעלויות שרתים
    • גמישות - ב - Outbrain רצים על Bare Metal, וה - Lead time של מכונות הוא ארוך. ככל שיהיה ניתן לקצר אותו כך גמישות התפעול תגדל, לפחות תיאורטית.
      • עבור מי שרץ על ענן - אין Lead Time, יש כפתור (“אני רוצה מכונה!”) וזהו (+ חשבונית. נחזור לזה).
      • כשהשרתים הם של החברה, צריך לספק כוח חישוב זמין (אתה הענן).
    • מכאן הגיע הצורך ב - Orchestration ו - (הנה זה בא) Containerization (כן, זו באמת מילה).
      • אתגר לאקדמיה - קופסונים? אורי מציע המכלה. תחשבו על זה שנייה.
    • בסוף הכל מתכנס ל - Velocity - רוצים שאנשים יוכלו לזוז יותר מהר, גם ב - Production וגם ב - Development.

אז הכוכבים התיישרו - ואיפה אנחנו היום?
  • מנהלים כיום שלושה Data Centers, כשכל אחד כמה מכיל מספר k8s clusters.
  • סדר גודל של כ - 1500 מכונות ב - Production (עם כמה Containers של כמה צוותים על כל מכונה)
  • מבחינת Distinct services - כ ~500 שרצים על ה - Clusters
  • מעבר לכך יש Clusters שמיועדים לבדיקות וכו’ - משהו כמו עשרה Clusters בסך הכל.

כל ה - Production workload רץ על k8s, או שיש גם מקומות אחרים (Batch cases, etc)?
  • ה - Databases עדיין לא רצים ב - k8s; כל ה - workload שהוא Stateless (למשל Java services) רצים בתוך Containers.
  • מה לגבי Batch processing - גם שם? עוד חזון למועד, אבל יש שאיפה גם בכיוון ה - State-full.
    • עבור החלק הזה יש מערכות workflow פנימיות שנכתבו ב - Outbrain; יש שימוש ב - Containers על מנת לבודד למשל ספריות של Hadoop (על מנת להיות Self-contained), אבל כיום לא בתוך k8s (אולי בעתיד).

ולחלק השני של הכותרת - מהי Dyploma?
  • מההתחלה - שחף הגיע ל - Outbrain לפני שנתיים וחצי, והתבקש לפתח מערכת Build & Deploy על k8s: “הנה סט הדרישות - בהצלחה”.
  • המטרה הייתה מערכת שיודעת לעשות Deployment על k8s, ליצור Object Orient service שלוקח את ה - Java client, לבנות עבורו את ה - flow וכו’.
    • בגדול - “זה השרת שלי, ככה קוראים לו וככה ניגשים אליו - אני רוצה Build & Deploy על k8s”. אפשר לציין גם את מספר ה - instances ,נתוני זכרון ו - CPU - וזהו בגדול. המפתח לא צריך להכיר k8s, רק את Dyploma, מה שאמור להאיץ מאוד את קצב העבודה.
    • בעצם - Dyploma היא Service שעוטף את k8s ומאפשר לעשות את כל ההגדרות (Routing וכו’).

התלבטות נפוצה בשימוש ב - k8s (רן שואל בשביל חבר) היא שימוש ישיר או בתיווך מעטפת - אפשר להגיד “הנה ה - Cluster, תעשה מה שאתה רוצה” (צור pods, שלח yml. וכו’), ואפשר גם לכתוב כלי (כמו Dyploma, אבל יש עוד כלים דומים בשוק שעוטפים את k8s). מה הביא לבחירה בכלי מעטפת? מהי הפרספקטיבה לאחר שנה ומשהו?
  • כדי להכיר את k8s צריך להיכנס לעולם שהוא לא בהכרח חלק מהיום-יום של כל מפתח. יש את ה Tech Savvy שרצים ללמוד כל דבר חדש ויש את אלה שפחות, ומחפשים את הכפתור של Build & Deploy שמאפשר ליצור את ה - Instances ולהמשיך הלאה - התרגלו לטוב.
    • גילוי נאות לגבי “התרגלו לטוב” - על המערכת הקודמת היה אחראי אחד בשם רן תבורי.

כשמתכננים API תמיד קיימת ההתלבטות של רמת החשיפה למפתח, כשבדיעבד לא כל ההחלטות מתגלות כנכונות - לפעמים דברים שנדמה היה שהגיוני להחביא יכולים היום (עם הסביבה העשירה של ספקי הענן השונים) לתת המון כוח למפתח שיודע להשתמש בהם, ולפעמים הפוך.
נניח שהתחלנו מאפס (בלי מצב נתון שהמפתחים כבר התרגלו אליו) - אילו החלטות נראות כיום כנכונות לאור הניסיון ב - Outbrain?
  • ההתחלה הייתה עם CLI, ותוך ניסיון למסך מידע שלא חיוני למפתח - והפידבק מרוב המשתמשים היה בסגנון “אחלה, תן לי להתמקד בקוד”.
  • עם הזמן התקדמנו ועוד Services עברו מה Bare metal ונוספו עוד משתמשים - וגילינו שיש Pipelines שנבנים (build) ב - Jenkins ועובדים מול ה - API של Dyploma. כמות הנפילות נמוכה יחסית והידע הנדרש לא רב מדי.
    • מבנה ה - Services ב - Outbrain (וה - Templates שמסתמכים עליהם) הוא מנגנון שחוזר על עצמו, ואין צורך בורסטיליות מאוד גבוהה - לא ממציאים את k8s מחדש וזה טוב מספיק עבור חלק גדול מאוד מה - use cases.
  • עם הזמן נוספו עוד use cases - משתמשים רוצים UI (רגילים . . . ואפשר לעשות יותר לעומת CLI ל - API).
    • בשלב הזה (לאחר שנה וחצי) כבר ראינו את הצורך בתמונה רחבה, של dashboard שמאפשר לראות כל ה  -Deployment, ניהול של כל ה - clusters ממקום אחד (Federation)
  • מדובר לא רק ב - Production אלא גם Staging ו - Testing (לא בהכרח חשוף למפתחים, רק למי שצריך).
  • לאחרונה התחלנו לעבוד על Cluster ב - GCP, ובגלל אופן העבודה של Dyploma מול k8s החיבור היה מאוד פשוט (צריך רק את ה - Key, בלי Plug-ins או Controllers וכו’)
  • מדובר בעצם על תהליך Setup היברידי - מפתח יכול לבחור ריצה על Bare metal או בענן, ועבורו זה פחות או יותר שקוף - לא בהכרח מודע האם הריצה היא על מכונה פיזית או בענן (שזה גם פיזית בסוף, אבל במקום אחר).
    • משהו שהיה חשוב לשמר בעבודה עם Dyploma, ולא להמציא משהו חדש.
    • המפתח ממשיך לדבר ב”שפה של Outbrain”, אבל על k8s.
    • ההפרדה ל Production/ Staging/ Test - אלו לא clusters שונים של k8s, אלא הפרדה לוגית שמתרחשת ברמת האפליקציה
      • האפליקציות מפרידות בין Production/ Staging/ Test באמצעות תיוג (tagging) שמוזרק כשמרימים אותן, ולא “יודעות” באיזה cluster הן רצות (אפשר לדעת, אבל לרוב זה לא מעניין - מעניין מהו ה Data Center).
  • התקשורת אינה מתרחשת באופן הקלאסי של k8s (חזרה לפרק על Networking) - מכיוון שמיישמים שכבה של Fabric מעל k8s ולא משתמשים ב Plug-ins, לכל Container יש IP משלו והוא מתקשר עם האחרים דרך תשתית התקשורת, בלי שום דבר באמצע.
    • מכאן נובע שכל מה שנמצא “בדרך” - אבסטרקציות כמו Services למינהם - לא נמצא בשימוש.
    • משתמשים ב - Consul לצורך Service Discovery, ורושמים כל Container שעולה (אין בחירה) - מעצם זה שהמפתח הגדיר deployment הוא נרשם עם כל ה - meta data שמוזרק ל - Consul.

קיימים גם clusters שכוללים Workloads מכמה מקורות (Production/ Staging/ Test) - עשוי להיווצר מצב של “גניבת משאבים” ביניהם?
  • כן - ובגלל זה יש יישום של Preemption (מגיע service גדול - מי זז?)
  • נותנים תעדוף ל - Deployment באמצעות Dyploma: ב - k8s תעדוף מוגדר ע”י מספר, והגדרנו שמות לתחומי עדיפות שונות (Bronze, Silver, Gold, Diamond), שחלקו מוגדר ע”י המפתח וחלקו מחושב בתוך Dyploma
    • לא רוצים ש Services עם instance בודד יתקעו בתור ויצרו Downtime, למשל.
    • מה שלא ב Production מקבל כמובן תעדוף יותר נמוך.

בחזרה ל - Work flow של המפתח - עד עכשיו התמקדנו בכך ש Dyploma מנהלת את ה- Clusters של k8s עבור המפתח (שלא נדרש להכיר k8s על בוריו). יש גם מעבר לכך - Dyploma מתחילה “להתערב” כבר משלב ה- Version Control וה - CI - 
    • ראשית, Dyploma מגדירה גם את ה - Permissions - על מנת לאפשר Log-in, המשתמש צריך להיות חלק מהארגון, וניתן להגדיר למשל איזה צוות אחראי על כל Service (רק מי ששייך לצוות יכול לנהל אותו).
    • שנית, ניתן לקבל היסטוריה על פעולות שמשתמשים עשו - לאיזו גירסא עשו Deploy ומתי, ואם משהו לא טוב - יש Revert
    • אפשרות ל - Logs - במקרה ש Containers נכשלו מיד בעלייה, כאשר יש הבחנה בין לוגים אפליקטיביים ללוגים תפעוליים (שהם “צרה של מישהו אחר”, נקרא לו “DevOps”).
    • העובדה ש Dyploma מאפשרת API מצומצם וברור יותר למפתח מאפשרת לו להעצים את היכולות של k8s ולבנות את אותם Pipelines שהזכרנו קודם.
    • בהמשך לשאלת ”מה היינו עושים אחרת?” - זה עבד כל כך טוב עד כדי מצב בו משתמשים התחילו לעשות עם המערכת דברים שלא צפינו (Deploy של Grafana? מאיפה זה הגיע? איך זה עלה בכלל?)
      • גילינו שיצרנו מערכת שאינה רק מערכת Deployment אלא “Gateway to Production” באופן כללי.
      • מאפשרים למפתח דבר במושגים של Production ו - Staging (“זו המערכת שלי”), ולבקש משאבים (“תן לי כמות instances של ה - Services הזה, ואני רוצה גם את הלוגים שלו”), ובאופן פשוט להגיע ל - Production, כשמה מה שיש מתחת זה כבר “בעיה של מישהו אחר” (ועל כן - בלתי נראית).
      • איפה זה פחות עבד? כל מי שרוצה מפורשות (Explicitly) לרוץ מעל k8s (כדי להרים Spark באופן מאוד ספציפי ולעבוד Pure k8s) - לזה אין מענה.
    • הצוות עצמו (שמפתח את Dyploma) כן רץ ישירות על k8s (מריצים elm files וכו’)?
      • גם לא . . . הכל עובר Deployment דרך Dyploma, חוץ מ - Dyploma עצמה שעוברת דרך Pipeline צדדי.
      • כרגע אין workloads נוספים על k8s, לא משתמשים ב controllers מיוחדים וכו’.
        • גילינו שרוב הדרישות שלנו מאוד פשוטות, ואם כבר הולכים למקומות יותר מורכבים אז יש לזה מחיר באינטגרציות (כשמגלים שאין מענה ב - Public hand charts).
        • ה  -Gateway שלם יחסית עבור רוב הצרכים נוכחיים, ולמה שלא כמעט שאין דרישה, לפחות בינתיים.

שירות למי שרוצה התחיל עם k8s - מה הייתם עושים אחרת? על אילו בורות הייתם מדלגים בדיעבד?
  • באופן כללי k8s זה ערימה של בורות . . . 
  • בתור התחלה - איך מריצים את k8s עצמו? 
    • הדבר הראשון שצריך לשים לב אליו הוא ה - etcd - הכל מחיל ונגמר שם, זה המקום שמחזיק את ה - state, וצריך לוודא שהכל מדופן, נעים וחם - ומגובה.
    • כבר נמחק לנו cluster שלם בהזדמנות - הכל עלה מחדש וזה היה מדהים לראות, עדיין לא מומלץ לנסות.
  • נושא אחר - High Availability - קשה ב - k8s בהגדרה (על מנת שתקנה ממישהו אחר?), אבל מאוד חשוב, כי חלקים יכשלו מתישהו וה - API Server צריך high availability.
    • אם מישהו אחר יכול לנהל את זה (GCP?) זו בהחלט אפשרות.
  • מבחינת Deployments בתוך המערכת - כדאי להתחיל ממשהו פשוט (בלי Auto-scaling וכו’), ולהבין היטב איך עובדים מנגנוני ה - Required וה - Limits, מתי ה - Pods יעלמו, מי נכנס ומתי . . . יש הרבה פינות.
    • ההבדל בין ה - Required וה - Limit נראה טריויאלי על פניו, עד שלומדים על Buffer Limit, שגם נספר כחלק מהזכרון שלך (ואם תכתוב הרבה לזכרון זה ימלא אותו וה - Pod יעוף . . .). 
  • הרבה דברים הגיוניים בהקשר של Linux, אבל כשמכניסים להקשר של k8s הם פתאום הופכים פחות אינטואיטיביים.
  • בעיקר - לקרוא את ה - Documentation.

דיברנו קודם על High availability, ועל זה שיש כמה Production Clusters של k8s באותו Data Center - למה? מהם השיקולים ליותר מ - Cluster אחד?
  • עבור Production יש אכן Cluster יחיד בכל Data Center
  • באופן כללי, אנחנו עובדים בצורה בה גם אם מאבדים Production cluster (ובמקרים קיצוניים אפילו שניים), המערכת עדיין מסוגלת לספוג את זה ולתפקד.
    • עקרון ה - High availability נשמר בין ה - Data Centers
  • הסיבה למספר Clusters היא בעיקר בדיקות וניסויים למיניהם, כאשר לפעמים Clusters שונים שייכים לצוותים שונים (לכל אחד יש את “הממלכה” הקטנה שלו).

בחזרה לחוויית המשתמש ומה נכון לחשוף ב - UI: יש לא מעט מערכות שמציעות פלטפורמות Serverless מעל k8s (למשל Knative או Kubeless, היה גם פרק עם ירון חביב בנושא) - האם גם אתם פוזלים לכיוון הזה?
  • כבר עכשיו אנחנו מאוד קרובים ל “Serverless” - מה שמפתח ב - Outbrain צריך היום על מנת להרים Service זה לכתוב את הקוד, כשהרבה דברים מגיעים ”בחינם” - ניטור, Metrics, Analytics וכו’ - וצריך רק את ה - Business Logic.
  • על מנת להגיע ל - Production צריך להיכנס ל - Dyploma, להגדיר את שם ה Service ומספר המופעים (Instances, שגם זה אמור להתחלף בגבול עליון / תחתון), האם מדובר ב - Production/Staging/other - וזהו.
  • המרחק בין זה לבין “כתבתי את הקוד והנה קסם  -זה רץ” הוא כבר לא גדול.
  • המפתח לא מכיר “מכונה” - הוא מכיר Service ו - Deployment. לא משנה מהי המכונה, מהו ה - IP וכו’. גם לא כמות משאבים הפנויים ב - Cluster.

ועדיין - המפתח צריך לדאוג ל - Auto-scaling וכו’, מה שלא קיים בעולמות ה - Serverless, או לפחות ספציפית ב - Lambda - אתה כותב את הפונקציה והיא כבר תרוץ כמה פעמים שצריך, וכל מה שצריך זה Commit ב - Git, בלי צורך לדאוג ל - Jenkins או Deployment או משהו. 
יש לזה יתרונות וחסרונות - האם זה משהו שחשבתם עליו?
    • כרגע לא - אנחנו לא Amazon או Google, ויש לנו כמות מוגבלת של משאבים, לא ברמה של “יעלה כמה שיעלה, אתה לא צריך לדאוג לזה”, כך שאנחנו לא מדברים כרגע על מערכת של Infinite Scalability.
    • יכול להיות שאפשר ליצור Threshold מאוד גבוה שיהיה דומה, אבל כרגע אין דרישה אמיתית.
      • אם תיהיה דרישה, אפשר לבנות משהו דומה, Knative ודומיו כבר עושים את זה. 
    • כשאומרים ש - “Dyploma מנהלת את k8s” הכוונה היא לניהול ה Meta-Data בכניסה, ולא על ניהול אקטיבי של פעולות עבור המפתח מאחורי הקלעים.
      • חשוב להבין שהארכיטקטורה היא אמנם microServices לקצה - אבל עדיין microServices. המשמעות היא של - Services יש מצב (state) והם “מדברים” אחד עם השני, ולא פועלים כפונקציה חד-פעמית.
      • אנחנו מכנים את זה “State-less” אבל יש Cache פנימי, כתיבה לקבצים לפעמים וכו’. יש State.
      • אחד מהדברים המעניינים ב - Offering של Lambda הוא היעדר האפשרות המובנית להחזיק State, מה שמאלץ פתרונות יצירתיים אחרים שמאפשרים Scale יותר “בריא”.
        • וגם לזה כמובן יש חסרונות . . .

נושאים נוספים?
  • הייצור של k8s מתבצע באמצעות Chef - משתמשים ב kubeadm, ו - Chef מנהל גם את היצירה של ה - Cluster.
  • ה - CI עובד על Vagrant - מייצרים Cluster, מוודאים שהכל נוצר באופן תקין. ככה גם בודקים פיצ’רים חדשים.
  • מבחינת ניהול ה - State, העבודה עם Chef מוודא ש - k8s ישאר במצב הרצוי.
  • אם מישהו לא משתמש ב - Dyploma, הוא צריך לנהל איכשהו באופן אחר את ה - Version control, קבצי yml. של ה- Deployments וכו’. Dyploma נותנת את זה כחלק מניהול ה - State.
  • זה מאפשר גם להוציא אנליטיקות בצורה יותר קלה - אילו Services צורכים יותר משאבים, איפה הקונפיגורציה פחות מתאימה וכו’.
  • אנחנו עובדים עם Consul לצורך Service Discovery - השתמשנו בפרויקט קוד פתוח בשם Registrator, שרץ על כל אחד מה - nodes ודואג לרשום את ה - Instances ל - Consul.
  • לצורך Metrics ו - Alerts - משתמשים ב Kube-state Metrics
    • מסתכלים על restarts של Deployments (נושא כאוב) - ברגע שה - Instance עובר Restarts חוזרים נשלח Alert לטיפול, וזה משהו שגם נחשף ב - UI של Dyploma.
  • חושפים Dashboards ב Grafana - כמה CPU וכמה זכרון נצרכים וכו’.
  • שיקולי עלויות - חושפים מצבים בהם יש יותר מדי או פחות מדי Resources
  • יש מחשבות על Quota לצוותים, על מנת לשקף את האילוץ למפתחים (אם אפשר לשפר זה יועיל לכולם).
  • לצורך העניין  -אני כמנהל מוצר יכול לראות “כמה הקוד שלי עולה”?
    • שאלה מצויינת . . עוד לא. עובדים עכשיו על מערכת בשם Usage Reports (שם זמני) שנותנת בדיוק את זה
    • אחת הבעיות הגדולות בענן היא שזה “ברזל של מישהו אחר” - לוחצים על כפתור ומופיעה עוד מכונה, והכסף נוזל בין האצבעות. להרים מכונה המפתח זוכר, לכבות זה כבר עניין של ה - DevOps . . . זה לא מרגיש כמו משהו שצריך לנהל עד שמגיעה החשבונית.
    • רואים את זה בצורה דומה עם k8s - למה לעבוד על אופטימיזציה אם אפשר להרים עוד מכונה? ה - Clusters הולכים וגדלים וכמות ה - Instances תופחת וזה מאוד “טבעי” כשאין את הנראות למחיר, רק לביצועים (מפתיע מפלטרפורמה שמגובה ע”י חברה שמרוויחה מהמודל הזה בדיוק, לא?).
    • עובדים עכשיו על מערכת שתראה את המחיר מול הביצועים ותאפשר את ה - trade-off - “הפרויקט מכניס X, האם זה שווה את זה?”
    • נותר רק לבחור את השם . . .
  • ועוד משהו - מחפשים אשת DevOps - בואו! מוזמנים לפנות גם ב LinkedIn או באתר.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

אין תגובות:

הוסף רשומת תגובה