מדריך

קביעת עקרון הליבה עבור צוות פלטפורמה כדי להבטיח אימוץ והפחתת חיכוך מפתחים.

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

למה: תפיסה זו מסיטה את המיקוד מבניית תשתית לאספקת ערך, ומבטיחה שהפלטפורמה פותרת בעיות מפתחים אמיתיות ולא נעקפת ("Shadow IT").

קביעת מקור אמת יחיד למצב הרצוי של כל התשתיות והיישומים.

→השתמש במאגרי Git כמקור אמת יחיד. פרוס סוכן בתוך האשכול (ArgoCD, Flux) שמפעיל לולאת התאמה רציפה כדי להשוות את מצב האשכול מול Git.

למה: זה מספק תיעוד ביקורת מלא, מאפשר חזרה קלה לאחור (rollbacks) ומונע סחף תצורה על ידי החזרה אוטומטית של שינויים מחוץ לתחום.

מקור↗

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

→התייחס לתשתית כבלתי ניתנת לשינוי (immutable). לעולם אל תשנה משאבים פועלים. במקום זאת, צור ארטיפקטים חדשים, מבוססי גרסאות (תמונות קונטיינר, תמונות VM) והחלף את הישנים. אכוף זאת באמצעות מערכות קבצים לקונטיינרים לקריאה בלבד (`readOnlyRootFilesystem: true`).

למה: אי-שינוי (Immutability) מבטל סחף תצורה והופך פריסות לניתנות לחיזוי ולשחזור. "החלף, אל תתקן."

בחר מודל פריסת GitOps מאובטח, במיוחד בסביבות מרובות אשכולות או רשתות מוגבלות.

→יישם מודל משיכה (pull-based). סוכן (ArgoCD, Flux) הפועל בתוך האשכול מושך מניפסטים מ-Git. הימנע ממודלים מבוססי דחיפה (push-based) שבהם מערכת CI חיצונית דוחפת ל-Kubernetes API.

למה: מודלים מבוססי משיכה מאובטחים יותר מכיוון שהם אינם דורשים חשיפת שרת ה-Kubernetes API כלפי חוץ או ניהול אישורים עבור מספר אשכולות ב-CI.

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

→הגדר "נתיבי זהב" (או כבישים סלולים): תבניות וזרימות עבודה מוגדרות מראש ותומכות היטב למשימות נפוצות (לדוגמה, יצירת מיקרו-שירות חדש).

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

מתן Multi-tenancy בפלטפורמת Kubernetes משותפת עם רמות בידוד מתאימות.

→לבידוד החזק ביותר, השתמש באשכולות נפרדים. לאיזון בין בידוד חזק ליעילות, השתמש באשכולות וירטואליים (vClusters). עבור Multi-tenancy בסיסי ורך, השתמש בבידוד ברמת Namespace עם RBAC, NetworkPolicies ו-ResourceQuotas.

למה: הבחירה תלויה בסיכון האבטחה ובסיכון "שכן רועש" (noisy neighbor). אשכולות וירטואליים מספקים בידוד במישור הבקרה (control plane) ללא עלות של אשכולות פיזיים מלאים.

הגדרת מצב האינטראקציה העיקרי בין צוות הפלטפורמה לצוותים המותאמים לזרם (מוצר).

→צוות הפלטפורמה צריך לפעול בעיקר במצב "X-as-a-Service", לספק כלי שירות עצמי, ממשקי API ותיעוד.

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

יישום אסטרטגיית Observability מקיפה למערכת מבוזרת.

→אסוף וקשר את שלושת העמודים: Metrics (נתוני סדרות זמן מספריות דרך Prometheus), Logs (אירועים מובנים דרך Fluent Bit), ו-Traces (זרימות בקשות דרך OpenTelemetry).

למה: אף עמוד בודד אינו מספיק. קישור ביניהם (לדוגמה, הטמעת Trace IDs ביומנים) חיוני לאבחון מהיר של בעיות בארכיטקטורות מיקרו-שירותים מורכבות.

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

→השתמש במנוע מדיניות כמו OPA/Gatekeeper או Kyverno, משולב כבקר אישור מאמת/משנה (validating/mutating admission controller). אחסן מדיניות ב-Git וסנכרן אותן דרך GitOps.

