מדריך

צור ConfigMap או Secret גנרי מצמדי מפתח-ערך של שורת הפקודה.

→השתמש ב-`kubectl create configmap <name> --from-literal=<key>=<value>` או ב-`kubectl create secret generic <name> --from-literal=<key>=<value>`.

למה: `--from-literal` מיועד לקלט ישיר של מפתח-ערך. השתמש בדגל מספר פעמים עבור מפתחות מרובים. זה מהיר יותר מאשר יצירת קובץ YAML למקרים פשוטים.

מקור↗

הזרק את כל צמדי המפתח-ערך מ-ConfigMap או Secret כמשתני סביבה לתוך container.

→במפרט ה-container, השתמש ב-`envFrom` עם `configMapRef` או `secretRef`. דוגמה: `envFrom: [{configMapRef: {name: my-config}}]`.

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

מקור↗

הזרק ערך יחיד וספציפי מ-ConfigMap או Secret כמשתנה סביבה.

→השתמש ב-`env.valueFrom`. דוגמה: `env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: my-config, key: log_level}}}]`.

למה: `valueFrom` מספק הזרקה סלקטיבית ומאפשר מיפוי מפתח המקור לשם משתנה סביבה אחר.

הרכב ConfigMap או Secret כקבצים לתוך Pod, המאפשר עדכונים חיים.

→הגדר `volume` מסוג `configMap` או `secret`. הרכב אותו ל-container באמצעות `volumeMounts`. הקבצים ייקראו על שם המפתחות.

למה: קבצים מורכבים מ-ConfigMaps/Secrets מתעדכנים אוטומטית כאשר המקור משתנה. משתני סביבה אינם מתעדכנים, ודורשים הפעלה מחדש של ה-Pod.

מקור↗

אכוף שיטות אבטחה מומלצות: מנע הרצה כ-root, הפוך את מערכת הקבצים הראשית ל-read-only, או ציין user ID.

→השתמש ב-`securityContext` ברמת ה-Pod או ה-container. הגדר `runAsNonRoot: true`, `readOnlyRootFilesystem: true`, ו/או `runAsUser: <UID>`.

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

מקור↗

הענק ל-Pod הרשאות מינימליות לגישה ל-Kubernetes API.

→1. צור `ServiceAccount` מותאם אישית. 2. צור `Role` עם הרשאות API הנחוצות בלבד (לדוגמה, list pods). 3. צור `RoleBinding` כדי לקשר את ה-ServiceAccount וה-Role. 4. הקצה את ה-ServiceAccount ל-Pod באמצעות `spec.serviceAccountName`.

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

מנע את ההרכבה האוטומטית של ServiceAccount token לתוך Pod שאינו זקוק לגישה ל-API.

→הגדר `automountServiceAccountToken: false` במפרט ה-Pod או ב-ServiceAccount עצמו.

למה: מפחית את שטח התקיפה בכך שאינו מספק אישורי API ל-containers שאינם דורשים אותם.

צור Secret לשימוש ב-TLS termination עבור Ingress או שירות מאובטח אחר.

→השתמש ב-`kubectl create secret tls <secret-name> --cert=<path/to/cert.pem> --key=<path/to/key.pem>`.

למה: זה יוצר Secret מהסוג הנכון `kubernetes.io/tls` עם מפתחות הנתונים הסטנדרטיים `tls.crt` ו-`tls.key` הצפויים על ידי Ingress controllers.

חשוף מטא נתונים של Pod (כמו שם, namespace, labels, או node IP) ל-container.

→השתמש ב-Downward API כדי להקרין מטא נתונים כמשתני סביבה או קבצים ב-`downwardAPI` volume. דוגמה: `valueFrom: {fieldRef: {fieldPath: metadata.name}}`.

למה: מאפשר ל-containers להיות מודעים לעצמם מבלי צורך לשלוף מידע מ-Kubernetes API, מפשט תצורה ומפחית דרישות RBAC.

מקור↗

הגדר בקשות CPU/זיכרון וlimits ברירת מחדל לכל ה-Pods ב-namespace.

→צור אובייקט `LimitRange` ב-namespace. הגדר ערכי `default` ו-`defaultRequest` למשאבים.

