Artwork

Вміст надано רברס עם פלטפורמה. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією רברס עם פלטפורמה або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.
Player FM - додаток Podcast
Переходьте в офлайн за допомогою програми Player FM !

490 K8s with Erez from Komodor

 
Поширити
 

Manage episode 463452336 series 2497397
Вміст надано רברס עם פלטפורמה. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією רברס עם פלטפורמה або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.
פרק מספר 490 (מי היה מאמין) של רברס עם פלטפורמה, שהוקלט ב-21 בינואר 2025. אורי ורן מארחים בהפסקת אש את ארז רבין חחברת Komodor לשיחה על Kubernetes, ולמעשה - כדי לספר את סיפור חייו של Kubernetes: קצת על ההיסטוריה של Kubernetes - מאיפה הוא בא? למה בכלל הוא נולד? מה עושים איתו היום וקצת Best Practices, שזה בעצם לחם-חוקם של ארז ושל חברת Komodor. 🎗️

01:22 ארז ו-Komodor

(רן) אז קצת לפני שנקפוץ ונדבר על Kubernetes - כמה מילים עליך, ארז, ועל Komodor.
  • (ארז) מגניב. אז אני ארז - בן ארבעים, גר ברמת גן, נשוי לשירן, אב לשלוש בנות.
    • כבר 16 שנה בתעשייה, בערך מ-2009. עובד היום ב-Komodor.
  • נספר קצת על Komodor כמוצר -
    • אז Komodor זה בעצם מוצר שנועד לצוותי פיתוח, שמשתמשים ב-Kubernetes, או עושים מיגרציה (Migration) ל-Kubernetes ב-Production.
    • אנחנו מציעים Offering שפונה גם ל-Experts בארגון - אם זה צוותי ה-DevOps או ה-Platform - וגם לצוותים שמפתחים, שבעצם הקוד שלהם רץ על גבי Kubernetes, אבל מטבע הדברים הם פחות מכירים לעומק את הכלי.
    • אז אם זה כלים של Cluster Management, Cost Efficiency ו-Reliability של ה-Workloads over time ו-Access Control, הנחלת קונבנציות (Conventions) בארגון הפיתוח - זה בעצם מה שאנחנו נותנים ל-Expert-ים.
    • לחבר'ה שפחות מכירים, יש לנו Guided Troubleshooting Tool כזה, שבמידה ויש Incident, בא ועושה איתם Root Cause Analysis
      • יש פה Generative AI, לוגיקה קלאסית שמעורבת בתהליך.
    • ובעצם, אנחנו עוזרים לארגונים, ל-Enterprise-ים גדולים, להפחית את העומס הזה שנוצר מכיוון צוותי הפיתוח לכיוון צוותי ה-DevOps, ולאפשר להם להיות עצמאיים.
      • ועל הדרך גם ללמד אותם על Kubernetes, ולמה קורים דברים שאנחנו לא היינו רוצים שיקרו.
(רן) כן, אז חדי-האוזן בוודאי הבחינו בהגייה שלך . . . .
  • (ארז) כן, מתנצל על זה מראש . . .
(רן) אז קודם כל, נשאלת השאלה- אם Kubernetes או קוברנטיקס? אז ובכן, אחת ולתמיד - זה Kubernetes.
אבל כן, אכן כותבים את זה קצת מוזר, וגם דיברנו על זה, אני חושב, לפני די הרבה פרקים, על זה שהמקור הוא ביוונית, וזה למעשה, מה זה? זה גלגל ההגה? [פרק 353 עם Istio]
(אורי) של הספינה, כן.
(רן) של הסירה, של הספינה. כן - אני חושב שיש פה חובלים שיודעים להנהן בראשם.
(אורי) חובלים יוונים.
(רן) חובלים יוונים, לא סתם - מהמקור!
אז אני חושב שיצא לנו לא מעט לדבר עם נתי שלום [לאחרונה ב-489 carburetor 38], שהוא גם לא מעט מדבר על נושאים בתחום הזה - והוא אמר שהרבה חברות למעשה לוקחות תשתית כמו Kubernetes, ובונות מעל זה PaaS. זאת אומרת, בונות מעל זה איזושהי פלטפורמה ל-Deployment של התוכנה שלהן . . .
(אורי) דיברנו על כל ה-Platform Engineering שבא מעל זה . . . . [445 Carburetor 33 - platform engineering]
(רן) . . . . בדיוק - ואני יודע, זה משהו שגם נעשה ב-Outbrain, וזה נעשה גם בחברות אחרות - אבל זה לא מה שאתם עושים ב-Komodor. זאת אומרת, אתם לא בונים PaaS לחברות . . .
  • (ארז) לא, למעשה אנחנו מה שנקרא Day One או Day Two.
    • בעצם, מרגע ה-Provisioning של ה-Cluster ופרישת ה-Workloads על גביו, אנחנו עוזרים לחברות לתחזק את “המפלצת הזאת” שנוצרת לפעמים לאורך זמן.
    • ושוב - לאפשר לארגון לעבוד בצורה שיותר Efficient, Self-Sustained, והייתי אומר “נורמלית”, בתוך כל הכאוס הזה, שעלול להיווצר ב-Cluster-ים מאוד גדולים.
(אורי) אז אתם מוצר או Service - או שניהם?
  • (ארז) אנחנו למעשה מוצר SaaS - יש לנו Agent, שלקוחות מתקינים על ה-Cluster שלהם.
    • ובעצם החל מאותו רגע, אנחנו מתחילים להזרים Data אלינו - ותוך שעות עד ימים מתחילים לנפק Insights.
      • זה, הייתי אומר, ה-Value היותר long-term-י.
  • בנוסף לזה, אנחנו סוג של “Gate ל-Kubernetes
    • אז אם לדוגמה אתה רוצה לנהל הרשאות גישה של משתמשים across clusters, ויש לנו לקוחות עם מאות Cluster-ים, אז בעצם אנחנו עוזרים למסד את הדבר הזה ולנהל אותו.
(אורי) כשירות או כמוצר?
  • (ארז) כשירות? אני לא בטוח שאני מבדיל בין שני המושגים האלה - זה מוצר שהוא שירות, כלומר...
(אורי) אוקיי.
  • (ארז) . . . . נכון, זה מוצר SaaS-י, בעצם אתה ניגש אליו...
(אורי) לא, לא - אני אומר “כשירות”, זאת אומרת - יש אנשים מאחורי זה? או שיש . .
(רן) . . . . עד כמה זה High-Touch או לLow-Touch?
  • (ארז) לא - הכל נעשה בצורה אוטומטית לחלוטין.
    • כמובן שאנחנו מאוד קשובים ללקוחות, ואם יש דקויות לפה או לשם אז אנחנו ניגשים ועוזרים ומסבירים.
      • לפעמים אפילו עושים שינויים במערכת.
    • אבל אין פה איזה Human Intervention במגע גבוה.

05:50 בחזרה לעתיד / למה אנחנו צריכים את כל זה?

(רן) אוקיי, אז אולי אחר כך גם נחזור לעוד כמה דברים ש-Komodor עושים - אבל זה הזמן לדבר על Kubernetes.
אז בואו נחזור אחורה בזמן - משהו כמו ה-17, 16, אולי אפילו 20 שנה. אני אספר לכם שבצעירותי, כשעוד היה לי שיער שחור לחלוטין . . .
(אורי) . . . כשעוד היה לך שיער . . .
(רן) . . . כשעוד היה לי שיער ברוב חלקי-ראשי, ופחות בשאר הגוף, אז יצא לי לעבוד ב-Google - ושם הייתה מערכת פנימית שקרו לה Borg. וזו הייתה מערכת שיודעת לפרוש שירותים, לייצר רפליקות (Replications) של שירותים, להריץ Job-ים, Load Balancers, Monitoring - “מכל הבא ליד”.
וכשסיימתי את העבודה שם ויצאתי החוצה, חיפשתי משהו כזה - ולא היה, במשך כמה שנים.
וכאן, ארז מצטרף לסיפור . . .
  • (ארז) כן. אז אני אשמח להתחיל את הסיפור דווקא במפגש הראשון שלי עם Kubernetes, בעצם אזור שנת 2015.
    • הצטרפתי בתקופתו ל-Nanit, ממש עובד רביעי-חמישי - וכבר היו בנויים כמה Containers ב-Docker, והיה צריך להחליט איך אנחנו עושים אורכסטרציה (Orchestration) לכל הדבר הזה.
  • בתקופתו היו שני שירותים עיקריים שמציעים פתרונות -
    • הראשון היה AWS ECS, שלמעשה קיים עד היום.
    • והשני היה Kubernetes - שהוא היה ממש “בחיתוליו”: לדעתי גרסה 1.0.2, גרסה ממש ראשונית.
  • ובעצם, המשימה הראשונה שלי הייתה להבין איך אנחנו הולכים לנהל ב-Long Term את כל ה-Docker Containers וה-Services שלנו, שהולכים להיווצר במהלך זמן חיי החברה.
(רן) אז קודם כל, אולי למה אנחנו צריכים את כל זה - ואחר כך גם נחבר לסיפור הנוגע ללב, אני חייב לומר, שלי על Borg . . . אז אם אתם, כל מה שיש לכם זה איזשהו, לא יודע, איזשהו Web Service, או משהו שהוא ככה Singleton, מאוד פשוט - כל מה שאתם צריכים זה אולי, רחמנא ליצלן, איזה FTP או סתם ככה SSH: הולכים ל-Server, מרימים איזשהו משהו וזה רץ, הכל טוב ויפה.
במציאות, צריך לפחות שניים מכל דבר, נכון? ויש איזשהם בדרך כלל Microservices, אצל הרבה חברות, שמדברים אחד עם שני . . . זאת אומרת, צורת ה-Deployment היא מורכבת, ואם תעשו את כל זה באופן ידני, אתם כנראה תטעו באיזשהו מקום, וזה מאוד קשה לניהול.
כאן בא Kubernetes ועוזר לנהל את כל זה. זאת אומרת, זה לא רק לבוא ולהתניע את ה-Container, אלא זה גם לנהל את כל ה-Life cycle של מה קורה אם אחד מהם מת, מה קורה אם צריך לעשות Deployment וכו'.
אז זה הצורך ב-Kubernetes. אוקיי - ואז אתה אומר שהייתם צריכים לבחור בין, נגיד, ECS ו-Kubernetes, והלכת על הילד החדש בשכונה?
  • (ארז) כן, בעצם מתוך המחקר שעשיתי, גיליתי שאם כמה זה ששני ה-Service-ים האלה, או השירותים האלה, או הפלטפורמות האלה, הן פלטפורמות צעירות - Kubernetes בעצם הציע המון דברים שהם סוג של “Batteries Included”
    • כמו Log collection, Metrics collection - כבר בשלבים המאוד ראשוניים שלה.
    • ו-ECS הרגיש מאוד “בוסרי” באותו שלב.
    • ולכן גם בעצם קיבלתי - וקיבלנו - את ההחלטה להמשיך עם Kubernetes.
    • החלטה שבתקופתו לא הייתה טריוויאלית או Obvious בכלל - ולשמחתי זה מאוד השתלם לנו.
  • חייב להגיד מילה לעניין ה-Complexity של ה-Deployments - אז יש בלוג-פוסט מאוד מוכר והומוריסטי של CircleCI בשם “It's the future”
(רן) אולי אחד הדברים שמי שיהיה באזור והכיר את Kubernetes בטח הרגיש, זה שהיא הייתה מערכת מאוד מאוד בוסרית. אתה אומר שהיו כמה “Batteries Included”, אבל מצד שני לא הכל עבד As-Spec, והדברים זזו, וגם אם משהו עבד, בגרסה הבאה פתאום זה משתנה . . . .
  • (ארז) נכון.
(רן) . . . . אז ככה שנדרש, בוא נאמר, אומץ רב, כדי לבוא ולאמץ מערכת כזאת בסביבת Production, בשלבים האלה.
אבל ההימור, כמו שאתה אומר, הצליח לכם.
(אורי) היא גם הייתה מאוד, ככה, “Strict” באיך שעובדים איתה, לא?
  • (ארז) היא הייתה אפילו מאוד מתסכלת, באיזשהו מובן. יכול לתת כמה דוגמאות . . . .
    • לדוגמא, Resource ה-Deployment, שהוא, הייתי אומר, אחרי Pod, כנראה ה-Resource הכי מוכר ונפוץ היום ב-Kubernetes, לא היה קיים בגרסאות הראשונות.
    • ולמעשה, חלק מה-Script-ים שאנחנו בנינו, היו מורידים ReplicaSet אחד ומעלים ReplicaSet אחר, כדי לעשות פרישה של גרסה חדשה.
(רן) כלומר, אם היית רוצה לעשות Deployment לגרסה חדשה, לא היה את הקונספט הזה שנקרא . . . שהיום קיים ב-Kubernetes ונקרא Deployment - היית צריך לייצר משהו כזה מה-Building Blocks שהיו קיימות אז, שהיו ReplicaSet. גם היום קיימות - אבל יש מעטפת, יש אבסטרקציה (Abstraction) קצת יותר גבוהה.
    • (ארז) לגמרי. אבסטרקציה, הייתי אומר כמעט מושלמת, נכון. היום, כשאני פורש איזשהו Service ב-Kubernetes, אז יש לי את כל השירותים.
      • עד כדי להחליט כמה אחוז מה-Workload שלי אני מוכן שיהיה Unavailable במהלך זמן פרישה.
      • שזה, הייתי אומר, מאוד Advanced, בטח יחסית למה שהיה אז.
    • כל האיחסונים של ConfigMap ו-Ingress להחצנת שירותים בעצם - לא היו קיימים.
  • ואם זה שאמרתי שאולי זה היה קצת מתסכל, אני חושב שגם זאת הייתה הזדמנות נפלאה לייצר המון Open Source.
    • ובאמת ייצרנו המון המון Open Source, כמעט לכל הדברים והכלים שנבנו במהלך הדרך.
      • אם זה Helm charts, שזה בעצם היכולת לעשות Injection של variables ל-Templates.
      • אם זה Ingress, שזה היכולת שלי להחצין איזשהו Load balancer, שמכווין ל-Internal Services וכו'.
  • אז אני חושב שבאמת עם כל הקושי, גם הרווחנו המון מהדבר הזה - אני אישית גם.

