הש

קר הגדול ביותר בעולם הטכנולוגיה של 5-6 השנים האחרונות הוא: "שים את האפליקציה שלך ב- Kubernetes והיא תעשה את השאר." מי שעולה על הבמה בכנסים יספר לכם כמה "ריפוי עצמי" קוברנטס (K8s) הוא כלי תזמור מדהים. אבל אף אחד לא מספר לך על העלות של צבא המ הנדסים שנדרש כדי לנהל את התזמורת הזאת.

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

1. פעולות "יום 2": החלום נגמר, המציאות מתחילה

העלאת אשכול Kubernetes הוא החלק הקל ("יום 1"). הסיוט העיקרי מתחיל בפע ולות "יום 2". שמירה על האשכול מעודכן, ניהול סיבובי אישורים, חוסר תאימות לגרסאות וצמתים מתרסקים...

  • עלות משאבי אנוש: ניהול K8s הוא עבודה במשרה מלאה בפני עצמה. האם זה התפקיד של המפתחים שלך לכתוב קוד, או לאפות באגים מדוע בקר Ingress אינו מנתב תנועה?
  • דליפת הפשטה: הם אומרים שחומרת K8s היא מופשטת אבל זה שקר. ברגע שאתה מגדיר מגבלות מעבד (`בקשות` ו- `מגבלות`) באופן שגוי, היישום שלך מת בשקט עם השגיאה "oom
  • Killed" (מחוץ לזיכרון).
  • רשת: תקשורת בין PODs, רשת שירות, תוספי CNI... בקשת HTTP פשוטה יכולה להפוך לפתע לבעיית הנדסת רשת בלתי פתירה
.

2. פיתוח מונע קורות

חיים

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

אם היישום שלך מתאים לשרת וירטואלי יחיד (VM) ואתה מחלק אותו לאשכול K8s של 3 צמתים, הדבר היחיד שאתה פותר הוא
האגו שלך, לא הבעיה הטכנית
.

3. פגיעויות הנגרמות על ידי מורכבות

המורכבות היא האויב מספר אחת של הביטחון. הגדרות ברירת המחדל של Kubernetes הן בדרך כלל "מכוונות עבודה", לא "בטוחות".

הפעלת

מיכל Docker עם סמכות שורש, עקיפת ניהול סודות (הצפנת etcd) או כללי RBAC (בקרת גישה מבוססת תפקידים) שהוגדרו בצורה שגויה... עבור האקרים, K8s הוא פארק שעשועים כאשר הוא מוגדר בצורה שגויה. כדי להבטיח את בטיחות ה- K8, אתה צריך כלים נוספים (trivy, falco וכו ') וזמן נוסף לניהול אותם.

4. מתי K8s, מתי PaaS?

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

  • גיהנו ם של מיקרו-שירות: אם באמת יש לך 50+ מיקרו-שירותים לנהל, והם מדברים זה עם זה באינטנסיביות, ה- K8s הוא מושיע.
  • יישומים מונוליטיים: אם יש לך יישום מונוליטי, העבודה והפעלתו על PaaS פשוט (Heroku, DigitalOcean App Platform וכו ') או שירות מכולות מנוהל (AWS ECS) יעלה לך 80% פחות עומס תפעולי.
  • ענן היברידי: אם אתה באמת רוצה לברוח מנעילה של ספק ולהפעיל את היישום שלך באותה צורה בכל מקום (On-Prem, AWS, Azure), K8s הוא הסטנדרט.
  • המילה האחרונה: טכנולוגיה משעממת היא טובה

    אוהב

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

    .