למה: מבטיח שלכל ה-Pods יהיו מגבלות משאבים, משפר תזמון ויציבות, גם אם מפתחים שוכחים לציין אותם. עובד בשיתוף פעולה עם ResourceQuota.

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

→צור אובייקט `ResourceQuota`. הגדר מגבלות קשיחות ב-`spec.hard`, לדוגמה: `requests.cpu: "4"`, `pods: "10"`.

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

הרץ משימות קדם-דרישה (לדוגמה, המתן ל-database, הפעל migrations, משוך נתונים) לפני שהיישום הראשי מתחיל.

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

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

מקור↗

הרחב container יישום ראשי עם פונקציונליות עזר כמו logging, monitoring, או proxying.

→הוסף container שני (ה-sidecar) למפרט ה-Pod. שני ה-containers חולקים משאבים כמו רשת ו-volumes.

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

שתף ספרייה לקריאה/כתיבה בין containers באותו Pod.

→הגדר `emptyDir` volume במפרט ה-Pod והרכב אותו לכל ה-containers הנדרשים.

למה: `emptyDir` מספק volume אחסון פשוט וחולף שקיים למשך חיי ה-Pod, מושלם לשיתוף נתונים בתוך ה-Pod.

דרוס את ה-ENTRYPOINT ו/או ה-CMD המוגדרים כברירת מחדל של image של container.

→במפרט ה-container, השתמש ב-`command` כדי לדרוס את ENTRYPOINT וב-`args` כדי לדרוס את CMD. `command: ["/bin/sh"], args: ["-c", "echo hello"]`.

למה: מספק שליטה מלאה על פקודת ההפעלה של ה-container מהגדרת ה-Pod, שימושי להתאמת images גנריים.

הרץ משימה סופית עד להשלמתה, תוך שליטה על מקביליות ומספר ההשלמות המוצלחות.

→השתמש במשאב `Job`. הגדר `spec.completions` לספירת ההצלחות הרצויה ו-`spec.parallelism` למספר ה-Pods המקבילים. השתמש ב-`spec.backoffLimit` כדי לשלוט בניסיונות חוזרים.

למה: Jobs מיועדים למשימות שמסתיימות עד להשלמה, בניגוד ל-Deployments ארוכי טווח. הגדרות אלו חיוניות לניהול עומסי עבודה של batch.

תזמן משימה חוזרת באמצעות תחביר cron ושלוט באופן הטיפול במשימות חופפות.

→השתמש במשאב `CronJob`. הגדר את `spec.schedule` בפורמט cron (לדוגמה, `*/5 * * * *`). הגדר `spec.concurrencyPolicy` ל-`Allow`, `Forbid`, או `Replace` עם.

למה: מבצע אוטומציה של משימות מתוזמנות. `concurrencyPolicy` קריטי למניעת הרצות חופפות (`Forbid`) או החלפת הרצות מיושנות (`Replace`).

צור במהירות manifest מסוג YAML עבור משאב מבלי ליצור אותו ב-cluster.

→השתמש בדגלים `--dry-run=client -o yaml` עם פקודות אימפרטיביות. דוגמה: `kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml`.

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

עדכן, הגדל/הקטן, בדוק סטטוס, צפה בהיסטוריה ובטל Deployment באופן אימפרטיבי.

→השתמש ב-`kubectl set image`, `kubectl scale`, `kubectl rollout status`, `kubectl rollout history`, וב-`kubectl rollout undo`.

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

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

→ב-`spec.strategy.rollingUpdate`, הגדר את `maxSurge` (כמה Pods נוספים ניתן ליצור) ואת `maxUnavailable` (כמה יכולים להיות מושבתים).

למה: איזון `maxSurge` ו-`maxUnavailable` הוא המפתח לניהול קיבולת מול שימוש במשאבים במהלך עדכונים. עבור זמן השבתה אפס, `maxUnavailable` חייב להיות פחות מ-`replicas`.

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

→הגדר `spec.strategy.type: Recreate` ב-Deployment.

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

בצע מספר שינויים ב-Deployment חי מבלי להפעיל rollout ביניים עבור כל שינוי.