12:01 להשתמש נכון / איך אני יודע שאני צריך אחד כזה?

(רן) כן, אז בסדר - אז נחזור רגע להיסטוריה: אז אמרנו ש... זאת אומרת לא אמרנו, אבל נגיד עכשיו - למעשה, Kubernetes נולד מתוך איזשהו פרויקט פנימי שהיה קיים ב-Google, שנקרא Borg. באיזשהו שלב, Google החליטו שהם רוצים לייצר גרסה חיצונית - זה לא אותו Codebase, אלא גרסה חיצונית שדומה לאותה מערכת - ולתת אותה לעולם.
יש לך מושג למה? כאילו, מה האסטרטגיה פה?
  • (ארז) אז אני חשבתי על זה לא מעט, ואני חושב שזה מאוד מקביל לשחרור של Android.
  • בעצם, המטרה היא פה לפרסם פלטפורמה שהיא חינמית והיא Cloud-agnostic
    • ובדרך הזאת, Google לדעתי קיוותה להיכנס לשוק ה-Cloud Providers, על ידי זה שהם מאפשרים העברה מאוד קלה של Workloads מ-Cloud אחר אליהם.
    • כי Kubernetes הוא בעצם שכבת האבסטרקציה לאותם Workloads - וזה משהו שעובד.
    • (רן) Anti-Lock-In . . . .
    • (ארז) בדיוק, Anti-Vendor-Lock . . . .
(רן) ואם ככה, אז כאילו, אתה יודע - מתבקש ש-AWS לצורך העניין, לא כל כך יאהבו את Kubernetes, אבל היום התמונה קצת שונה, נכון? היום אתה רוצה Kubernetes, אתה לוחץ על כפתור - הוא מריץ Script קטן ויש לך Cluster בכל Cloud Provider שמכבד את עצמו, וגם כנראה באלה שפחות מכבדים את עצמם . . . . זאת אומרת, זה מאוד מאוד נפוץ.
יחד עם זאת, זה עדיין לא פשוט להשתמש בו . . . זאת אומרת, אולי קל להתניע אחד כזה, אבל להשתמש בצורה נכונה - זה לא קל.
  • (ארז) נכון, אני חושב שצריך להכיר - כמו כל כלי שהוא מורכב, הוא בעצם סוג של פלטפורמה ל-Distributed Execution של קוד.
  • בגלל שהבעיה היא כל כך קשה, גם הפתרון מצריך המון ידע והעמקה וההבנה של מה כלי הזה מאפשר לנו.
  • אז יש המון דברים שכדאי שנכיר. נתחיל לעבור על זה?
(רן) כן. אז אולי שאלה הראשונה זה מתי אני צריך Kubernetes? כלומר, איך אני יודע שאני צריך אחד כזה?
  • (ארז) אז הייתי אומר שהיום, בזכות העובדה ש-Kubernetes הוא כל כך נגיש וקל להקמה ויש Ecosystem כל כך רחב סביבו, אז באמת כל דבר שהוא יותר מ-Single Service, כבר הייתי מעלה היום Cluster ופורש את ה-Workload שלי עליו.
    • כמובן, בהנחה שזה משהו שמשרת לקוחות, ומאוד חשוב לנו שהוא יהיה Highly Available ו-Robust ועם Visibility על הדברים.
    • אני חושב שזה היום יחסית No-Brainer, באמת.
(רן) כן. ואולי הזכרנו את זה מקודם - אם אתם מפחדים להיות נעולים אצל אחד מה-Provider-ים, אז Kubernetes יכול לעזור. דרך אגב, זה לא פתרון מושלם - עדיין יש לא מעט ערך מוסף שה-Provider-ים, זאת אומרת, Google ו- GKS [GKE] ו-EKS וכל זה נותנים. אז זה לא אפס, אבל עדיין זה פחות מ-100.

14:57 בואו נדבר קצת על Best Practices

אוקיי. אז החלטתי שאני רוצה Kubernetes אצלי בגינה - בואו נדבר קצת על Best Practices. זאת אומרת, מה אני כאיש Infrastructure או מה אני כמפתח, צריך להכיר, שיעשה את החיים יותר טובים.
  • (ארז) סבבה. אז דבר ראשון, אני חושב שעוד פעם מאוד Obvious, אבל כן להשתמש ב-Managed Solutions.
  • דיברנו קצת על תחילת הדרך - אז באותה תקופה, כדי להרים Cluster, היית צריך להריץ cube-up.sh עם מלא Environment Variables, ולהחזיק אצבעות . . .
(רן) . . . להתפלל ל-Kelsey Hightower שהכל יעבוד . . .
  • (ארז) ממש, ממש. זה היה Kubernetes the hard way”, אבל “This is the only way also” - וזה היה בעייתי.
  • היום, בעצם כל Cloud Provider שמכבד את עצמו, וגם אלה שפחות, מציעים שירות שהוא מאוד נגיש.
    • גם ב-Provisioning - יש לך Control Plane עם Auto-Scaling ו-Full Visibility ו-Resiliency.
    • ואתה לא רוצה פשוט להיכנס לכאב ראש הזה.
  • אז אני חושב שהדבר הראשון כשבאים להקים, זה באמת לבחור את ה-Cloud Provider, שכנראה כבר עובדים בו
    • ופשוט להשתמש ב-Managed Solution שלהם כדי להרים את ה-Control Plane.
    • זה נראה לי התחלה טובה.
(רן) כן, כשאתה אומרת Control Plane - אתה מדבר על “השלד”, שעליו אפשר אחר כך להרים את ה-Workload עצמו, את ה-Container-ים, את ה-Pod-ים . . .
  • (ארז) כן, למעשה אולי משפט על זה - אז בעצם ל-Kubernetes מחולק ל-Data Plane ו-Control Plane.
    • ה-Control Plane זה כל ה-Internal Tools, שעוזרים ל-Kubernetes לעבוד,
      • אם זה ה-Scheduler שלו, אם זה ה-Kubernetes API, אם זה ה-ETCD, שהוא למעשה ה-Storage של כל ה-Resources שלנו.
    • וה-Data Plane - אלה ה-Node-ים שעליהם אנחנו, “ה”User-ים” במרכאות כפולות, מריצים את ה- Workload-ים שלנו.
  • אז בעצם, ה-Managed Services - הם עוזרים לך להקים ולתחזק ולעשות Auto-Scale לכל מה שנקרא “ה-Control Plane”.
    • ואז אתה יכול להתעסק ב-Business שלך וב-Workloads שאתה מפתח.
(אורי) זה לא מין תופעה כזאת של “אוקיי, קם Kubernetes. בהתחלה הוא היה פשוט, אחר כך לאט לאט . . .” - אתה יודע, כשרוצים אז מצטרפים עוד ועוד פיצ'רים לדבר הזה וזה נהיה מסובך. ואז מייצרים מעל זה Managed Services - ועכשיו אנשים מתחילים לשתמש ב-Managed Service, וכשהם שמשתמשים אז הם רוצים עוד פיצ'רים,
ואז נהיים לו מלא פיצ'רים - ואז עוד פעם נהיה . . . “Managed Service מעל ה-Managed Service”?
  • (ארז) זו שאלה טובה . . .
(אורי) . . . מהתהליך הזה . . . אתם מכירים את זה, שבהתחלה אמרו כשקם ה-Cloud, “נגמרה העבודה לאנשי
ה-Ops”, ואז . . .
(רן) . . . “וואי וואי, כמה עבודה יש ב-Cloud” . . .
  • (ארז) כן, פשוט העברנו אותה ל . . .
(אורי) בדיוק . . . ואז פתאום Kubernetes נהיה העבודה של ה-DevOps, ואז נהיה מן Managed Service אבל גם הם נהיו מסובכים . . . בקיצור, תמיד יש עבודה לחבר’ה האלה, להתעסק במה שהמפתחים לא רוצים להתעסק בזה . . .
  • (ארז) אז אני חושב שה-Complexity שהתווסף ל-Kubernetes Over the years הוא למעשה דווקא לא ב-Control Plane אלא יותר ב-Data Plane.
    • כלומר, באפשרויות שלנו, בתור User-ים של Kubernetes ולא בהכרח בתור אלה שמנהלים את ה-Control Plane, להשתמש בו.
    • ולרוב הוא נולד כתולדה מצורך.
  • אז באמת, האבולוציה היא כזאת שהם התחילו מ”הכי Lean שיש”,ולמעשה הוסיפו Complexity לפי הצורך ולפי הצרכים הארגוניים של ארגוני תוכנה גדולים.
  • ואני שמחתי מאוד להינות גם מהדברים האלה במהלך הדרך.
    • כלומר, הרבה דברים שאנחנו חיכינו או עשינו Hacks או Workarounds כדי להקים, פתאום בגרסה הבאה של Kubernetes כבר היו Native Resources ונוהלו על ידו.
  • אז דווקא הייתי אומר שמבחינת Complexity, אני למעשה יכול להשתמש היום ב-Kubernetes כמו שהשתמשתי בו לפני שש-שבע שנים, כי רוב ה-Main Objects הם Stable כבר מאז.
    • אבל אם יש לי צרכים ייחודיים, שהם הייתי אומר Outstanding, אז גם יש לי את האפשרות להשתמש בדברים שהם יותר Complex ולעשות יותר Tuning לפרישות ול-Workloads שלי.
(רן) אבל אני גם חושב, אורי, שמה שאתה מתאר זה איזשהו מעגל אופייני של שימוש בטכנולוגיה. אתה יודע - היא מפשטת, ואז על זה בונים ומסבכים, ואז היא שוב משהו מפשטת . . .
(אורי) . . . הבעיה היה משתמשים . . . כי יש משתמשים - יש בעיה. הבעיה היה העולם - הם רוצים פיצ'רים . . .
(רן) כן, כן . . . אבל כאילו, אני אומר שזה קורה עם המון טכנולוגיה. זאת אומרת נכון שבמקרה הזה דיברנו על Kubernetes, אבל זה קורה כמעט עם כל טכנולוגיה - אם זה טלפונים חכמים, אם זה LLM-ים, כל דבר שאתה תדבר עליו - אני חושב שזה נכון.

19:40 על Resource Requests, Limits, שכנים רועשים ו“הסכרת של ה-Workloads”

אוקיי, בוא נחזור קצת ל-Best Practices - אז אמרת: בתור התחלה, אל תפרשו בעצמכם את ה-ETCD ואת כל ה-Control Plane, תשתמשו במשהו מוכן - ויש כאלה, טובים וחזקים. תשתמשו פשוט ב-Cloud Provider שלכם.
זה עדיין . . . זאת אומרת, אמרנו - זה אולי 20% Lock-In, אוקיי? אבל זה לא 100.
אוקיי - מה עוד?
  • (ארז) אז בוא נגיד שהעלינו את הControl Plane - עכשיו בעצם אנחנו צריכים להתחיל להתעסק ב-Data Plane, שזה ה-Workloads שאותם אנחנו מפתחים ומריצים בענן.
  • אז אני חושב שהדבר העיקרי שכדאי להכיר וגם להשתמש ב-Kubernetes זה בעצם היכולת להגדיר Resource Requests ו-Limits.
    • משפט על זה - אז Resource Requests בעצם עוזר ל-Kubernetes להבין כמה Resources - אם זה CPU או Memory, אתה צופה שה-Process שלך ידרוש.
    • ובהתאם לזה לעשות Scheduling נכון ל-VM-ים ב-Data Plane שלך.
(רן) כלומר, אם אתה פורש איזשהו Service, אתה צריך להגיד מראש - לנחש, או אולי ככה, לעשות “Guesstimation” של כמה CPU תרצה להשתמש וכמה זיכרון . . .
(אורי) . . . .או ניסוי וטעייה . . . אתה רואה שאתה לא משתמש בכל מה שחשבתם.
(רן) . . . מה שנקרא Sizing . . .
  • (ארז) נכון. ברוב המקרים מאוד קשה לצפות את הדברים האלה מראש.
    • ולכן אתם צודקים - מה שעושים זה שפורשים את זה בענן, נותנים לזה לרוץ X זמן, ואחרי זה בעצם לוקחים איזשהו Percentile של השימוש, כדי גם לאפשר מרווח.
(רן) אבל אני חושב שזאת מסקנה יפה ונכונה להמון סוגים של Resource-ים. זאת אומרת, לפעמים ה-Resource זה API שאתה חושף החוצה ללקוחות - וגם את זה תרצה להגביל. אתה יכול לקבוע “לא יותר מ-5,000 Request-ים בשנייה”, או Whatever. אם זה גודל של קובץ שאפשר לעשות לו Upload . . . נכון, אתה לא מדמיין שהם יעלו לך קובץ של 1 Tera, אבל בוא - תגביל. אז “לא יותר מ-Mb500”. לכל דבר תשימו מגבלות - כולל לשירותים שלכם, כי גם אתם תפתיעו את עצמכם באיזשהו יום ותיצרכו יותר זיכרון ממה שחשבתם או שתיצרכו יותר CPU ממה שחשבתם, ואתם כנראה . . . .
קודם כל, אתם רוצים לעזור לCluster - לשים את השירות במקום הנכון, שיש לו מספיק ממה שהוא צריך. ודבר שני - לדעת כשחרגתם ולדעת לנהל את זה . . .
  • (ארז) להגביל את החריגה.
