מדריך

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

→הגדר משאב `Pod`. Pods יכולים להכיל קונטיינר אחד או יותר שחולקים רשת ואחסון.

למה: ה-Pod הוא היחידה האטומית לתזמון ב-Kubernetes. קונטיינרים נפרסים תמיד בתוך Pod.

מקור↗

ודא שמצב האשכול תואם באופן רציף למצב רצוי.

→הסתמך על ה-`kube-controller-manager`. הוא מריץ לולאות בקרה שצופות במשאבים (לדוגמה, ReplicaSets, Deployments) ומתאמת הבדלים.

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

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

→הסתמך על ה-`kube-scheduler`. הוא מסנן צמתים בהתבסס על דרישות Pod (לדוגמה, בקשות למשאבים) ומדרג אותם כדי לבחור את ההתאמה הטובה ביותר.

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

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

→סוכן ה-`kubelet` פועל על כל צומת, מתקשר עם שרת ה-API, ומנהל את מחזור החיים של הקונטיינר (התחלה, עצירה, בדיקות בריאות) באמצעות runtime של קונטיינרים.

למה: Kubelet הוא החוליה המקשרת בין ה-control plane לצומת העבודה; הוא מבצע את מפרטי ה-Pod.

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

→השתמש ב-`etcd`, מאגר מפתח-ערך עמיד ועקבי בעל זמינות גבוהה. הוא משמש כמקור האמת היחיד לאשכול.