→השתמש ב-`kubectl rollout pause deployment/<name>`, החל שינויים, ולאחר מכן `kubectl rollout resume deployment/<name>`.

למה: מאחד מספר עדכונים לאירוע rollout יחיד, מונע תזזיתיות ותנאי מירוץ.

הגבל את מספר ה-ReplicaSets הישנים שנשמרים עבור Deployment כדי לחסוך באחסון etcd.

→הגדר `spec.revisionHistoryLimit` למספר ה-revisions הרצוי לשמירה (לדוגמה, 3). ברירת המחדל היא 10.

למה: הגדרת מגבלה נמוכה יותר מפחיתה עומס על etcd. הגדרה ל-`0` משביתה לחלוטין את יכולת ה-rollback.

תעד את הסיבה לעדכון Deployment כך שתופיע בהיסטוריית ה-revision.

→הוסף annotation של `kubernetes.io/change-cause` ל-manifest של ה-Deployment. דוגמה: `kubectl annotate deployment/nginx kubernetes.io/change-cause="update to 1.20"`.

למה: מספק הקשר חשוב בעת צפייה בהיסטוריית ה-rollout (`kubectl rollout history`), מה שמקל על זיהוי איזה revision לבצע rollback אליו.

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

→השתמש בשני Deployments (לדוגמה, `app-blue`, `app-green`) עם labels גרסה שונים. Service יחיד בוחר את הגרסה הפעילה באמצעות ה-`selector` שלו. כדי לעבור, `kubectl patch service` כדי לעדכן את ה-selector ל-label הגרסה החדש.

למה: מספק שחרורים מיידיים בסיכון נמוך ויכולת rollback מיידית על ידי פשוט תיקון ה-selector של ה-Service בחזרה.

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

→השתמש בשני Deployments (stable, canary) החולקים את אותו selector label. Service אחד מכוון לשניהם. שלוט באחוז התנועה לפי יחס ה-replicas (לדוגמה, 9 replicas stable, 1 canary עבור 10% תנועה).

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

חשוף קבוצת Pods לתקשורת רק מתוך ה-cluster.

→השתמש ב-Service עם `type: ClusterIP`. זהו סוג ברירת המחדל.

למה: `ClusterIP` מספק כתובת IP פנימית יציבה ושם DNS עבור service, המפשט כתובות IP של Pods בודדים.

חשוף service בפורט סטטי בכתובת ה-IP של כל node.

→השתמש ב-Service עם `type: NodePort`. K8s מקצה פורט מטווח מסוים (ברירת מחדל: 30000-32767).

למה: שימושי לפיתוח או כאשר load balancer חיצוני אינו זמין. תנועה ל-`<NodeIP>:<NodePort>` מועברת ל-Service.

נתב תעבורת HTTP/S חיצונית לשירותים פנימיים על בסיס hostname או נתיב URL.

→צור משאב `Ingress`. הגדר `rules` עבור hosts ו-`http.paths` למיפוי לשירותי backend. הגדר TLS עם `spec.tls` המצביע על TLS Secret.

למה: Ingress מספק ניתוב L7, מאחד מספר שירותים תחת כתובת IP חיצונית אחת ופורק את TLS termination.

הגבל תעבורת רשת אל ומ-Pods על בסיס labels, namespaces, או IP blocks.

→צור `NetworkPolicy` המכוון ל-Pods עם `podSelector`. הגדר כללי `ingress` ו/או `egress` כדי לאפשר תעבורה ספציפית. כברירת מחדל, יישום policy ל-pod מונע את כל התעבורה שאינה מותרת במפורש.

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

מקור↗

חסום את כל תעבורת ה-ingress וה-egress עבור כל ה-pods ב-namespace כברירת מחדל.

→צור NetworkPolicy עם `podSelector: {}` ריק וכללי ingress/egress ריקים. דוגמה: `podSelector: {}, policyTypes: [Ingress, Egress]` עם.

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

ספק ערך DNS יציב שמתורגם ישירות לכל כתובות ה-IP של Pod, ללא IP וירטואלי עבור load balancing.

→צור Service עם `spec.clusterIP: None`.

למה: חיוני עבור יישומים stateful (כמו StatefulSets) או מערכות peer-to-peer שצריכות לגלות ולתקשר ישירות עם Pods ספציפיים.