(רן) כן - “שלא תפריעו לשכנים שלכם”, מה שנקרא . . .
(אורי) גם חשוב לדעת שזה - בסוף זה “קוביות של טטריס” שה-Cluster משחק איתן - ואם תיקח קוביה גדולה מדי, יהיו לך פחות אפשרויות לפרוש.
  • (ארז) נכון, אתה תהיה פחות Efficient כנראה.
  • רק מילה על העניין של Request-ים ו-Limits - נכון, אז Request משתמשים, ה-Scheduler משתמש בהם.
    • ו-Limits ממש מגבילים את ה-Process שלנו, וצריכים להיות מאוד זהירים פה.
      • כי אם אנחנו מגיעים ל-Memory Limits, אנחנו בעצם נחטוף Restart OOM-Kill.
    • אבל לדעתי יותר גרוע זה להגיע ל-CPU Limits - שם אנחנו חוטפים CPU Throttling, ולמעשה all hell break loose . . . [ד”ש לקבוצת ה-Power ב-Intel . . . .]
  • חוויתי לא מעט פעמים במהלך הקריירה שלי Process-ים אפילו תשתיתיים שמגיעים ל-CPU Limit, חוטפים Throttling - ומאוד קשה להבין, אם לא מודעים, אם אין Awareness לעובדה הזאת, מה לעזאזל קורה.
    • כי למעשה, כל השמה של משתנה עלולה לקחת פתאום 20 שניות - ואלה דברים שבדרך כלל אנחנו לא צופים.
    • לרוב אנחנו צופים האטה כתוצאה מ-I/O או כתיבות לדיסק - לא מ-Execution של קוד לוקלי.
    • ו-CPU Throttling זה . . . אני קורא לזה “הסכרת של ה-Workloads” - צריך לשים שם את העיניים.
      • להציב אותם - אבל גם לדעת להיות Aware ולנטר את הדבר הזה, כדי שלא נפגע.
(רן) כן, אבל פה אולי חשוב לדבר על למה בעצם מעניין אותנו על “השכנים הרועשים” - כי למעשה אותם Pod-ים,
אותם Container-ים שעליהם דיברנו - אוקיי, Pod זה קצת יותר מ-Container, אבל לא נכנס לשם - למעשה, הם פרושים הרבה פעמים על אותה חומרה, אבל, זאת אומרת, הם שירותים שונים. לוקחים שרת מאוד מאוד גדול, מחלקים אותו - דרך אגב, זה גם כמובן מה שה-Cloud Providers בעצמם עושים, אבל גם בתוך Kubernetes - לוקחים חומרה, מחלקים אותה לפרוסות קטנות יותר, ועל כל פרוסה שמים איזשהו Pod, ואם Pod אחד “משתולל”,
אז הוא יכול להפריע לכל האחרים.
  • (ארז) כן, תופעה שנקראת “Noisy neighbor” - “השכן הרועש”.
  • אפרופו Komodor - אז יש לנו גם מנגנון Detection לדברים האלה.
    • כלומר, Pod שה-Execution שלו נפגע, למרות שהוא לגמרי עומד ב-Request-ים וב-Limit-ים שהציבו לו, רק כי Pod שכן שלו - היה לו את אותו VM בטעות, והחליט להתפרע.
(רן) אז יבואו חכמים וגידו “רגע, אז למה צריך שכנים?! - אז תשים Service אחד על כל Host אחד!” . . . “מה הבעיה? למה אתה צריך לקבץ אותם?”
  • (ארז) אז אני חושב שפה...
(אורי) . . . . כי “מה הועילו חכמים בתקנתם”, נכון? . . .
(רו) . . . אנחנו כל כך צדיקים היום, הא?
  • (ארז) אני חושב שהניסיון פה באמת . . . הייתי אומר שני דברים:
    • אחד - לעשות אבסטרקציה ל-VM-ים, בסדר? התשתית היא רק ה-Vessel שעל גביו אתה רץ, ואתה לא באמת חייב להכיר איזה סוגי Node-ים וכמה CPU.
      • הכל נכנס לאיזה Blob אחד - כמו S3 ל-Blob Storage, אז הייתי אומר CPU ו-Memory Storage.
    • והדבר השני זה Cost Efficiency - בעצם, זה שאנחנו יכולים לחתוך את ה-Workload שלנו לחתיכות קטנות יותר.
      • אם דיברת על מחסן או טטריס, אז זה בעצם מאפשר לנו לקבל הייתי אומר, “כיסוי יותר מלא” של ה-Resources שאנחנו משלמים עבורם.
(רן) כן, אז אם נגיד פעם היה לכם One service per VM, אבל ה-VM היה מגיע, בימים טובים, ל-20% CPU או 15% זיכרון - אז פה אתם יכולים להיות יותר יעילים, בלי לעבוד כל כך קשה. זאת אומרת, לתת ל-Kubernetes לעשות את העבודה של הצמצום בשבילכם.
  • (ארז) לגמרי.
(רן) אוקיי, אז אמרת Resource Request ו-Resource Limit, שזה דברים דומים אבל לא בדיוק אותו דבר: Request זה כמה אני צריך ו-Limit זה מתי “תחנוק אותי” - ולמעשה, ה-Best Practice הוא להשתמש בשניהם.

25:42 כשקשה - קשה לכולם

(רן) אוקיי, אז דיברנו בינתיים על שניים, אולי שניים-וחצי - בואו נעבור לדבר הבא. מה עוד כדאי לעשות?
  • (ארז) כן, אז זה מאוד חשוב להכיר את כל נושא ה-Probe-ים ב-Kubernetes, שזה בעצם היכולת שלנו להגדיר ב-Deployment שלנו, ב-Container, איך Kubernetes יודע שהוא חי ובריא.
  • בעצם, יש שני סוגים של Probe-ים כאלה - אחד נקרא Liveness Probe והשני Readiness Probe.
    • כש-Readiness Probe - במידה וה-Pod שלנו לא עונה, לדוגמה, לאיזשהו TCP Socket או כל בדיקה אחרת.
      • זה בעצם יוציא את אותו Pod מה-Service, והוא יפסיק לשרת בקשות.
      • שזה, הייתי אומר, פעולה שהיא פחות Intrusive.
    • ו-Liveness Probe - במידה ואנחנו לא מצליחים לעבור אותו, ה-Container שלנו יחטוף Restart.
  • אז ההמלצה היא כן להשתמש בשני המנגנונים האלה, אבל בכל מה שקשור ל-Liveness Probe - צריכים להיות זהירים.
    • כי בהרבה מהמקרים, בעצם מה שקורה זה שה-Pod שלנו הוא לא בריא
      • מאיזושהי סיבה - זה גם יכול להיות כתוצאה מאיזשהו כשל Infra-אי, כמו Database או Redis או Queue.
      • וה-Restart שלו בעצם יוצר אפקט של Cascading Failure, כי לפעמים Process-ים שעולים צריכים לחמם Cache וצריכים לפתוח Connection-ים ל-Database, וכל מיני Warm-up-ים כאלה . . . .
    • (רן) כמו שאומרים - כשקשה, קשה לכולם, אז אל תעשה את זה קשה יותר . . . .
(רן) אבל אולי, רגע, נחזור אחורה - מה המשמעות, למי שלא מכיר: מה זה Liveness ומה זה Readiness? אז בעצם,
כשכותבים שירות, ברוב המקרים אתם רוצים יותר מ-Instance אחד שלו, אתם לא רוצים שיהיה רק אחד. אז אם זה ששמים זה מאחורי Load Balancer או אם זה איזשהו Job שרץ ברקע, אז זה משהו שנגיד קורא Job-ים מ-Queue ומריץ. אבל אתם רוצים יותר מאחד כזה, כי כל אחד יכול “להתאדות” מתישהו, אז תמיד כדאי שיהיה יותר מאחד.
עכשיו, כשאחד כזה עולה - פרשתם נגיד, או עשיתם Restart, ויש לכם אחד כזה חדש - אתם רוצים לבוא ולהגיד מתי הוא מוכן להתחיל לעבוד, מתי להכניס אותו ל-Load Balancer או מתי הוא יכול להתחיל לקרוא מהתור וכו’, ולצורך זה, באמת מוגדרים ה-Probe-ים האלה.
אז Liveness זה אומר “אני בחיים. אולי אני לא אעשה את הדבר הנכון, אבל אני בחיים - רגע, אל תהרוג אותי” . . . .
(אורי) . . . אני - ה-Container. זה עוד לא אומר שה-Service בחיים . . . . הפוך זה ה-Readiness, “אל תהרוג אותי” . . .
(רן) אוקיי, סליחה - זה ה-Readiness, וה-Liveness זה אומר “אני מוכן - תביא!”. תביא עבודה, תן לי Traffic . . .
(אורי) לא . . . הפוך.
(רן) אז צדקתי מהתחלה! אז רגע . . .
  • (ארז) שני ה-Probe-ים האלה יכולים להצליח או להיכשל.
  • כש-Pod עולה, הוא צריך לעבור Readiness Probe, כדי להתחיל לשרת בקשות.
    • הוא גם יכול להיכשל במהלך ה-Lifetime שלו, ולצאת ולהיכנס שוב לאותו סט של Pod-ים, שבעצם מנגיש לו את ה-ה-Service.
    • ו-Liveness Probe, מהצד השני, בעצם ברגע שהוא נכשל הוא ב-Restart.
      • ואותו Pod יכול לעבור גם כמה Restart-ים במהלך ה-Life cycle.
(רן) זאת אומרת, אם ה-Live שלי נכשל, זה אומר כאילו “תהרגו אותי” . . . “אין לי מה לעשות פה, אני לא מועיל יותר”
  • (ארז) “אני תקוע, אני צריך שמישהו יבוא לחלץ אותי”.
  • ו-Readiness זה “שים אותי שנייה בצד, תחזור אותי עוד כמה דקות, אני רגע עסוק”.
(רן) . . . “אני עסוק, רגע, אל תפנה לי Traffic . . . הנה, אני מוכן! עכשיו אני Ready!”
  • (ארז) בדיוק.
(רן) בסדר.
  • (ארז) אז רק לחדד פה, שהסכנה היא באמת בעיקר ב-Liveness Probe, בגלל ה-Cascading effect שנוצר כתוצאה מ-Restart-ים.
    • לא להשתמש בו Blindly, מה שנקרא.
(אורי) רגע, אני רוצה להבין משהו - יש קשר בין הקוד או ה-Service שרץ על ה-Container, לבין ה-Probe-ים האלה? זאת אומרת אני יכול להשתמש בהם, נגיד אם ה-Cache שלי עוד לא חם . . .
  • (ארז) לגמרי . . . .
  • אז למעשה, בוא ניקח Probe קלאסי, שדוגם איזשהו HTTP Endpoint בקוד שלך.
    • ואתה, בקוד שלך, באותו קוד של Endpoint, יכול להגיד “אני בודק שה-Connection שלי ל-Database בריא, ושחיממתי את ה-Cache ושהצלחתי להוריד קובץ קונפיגורציה מ-S3.
    • ורק החל מהרגע שאותם תנאים יתמלאו, אתה מכריז על עצמך בתור Ready, כלומר - “אני מוכן להתחיל להנגיש את השירות, לשרת לקוחות”.
(אורי) ואז בעצם, מבחינת המערכת - ה-Load Balancer, או מה שזה - ה-IP שלי “חי”.
  • (ארז) ה-IP הוא למעשה חי מרגע היווצרות ה-Pod , מוצמד IP לכל Pod.
    • השאלה היא האם אתה חלק מה-Target Group ב-Load Balancer, או לא?
    • זאת השאלה, זה ה-Readiness - אם אתה מוכן אז אתה חלק מה-Target Group, ואם אתה Not-Ready, אז אתה יוצא מה-Target Group.
(רן) יש מקומות שבהם ל-Readiness הזה גם קוראים Health, זה אומר “אני בריא ואני מוכן לשרת!”, כלומר - כמו שאמרת: “יש לי את החיבור ל-Database שאני צריך, יש לי מספיק זיכרון” . . . לא יודע, “טענתי מה-Cache, אני מוכן
עכשיו לקבל”, “פתוח לקבלת קהל” מה שנקרא.

30:21 איך הוא עושה Distribution לדבר הזה / Anti-Affinity, Taints & Tolerations

(רן) בסדר, עכשיו כתבת פה בסעיף D [בהכנות לפרק] מונח מאוד מעניין, שנקרא Anti-Affinity . . . ובכן?
  • (ארז) אז בעצם, דיברנו על ה-Scheduler של Kubernetes, שבסוף - יש לו אוסף מאוד גדול של Pod-ים
    • חלקם מאותו Service, חלקם מ-Service-ים שונים.
    • והוא צריך עכשיו להחליט איך הוא עושה Distribution לדבר הזה, כדי באמת להפוך את אותו Service ל-Highly Available, Resilient, Fault-Tolerant וכל ה-Buzzwords האלה.
  • ובעצם, Anti-Affinity Rules מאפשרים לנו להגדיר ל-Scheduler איך לבזר נכון את אותם Pod-ים.
    • כש-Anti-Affinity Rule יכול להיות “אל תשים לי שני Pod-ים מאותו Service על Node יחיד”, הם יכולים להיות “אל תשים לי באותו Availability Zone”, אוקיי?
  • כלומר, יש לנו דרך להגדיר איך אנחנו היינו רוצים שה-Scheduler יבזר את ה-Workloads שלנו
    • כדי שבאמת אם יש עכשיו איזשהו כישלון Availability Zone, ב-AZ אחד ב-Amazon, אז בעצם יש לנו עוד שני AZs שכבר פרושים שם Pod-ים . . .
(רן) כלומר, הCluster, “באופן טבעי”, גם פרוש על פני מספר Availability Zones - ו-Kubernetes מבין את זה. הוא מבין את ה-Concept, הוא יודע. ואז, כשאתה פורש את השירות שלך, אתה אומר “תשים לי אחד בכל Availability Zone”, אין טעם לשים את כל השלושה באותו אחד, כי אין בזה טעם.
  • (ארז) אז מה שמעניין, דרך אגב, זה ש-Kubernetes לא באמת חייב להבין את זה.
    • אלא כל Node שעולה מקבל Label-ים מה-Cloud Provider, ולמעשה אתה יכול להגדיר Anti-Affinity Rules על Label-ים ואפילו על Label - Custom, שאתה שמת.
    • (רן) “שרירותיים” . . .
    • (ארז) כן, בדיוק.
    • (רן) אבל Out of the Box, כנראה אני מניח שעל פני ה-Cloud Provider יש גם את ההבנה הזאת, ואתה יכול בנוסף לייצר אחרים.
