מדריך

הקצאה וניהול של תשתית מרובת עננים באמצעות ממשקי API הצהרתיים, מובנים ב-Kubernetes.

→השתמש ב-Crossplane. התקן CRDs של ספק ענן (לדוגמה, provider-aws). הגדר הפשטות פלטפורמה באמצעות Composition ו-CompositeResourceDefinition (XRD).

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

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

→יישם Cluster API (CAPI) עם ספקי תשתית רלוונטיים (לדוגמה, CAPA עבור AWS, CAPZ עבור Azure). הגדר אשכולות כמשאבי Kubernetes באשכול ניהול.

למה: מתייחס למחזור חיי האשכול כקוד, מאפשר GitOps לאשכולות עצמם. CAPI MachineHealthChecks מספקים תיקון אוטומטי של צמתים.

מקור↗

ספק בידוד חזק בין עומסי עבודה של דיירים בפלטפורמת Kubernetes משותפת.

→שלב מאגרי צמתים ייעודיים (compute), NetworkPolicies (רשת), RBAC (API), ResourceQuotas (משאב), ו-Pod Security Standards (אבטחה). שקול אשכולות וירטואליים (vCluster) לבידוד מישור הבקרה.

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

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

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

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

ספק לצוותי פיתוח סביבות מבודדות, דמויות cluster-admin, ללא התקורה של אשכולות פיזיים.

→השתמש ב-vCluster. כל vCluster מריץ מישור בקרה נפרד של K8s כ-pods בתוך namespace של אשכול מארח, ומשתף את צומתי העבודה של המארח.

למה: מציע בידוד חזק ברמת ה-API בעלות נמוכה יותר מאשכולות מלאים. ה-vCluster syncer מממש משאבים נחוצים באשכול המארח.

מקור↗

ודא התאוששות מאסון עבור עומסי עבודה stateful עם RPO/RTO נמוכים.

→השתמש במנהל התקן CSI התומך בשכפול נתונים סינכרוני או אסינכרוני חוצה אזורים/חוצה אשכולות (לדוגמה, Rook-Ceph, Portworx).

למה: שכפול חיוני לזמינות נתונים במקרה של כשל אזורי. צילומי מצב מקומיים או שכבות ביצועים גבוהים אינם מטפלים ב-DR חוצה אתרים.

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

→השתמש ב-Pod Topology Spread Constraints במפרטי עומסי עבודה. הגדר `topologyKey` (לדוגמה, `topology.kubernetes.io/zone`) ו-`whenUnsatisfiable: ScheduleAnyway` או `DoNotSchedule`.

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

נהל מדיניות ו-RBAC עבור צוותים בעלי מבנים ארגוניים היררכיים.

→יישם את Hierarchical Namespace Controller (HNC). צור יחסי הורה-ילד של namespace להפצת RBAC, NetworkPolicies ו-ResourceQuotas.

למה: HNC מפשט את הניהול בכך שהוא מאפשר למנהלי פלטפורמה להגדיר מדיניות ברמת צוות/ארגון (parent namespace) אשר עוברת בירושה אוטומטית לכל ה-sub-namespaces.

יישם אסטרטגיות פריסה מתקדמות ואוטומטיות כמו canary או blue-green עם ניתוח מבוסס מדדים ו-rollback.

→השתמש ב-Argo Rollouts. הגדר משאב Rollout עם אסטרטגיה (לדוגמה, canary) הכוללת תצורת ניתוב תעבורה (עבור service mesh) ו-AnalysisTemplate המפנה לספק מדדים כמו Prometheus.

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

מקור↗

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

→השתמש ב-Sealed Secrets (מצפין secrets עבור אשכול ספציפי) או ב-External Secrets Operator (מסנכרן מ-Vault, AWS/GCP/Azure secret managers). בצע commit רק של ה-secret המוצפן או משאב ההפניה ל-Git.

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

בצע אוטומציה של יצירה וניהול של ArgoCD Applications עבור מספר אשכולות, סביבות או מיקרו-שירותים.

→השתמש ב-ApplicationSet. הגדר תבנית עבור ה-Application והשתמש ב-generator (לדוגמה, cluster, git, matrix) כדי ליצור Applications באופן דינמי בהתבסס על רשימות אשכולות, ספריות Git או מקורות אחרים.

למה: מבטל יצירת Application ידנית, מאפשר ניהול ניתן להרחבה של מאות יישומים או אשכולות מהגדרה יחידה.

ספק סביבות תצוגה מקדימה אפמרליות למפתחים לבדיקת שינויים ב-pull request.

→השתמש ב-ArgoCD ApplicationSet עם Pull Request generator. הוא יוצר Application באופן אוטומטי כאשר PR נפתח ומוחק אותו כאשר ה-PR נסגר/מוזג.

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

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

→יישם את תבנית App-of-Apps. Application שורש מנהל Applications ילדים אחרים, שיכולים בתורם לנהל Applications אחרים, ויוצר מבנה היררכי.

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

ודא שמשאבים נפרסים בסדר הנכון (לדוגמה, CRDs לפני CRs, תשתית לפני יישומים).