למה: זה מספק מעקות הגנה אוטומטיים ומונעים, המעניקים למפתחים משוב מהיר בצינור ה-CI/CD שלהם במקום שערי בדיקה איטיים וידניים.

בחר מנוע מדיניות עבור Kubernetes בהתבסס על מערך הכישורים של הצוות ומורכבות המדיניות.

→השתמש ב-Kyverno עבור מדיניות שניתן לבטא ב-YAML מוכר בסגנון Kubernetes. השתמש ב-OPA/Gatekeeper עבור מדיניות מורכבת הדורשת שפה חזקה וייעודית יותר (Rego) ואינטגרציה של נתונים חיצוניים.

למה: ל-Kyverno עקומת למידה נמוכה יותר עבור מתרגלי Kubernetes. OPA/Rego חזקים יותר אך דורשים לימוד שפה חדשה.

הבטחת שלמות ואותנטיות תמונות קונטיינרים שנפרסות לייצור.

→יישם חתימת תמונות בצינור ה-CI באמצעות Sigstore/Cosign. השתמש בבקר מדיניות (Kyverno, Gatekeeper) כדי ליצור מדיניות קבלה (admission policy) שמאמתת חתימות תמונות לפני שמאפשרת יצירת Pod.

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

מקור↗

אבטח את כל התקשורת שבין שירותים בתוך האשכול בגישת Zero-Trust.

→פרוס Service Mesh (לדוגמה, Istio, Linkerd) ואפשר mTLS הדוק (mutual TLS) לכל התעבורה בתוך הרשת.

למה: mTLS מספק הן הצפנה בתעבורה והן זהות חזקה וניתנת לאימות קריפטוגרפי עבור הלקוח והשרת כאחד, ומונע התחזות והתקפות Man-in-the-Middle בתוך האשכול.

אכיפת שיטות אבטחה מומלצות לכל העומסים (workloads) הפועלים באשכול.

→הפעל את בקר ה-Pod Security Admission המובנה. הגדר Namespaces לאכוף את פרופיל ה-`restricted` עבור עומסים ואת ה-`baseline` עבור רכיבי פלטפורמה.

למה: פרופיל ה-`restricted` אוכף הידוק אבטחה קריטי (לדוגמה, הרצה כמשתמש לא-שורש, הורדת כל היכולות, איסור על הרחבת הרשאות) ומהווה אמצעי אבטחה יסודי.

מקור↗

זיהוי התנהגות חריגה או זדונית בתוך קונטיינרים פועלים ברמת מערכת ההפעלה.

→פרוס כלי אבטחה בזמן ריצה המשתמש ב-eBPF, כגון Falco או Tetragon. הגדר כללים לזיהוי קריאות מערכת חשודות, גישה לקבצים וביצוע תהליכים.

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

בניית צינור נתונים (pipeline) של Observability שניתן להרחבה ועמיד.

→השתמש ב-OpenTelemetry (OTel) Collector. שרשר מעבדים (processors) כדי לשנות נתונים (לדוגמה, מעבד `attributes` להסרת PII, מעבד `batch` ליעילות). השתמש במעבד `memory_limiter` מוקדם בצינור כדי למנוע OOMs.

למה: ה-Collector מנתק את ה-instrumentation מה-backends ומספק דרך גמישה וניטרלית לספק לעבד, לסנן ולנתב נתוני טלמטריה לפני הייצוא.

מקור↗

פריסת גרסאות יישום חדשות לייצור תוך מזעור סיכונים ורדיוס פגיעה.

→יישם פריסות Canary אוטומטיות באמצעות כלי כמו Flagger או Argo Rollouts. העבר בהדרגה תעבורה לגרסה החדשה תוך ניתוח אוטומטי של מדדים מרכזיים (שיעור הצלחה, חביון). חזור לאחור אוטומטית במקרה של הפרת SLO.

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

פריסת גרסה חדשה של יישום עם היכולת לבצע Rollback מיידי.

→תחזק שתי סביבות ייצור זהות ("כחול" ו"ירוק"). פרוס את הגרסה החדשה לסביבה הלא פעילה (ירוק). לאחר האימות, שנה את ה-Load Balancer לנתב את כל התעבורה לירוק. שמור את כחול לא פעיל עבור Rollback מיידי.