(רן) אוקיי, אז זה מה שנקרא Anti-Affinity. בסדר, אולי קצת . . .
  • (ארז) יש עוד איזה נושא שהוא טיפה קרוב . . . הוא לא בדיוק זה, אבל זה כל העניין של Taints ו-Tolerations.
  • קצת מורכב, אבל בעצם Kubernetes מאפשר לנו לשים Taint-ים, שזה סוג של סירחון, לפחות לפי התרגום שאני קראתי . . .
    • ורק Pod-ים שהם יהיו Tolerates את ה-Taint הזה יהיו Scheduled לאותו Node.
    • זאת נגיד דרך מעולה לעשות Scheduling ל-Pod-ים שצריכים GPUs רק ל-GPU Nodes.
    • או לבודד כל מיני Infra Workloads שהיית רוצה שירוצו לבד.
    • זה גם אחלה כלי . . .
(רן) כן, כלומר אוקיי - אולי לא הייתי קורא לזה “סירחון” . . . יכול להיות זה הפירוש, אולי הייתי קורא לזה “איזה טעמים” - איזה טעמים יש לזה: “יש לזה טעם של GPU - אני רוצה לרוץ על משהו עם טעם GPU” או “יש לזה טעם של High Network Bandwidth, אז אני רוצה לרוץ על משהו כזה”.
  • (ארז) בדיוק.
(רן) בסדר. עכשיו, זה Label-ים שה-Cluster Admin, לצורך העניין, שם על ה-Node-ים, כי כשהוא מרים את ה-Cluster, אז הוא מבין מה יש לו. ואתה, בתור מפתח שכותב את השירותים, אתה יכול לעבור ולהגיד מה אתה מעדיף.
מה קורה אם אין כאלה? מה קורה אם אין מספיק - מה ה-Kubernetes יעשה?
(אורי) . . . אם אין מספיק Resource-ים . . . .
  • (ארז) כן, אז בעצם - האמת שזו התנהלות ממש מעולה של Kubernetes.
    • כי Pod -ים שה-Scheduler לא מצליח לסקנג'ל (To Schedule) אותם לתוך Node-ים בגלל Insufficient Resources, והוא גם יודע להגיד למה, בעצם זאת ההזדמנות שלנו להטריג (Trigger) Auto-Scaling ב-Cluster ולהעלות עוד Node-ים.
  • ובאמת, Cluster Auto-Scaler ו-Karpenter - שהם הייתי אומר שני הכלים המובילים היום ל-Scaling של ה-Infra - הם משתמשים ב-event-ים האלה כדי להבין שצריך להוסיף עוד Resources לCluster, כדי לספק את הביקוש.
(אורי) אתה יכול לכוון אותם בצורה מסוימת? זאת אומרת, לתת High-water mark, Low-water mark . . .
  • (ארז) בדיוק. אז אפשר להגדיר Headroom, אפשר להגדיר מינימום, מקסימום . . .
    • אפשר להגדיר אותם פר AZ . . . כלומר, ממש “קונפיגורציה כאוות נפשך”.
  • באמת כלים מעולים, שפשוט מתממשקים לעובדה הזאת - ולא אמרנו את זה, אבל כדאי להגיד: אני חושב שאחד החידושים או באמת הדברים ש-Kubernetes הביא לעולם זה האיחוד של כל ה-Infra וה-Workloads תחת Unified APIs.
    • וזה בעצם מהווה כר פורה ל-Ecosystem מטורף, שפשוט משתמש במידע הזה וקורא וגם כותב אליו.
(רן) כן. פה, אתה יודע . . . זאת אומרת, כמישהו שמתעסק עם מערכות, לפעמים יש דילמה של מתי לייצר אבסטרקציה. כלומר, מתי לאבסטרקט (Abstract) את ה-Infrastructure מהמפתח, ומתי כן לחשוף.
נגיד, אתה לא תמיד רוצה לדעת על איזה סוג של CPU - האם אתה רץ על Intel, על AMD . . . . - זה לא תמיד מעניין אותך.
  • (ארז) נכון.
(רן) . . . אבל אתה אומר - אם זה מעניין אותך, אז אתה יכול לדעת. אם מעניין אותך איזה סוג של Network יש, אז אתה יכול לדעת, אבל זה לא תמיד אכפת לך.
  • (ארז) נכון. הם פשוט עשו עבודה מעולה בלהנגיש, כמו שאתה אומר, את האופציות.
    • ועדיין - לא להכיר אותם בכלל, ולעבוד בסדר.
    • שזה, הייתי אומר, ה-Sweet-Spot.

35:08 כמה מילים על Monitoring, על מה להסתכל ואיפה החברים מהגן

(רן) כן, בסדר, אולי ככה אנחנו לקראת סיום - אולי כמה מילים על Monitoring? על מה כדאי להסתכל?
  • (ארז) כן, אז דבר ראשון - Kubernetes, כמו שאמרתי, מחצין המון המון מידע בצורה סטנדרטית.
    • וזה מאפשר להמון כלי Monitoring לעלות.
  • היום, ה-Stack הרווח הוא kube-state-metrics, Prometheus, Grafana . . .
    • אפשר להתקין אותם ב-Helm Charts שהם Official מאוד בקלות.
    • אז אם הייתי צריך לבחור היום Monitoring Stack ל-Kubernetes - כ-In-House כמובן, שהוא לא חיצוני - כנראה שהייתי הולך עם הכלים האלה.
    • אז זה דבר ראשון.
  • עכשיו, לגבי על מה להסתכל - אז אני חושב שקצת עברנו על זה ב-Best Practices, אבל בעיקר על ה-Resource Usage.
    • בעיקר לשים לב ל-CPU ולהגעה שלו ל-Limits.
    • על Container Restarts - שאנחנו אולי נוטים להתעלם מהם, אבל הם עדיין איזשהו סימפטום של תופעה שלא רצויה, ותמיד יכולה להתגבר ברגעים הכי פחות מתאימים [גם בחלליות…].
  • ואם משתמשים ב-HPA - שלא דיברנו על זה, אבל זה הדרך של Kubernetes לאפשר לי לעשות Horizontal Scaling ל-Workloads שלי.
    • כלומר, לפי ה-Consumption - להחליט אם אני צריך יותר Pod-ים או פחות Pod-ים מאותו Service.
    • אז לשים לב שאם הוא מגיע למקסימום לאורך זמן - כנראה שאנחנו עם Insufficient Resources על אותו Service, ולכן כדאי לשנות שם את הקונפיגורציה (Configuration).
(רן) כן, אז אולי ממש ניגע בזה בקטנה - דיברנו על Auto-Scaling של ה-Cluster, עצמו לא דיברנו על Auto-Scaling של ה-Service-ים. אז למעשה, אפשר לעשות Auto-Scaling בשתי הרמות - זאת אומרת, אם ה-Service שלך נגיד אין לו מספיק Pod-ים, ואתה רוצה באופן אוטומטי להטריג (Trigger), זאת אומרת לייצר עוד, ואחר כך להוריד, כי חבל על הזיכרון ועל ה-CPU שלא צריך. אבל אם אתה עושה הרבה כאלה, אז מתישהו גם נגמר לך המקום ב-Cluster . . . ואז אתה צריך לייצר Auto-Scaling של ה-Cluster. ושני הדברים האלה, כמו שאמרת, זמינים ובאים באופן דיפולטיבי (Default) בתוך Kubernetes. אוקיי.
(אורי) אותי רק . . . נחזור שנייה להיסטוריה - הוא [Kubernetes.] לא תמיד היה פה, והייתה סוג-של . . . לפני שהוא הגיע, סוג של “מלחמת Provider-ים”, או נקרא את זה “פתרונות”. אני לא בטוח שהוא היה, נגיד, תמיד הכי טוב - אבל איכשהו, The winner takes it all, והוא נהיה סטנדרט . . .
(רן) רצית להגיד Mesos, רצית להגיד Nomad, רצית להגיד...
(אורי) כן, כל החבר'ה האלה - היום הם לא יודעים...
(רן) “החברים מהגן” . . .
(אורי) כן, אבל היום לא מכירים אותם - והוא רץ, ו...
(רן) כן, אז היו לא מעט - אז הזכרנו כמה: Mesos, Nomad, הזכרת מקודם את AWS ECS, שזה פחות או יותר באותה שכונה. יש את OpenStack, Docker Swarm, יש לא מעט . . . ובאמת, אני לא יודע מי מהם שרד. כאילו, חוץ מ-Kubernetes. זאת אומרת, ECS קיים . . .
(אורי) היה בו משהו, לדעתי - בקהילה, או ב-Google, שדחפו אותו, או...
  • (ארז) אני חושב שהוא באמת, באופן כן, הוא פשוט ייצר את ה-Feature set שהיה הכי נכון - לאותה תקופה.
    • וידע להתגלגל, כמו מוצר אג’ילי (Agile) של חברה מסחרית - ובגלל זה הוא ניצח.
    • הוא פשוט היה קשוב ל-Community, וידע להוסיף את הדברים הנכונים - בזמן הנכון, בצורה הנכונה.
    • וזה מה שקנה אותי לאורך הזמן.
  • ולכן, גם אני, החל מהרגע שעשיתי את ה-Research הזה ובחרתי ב-Kubernetes, לא הסתכלתי אחורה לשנייה.
    • כי באמת לא היה שום מתחרה בסדר גודל כזה, שידע לספק את הדברים.
(רן) כן. דרך אגב - זאת אומרת, הזכרנו פה שמות של מוצרים אחרים. הרבה מהם כתובים ב-Open source. זה לא אומר שלא השקיעו בהם כסף . . . משקיעים בהם הרבה מאוד כסף: גם ב-Kubernetes. זה Google וגם אחרים, וגם באחרים - ב-Mesos, ב-Nomad ואחרים - השקיעו הרבה מאוד כסף.
זה נכון שהם היו בקוד פתוח - אבל עדיין, צריך לפתח אותם. אז...
(אורי) לא, לא - זה תופעה חברתית כזאת, שיש בסוף מישהו שלוקח - Winner Takes it All.
(רן) לא, יש פה Network Effect, זה ברור, נכון. זה ה-Community, זה ה-Know-How, זה ה-Adoption מצד ה-Provider-ים. זאת אומרת, יש פה הרבה דברים, יש פה Network Effect משמעותי.
  • (ארז) דווקא אני חושב שפה ה-Adoption הוא באמת היה בעייתי - כי אני חושב שכל Cloud Provider ידע.
    • או לפחות Amazon, שהוא היה בתקופתו, באמת, לא יודע, 80% מה-Market - הם ידעו שברגע שהם עושים Adoption לדבר הזה, זה דווקא מעמיד אותם בסכנה.
(רן) נכון.
  • (ארז) הייתי אומר שדווקא Adoption היה נגדו באיזשהו אופן - אבל הם הצליחו בכל זאת.
    • פשוט כי זה היה הכלי הנבחר על ידי ארגוני DevOps.
(אורי) אני יכול להגיד שלנו ב-Outbrain - הלכנו איתו על On-Prem, אבל אחר כך כשרצינו להיות מסוגלים
לעבוד גם על Cloud Providers, זה היה די פשוט.
  • (ארז) מאוד . . .
(אורי) עוד פעם - “פשוט” זה לא, אבל... Doable בזמן סביר.
(רן) מקודם דיברנו על Lock-In - אבל פה אתה מדבר על Scenario של Hybrid, נכון? או שני Cloud-ים, או Cloud ו-On-Prem . . . אבל זה למעשה, זה אף פעם לא נורא פשוט - אבל זה כן מאפשר את היכולת הזאת [זכרונות מ-2019 - 382 Carburetor 27 - k8s and multi-cloud].
(אורי) לגמרי.
  • (ארז) זה מוריד קצת “מהכבלים האלה”, שקושרים אותך ל-Infra.
(אורי) כן. לפעמים, אבל כאילו - ב-On-Prem, אתה מסוגל להגיע לעומסים על מכונה מאוד רצינית. פתאום אתה עובר ל-Cloud, שגם ככה יש לו את ה-VM - וכאילו, החומרה לא ממש מנוצלת כמו שצריך, גם אם אתה מתאמץ. ופתאום, אני אומר לך “רגע, אנחנו לא . . . “, ממש, Provider-ים אומרים “אנחנו לא בנויים לעומסים האלה על Node או על...”.
  • (ארז) כן, אז ה-Coefficient של ה-Resource Consumption שלך משתנה, כשאתה עולה ל-Cloud, נכון?
(אורי) כן - אז זה משלם יותר . . .

41:26 עוד קצת על Komodor לסיום

(רן) כן, בסדר. אנחנו ככה ממש לקראת סיום - אולי עוד כמה מילים על Komodor? קצת על החברה, כמה עובדים אתם? איפה אתם נמצאים? את מי אתם מגייסים - אם אתם...
(רן) אולי שווה לציין - ה-Komodor הוא ב-K - ולא ב-C, כמו שאולי התרגלתם . . .
  • (ארז) זה ה-Theme שלנו, דרך אגב - יש לנו עוד דברים ב-K . . .
(רן) אוקיי, כן. כן, אז זה לא המחשב משנות ה-80 - זה Komodor ב-K, אז כשאתם מחפשים, זה שם.

טוב, תודה רבה - ושיהיה לכם בהצלחה. להתראות.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!
  continue reading

156 епізодів

Artwork
iconПоширити
 