→ב-ArgoCD, השתמש ב-Sync Waves ובבדיקות תקינות משאבים. ב-Flux, השתמש ב-`dependsOn` במשאבי Kustomization או HelmRelease.

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

יישם צינור GitOps מלא באמצעות Flux.

→שלב את בקרי Flux: Source Controller (למקורות Git/Helm/OCI), Kustomize Controller (ליישום מניפסטים), ו-Helm Controller (עבור HelmReleases). השתמש ב-Notification Controller להתראות.

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

מקור↗

ודא שמצב האשכול החי תואם ברציפות את המצב הרצוי ב-Git, מחזיר כל שינוי ידני לאחור.

→הגדר ArgoCD Application עם `syncPolicy.automated.selfHeal: true`. ArgoCD יזהה סחף ויבצע סנכרון אוטומטי כדי להחזיר שינויים לא מורשים.

למה: ריפוי עצמי הוא עיקרון ליבה של GitOps המאכף את Git כמקור האמת היחיד ומונע סחף תצורה, החיוני לתאימות ויציבות.

קדם גרסאות יישומים על פני סביבות (פיתוח -> staging -> production) עם ביקורת ושערי אישור מתאימים.

→השתמש בספריות או ענפים נפרדים לכל סביבה ב-Git. קדם שינויים על ידי יצירת pull requests (לדוגמה, מענף staging לענף/ספריית production). אכוף ביקורות PR.

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

יישם ריבוי דיירים במופע ArgoCD משותף, והגבל צוותים למשאבים שלהם.

→צור ArgoCD Projects עבור כל צוות. הגדר פרויקטים להגבלת מאגרי Git מקור, אשכולות/namespaces יעד, וסוגי משאבים מורשים. שלב עם SSO ומפה קבוצות לתפקידי פרויקט.

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

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

→הגדר API ברמה גבוהה עם CompositeResourceDefinition (XRD). יישם את ה-API עם Composition הממפה את השדות ברמה גבוהה למשאבים מנוהלים בסיסיים. מפתחים מקיימים אינטראקציה עם Composite Resource Claim (XRC) פשוט.

למה: מודל שלוש השכבות הזה (Claim -> Composition -> Managed Resource) מפריד את ה-API הפונה למשתמש מהיישום, מספק הפשטה נקייה ומאפשר ניהול פלטפורמה.

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

→צור Backstage Software Templates. התבנית מגדירה פרמטרי קלט (ממשק משתמש טופס) וסדרה של פעולות scaffolder (לדוגמה, אחזור שלד, יצירת מאגר Git, רישום בקטלוג).

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

מקור↗

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

→יישם את Backstage Software Catalog. קלוט את מתארי ישויות `catalog-info.yaml` ממאגרי Git כדי לבנות גרף ניתן לחיפוש של רכיבי תוכנה ויחסיהם.

למה: הקטלוג הוא הליבה של IDP, מספק יכולת גילוי ובסיס לתכונות אחרות כמו TechDocs, תיעוד API ונראות סטטוס CI/CD.

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

→השתמש ב-finalizers. בבקר, הוסף finalizer ל-CR בעת יצירתו. בלולאת התיאום, אם `deletionTimestamp` מוגדר, בצע לוגיקת ניקוי ולאחר מכן הסר את ה-finalizer.

למה: Finalizers מונעים מ-Kubernetes למחוק משאב עד שהבקר השלים בהצלחה את משימות הניקוי שלו, ומונעים משאבים חיצוניים יתומים.

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

→השתמש בפתרונות Workload Identity של ספקי ענן (AWS IRSA, GCP Workload Identity, Azure Workload Identity). זה מקשר ServiceAccount של Kubernetes לתפקיד IAM בענן, ומאפשר ל-pods להשיג אישורים זמניים.

למה: מבטל את הסיכון של אישורים סטטיים ארוכי טווח. זו התבנית המאובטחת ביותר למתן הרשאות ענן ל-pods.

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

→אפשר את ה-status subresource בהגדרת ה-CRD. הבקר צריך לעדכן את הסטטוס עם תנאים (לדוגמה, `Type: Ready`, `Status: True`) ומצב נצפה.

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

פתח ממשקי API של פלטפורמה (CRDs) מבלי לשבור לקוחות או משתמשים קיימים.

→פעל לפי מוסכמות גרסאות ה-API של Kubernetes (v1alpha1 -> v1beta1 -> v1). בעת הצגת שינויים שוברי תאימות, צור גרסה חדשה ויישם conversion webhook לתרגום בין גרסאות מאוחסנות לגרסאות מוגשות.

למה: Conversion webhooks מאפשרים לשרת ה-API לשרת מספר גרסאות של משאב בו זמנית תוך שמירה על גרסת אחסון יחידה, ומאפשרים אבולוציית API חלקה.

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

→הגדר SLOs וחשב תקציבי שגיאות. יישם התראות מרובות חלונות ומרובות קצבי שריפה המופעלות כאשר קצב צריכת תקציב השגיאות מאיים על ה-SLO.

