נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן CKAD בודק. קראו מלמעלה למטה, או דלגו לסעיף.
צור 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 המקורי.