Manage episode 463452336 series 2497397
Вміст надано רברס עם פלטפורמה. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією רברס עם פלטפורמה або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.
פרק מספר 490 (מי היה מאמין) של רברס עם פלטפורמה, שהוקלט ב-21 בינואר 2025. אורי ורן מארחים בהפסקת אש את ארז רבין חחברת Komodor לשיחה על Kubernetes, ולמעשה - כדי לספר את סיפור חייו של Kubernetes: קצת על ההיסטוריה של Kubernetes - מאיפה הוא בא? למה בכלל הוא נולד? מה עושים איתו היום וקצת Best Practices, שזה בעצם לחם-חוקם של ארז ושל חברת Komodor. 🎗️

01:22 ארז ו-Komodor

(רן) אז קצת לפני שנקפוץ ונדבר על Kubernetes - כמה מילים עליך, ארז, ועל Komodor.
  • (ארז) מגניב. אז אני ארז - בן ארבעים, גר ברמת גן, נשוי לשירן, אב לשלוש בנות.
    • כבר 16 שנה בתעשייה, בערך מ-2009. עובד היום ב-Komodor.
  • נספר קצת על Komodor כמוצר -
    • אז Komodor זה בעצם מוצר שנועד לצוותי פיתוח, שמשתמשים ב-Kubernetes, או עושים מיגרציה (Migration) ל-Kubernetes ב-Production.
    • אנחנו מציעים Offering שפונה גם ל-Experts בארגון - אם זה צוותי ה-DevOps או ה-Platform - וגם לצוותים שמפתחים, שבעצם הקוד שלהם רץ על גבי Kubernetes, אבל מטבע הדברים הם פחות מכירים לעומק את הכלי.
    • אז אם זה כלים של Cluster Management, Cost Efficiency ו-Reliability של ה-Workloads over time ו-Access Control, הנחלת קונבנציות (Conventions) בארגון הפיתוח - זה בעצם מה שאנחנו נותנים ל-Expert-ים.
    • לחבר'ה שפחות מכירים, יש לנו Guided Troubleshooting Tool כזה, שבמידה ויש Incident, בא ועושה איתם Root Cause Analysis
      • יש פה Generative AI, לוגיקה קלאסית שמעורבת בתהליך.
    • ובעצם, אנחנו עוזרים לארגונים, ל-Enterprise-ים גדולים, להפחית את העומס הזה שנוצר מכיוון צוותי הפיתוח לכיוון צוותי ה-DevOps, ולאפשר להם להיות עצמאיים.
      • ועל הדרך גם ללמד אותם על Kubernetes, ולמה קורים דברים שאנחנו לא היינו רוצים שיקרו.
(רן) כן, אז חדי-האוזן בוודאי הבחינו בהגייה שלך . . . .
  • (ארז) כן, מתנצל על זה מראש . . .
(רן) אז קודם כל, נשאלת השאלה- אם Kubernetes או קוברנטיקס? אז ובכן, אחת ולתמיד - זה Kubernetes.
אבל כן, אכן כותבים את זה קצת מוזר, וגם דיברנו על זה, אני חושב, לפני די הרבה פרקים, על זה שהמקור הוא ביוונית, וזה למעשה, מה זה? זה גלגל ההגה? [פרק 353 עם Istio]
(אורי) של הספינה, כן.
(רן) של הסירה, של הספינה. כן - אני חושב שיש פה חובלים שיודעים להנהן בראשם.
(אורי) חובלים יוונים.
(רן) חובלים יוונים, לא סתם - מהמקור!
אז אני חושב שיצא לנו לא מעט לדבר עם נתי שלום [לאחרונה ב-489 carburetor 38], שהוא גם לא מעט מדבר על נושאים בתחום הזה - והוא אמר שהרבה חברות למעשה לוקחות תשתית כמו Kubernetes, ובונות מעל זה PaaS. זאת אומרת, בונות מעל זה איזושהי פלטפורמה ל-Deployment של התוכנה שלהן . . .
(אורי) דיברנו על כל ה-Platform Engineering שבא מעל זה . . . . [445 Carburetor 33 - platform engineering]
(רן) . . . . בדיוק - ואני יודע, זה משהו שגם נעשה ב-Outbrain, וזה נעשה גם בחברות אחרות - אבל זה לא מה שאתם עושים ב-Komodor. זאת אומרת, אתם לא בונים PaaS לחברות . . .
  • (ארז) לא, למעשה אנחנו מה שנקרא Day One או Day Two.
    • בעצם, מרגע ה-Provisioning של ה-Cluster ופרישת ה-Workloads על גביו, אנחנו עוזרים לחברות לתחזק את “המפלצת הזאת” שנוצרת לפעמים לאורך זמן.
    • ושוב - לאפשר לארגון לעבוד בצורה שיותר Efficient, Self-Sustained, והייתי אומר “נורמלית”, בתוך כל הכאוס הזה, שעלול להיווצר ב-Cluster-ים מאוד גדולים.
(אורי) אז אתם מוצר או Service - או שניהם?
  • (ארז) אנחנו למעשה מוצר SaaS - יש לנו Agent, שלקוחות מתקינים על ה-Cluster שלהם.
    • ובעצם החל מאותו רגע, אנחנו מתחילים להזרים Data אלינו - ותוך שעות עד ימים מתחילים לנפק Insights.
      • זה, הייתי אומר, ה-Value היותר long-term-י.
  • בנוסף לזה, אנחנו סוג של “Gate ל-Kubernetes
    • אז אם לדוגמה אתה רוצה לנהל הרשאות גישה של משתמשים across clusters, ויש לנו לקוחות עם מאות Cluster-ים, אז בעצם אנחנו עוזרים למסד את הדבר הזה ולנהל אותו.
(אורי) כשירות או כמוצר?
  • (ארז) כשירות? אני לא בטוח שאני מבדיל בין שני המושגים האלה - זה מוצר שהוא שירות, כלומר...
(אורי) אוקיי.
  • (ארז) . . . . נכון, זה מוצר SaaS-י, בעצם אתה ניגש אליו...
(אורי) לא, לא - אני אומר “כשירות”, זאת אומרת - יש אנשים מאחורי זה? או שיש . .
(רן) . . . . עד כמה זה High-Touch או לLow-Touch?
  • (ארז) לא - הכל נעשה בצורה אוטומטית לחלוטין.
    • כמובן שאנחנו מאוד קשובים ללקוחות, ואם יש דקויות לפה או לשם אז אנחנו ניגשים ועוזרים ומסבירים.
      • לפעמים אפילו עושים שינויים במערכת.
    • אבל אין פה איזה Human Intervention במגע גבוה.

05:50 בחזרה לעתיד / למה אנחנו צריכים את כל זה?

(רן) אוקיי, אז אולי אחר כך גם נחזור לעוד כמה דברים ש-Komodor עושים - אבל זה הזמן לדבר על Kubernetes.
אז בואו נחזור אחורה בזמן - משהו כמו ה-17, 16, אולי אפילו 20 שנה. אני אספר לכם שבצעירותי, כשעוד היה לי שיער שחור לחלוטין . . .
(אורי) . . . כשעוד היה לך שיער . . .
(רן) . . . כשעוד היה לי שיער ברוב חלקי-ראשי, ופחות בשאר הגוף, אז יצא לי לעבוד ב-Google - ושם הייתה מערכת פנימית שקרו לה Borg. וזו הייתה מערכת שיודעת לפרוש שירותים, לייצר רפליקות (Replications) של שירותים, להריץ Job-ים, Load Balancers, Monitoring - “מכל הבא ליד”.
וכשסיימתי את העבודה שם ויצאתי החוצה, חיפשתי משהו כזה - ולא היה, במשך כמה שנים.
וכאן, ארז מצטרף לסיפור . . .
  • (ארז) כן. אז אני אשמח להתחיל את הסיפור דווקא במפגש הראשון שלי עם Kubernetes, בעצם אזור שנת 2015.
    • הצטרפתי בתקופתו ל-Nanit, ממש עובד רביעי-חמישי - וכבר היו בנויים כמה Containers ב-Docker, והיה צריך להחליט איך אנחנו עושים אורכסטרציה (Orchestration) לכל הדבר הזה.
  • בתקופתו היו שני שירותים עיקריים שמציעים פתרונות -
    • הראשון היה AWS ECS, שלמעשה קיים עד היום.
    • והשני היה Kubernetes - שהוא היה ממש “בחיתוליו”: לדעתי גרסה 1.0.2, גרסה ממש ראשונית.
  • ובעצם, המשימה הראשונה שלי הייתה להבין איך אנחנו הולכים לנהל ב-Long Term את כל ה-Docker Containers וה-Services שלנו, שהולכים להיווצר במהלך זמן חיי החברה.
(רן) אז קודם כל, אולי למה אנחנו צריכים את כל זה - ואחר כך גם נחבר לסיפור הנוגע ללב, אני חייב לומר, שלי על Borg . . . אז אם אתם, כל מה שיש לכם זה איזשהו, לא יודע, איזשהו Web Service, או משהו שהוא ככה Singleton, מאוד פשוט - כל מה שאתם צריכים זה אולי, רחמנא ליצלן, איזה FTP או סתם ככה SSH: הולכים ל-Server, מרימים איזשהו משהו וזה רץ, הכל טוב ויפה.
במציאות, צריך לפחות שניים מכל דבר, נכון? ויש איזשהם בדרך כלל Microservices, אצל הרבה חברות, שמדברים אחד עם שני . . . זאת אומרת, צורת ה-Deployment היא מורכבת, ואם תעשו את כל זה באופן ידני, אתם כנראה תטעו באיזשהו מקום, וזה מאוד קשה לניהול.
כאן בא Kubernetes ועוזר לנהל את כל זה. זאת אומרת, זה לא רק לבוא ולהתניע את ה-Container, אלא זה גם לנהל את כל ה-Life cycle של מה קורה אם אחד מהם מת, מה קורה אם צריך לעשות Deployment וכו'.
אז זה הצורך ב-Kubernetes. אוקיי - ואז אתה אומר שהייתם צריכים לבחור בין, נגיד, ECS ו-Kubernetes, והלכת על הילד החדש בשכונה?
  • (ארז) כן, בעצם מתוך המחקר שעשיתי, גיליתי שאם כמה זה ששני ה-Service-ים האלה, או השירותים האלה, או הפלטפורמות האלה, הן פלטפורמות צעירות - Kubernetes בעצם הציע המון דברים שהם סוג של “Batteries Included”
    • כמו Log collection, Metrics collection - כבר בשלבים המאוד ראשוניים שלה.
    • ו-ECS הרגיש מאוד “בוסרי” באותו שלב.
    • ולכן גם בעצם קיבלתי - וקיבלנו - את ההחלטה להמשיך עם Kubernetes.
    • החלטה שבתקופתו לא הייתה טריוויאלית או Obvious בכלל - ולשמחתי זה מאוד השתלם לנו.
  • חייב להגיד מילה לעניין ה-Complexity של ה-Deployments - אז יש בלוג-פוסט מאוד מוכר והומוריסטי של CircleCI בשם “It's the future”
(רן) אולי אחד הדברים שמי שיהיה באזור והכיר את Kubernetes בטח הרגיש, זה שהיא הייתה מערכת מאוד מאוד בוסרית. אתה אומר שהיו כמה “Batteries Included”, אבל מצד שני לא הכל עבד As-Spec, והדברים זזו, וגם אם משהו עבד, בגרסה הבאה פתאום זה משתנה . . . .
  • (ארז) נכון.
(רן) . . . . אז ככה שנדרש, בוא נאמר, אומץ רב, כדי לבוא ולאמץ מערכת כזאת בסביבת Production, בשלבים האלה.
אבל ההימור, כמו שאתה אומר, הצליח לכם.
(אורי) היא גם הייתה מאוד, ככה, “Strict” באיך שעובדים איתה, לא?
  • (ארז) היא הייתה אפילו מאוד מתסכלת, באיזשהו מובן. יכול לתת כמה דוגמאות . . . .
    • לדוגמא, Resource ה-Deployment, שהוא, הייתי אומר, אחרי Pod, כנראה ה-Resource הכי מוכר ונפוץ היום ב-Kubernetes, לא היה קיים בגרסאות הראשונות.
    • ולמעשה, חלק מה-Script-ים שאנחנו בנינו, היו מורידים ReplicaSet אחד ומעלים ReplicaSet אחר, כדי לעשות פרישה של גרסה חדשה.
(רן) כלומר, אם היית רוצה לעשות Deployment לגרסה חדשה, לא היה את הקונספט הזה שנקרא . . . שהיום קיים ב-Kubernetes ונקרא Deployment - היית צריך לייצר משהו כזה מה-Building Blocks שהיו קיימות אז, שהיו ReplicaSet. גם היום קיימות - אבל יש מעטפת, יש אבסטרקציה (Abstraction) קצת יותר גבוהה.
    • (ארז) לגמרי. אבסטרקציה, הייתי אומר כמעט מושלמת, נכון. היום, כשאני פורש איזשהו Service ב-Kubernetes, אז יש לי את כל השירותים.
      • עד כדי להחליט כמה אחוז מה-Workload שלי אני מוכן שיהיה Unavailable במהלך זמן פרישה.
      • שזה, הייתי אומר, מאוד Advanced, בטח יחסית למה שהיה אז.
    • כל האיחסונים של ConfigMap ו-Ingress להחצנת שירותים בעצם - לא היו קיימים.
  • ואם זה שאמרתי שאולי זה היה קצת מתסכל, אני חושב שגם זאת הייתה הזדמנות נפלאה לייצר המון Open Source.
    • ובאמת ייצרנו המון המון Open Source, כמעט לכל הדברים והכלים שנבנו במהלך הדרך.
      • אם זה Helm charts, שזה בעצם היכולת לעשות Injection של variables ל-Templates.
      • אם זה Ingress, שזה היכולת שלי להחצין איזשהו Load balancer, שמכווין ל-Internal Services וכו'.
  • אז אני חושב שבאמת עם כל הקושי, גם הרווחנו המון מהדבר הזה - אני אישית גם.