למה: דפוס זה מספק פריסות ללא השבתה (zero-downtime) ואת ה-Rollback המהיר ביותר האפשרי, אך בדרך כלל דורש פי שניים ממשאבי התשתית.

ניהול סודות באופן דקלרטיבי בזרימת עבודה של GitOps מבלי לאחסן אישורים בטקסט פשוט ב-Git.

→השתמש ב-Secrets Operator ייעודי. הצפן סודות לפני ביצוע (Bitnami Sealed Secrets, Mozilla SOPS) או הפנה לסודות מכספת חיצונית (External Secrets Operator).

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

ניהול תצורות יישומים על פני מספר סביבות (dev, staging, prod) ללא כפילויות.

→השתמש בכלי כמו Kustomize עם מבנה Base-and-Overlay, או Helm עם קבצי Values ספציפיים לסביבה. קדם שינויים על ידי עדכון תגי תמונה או תצורה בקובץ ה-Overlay/Values של סביבת היעד, בדרך כלל באמצעות Pull Request.

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

ניהול פריסות של אותו יישום על פני צי גדול ודינמי של אשכולות.

→השתמש ב-ArgoCD ApplicationSets עם Cluster Generator. ה-Generator מגלה באופן דינמי אשכולות בהתבסס על תוויות ומשתמש בתבנית כדי ליצור Application resource עבור כל אשכול תואם.

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

מקור↗

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

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

למה: זה מפריד סיכון טכני (פריסה) מסיכון עסקי (שחרור), מאפשר פריסות במהירות גבוהה, בדיקות A/B, ויכולות "מתג השבתה" (kill switch).

פרוס אוטומטית תמונות קונטיינר חדשות ברגע שהן נדחפות ל-Registry.

→השתמש ברכיבי Image Automation של FluxCD. ה-`ImageRepository` סורק את ה-Registry, ה-`ImagePolicy` בוחר את התגית החדשה (לדוגמה, בהתבסס על SemVer), וה-`ImageUpdateAutomation` מבצע Commit של שינוי התגית בחזרה למאגר ה-Git.

למה: זה סוגר את הלולאה מ-CI (דחיפת תמונה) ל-CD (פריסה) עבור זרימת עבודה אוטומטית מלאה של GitOps, מבלי שמערכת ה-CI תצטרך גישה לאשכול.

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

→השתמש ב-Crossplane. התקן פלאגינים של ספקי ענן והגדר CompositeResourceDefinitions (XRDs) ברמה גבוהה עבור מפתחים (לדוגמה, `kind: PostgresSQLInstance`). מפה אותם למשאבי ענן בסיסיים באמצעות Compositions.

למה: זה מרחיב את מישור הבקרה של Kubernetes לניהול משאבים חיצוניים, ומאפשר למפתחים להשתמש ב-`kubectl` וזרימות עבודה מוכרות של GitOps עבור כל תלויות היישום שלהם, מנוהל על ידי דפוסי הפלטפורמה.

מקור↗

אוטומציה של ניהול מחזור חיים מורכב וסטייטפול של יישומים (לדוגמה, התקנה, שדרוגים, גיבויים, שחזור כשלים) באופן Kubernetes-native.

→בנה Kubernetes Operator. הגדר Custom Resource Definition (CRD) עבור היישום שלך ויישם בקר מותאם אישית שמפעיל לולאת התאמה (reconciliation loop) לניהול מצב היישום.

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

הבטחה שאופרטור יכול לבצע ניקוי של משאבים חיצוניים (לדוגמה, Load Balancer בענן) לפני שה-Custom Resource המשויך אליו נמחק מ-Kubernetes.

→הוסף Finalizer למטה-נתונים של ה-Custom Resource. כאשר משתמש מוחק את ה-CR, הוא נכנס למצב `Terminating`. לוגיקת ה-Reconciliation של האופרטור מזהה זאת, מבצעת ניקוי, ולאחר מכן מסירה את ה-Finalizer, ומאפשרת לשרת ה-K8s API להשלים את המחיקה.

למה: ללא Finalizer, ה-CR עלול להימחק לפני שלאופרטור יש זמן לנקות משאבים חיצוניים, מה שמוביל לתשתיות יתומות ויקרות.