למה: כל אובייקטי האשכול (Pods, Services וכו') מאוחסנים ב-etcd. רק שרת ה-API מתקשר איתו ישירות.

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

→רכיב ה-`kube-proxy` בכל צומת מתחזק כללי רשת (לדוגמה, iptables, IPVS) שמנתבים תעבורה מ-Service IP אל ה-Pods המתאימים ב-backend.

למה: Kube-proxy הוא פרט היישום מאחורי הפשטת ה-Service, ומטפל באיזון עומסים וניתוב.

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

→צור משאבי `Namespace`. Namespaces מספקים טווח לשמות ודרך לצרף הרשאות ומדיניות (לדוגמה, ResourceQuotas).

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

ספק נקודת קצה יציבה לרשת (IP ו-DNS) עבור קבוצה של Pods זמניים.

→הגדר משאב `Service` המכוון לקבוצת Pods באמצעות בורר תוויות.

למה: Pods הם זמניים וכתובות ה-IP שלהם משתנות. Service מספק הפשטה עמידה המאזנת עומסים לתעבורה אל ה-Pods הנכונים.

מקור↗

חשוף יישום הפועל ב-Pods לטווחים שונים של רשת.

→בחר `type` של Service: `ClusterIP` (פנימי בלבד, ברירת מחדל), `NodePort` (חושף בכל IP:port של צומת), או `LoadBalancer` (מקצה Load Balancer בענן).

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

אפשר גילוי רשת ישיר של Pods בודדים, תוך עקיפת ה-proxy של ה-Service.

→צור `Service` עם `clusterIP: None`. זה יוצר רשומות DNS A עבור כל Pod, ומאפשר ללקוחות להתחבר ל-Pods ישירות.

למה: חיוני ליישומים עם מצב (stateful) כמו מסדי נתונים (לעתים קרובות עם StatefulSets) כאשר נדרשת תקשורת עמית-לעמית או זהות Pod יציבה.

ארגן ובחר תת-קבוצה של אובייקטי Kubernetes.

→צרף `labels` של מפתח-ערך לאובייקטים (לדוגמה, `app: my-api`). השתמש ב-`label selectors` באובייקטים אחרים (לדוגמה, Services, Deployments) כדי למקד אליהם.

למה: Labels הם מנגנון הקיבוץ הליבתי ב-Kubernetes, המאפשר צימוד רופף בין משאבים.

הפרד את תצורת היישום מתמונת הקונטיינר.

→אחסן נתוני תצורה שאינם רגישים ב-`ConfigMap`. טען אותו כ-volume או הזרק מפתחות כמשתני סביבה לתוך Pods.

למה: זה מאפשר לנהל תצורה באופן עצמאי מקוד היישום, בהתאם לעקרונות 12-Factor App.

אחסן נתונים רגישים כמו סיסמאות, אסימונים או מפתחות API לשימוש היישום.

→השתמש באובייקט `Secret`. טען כ-volume או הזרק כמשתנה סביבה.

למה: Secrets מיועדים באופן ספציפי לנתונים רגישים ומטופלים בצורה מאובטחת יותר מ-ConfigMaps (לדוגמה, אינם מוצגים ב-`kubectl describe` כברירת מחדל, ניתנים להצפנה במנוחה).

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

→Pod יוצר `PersistentVolumeClaim` (PVC) כדי לבקש אחסון. מנהל מערכת מקצה `PersistentVolume` (PV) שממלא את הבקשה.

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

נהל הקצאת CPU וזיכרון עבור קונטיינרים.

→הגדר `resources.requests` למשאבים מובטחים (משמש לתזמון) ו-`resources.limits` לשימוש המרבי המותר (נאכף בזמן ריצה).

למה: Requests מבטיחים של-Pods יש מספיק משאבים כדי לרוץ; Limits מונעים מ-Pods לצרוך יותר מדי משאבים ולהשפיע על עומסי עבודה אחרים.

הגדר אילוצי משאבים מצטברים על namespace.

→צור אובייקט `ResourceQuota` כדי להגביל את הכמות הכוללת של CPU, זיכרון, או מספר האובייקטים (Pods, Services) שניתן ליצור ב-namespace.

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

נהל משאבי Kubernetes באמצעות קבצי תצורה מנוהלי גרסאות.

→השתמש ב-`kubectl apply -f <filename.yaml>`. פקודה זו יוצרת או מעדכנת משאבים בהתבסס על תוכן הקובץ.

למה: `apply` הוא דקלרטיבי, מה שהופך אותו לאידיאלי עבור GitOps ו-CI/CD. הוא עוקב אחר שינויים ומבצע מיזוג תלת-כיווני, שהוא בטוח יותר מהפקודות האימפרטיביות `create` או `replace`.

אבחן מדוע Pod אינו פועל כהלכה (לדוגמה, תקוע ב-Pending, ContainerCreating, או CrashLoopBackOff).

→השתמש ב-`kubectl describe pod <pod-name>`. בדוק את מקטע ה-`Events` בתחתית להודעות מפורטות מהמתזמן, kubelet או בקרים.

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

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

→השתמש בתוסף Container Network Interface (CNI) (לדוגמה, Calico, Flannel, Cilium). ה-kubelet בכל צומת משתמש בתוסף CNI כדי להגדיר רשת עבור כל Pod.

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

שלוט בגישה למשאבי Kubernetes API עבור משתמשים ויישומים.

→השתמש ב-Role-Based Access Control (RBAC). הגדר `Role` (מוגבל ל-namespace) או `ClusterRole` (רחב אשכול) עם הרשאות, וקשור אותו ל-subject (User, Group, ServiceAccount) באמצעות `RoleBinding` או `ClusterRoleBinding`.

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

מקור↗

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

→השתמש בעומס עבודה מסוג `Deployment`. הוא מנהל ReplicaSets כדי להבטיח שמספר רצוי של עותקי Pod פועלים, ומספק אסטרטגיות עדכון דקלרטיביות.

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

מקור↗

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

→השתמש בעומס עבודה מסוג `StatefulSet`. הוא מספק לכל Pod שם מארח יציב וייחודי ואחסון קבוע שנשאר עמו לאורך הפעלות מחדש.

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

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

→השתמש בעומס עבודה מסוג `DaemonSet`. הוא מבטיח שעוותק של Pod ירוץ על כל צומת (או תת-קבוצה של צמתים).

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

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

→השתמש במשאב `Job`. הוא יוצר Pod אחד או יותר ומוודא שהם מסיימים בהצלחה.

למה: Jobs מיועדים לעיבוד אצווה, בניגוד ל-Deployments המיועדים לשירותים רציפים. ה-Pods אינם מוחלפים לאחר סיום מוצלח.

הפעל משימה בלוח זמנים חוזר (לדוגמה, גיבויים ליליים, דוחות).

→השתמש במשאב `CronJob`. הוא יוצר Jobs בהתבסס על מחרוזת לוח זמנים של cron.

למה: CronJobs מספקים דרך מקורית ב-Kubernetes לנהל משימות חוזרות מבוססות זמן.

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

→הגדר `livenessProbe` במפרט הקונטיינר. אם הבדיקה נכשלת, ה-kubelet מפעיל מחדש את הקונטיינר.

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

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

→הגדר `readinessProbe` במפרט הקונטיינר. ה-Pod מתווסף לנקודות קצה של Service רק לאחר שהבדיקה מצליחה.

למה: בדיקות Readiness קריטיות לעדכוני Rolling ללא השבתה, ומבטיחות ש-Pods חדשים מאותחלים במלואם לפני קבלת תעבורת ייצור.

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

→הגדר `initContainers` אחד או יותר במפרט ה-Pod. הם פועלים עד להשלמה ברצף לפני שמתחילים קונטיינרים כלשהם של היישום.

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

ודא ש-Pods מתוזמנים על צמתים עם מאפיינים ספציפיים (לדוגמה, צמתים עם GPUs, SSDs).

→השתמש ב-`nodeAffinity` במפרט ה-Pod כדי להגדיר כללים המבוססים על תוויות צומת. יכול להיות אילוץ "נדרש" (קשה) או "מועדף" (רך).

למה: Node affinity הוא אקספרסיבי יותר מ-`nodeSelector` והוא הדרך המודרנית לשלוט במיקום Pod על בסיס מאפייני צומת.

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

→השתמש ב-`podAffinity` כדי לתזמן Pods יחד (לדוגמה, על אותו צומת) או ב-`podAntiAffinity` כדי לפזר אותם (לדוגמה, על פני צמתים או אזורים שונים).

למה: Anti-affinity חיוני כדי להבטיח שעותקי שירות אינם באותו תחום כשל, ובכך להגביר את הזמינות.

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

→החל `Taint` על צומת. ל-Pods חייבת להיות `Toleration` תואמת במפרט שלהם כדי שיתוזמנו על צומת זה.

למה: Taints ו-tolerations מבטיחים שצמתים שמורים לעומסי עבודה המורשים במפורש לרוץ עליהם.

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

→הגדר `topologySpreadConstraints` במפרט ה-Pod כדי לשלוט באופן שבו Pods מפוזרים על בסיס תוויות ומפתחות טופולוגיה (לדוגמה, `topology.kubernetes.io/zone`).

למה: זה מספק שליטה מדויקת יותר על HA מאשר pod anti-affinity, ומונע מכל העותקים להתרכז במיקום אחד.

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

→צור משאב `HorizontalPodAutoscaler` (HPA) המכוון ל-Deployment ומציין מדד (לדוגמה, ניצול CPU) וערך יעד.

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

מקור↗

הוסף או הסר אוטומטית צמתי עבודה מהאשכול כדי להתאים לדרישת המשאבים.

→פרוס את ה-`Cluster Autoscaler`. הוא צופה ב-Pods שלא ניתן לתזמן (בשל מחסור במשאבים) ומוסיף צמתים, או מסיר צמתים בשימוש חסר.

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

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

→צור `PodDisruptionBudget` (PDB) המציין `minAvailable` או `maxUnavailable` עבור קבוצה של Pods.

למה: PDBs מונעים פעולות כמו `kubectl drain` מלהפיל יותר מדי עותקים בבת אחת, ובכך מגנים על זמינות היישום.

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

→השתמש ב-`Deployment` עם אסטרטגיית ה-`RollingUpdate` כברירת מחדל. הגדר `maxSurge` ו-`maxUnavailable` כדי לשלוט בתהליך העדכון.

למה: עדכוני Rolling מחליפים בהדרגה Pods ישנים בחדשים, ומבטיחים שהשירות יישאר זמין לאורך כל העדכון.

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

→הטמע GitOps. השתמש במאגר Git כמקור האמת היחיד. השתמש בכלי כמו Argo CD או Flux כדי לסנכרן אוטומטית את מצב האשכול עם Git.

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

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

→השתמש ב-`Helm`, מנהל החבילות עבור Kubernetes. ארוז יישומים כ-`Charts` עם מניפסטים מתוזמנים וקובצי `values.yaml` הניתנים להגדרה.

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

התאם אישית מניפסטים של Kubernetes לסביבות שונות ללא שימוש בתבניות.

→השתמש ב-`Kustomize`. הגדר קובץ `kustomization.yaml` המציין תצורת בסיס ומחיל תיקונים או שכבות על עבור כל סביבה.

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

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

→פרוס את הגרסה החדשה לצד הישנה. השתמש ב-Service Mesh או ב-Ingress controller כדי לנתב אחוז קטן מהתעבורה (לדוגמה, 5%) לגרסת ה-"canary" החדשה.

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

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

→פרוס את גרסת ה-"green" החדשה לצד גרסת ה-"blue" הקיימת. לאחר אימות גרסת ה-"green", העבר 100% מהתעבורה מ-"blue" ל-"green" ברמת ה-Service/router.

למה: פריסות Blue-green מבטלות השבתה. חזרה לאחור פשוטה כמו העברת התעבורה בחזרה לסביבת ה-"blue".

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

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

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

בנה יישום נייד, ניתן להרחבה ו-Cloud Native בהתאם לשיטות עבודה מומלצות מבוססות.

→הקפד על מתודולוגיית Twelve-Factor App. עקרון מפתח הוא אחסון כל התצורה המשתנה בין סביבות במשתני סביבה.

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

מקור↗

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

→הטמע Service Mesh (לדוגמה, Istio, Linkerd). הוא מזריק Sidecar proxy לכל Pod כדי ליירט ולנהל את כל תעבורת הרשת.

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

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

→פרוס קונטיינר "sidecar" באותו Pod כמו היישום הראשי. הוא חולק את אותה רשת ואחסון.

למה: Sidecars משמשים לדאגות חוצות כמו רישום לוגים, ניטור, או proxying (כמו ב-Service Mesh), ומקדמים הפרדת דאגות.

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

→הטמע את שלושת עמודי התווך של observability: `Metrics` (נתונים מספריים מצטברים), `Logs` (אירועים בודדים), ו-`Traces` (זרימות בקשות מקצה לקצה).

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