12:01 להשתמש נכון / איך אני יודע שאני צריך אחד כזה?

(רן) כן, אז בסדר - אז נחזור רגע להיסטוריה: אז אמרנו ש... זאת אומרת לא אמרנו, אבל נגיד עכשיו - למעשה, Kubernetes נולד מתוך איזשהו פרויקט פנימי שהיה קיים ב-Google, שנקרא Borg. באיזשהו שלב, Google החליטו שהם רוצים לייצר גרסה חיצונית - זה לא אותו Codebase, אלא גרסה חיצונית שדומה לאותה מערכת - ולתת אותה לעולם.
יש לך מושג למה? כאילו, מה האסטרטגיה פה?
  • (ארז) אז אני חשבתי על זה לא מעט, ואני חושב שזה מאוד מקביל לשחרור של Android.
  • בעצם, המטרה היא פה לפרסם פלטפורמה שהיא חינמית והיא Cloud-agnostic
    • ובדרך הזאת, Google לדעתי קיוותה להיכנס לשוק ה-Cloud Providers, על ידי זה שהם מאפשרים העברה מאוד קלה של Workloads מ-Cloud אחר אליהם.
    • כי Kubernetes הוא בעצם שכבת האבסטרקציה לאותם Workloads - וזה משהו שעובד.
    • (רן) Anti-Lock-In . . . .
    • (ארז) בדיוק, Anti-Vendor-Lock . . . .
(רן) ואם ככה, אז כאילו, אתה יודע - מתבקש ש-AWS לצורך העניין, לא כל כך יאהבו את Kubernetes, אבל היום התמונה קצת שונה, נכון? היום אתה רוצה Kubernetes, אתה לוחץ על כפתור - הוא מריץ Script קטן ויש לך Cluster בכל Cloud Provider שמכבד את עצמו, וגם כנראה באלה שפחות מכבדים את עצמם . . . . זאת אומרת, זה מאוד מאוד נפוץ.
יחד עם זאת, זה עדיין לא פשוט להשתמש בו . . . זאת אומרת, אולי קל להתניע אחד כזה, אבל להשתמש בצורה נכונה - זה לא קל.
  • (ארז) נכון, אני חושב שצריך להכיר - כמו כל כלי שהוא מורכב, הוא בעצם סוג של פלטפורמה ל-Distributed Execution של קוד.
  • בגלל שהבעיה היא כל כך קשה, גם הפתרון מצריך המון ידע והעמקה וההבנה של מה כלי הזה מאפשר לנו.
  • אז יש המון דברים שכדאי שנכיר. נתחיל לעבור על זה?
(רן) כן. אז אולי שאלה הראשונה זה מתי אני צריך Kubernetes? כלומר, איך אני יודע שאני צריך אחד כזה?
  • (ארז) אז הייתי אומר שהיום, בזכות העובדה ש-Kubernetes הוא כל כך נגיש וקל להקמה ויש Ecosystem כל כך רחב סביבו, אז באמת כל דבר שהוא יותר מ-Single Service, כבר הייתי מעלה היום Cluster ופורש את ה-Workload שלי עליו.
    • כמובן, בהנחה שזה משהו שמשרת לקוחות, ומאוד חשוב לנו שהוא יהיה Highly Available ו-Robust ועם Visibility על הדברים.
    • אני חושב שזה היום יחסית No-Brainer, באמת.
(רן) כן. ואולי הזכרנו את זה מקודם - אם אתם מפחדים להיות נעולים אצל אחד מה-Provider-ים, אז Kubernetes יכול לעזור. דרך אגב, זה לא פתרון מושלם - עדיין יש לא מעט ערך מוסף שה-Provider-ים, זאת אומרת, Google ו- GKS [GKE] ו-EKS וכל זה נותנים. אז זה לא אפס, אבל עדיין זה פחות מ-100.

14:57 בואו נדבר קצת על Best Practices

אוקיי. אז החלטתי שאני רוצה Kubernetes אצלי בגינה - בואו נדבר קצת על Best Practices. זאת אומרת, מה אני כאיש Infrastructure או מה אני כמפתח, צריך להכיר, שיעשה את החיים יותר טובים.
  • (ארז) סבבה. אז דבר ראשון, אני חושב שעוד פעם מאוד Obvious, אבל כן להשתמש ב-Managed Solutions.
  • דיברנו קצת על תחילת הדרך - אז באותה תקופה, כדי להרים Cluster, היית צריך להריץ cube-up.sh עם מלא Environment Variables, ולהחזיק אצבעות . . .
(רן) . . . להתפלל ל-Kelsey Hightower שהכל יעבוד . . .
  • (ארז) ממש, ממש. זה היה Kubernetes the hard way”, אבל “This is the only way also” - וזה היה בעייתי.
  • היום, בעצם כל Cloud Provider שמכבד את עצמו, וגם אלה שפחות, מציעים שירות שהוא מאוד נגיש.
    • גם ב-Provisioning - יש לך Control Plane עם Auto-Scaling ו-Full Visibility ו-Resiliency.
    • ואתה לא רוצה פשוט להיכנס לכאב ראש הזה.
  • אז אני חושב שהדבר הראשון כשבאים להקים, זה באמת לבחור את ה-Cloud Provider, שכנראה כבר עובדים בו
    • ופשוט להשתמש ב-Managed Solution שלהם כדי להרים את ה-Control Plane.
    • זה נראה לי התחלה טובה.
(רן) כן, כשאתה אומרת Control Plane - אתה מדבר על “השלד”, שעליו אפשר אחר כך להרים את ה-Workload עצמו, את ה-Container-ים, את ה-Pod-ים . . .
  • (ארז) כן, למעשה אולי משפט על זה - אז בעצם ל-Kubernetes מחולק ל-Data Plane ו-Control Plane.
    • ה-Control Plane זה כל ה-Internal Tools, שעוזרים ל-Kubernetes לעבוד,
      • אם זה ה-Scheduler שלו, אם זה ה-Kubernetes API, אם זה ה-ETCD, שהוא למעשה ה-Storage של כל ה-Resources שלנו.
    • וה-Data Plane - אלה ה-Node-ים שעליהם אנחנו, “ה”User-ים” במרכאות כפולות, מריצים את ה- Workload-ים שלנו.
  • אז בעצם, ה-Managed Services - הם עוזרים לך להקים ולתחזק ולעשות Auto-Scale לכל מה שנקרא “ה-Control Plane”.
    • ואז אתה יכול להתעסק ב-Business שלך וב-Workloads שאתה מפתח.
(אורי) זה לא מין תופעה כזאת של “אוקיי, קם Kubernetes. בהתחלה הוא היה פשוט, אחר כך לאט לאט . . .” - אתה יודע, כשרוצים אז מצטרפים עוד ועוד פיצ'רים לדבר הזה וזה נהיה מסובך. ואז מייצרים מעל זה Managed Services - ועכשיו אנשים מתחילים לשתמש ב-Managed Service, וכשהם שמשתמשים אז הם רוצים עוד פיצ'רים,
ואז נהיים לו מלא פיצ'רים - ואז עוד פעם נהיה . . . “Managed Service מעל ה-Managed Service”?
  • (ארז) זו שאלה טובה . . .
(אורי) . . . מהתהליך הזה . . . אתם מכירים את זה, שבהתחלה אמרו כשקם ה-Cloud, “נגמרה העבודה לאנשי
ה-Ops”, ואז . . .
(רן) . . . “וואי וואי, כמה עבודה יש ב-Cloud” . . .
  • (ארז) כן, פשוט העברנו אותה ל . . .
(אורי) בדיוק . . . ואז פתאום Kubernetes נהיה העבודה של ה-DevOps, ואז נהיה מן Managed Service אבל גם הם נהיו מסובכים . . . בקיצור, תמיד יש עבודה לחבר’ה האלה, להתעסק במה שהמפתחים לא רוצים להתעסק בזה . . .
  • (ארז) אז אני חושב שה-Complexity שהתווסף ל-Kubernetes Over the years הוא למעשה דווקא לא ב-Control Plane אלא יותר ב-Data Plane.
    • כלומר, באפשרויות שלנו, בתור User-ים של Kubernetes ולא בהכרח בתור אלה שמנהלים את ה-Control Plane, להשתמש בו.
    • ולרוב הוא נולד כתולדה מצורך.
  • אז באמת, האבולוציה היא כזאת שהם התחילו מ”הכי Lean שיש”,ולמעשה הוסיפו Complexity לפי הצורך ולפי הצרכים הארגוניים של ארגוני תוכנה גדולים.
  • ואני שמחתי מאוד להינות גם מהדברים האלה במהלך הדרך.
    • כלומר, הרבה דברים שאנחנו חיכינו או עשינו Hacks או Workarounds כדי להקים, פתאום בגרסה הבאה של Kubernetes כבר היו Native Resources ונוהלו על ידו.
  • אז דווקא הייתי אומר שמבחינת Complexity, אני למעשה יכול להשתמש היום ב-Kubernetes כמו שהשתמשתי בו לפני שש-שבע שנים, כי רוב ה-Main Objects הם Stable כבר מאז.
    • אבל אם יש לי צרכים ייחודיים, שהם הייתי אומר Outstanding, אז גם יש לי את האפשרות להשתמש בדברים שהם יותר Complex ולעשות יותר Tuning לפרישות ול-Workloads שלי.
(רן) אבל אני גם חושב, אורי, שמה שאתה מתאר זה איזשהו מעגל אופייני של שימוש בטכנולוגיה. אתה יודע - היא מפשטת, ואז על זה בונים ומסבכים, ואז היא שוב משהו מפשטת . . .
(אורי) . . . הבעיה היה משתמשים . . . כי יש משתמשים - יש בעיה. הבעיה היה העולם - הם רוצים פיצ'רים . . .
(רן) כן, כן . . . אבל כאילו, אני אומר שזה קורה עם המון טכנולוגיה. זאת אומרת נכון שבמקרה הזה דיברנו על Kubernetes, אבל זה קורה כמעט עם כל טכנולוגיה - אם זה טלפונים חכמים, אם זה LLM-ים, כל דבר שאתה תדבר עליו - אני חושב שזה נכון.

19:40 על Resource Requests, Limits, שכנים רועשים ו“הסכרת של ה-Workloads”

אוקיי, בוא נחזור קצת ל-Best Practices - אז אמרת: בתור התחלה, אל תפרשו בעצמכם את ה-ETCD ואת כל ה-Control Plane, תשתמשו במשהו מוכן - ויש כאלה, טובים וחזקים. תשתמשו פשוט ב-Cloud Provider שלכם.
זה עדיין . . . זאת אומרת, אמרנו - זה אולי 20% Lock-In, אוקיי? אבל זה לא 100.
אוקיי - מה עוד?
  • (ארז) אז בוא נגיד שהעלינו את הControl Plane - עכשיו בעצם אנחנו צריכים להתחיל להתעסק ב-Data Plane, שזה ה-Workloads שאותם אנחנו מפתחים ומריצים בענן.
  • אז אני חושב שהדבר העיקרי שכדאי להכיר וגם להשתמש ב-Kubernetes זה בעצם היכולת להגדיר Resource Requests ו-Limits.
    • משפט על זה - אז Resource Requests בעצם עוזר ל-Kubernetes להבין כמה Resources - אם זה CPU או Memory, אתה צופה שה-Process שלך ידרוש.
    • ובהתאם לזה לעשות Scheduling נכון ל-VM-ים ב-Data Plane שלך.
(רן) כלומר, אם אתה פורש איזשהו Service, אתה צריך להגיד מראש - לנחש, או אולי ככה, לעשות “Guesstimation” של כמה CPU תרצה להשתמש וכמה זיכרון . . .
(אורי) . . . .או ניסוי וטעייה . . . אתה רואה שאתה לא משתמש בכל מה שחשבתם.
(רן) . . . מה שנקרא Sizing . . .
  • (ארז) נכון. ברוב המקרים מאוד קשה לצפות את הדברים האלה מראש.
    • ולכן אתם צודקים - מה שעושים זה שפורשים את זה בענן, נותנים לזה לרוץ X זמן, ואחרי זה בעצם לוקחים איזשהו Percentile של השימוש, כדי גם לאפשר מרווח.
(רן) אבל אני חושב שזאת מסקנה יפה ונכונה להמון סוגים של Resource-ים. זאת אומרת, לפעמים ה-Resource זה API שאתה חושף החוצה ללקוחות - וגם את זה תרצה להגביל. אתה יכול לקבוע “לא יותר מ-5,000 Request-ים בשנייה”, או Whatever. אם זה גודל של קובץ שאפשר לעשות לו Upload . . . נכון, אתה לא מדמיין שהם יעלו לך קובץ של 1 Tera, אבל בוא - תגביל. אז “לא יותר מ-Mb500”. לכל דבר תשימו מגבלות - כולל לשירותים שלכם, כי גם אתם תפתיעו את עצמכם באיזשהו יום ותיצרכו יותר זיכרון ממה שחשבתם או שתיצרכו יותר CPU ממה שחשבתם, ואתם כנראה . . . .
קודם כל, אתם רוצים לעזור לCluster - לשים את השירות במקום הנכון, שיש לו מספיק ממה שהוא צריך. ודבר שני - לדעת כשחרגתם ולדעת לנהל את זה . . .
  • (ארז) להגביל את החריגה.