ניהול מחזור החיים של צי של אשכולות Kubernetes עצמם באמצעות כלי עבודה דקלרטיביים וידידותיים ל-GitOps.

→השתמש ב-Cluster API (CAPI). אשכול ניהול מריץ בקרי CAPI שמתאמים משאבי `Cluster` ו-`Machine` כדי להקצות ולהגדיר אשכולות Workload על פני ספקי ענן שונים.

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

מקור↗

פיתוח ממשקי API של פלטפורמה (מוגדרים כ-CRDs) מבלי לשבור משתמשים קיימים או לדרוש הגירה בסגנון "מפץ גדול".

→תמוך במספר גרסאות בהגדרת ה-CRD (לדוגמה, v1beta1, v1). יישם Conversion Webhook כדי לתרגם בין גרסאות, מה שמאפשר ללקוחות חדשים להשתמש ב-v1 בזמן שלקוחות ישנים ממשיכים להשתמש ב-v1beta1 מול אותו אובייקט מאוחסן.

למה: Conversion Webhooks הם המנגנון המקורי של Kubernetes המאפשר אבולוציה לא-משבשת של API, שהיא קריטית למוצר פלטפורמה יציב.

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

→יישם פורטל מפתחים פנימי (IDP) באמצעות Framework כמו CNCF Backstage. אכלס את קטלוג התוכנה שלו, ספק תבניות תוכנה (Software Templates) לבניית שירותים חדשים, ושלב TechDocs עבור "docs-as-code".

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

מקור↗

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

→יישם קטלוג תוכנה (לדוגמה, Backstage Software Catalog) המאוכלס באמצעות קבצי `catalog-info.yaml` במאגרי Git. זה יוצר רישום מרכזי וניתן לחיפוש של שירותים, ספריות, ממשקי API וכו'.

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

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

→השתמש בכלי Scaffolding כמו Backstage Software Templates. הגדר תבניות שמייצרות מאגר Git חדש עם מבנה פרויקט סטנדרטי, תצורת צינור CI/CD, לוחות מחוונים של Observability, וקובץ `catalog-info.yaml`.

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

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

→אמץ גישת "docs-as-code". אחסן תיעוד בקבצי Markdown בתוך מאגר ה-Git של השירות. השתמש בכלי כמו Backstage TechDocs כדי לבנות ולהציג אוטומטית תיעוד זה ב-IDP.

למה: מודל זה מתייחס לתיעוד כמו לקוד – ניתן לבדוק אותו ב-Pull Requests והוא מבוקר גרסאות לצד התכונה שהוא מתאר, ומונע תיעוד מיושן או לא עדכני.

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

→עקוב אחר ארבעת מדדי DORA: תדירות פריסה (Deployment Frequency - מהירות), זמן הובלה לשינויים (Lead Time for Changes - מהירות), שיעור כשל שינוי (Change Failure Rate - יציבות), וזמן לשחזור שירות (Time to Restore Service - MTTR, יציבות).

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

מקור↗

מתן נראות עלויות מדויקת ומפורטת לצוותים המשתמשים בפלטפורמת Kubernetes משותפת.

→פרוס כלי FinOps כמו OpenCost או Kubecost. ייחס עלויות לעומסים בהתבסס על צריכת המשאבים בפועל שלהם לאורך זמן. הקצה עלויות אשכול משותפות (לדוגמה, רכיבי מערכת, תקורה של Nodes) באופן יחסי.

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

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

→עקוב אחר שיעור האימוץ של תכונות פלטפורמה מרכזיות, במיוחד תבניות "נתיב זהב" וצינורות CI/CD משותפים. השלם עם סקרי שביעות רצון מפתחים (בסגנון NPS).

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

הערכת המצב הנוכחי של הפלטפורמה ויצירת מפת דרכים לשיפור.

→השתמש במודל בשלות פלטפורמה (Platform Maturity Model) כדי להעריך יכולות על פני ממדים מרובים: לדוגמה, שירות עצמי (Self-Service), Observability, אבטחה, אמינות ומשילות (Governance). הגדר רמות מאד-הוק/ידני ועד אוטומטי לחלוטין ואופטימלי.

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