ודא ש-Pods ב-backend רואים את כתובת ה-IP המקורית של הלקוח עבור תעבורה מ-NodePort או LoadBalancer Service.

→הגדר `spec.externalTrafficPolicy: Local` ב-Service.

למה: מדיניות ברירת המחדל (`Cluster`) מטשטשת את כתובת ה-IP המקורית באמצעות network address translation. `Local` שומר עליה אך עלול להוביל לחלוקת תעבורה לא אחידה אם Pods אינם נמצאים בכל ה-nodes.

ודא שכל הבקשות מלקוח ספציפי נשלחות לאותו Pod.

→ב-Service, הגדר `spec.sessionAffinity: ClientIP`.

למה: מספק 'sticky sessions', הנחוץ ליישומים מדור קודם המאחסנים מצב session בזיכרון ב-Pod ספציפי.

Pod ב-namespace אחד צריך לתקשר עם Service ב-namespace אחר.

→השתמש בשם ה-DNS המורחב: `<service-name>.<namespace-name>.svc.cluster.local` או בצורה המקוצרת `<service-name>.<namespace-name>`.

למה: שמות service פשוטים נפתרים רק בתוך אותו namespace. תקשורת בין-namespaces דורשת ציון ה-namespace היעד בשאילתת ה-DNS.

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

→`livenessProbe`: מפעיל מחדש את ה-container אם הבדיקה נכשלת. `readinessProbe`: מסיר את ה-Pod מנקודות קצה של Service אם הבדיקה נכשלת. `startupProbe`: משבית בדיקות אחרות עד שה-container מסיים את ההפעלה שלו.

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

מקור↗

אבחן מדוע Pod תקוע במצב שאינו Running (לדוגמה, Pending, ContainerCreating, CrashLoopBackOff).

→השתמש ב-`kubectl describe pod <pod-name>`. קטע ה-`Events` מספק רמזים קריטיים מה-scheduler (בעיות משאבים), kubelet (שגיאות משיכת image), או container runtime.

למה: `describe` היא הפקודה החשובה ביותר להבנת בעיות מחזור חיי Pods המתרחשות לפני שהיישום מתחיל או מדווח משהו.

בדוק את ה-logs מ-container שקרס וכעת נמצא בלולאת הפעלה מחדש (CrashLoopBackOff).

→השתמש ב-`kubectl logs <pod-name> --previous`.

למה: הדגל `--previous` מציג את ה-logs מהמופע האחרון שהופסק של ה-container, המכיל את השגיאה שגרמה לקריסה.

הצג ועקוב אחר logs מכל ה-Pods התואמים ל-label selector בזמן אמת.

→השתמש ב-`kubectl logs -l <label-selector> -f`. הוסף `--prefix` כדי לראות מאיזה pod הגיעה כל שורה.

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

בצע פקודה או קבל shell אינטראקטיבי בתוך container רץ לצורך איתור באגים.

→השתמש ב-`kubectl exec -it <pod-name> -- /bin/sh` (או `/bin/bash`). ה-`--` מפריד את דגלי kubectl מהפקודה.

למה: מספק גישה ישירה לסביבת ה-container לצורך איתור באגים חי, בדיקת קבצים, או בדיקת קישוריות רשת.

הצג את צריכת ה-CPU והזיכרון הנוכחית של Pod רץ.

→השתמש ב-`kubectl top pod <pod-name>`. השתמש ב-`--containers` כדי לראות את השימוש עבור כל container ב-Pod.

למה: דורש התקנת Metrics Server. זה חיוני לזיהוי יישומים זוללי משאבים, דליפות זיכרון, או צווארי בקבוק ב-CPU.

פתור בעיות ב-container רץ שחסר לו shell או כלי איתור באגים.

→השתמש ב-`kubectl debug <pod-name> -it --image=busybox --share-processes --copy-to=debug-pod`. זה יוצר Pod חדש עם debug container החולק את אותו process namespace.

למה: `kubectl debug` היא הדרך המודרנית לצרף "ephemeral container" זמני עם כלי איתור באגים ל-Pod רץ מבלי לשנות את מפרט ה-Pod המקורי.