(רן) כן - “שלא תפריעו לשכנים שלכם”, מה שנקרא . . .
(אורי) גם חשוב לדעת שזה - בסוף זה “קוביות של טטריס” שה-Cluster משחק איתן - ואם תיקח קוביה גדולה מדי, יהיו לך פחות אפשרויות לפרוש.
  • (ארז) נכון, אתה תהיה פחות Efficient כנראה.
  • רק מילה על העניין של Request-ים ו-Limits - נכון, אז Request משתמשים, ה-Scheduler משתמש בהם.
    • ו-Limits ממש מגבילים את ה-Process שלנו, וצריכים להיות מאוד זהירים פה.
      • כי אם אנחנו מגיעים ל-Memory Limits, אנחנו בעצם נחטוף Restart OOM-Kill.
    • אבל לדעתי יותר גרוע זה להגיע ל-CPU Limits - שם אנחנו חוטפים CPU Throttling, ולמעשה all hell break loose . . . [ד”ש לקבוצת ה-Power ב-Intel . . . .]
  • חוויתי לא מעט פעמים במהלך הקריירה שלי Process-ים אפילו תשתיתיים שמגיעים ל-CPU Limit, חוטפים Throttling - ומאוד קשה להבין, אם לא מודעים, אם אין Awareness לעובדה הזאת, מה לעזאזל קורה.
    • כי למעשה, כל השמה של משתנה עלולה לקחת פתאום 20 שניות - ואלה דברים שבדרך כלל אנחנו לא צופים.
    • לרוב אנחנו צופים האטה כתוצאה מ-I/O או כתיבות לדיסק - לא מ-Execution של קוד לוקלי.
    • ו-CPU Throttling זה . . . אני קורא לזה “הסכרת של ה-Workloads” - צריך לשים שם את העיניים.
      • להציב אותם - אבל גם לדעת להיות Aware ולנטר את הדבר הזה, כדי שלא נפגע.
(רן) כן, אבל פה אולי חשוב לדבר על למה בעצם מעניין אותנו על “השכנים הרועשים” - כי למעשה אותם Pod-ים,
אותם Container-ים שעליהם דיברנו - אוקיי, Pod זה קצת יותר מ-Container, אבל לא נכנס לשם - למעשה, הם פרושים הרבה פעמים על אותה חומרה, אבל, זאת אומרת, הם שירותים שונים. לוקחים שרת מאוד מאוד גדול, מחלקים אותו - דרך אגב, זה גם כמובן מה שה-Cloud Providers בעצמם עושים, אבל גם בתוך Kubernetes - לוקחים חומרה, מחלקים אותה לפרוסות קטנות יותר, ועל כל פרוסה שמים איזשהו Pod, ואם Pod אחד “משתולל”,
אז הוא יכול להפריע לכל האחרים.
  • (ארז) כן, תופעה שנקראת “Noisy neighbor” - “השכן הרועש”.
  • אפרופו Komodor - אז יש לנו גם מנגנון Detection לדברים האלה.
    • כלומר, Pod שה-Execution שלו נפגע, למרות שהוא לגמרי עומד ב-Request-ים וב-Limit-ים שהציבו לו, רק כי Pod שכן שלו - היה לו את אותו VM בטעות, והחליט להתפרע.
(רן) אז יבואו חכמים וגידו “רגע, אז למה צריך שכנים?! - אז תשים Service אחד על כל Host אחד!” . . . “מה הבעיה? למה אתה צריך לקבץ אותם?”
  • (ארז) אז אני חושב שפה...
(אורי) . . . . כי “מה הועילו חכמים בתקנתם”, נכון? . . .
(רו) . . . אנחנו כל כך צדיקים היום, הא?
  • (ארז) אני חושב שהניסיון פה באמת . . . הייתי אומר שני דברים:
    • אחד - לעשות אבסטרקציה ל-VM-ים, בסדר? התשתית היא רק ה-Vessel שעל גביו אתה רץ, ואתה לא באמת חייב להכיר איזה סוגי Node-ים וכמה CPU.
      • הכל נכנס לאיזה Blob אחד - כמו S3 ל-Blob Storage, אז הייתי אומר CPU ו-Memory Storage.
    • והדבר השני זה Cost Efficiency - בעצם, זה שאנחנו יכולים לחתוך את ה-Workload שלנו לחתיכות קטנות יותר.
      • אם דיברת על מחסן או טטריס, אז זה בעצם מאפשר לנו לקבל הייתי אומר, “כיסוי יותר מלא” של ה-Resources שאנחנו משלמים עבורם.
(רן) כן, אז אם נגיד פעם היה לכם One service per VM, אבל ה-VM היה מגיע, בימים טובים, ל-20% CPU או 15% זיכרון - אז פה אתם יכולים להיות יותר יעילים, בלי לעבוד כל כך קשה. זאת אומרת, לתת ל-Kubernetes לעשות את העבודה של הצמצום בשבילכם.
  • (ארז) לגמרי.
(רן) אוקיי, אז אמרת Resource Request ו-Resource Limit, שזה דברים דומים אבל לא בדיוק אותו דבר: Request זה כמה אני צריך ו-Limit זה מתי “תחנוק אותי” - ולמעשה, ה-Best Practice הוא להשתמש בשניהם.

25:42 כשקשה - קשה לכולם

(רן) אוקיי, אז דיברנו בינתיים על שניים, אולי שניים-וחצי - בואו נעבור לדבר הבא. מה עוד כדאי לעשות?
  • (ארז) כן, אז זה מאוד חשוב להכיר את כל נושא ה-Probe-ים ב-Kubernetes, שזה בעצם היכולת שלנו להגדיר ב-Deployment שלנו, ב-Container, איך Kubernetes יודע שהוא חי ובריא.
  • בעצם, יש שני סוגים של Probe-ים כאלה - אחד נקרא Liveness Probe והשני Readiness Probe.
    • כש-Readiness Probe - במידה וה-Pod שלנו לא עונה, לדוגמה, לאיזשהו TCP Socket או כל בדיקה אחרת.
      • זה בעצם יוציא את אותו Pod מה-Service, והוא יפסיק לשרת בקשות.
      • שזה, הייתי אומר, פעולה שהיא פחות Intrusive.
    • ו-Liveness Probe - במידה ואנחנו לא מצליחים לעבור אותו, ה-Container שלנו יחטוף Restart.
  • אז ההמלצה היא כן להשתמש בשני המנגנונים האלה, אבל בכל מה שקשור ל-Liveness Probe - צריכים להיות זהירים.
    • כי בהרבה מהמקרים, בעצם מה שקורה זה שה-Pod שלנו הוא לא בריא
      • מאיזושהי סיבה - זה גם יכול להיות כתוצאה מאיזשהו כשל Infra-אי, כמו Database או Redis או Queue.
      • וה-Restart שלו בעצם יוצר אפקט של Cascading Failure, כי לפעמים Process-ים שעולים צריכים לחמם Cache וצריכים לפתוח Connection-ים ל-Database, וכל מיני Warm-up-ים כאלה . . . .
    • (רן) כמו שאומרים - כשקשה, קשה לכולם, אז אל תעשה את זה קשה יותר . . . .
(רן) אבל אולי, רגע, נחזור אחורה - מה המשמעות, למי שלא מכיר: מה זה Liveness ומה זה Readiness? אז בעצם,
כשכותבים שירות, ברוב המקרים אתם רוצים יותר מ-Instance אחד שלו, אתם לא רוצים שיהיה רק אחד. אז אם זה ששמים זה מאחורי Load Balancer או אם זה איזשהו Job שרץ ברקע, אז זה משהו שנגיד קורא Job-ים מ-Queue ומריץ. אבל אתם רוצים יותר מאחד כזה, כי כל אחד יכול “להתאדות” מתישהו, אז תמיד כדאי שיהיה יותר מאחד.
עכשיו, כשאחד כזה עולה - פרשתם נגיד, או עשיתם Restart, ויש לכם אחד כזה חדש - אתם רוצים לבוא ולהגיד מתי הוא מוכן להתחיל לעבוד, מתי להכניס אותו ל-Load Balancer או מתי הוא יכול להתחיל לקרוא מהתור וכו’, ולצורך זה, באמת מוגדרים ה-Probe-ים האלה.
אז Liveness זה אומר “אני בחיים. אולי אני לא אעשה את הדבר הנכון, אבל אני בחיים - רגע, אל תהרוג אותי” . . . .
(אורי) . . . אני - ה-Container. זה עוד לא אומר שה-Service בחיים . . . . הפוך זה ה-Readiness, “אל תהרוג אותי” . . .
(רן) אוקיי, סליחה - זה ה-Readiness, וה-Liveness זה אומר “אני מוכן - תביא!”. תביא עבודה, תן לי Traffic . . .
(אורי) לא . . . הפוך.
(רן) אז צדקתי מהתחלה! אז רגע . . .
  • (ארז) שני ה-Probe-ים האלה יכולים להצליח או להיכשל.
  • כש-Pod עולה, הוא צריך לעבור Readiness Probe, כדי להתחיל לשרת בקשות.
    • הוא גם יכול להיכשל במהלך ה-Lifetime שלו, ולצאת ולהיכנס שוב לאותו סט של Pod-ים, שבעצם מנגיש לו את ה-ה-Service.
    • ו-Liveness Probe, מהצד השני, בעצם ברגע שהוא נכשל הוא ב-Restart.
      • ואותו Pod יכול לעבור גם כמה Restart-ים במהלך ה-Life cycle.
(רן) זאת אומרת, אם ה-Live שלי נכשל, זה אומר כאילו “תהרגו אותי” . . . “אין לי מה לעשות פה, אני לא מועיל יותר”
  • (ארז) “אני תקוע, אני צריך שמישהו יבוא לחלץ אותי”.
  • ו-Readiness זה “שים אותי שנייה בצד, תחזור אותי עוד כמה דקות, אני רגע עסוק”.
(רן) . . . “אני עסוק, רגע, אל תפנה לי Traffic . . . הנה, אני מוכן! עכשיו אני Ready!”
  • (ארז) בדיוק.
(רן) בסדר.
  • (ארז) אז רק לחדד פה, שהסכנה היא באמת בעיקר ב-Liveness Probe, בגלל ה-Cascading effect שנוצר כתוצאה מ-Restart-ים.
    • לא להשתמש בו Blindly, מה שנקרא.
(אורי) רגע, אני רוצה להבין משהו - יש קשר בין הקוד או ה-Service שרץ על ה-Container, לבין ה-Probe-ים האלה? זאת אומרת אני יכול להשתמש בהם, נגיד אם ה-Cache שלי עוד לא חם . . .
  • (ארז) לגמרי . . . .
  • אז למעשה, בוא ניקח Probe קלאסי, שדוגם איזשהו HTTP Endpoint בקוד שלך.
    • ואתה, בקוד שלך, באותו קוד של Endpoint, יכול להגיד “אני בודק שה-Connection שלי ל-Database בריא, ושחיממתי את ה-Cache ושהצלחתי להוריד קובץ קונפיגורציה מ-S3.
    • ורק החל מהרגע שאותם תנאים יתמלאו, אתה מכריז על עצמך בתור Ready, כלומר - “אני מוכן להתחיל להנגיש את השירות, לשרת לקוחות”.
(אורי) ואז בעצם, מבחינת המערכת - ה-Load Balancer, או מה שזה - ה-IP שלי “חי”.
  • (ארז) ה-IP הוא למעשה חי מרגע היווצרות ה-Pod , מוצמד IP לכל Pod.
    • השאלה היא האם אתה חלק מה-Target Group ב-Load Balancer, או לא?
    • זאת השאלה, זה ה-Readiness - אם אתה מוכן אז אתה חלק מה-Target Group, ואם אתה Not-Ready, אז אתה יוצא מה-Target Group.
(רן) יש מקומות שבהם ל-Readiness הזה גם קוראים Health, זה אומר “אני בריא ואני מוכן לשרת!”, כלומר - כמו שאמרת: “יש לי את החיבור ל-Database שאני צריך, יש לי מספיק זיכרון” . . . לא יודע, “טענתי מה-Cache, אני מוכן
עכשיו לקבל”, “פתוח לקבלת קהל” מה שנקרא.

30:21 איך הוא עושה Distribution לדבר הזה / Anti-Affinity, Taints & Tolerations

(רן) בסדר, עכשיו כתבת פה בסעיף D [בהכנות לפרק] מונח מאוד מעניין, שנקרא Anti-Affinity . . . ובכן?
  • (ארז) אז בעצם, דיברנו על ה-Scheduler של Kubernetes, שבסוף - יש לו אוסף מאוד גדול של Pod-ים
    • חלקם מאותו Service, חלקם מ-Service-ים שונים.
    • והוא צריך עכשיו להחליט איך הוא עושה Distribution לדבר הזה, כדי באמת להפוך את אותו Service ל-Highly Available, Resilient, Fault-Tolerant וכל ה-Buzzwords האלה.
  • ובעצם, Anti-Affinity Rules מאפשרים לנו להגדיר ל-Scheduler איך לבזר נכון את אותם Pod-ים.
    • כש-Anti-Affinity Rule יכול להיות “אל תשים לי שני Pod-ים מאותו Service על Node יחיד”, הם יכולים להיות “אל תשים לי באותו Availability Zone”, אוקיי?
  • כלומר, יש לנו דרך להגדיר איך אנחנו היינו רוצים שה-Scheduler יבזר את ה-Workloads שלנו
    • כדי שבאמת אם יש עכשיו איזשהו כישלון Availability Zone, ב-AZ אחד ב-Amazon, אז בעצם יש לנו עוד שני AZs שכבר פרושים שם Pod-ים . . .
(רן) כלומר, הCluster, “באופן טבעי”, גם פרוש על פני מספר Availability Zones - ו-Kubernetes מבין את זה. הוא מבין את ה-Concept, הוא יודע. ואז, כשאתה פורש את השירות שלך, אתה אומר “תשים לי אחד בכל Availability Zone”, אין טעם לשים את כל השלושה באותו אחד, כי אין בזה טעם.
  • (ארז) אז מה שמעניין, דרך אגב, זה ש-Kubernetes לא באמת חייב להבין את זה.
    • אלא כל Node שעולה מקבל Label-ים מה-Cloud Provider, ולמעשה אתה יכול להגדיר Anti-Affinity Rules על Label-ים ואפילו על Label - Custom, שאתה שמת.
    • (רן) “שרירותיים” . . .
    • (ארז) כן, בדיוק.
    • (רן) אבל Out of the Box, כנראה אני מניח שעל פני ה-Cloud Provider יש גם את ההבנה הזאת, ואתה יכול בנוסף לייצר אחרים.