למה: התראה על שריפת תקציב שגיאות משמעותית יותר מהתראות סף פשוטות. היא מקשרת ישירות התראות להשפעה על המשתמש ולהפרות SLO.

מקור↗

יישם צינור מאוחד ובלתי תלוי בספק לאיסוף, עיבוד וייצוא של אותות נראות (traces, metrics, logs).

→פרוס את OpenTelemetry Collector. הגדר צינורות עם receivers (לדוגמה, OTLP, Jaeger), processors (לדוגמה, batch, attributes), ו-exporters (לדוגמה, Prometheus, Loki, Tempo, backends של ספקים).

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

מקור↗

הגדר את Prometheus באופן הצהרתי כדי לגלות ולגרד מדדים מעומסי עבודה של Kubernetes.

→השתמש ב-Prometheus Operator. צור `ServiceMonitor` או `PodMonitor` Custom Resources המשתמשים בבוררי תוויות כדי להגדיר אילו שירותים או pods Prometheus צריך לגרד.

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

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

→השתמש ב-Prometheus exemplars. בצע אינסטרומנטציה ליישומים כדי לצרף מזהי trace לתצפיות מדדים. הגדר את Prometheus ו-Grafana להצגת exemplars, מספק קישורים ישירים ממדדים ל-traces ב-backend של tracing כמו Tempo או Jaeger.

למה: מפחית באופן דרסטי את MTTR על ידי קישור ישיר של ה"מה" (מדד) ל"למה" (trace), ומבטל מאמצי קורלציה ידניים.

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

→נטר את ארבעת ה"אותות המוזהבים": Latency (זמן תגובה), Traffic (בקשות לשנייה), Errors (קצב בקשות כושלות), ו-Saturation (ניצול משאבים).

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

מקור↗

ספק לצוותים נראות לעלות עומסי העבודה שלהם ב-Kubernetes עבור chargeback או showback.

→פרוס כלי קוד פתוח כמו OpenCost או Kubecost. כלים אלה מקצים עלויות ענן למשאבי Kubernetes (pods, namespaces, labels) בהתבסס על בקשות ושימוש במשאבים שלהם.

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

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

→הגדר `inhibit_rules` ב-Alertmanager. לדוגמה, עכב את כל ההתראות עבור אשכול ספציפי אם התראת "ClusterUnreachable" כבר פעילה.

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

בדוק באופן יזום את עמידות הפלטפורמה והיישומים על ידי הזרקת כשלים באופן מבוקר.

→השתמש בכלי הנדסת כאוס כמו Chaos Mesh או Litmus. הגדר ניסויים עם רדיוס פיצוץ מוגבל (לדוגמה, namespaces או תוויות ספציפיים) ותנאי עצירה אוטומטיים המבוססים על SLOs או מדדים קריטיים.

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

בחר מנוע מדיניות לאכיפת מעקות בטיחות בפלטפורמת Kubernetes.

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

למה: ל-Kyverno יש חסם כניסה נמוך יותר עבור מהנדסי Kubernetes. OPA/Gatekeeper גמיש יותר וניתן להשתמש בו מחוץ ל-Kubernetes אך יש לו עקומת למידה תלולה יותר.

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

→השתמש במנוע מדיניות כמו Kyverno. השתמש בכללי `validate` לחסימה/ביקורת, בכללי `mutate` להוספת ברירות מחדל (לדוגמה, securityContext, labels), ובכללי `generate` ליצירת משאבים (לדוגמה, NetworkPolicy ברירת מחדל).

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

מקור↗

אכוף חיזוק אבטחה בסיסי לכל ה-pods הפועלים בפלטפורמה.

→השתמש ב-Pod Security Standards (PSS) באמצעות בקר הקבלה המובנה של Pod Security Admission. תייג namespaces עם `pod-security.kubernetes.io/enforce=baseline` או `restricted`.

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

מקור↗

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

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

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

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

→השתמש ב-SPIFFE/SPIRE להנפקת זהויות קריפטוגרפיות קצרות טווח וניתנות לסיבוב (SVIDs) לעומסי עבודה. אכוף mTLS באמצעות service mesh, המאמת SVIDs בכל בקשה.

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

בודד עומסי עבודה ברמת הרשת, אכוף מדיניות "default-deny" ואפשר רק נתיבי תקשורת נדרשים.

→יישם Kubernetes NetworkPolicies. החל מדיניות default-deny על כל namespace, ולאחר מכן הוסף מדיניות ingress/egress ספציפית המאפשרת תעבורה בהתבסס על תוויות pod/namespace.

למה: מפחית את שטח התקפה של תנועה רוחבית. פגיעה ב-pod אחד אינה מעניקה אוטומטית גישת רשת לכל שאר השירותים באשכול.

צור יומן ביקורת מקיף ובלתי ניתן לשינוי של כל הפעולות שבוצעו על שרת ה-Kubernetes API עבור אבטחה ותאימות.

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

למה: יומני ביקורת חיוניים לחקירת אירועים, דיווח תאימות (לדוגמה, PCI-DSS, SOC2), וזיהוי פעילות API חריגה.