(רן) אוקיי, אז זה מה שנקרא Anti-Affinity. בסדר, אולי קצת . . .
  • (ארז) יש עוד איזה נושא שהוא טיפה קרוב . . . הוא לא בדיוק זה, אבל זה כל העניין של Taints ו-Tolerations.
  • קצת מורכב, אבל בעצם Kubernetes מאפשר לנו לשים Taint-ים, שזה סוג של סירחון, לפחות לפי התרגום שאני קראתי . . .
    • ורק Pod-ים שהם יהיו Tolerates את ה-Taint הזה יהיו Scheduled לאותו Node.
    • זאת נגיד דרך מעולה לעשות Scheduling ל-Pod-ים שצריכים GPUs רק ל-GPU Nodes.
    • או לבודד כל מיני Infra Workloads שהיית רוצה שירוצו לבד.
    • זה גם אחלה כלי . . .
(רן) כן, כלומר אוקיי - אולי לא הייתי קורא לזה “סירחון” . . . יכול להיות זה הפירוש, אולי הייתי קורא לזה “איזה טעמים” - איזה טעמים יש לזה: “יש לזה טעם של GPU - אני רוצה לרוץ על משהו עם טעם GPU” או “יש לזה טעם של High Network Bandwidth, אז אני רוצה לרוץ על משהו כזה”.
  • (ארז) בדיוק.
(רן) בסדר. עכשיו, זה Label-ים שה-Cluster Admin, לצורך העניין, שם על ה-Node-ים, כי כשהוא מרים את ה-Cluster, אז הוא מבין מה יש לו. ואתה, בתור מפתח שכותב את השירותים, אתה יכול לעבור ולהגיד מה אתה מעדיף.
מה קורה אם אין כאלה? מה קורה אם אין מספיק - מה ה-Kubernetes יעשה?
(אורי) . . . אם אין מספיק Resource-ים . . . .
  • (ארז) כן, אז בעצם - האמת שזו התנהלות ממש מעולה של Kubernetes.
    • כי Pod -ים שה-Scheduler לא מצליח לסקנג'ל (To Schedule) אותם לתוך Node-ים בגלל Insufficient Resources, והוא גם יודע להגיד למה, בעצם זאת ההזדמנות שלנו להטריג (Trigger) Auto-Scaling ב-Cluster ולהעלות עוד Node-ים.
  • ובאמת, Cluster Auto-Scaler ו-Karpenter - שהם הייתי אומר שני הכלים המובילים היום ל-Scaling של ה-Infra - הם משתמשים ב-event-ים האלה כדי להבין שצריך להוסיף עוד Resources לCluster, כדי לספק את הביקוש.
(אורי) אתה יכול לכוון אותם בצורה מסוימת? זאת אומרת, לתת High-water mark, Low-water mark . . .
  • (ארז) בדיוק. אז אפשר להגדיר Headroom, אפשר להגדיר מינימום, מקסימום . . .
    • אפשר להגדיר אותם פר AZ . . . כלומר, ממש “קונפיגורציה כאוות נפשך”.
  • באמת כלים מעולים, שפשוט מתממשקים לעובדה הזאת - ולא אמרנו את זה, אבל כדאי להגיד: אני חושב שאחד החידושים או באמת הדברים ש-Kubernetes הביא לעולם זה האיחוד של כל ה-Infra וה-Workloads תחת Unified APIs.
    • וזה בעצם מהווה כר פורה ל-Ecosystem מטורף, שפשוט משתמש במידע הזה וקורא וגם כותב אליו.
(רן) כן. פה, אתה יודע . . . זאת אומרת, כמישהו שמתעסק עם מערכות, לפעמים יש דילמה של מתי לייצר אבסטרקציה. כלומר, מתי לאבסטרקט (Abstract) את ה-Infrastructure מהמפתח, ומתי כן לחשוף.
נגיד, אתה לא תמיד רוצה לדעת על איזה סוג של CPU - האם אתה רץ על Intel, על AMD . . . . - זה לא תמיד מעניין אותך.
  • (ארז) נכון.
(רן) . . . אבל אתה אומר - אם זה מעניין אותך, אז אתה יכול לדעת. אם מעניין אותך איזה סוג של Network יש, אז אתה יכול לדעת, אבל זה לא תמיד אכפת לך.
  • (ארז) נכון. הם פשוט עשו עבודה מעולה בלהנגיש, כמו שאתה אומר, את האופציות.
    • ועדיין - לא להכיר אותם בכלל, ולעבוד בסדר.
    • שזה, הייתי אומר, ה-Sweet-Spot.

35:08 כמה מילים על Monitoring, על מה להסתכל ואיפה החברים מהגן

(רן) כן, בסדר, אולי ככה אנחנו לקראת סיום - אולי כמה מילים על Monitoring? על מה כדאי להסתכל?
  • (ארז) כן, אז דבר ראשון - Kubernetes, כמו שאמרתי, מחצין המון המון מידע בצורה סטנדרטית.
    • וזה מאפשר להמון כלי Monitoring לעלות.
  • היום, ה-Stack הרווח הוא kube-state-metrics, Prometheus, Grafana . . .
    • אפשר להתקין אותם ב-Helm Charts שהם Official מאוד בקלות.
    • אז אם הייתי צריך לבחור היום Monitoring Stack ל-Kubernetes - כ-In-House כמובן, שהוא לא חיצוני - כנראה שהייתי הולך עם הכלים האלה.
    • אז זה דבר ראשון.
  • עכשיו, לגבי על מה להסתכל - אז אני חושב שקצת עברנו על זה ב-Best Practices, אבל בעיקר על ה-Resource Usage.
    • בעיקר לשים לב ל-CPU ולהגעה שלו ל-Limits.
    • על Container Restarts - שאנחנו אולי נוטים להתעלם מהם, אבל הם עדיין איזשהו סימפטום של תופעה שלא רצויה, ותמיד יכולה להתגבר ברגעים הכי פחות מתאימים [גם בחלליות…].
  • ואם משתמשים ב-HPA - שלא דיברנו על זה, אבל זה הדרך של Kubernetes לאפשר לי לעשות Horizontal Scaling ל-Workloads שלי.
    • כלומר, לפי ה-Consumption - להחליט אם אני צריך יותר Pod-ים או פחות Pod-ים מאותו Service.
    • אז לשים לב שאם הוא מגיע למקסימום לאורך זמן - כנראה שאנחנו עם Insufficient Resources על אותו Service, ולכן כדאי לשנות שם את הקונפיגורציה (Configuration).
(רן) כן, אז אולי ממש ניגע בזה בקטנה - דיברנו על Auto-Scaling של ה-Cluster, עצמו לא דיברנו על Auto-Scaling של ה-Service-ים. אז למעשה, אפשר לעשות Auto-Scaling בשתי הרמות - זאת אומרת, אם ה-Service שלך נגיד אין לו מספיק Pod-ים, ואתה רוצה באופן אוטומטי להטריג (Trigger), זאת אומרת לייצר עוד, ואחר כך להוריד, כי חבל על הזיכרון ועל ה-CPU שלא צריך. אבל אם אתה עושה הרבה כאלה, אז מתישהו גם נגמר לך המקום ב-Cluster . . . ואז אתה צריך לייצר Auto-Scaling של ה-Cluster. ושני הדברים האלה, כמו שאמרת, זמינים ובאים באופן דיפולטיבי (Default) בתוך Kubernetes. אוקיי.
(אורי) אותי רק . . . נחזור שנייה להיסטוריה - הוא [Kubernetes.] לא תמיד היה פה, והייתה סוג-של . . . לפני שהוא הגיע, סוג של “מלחמת Provider-ים”, או נקרא את זה “פתרונות”. אני לא בטוח שהוא היה, נגיד, תמיד הכי טוב - אבל איכשהו, The winner takes it all, והוא נהיה סטנדרט . . .
(רן) רצית להגיד Mesos, רצית להגיד Nomad, רצית להגיד...
(אורי) כן, כל החבר'ה האלה - היום הם לא יודעים...
(רן) “החברים מהגן” . . .
(אורי) כן, אבל היום לא מכירים אותם - והוא רץ, ו...
(רן) כן, אז היו לא מעט - אז הזכרנו כמה: Mesos, Nomad, הזכרת מקודם את AWS ECS, שזה פחות או יותר באותה שכונה. יש את OpenStack, Docker Swarm, יש לא מעט . . . ובאמת, אני לא יודע מי מהם שרד. כאילו, חוץ מ-Kubernetes. זאת אומרת, ECS קיים . . .
(אורי) היה בו משהו, לדעתי - בקהילה, או ב-Google, שדחפו אותו, או...
  • (ארז) אני חושב שהוא באמת, באופן כן, הוא פשוט ייצר את ה-Feature set שהיה הכי נכון - לאותה תקופה.
    • וידע להתגלגל, כמו מוצר אג’ילי (Agile) של חברה מסחרית - ובגלל זה הוא ניצח.
    • הוא פשוט היה קשוב ל-Community, וידע להוסיף את הדברים הנכונים - בזמן הנכון, בצורה הנכונה.
    • וזה מה שקנה אותי לאורך הזמן.
  • ולכן, גם אני, החל מהרגע שעשיתי את ה-Research הזה ובחרתי ב-Kubernetes, לא הסתכלתי אחורה לשנייה.
    • כי באמת לא היה שום מתחרה בסדר גודל כזה, שידע לספק את הדברים.
(רן) כן. דרך אגב - זאת אומרת, הזכרנו פה שמות של מוצרים אחרים. הרבה מהם כתובים ב-Open source. זה לא אומר שלא השקיעו בהם כסף . . . משקיעים בהם הרבה מאוד כסף: גם ב-Kubernetes. זה Google וגם אחרים, וגם באחרים - ב-Mesos, ב-Nomad ואחרים - השקיעו הרבה מאוד כסף.
זה נכון שהם היו בקוד פתוח - אבל עדיין, צריך לפתח אותם. אז...
(אורי) לא, לא - זה תופעה חברתית כזאת, שיש בסוף מישהו שלוקח - Winner Takes it All.
(רן) לא, יש פה Network Effect, זה ברור, נכון. זה ה-Community, זה ה-Know-How, זה ה-Adoption מצד ה-Provider-ים. זאת אומרת, יש פה הרבה דברים, יש פה Network Effect משמעותי.
  • (ארז) דווקא אני חושב שפה ה-Adoption הוא באמת היה בעייתי - כי אני חושב שכל Cloud Provider ידע.
    • או לפחות Amazon, שהוא היה בתקופתו, באמת, לא יודע, 80% מה-Market - הם ידעו שברגע שהם עושים Adoption לדבר הזה, זה דווקא מעמיד אותם בסכנה.
(רן) נכון.
  • (ארז) הייתי אומר שדווקא Adoption היה נגדו באיזשהו אופן - אבל הם הצליחו בכל זאת.
    • פשוט כי זה היה הכלי הנבחר על ידי ארגוני DevOps.
(אורי) אני יכול להגיד שלנו ב-Outbrain - הלכנו איתו על On-Prem, אבל אחר כך כשרצינו להיות מסוגלים
לעבוד גם על Cloud Providers, זה היה די פשוט.
  • (ארז) מאוד . . .
(אורי) עוד פעם - “פשוט” זה לא, אבל... Doable בזמן סביר.
(רן) מקודם דיברנו על Lock-In - אבל פה אתה מדבר על Scenario של Hybrid, נכון? או שני Cloud-ים, או Cloud ו-On-Prem . . . אבל זה למעשה, זה אף פעם לא נורא פשוט - אבל זה כן מאפשר את היכולת הזאת [זכרונות מ-2019 - 382 Carburetor 27 - k8s and multi-cloud].
(אורי) לגמרי.
  • (ארז) זה מוריד קצת “מהכבלים האלה”, שקושרים אותך ל-Infra.
(אורי) כן. לפעמים, אבל כאילו - ב-On-Prem, אתה מסוגל להגיע לעומסים על מכונה מאוד רצינית. פתאום אתה עובר ל-Cloud, שגם ככה יש לו את ה-VM - וכאילו, החומרה לא ממש מנוצלת כמו שצריך, גם אם אתה מתאמץ. ופתאום, אני אומר לך “רגע, אנחנו לא . . . “, ממש, Provider-ים אומרים “אנחנו לא בנויים לעומסים האלה על Node או על...”.
  • (ארז) כן, אז ה-Coefficient של ה-Resource Consumption שלך משתנה, כשאתה עולה ל-Cloud, נכון?
(אורי) כן - אז זה משלם יותר . . .

41:26 עוד קצת על Komodor לסיום

(רן) כן, בסדר. אנחנו ככה ממש לקראת סיום - אולי עוד כמה מילים על Komodor? קצת על החברה, כמה עובדים אתם? איפה אתם נמצאים? את מי אתם מגייסים - אם אתם...
(רן) אולי שווה לציין - ה-Komodor הוא ב-K - ולא ב-C, כמו שאולי התרגלתם . . .
  • (ארז) זה ה-Theme שלנו, דרך אגב - יש לנו עוד דברים ב-K . . .
(רן) אוקיי, כן. כן, אז זה לא המחשב משנות ה-80 - זה Komodor ב-K, אז כשאתם מחפשים, זה שם.

טוב, תודה רבה - ושיהיה לכם בהצלחה. להתראות.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!
  continue reading

156 епізодів

Alle episoder

×
 
Loading …

Ласкаво просимо до Player FM!

Player FM сканує Інтернет для отримання високоякісних подкастів, щоб ви могли насолоджуватися ними зараз. Це найкращий додаток для подкастів, який працює на Android, iPhone і веб-сторінці. Реєстрація для синхронізації підписок між пристроями.

 

Короткий довідник

Слухайте це шоу, досліджуючи
Відтворити