Kubernetes Manifests ללא כאב

למה K8s כואב, ולמה Claude משנה את זה

חברת SaaS ישראלית עברה ל-Kubernetes אחרי שגדלה ל-10M בקשות ביום. הבעיה: אף אחד בצוות לא ידע K8s ברמה מספיקה. בשבוע הראשון, Claude כתב את כל ה-manifests הבסיסיים, הסביר כל שדה, ועזר לאבחן 3 אירועי CrashLoopBackOff. הצוות עלה ל-production תוך 3 שבועות במקום 3 חודשים.

Kubernetes מפורסם ב-boilerplate ובמורכבות. manifest של Deployment בסיסי יכול להיות 80 שורות YAML עם עשרות שדות אופציונליים שכל אחד מהם בעל אפקט. Claude יודע מה כל שדה עושה, מתי להשתמש בו, ומה הטעות שרוב הצוותים עושים. נכון ל-2026, ניתן גם לחבר Claude ישירות לקלסטר דרך MCP servers ייעודיים ולבצע kubectl בשפה טבעית.

מה תקבל: חבילת manifests מלאה מתיאור אחד

כדי לקבל פלט production-ready מ-Claude, צריך לספק הקשר מלא. ה-prompt הבא מייצר Deployment, Service, Ingress, HPA, ConfigMap, Secret stub, ו-PodDisruptionBudget:

אתה K8s architect עם 7 שנות ניסיון ב-EKS production.
כתוב manifests מלאים לשירות Node.js API:

פרטי ה-workload:
- Image: 123456.dkr.ecr.il-central-1.amazonaws.com/api:v1.2.3
- Port: 3000 | Namespace: production

Scaling:
- Replicas: 3 כברירת מחדל
- HPA: min 2, max 20, target CPU 65%, target Memory 70%
- PodDisruptionBudget: minAvailable 2

Resources:
- requests: cpu 200m, memory 256Mi
- limits: cpu 1000m, memory 512Mi

Configuration:
- DB_URL, REDIS_URL, JWT_SECRET מגיעים מ-Secret (שם: api-secrets)
- LOG_LEVEL=info, NODE_ENV=production מ-ConfigMap

Health checks:
- Liveness: GET /health, initialDelay 30s, period 10s, failure 3
- Readiness: GET /ready, initialDelay 10s, period 5s, failure 2
- Startup probe: GET /health, failureThreshold 30, period 10s

Networking:
- Ingress: api.mycompany.co.il → port 3000
- TLS מ-cert-manager (ClusterIssuer: letsencrypt-prod)

Update strategy:
- Rolling update, maxSurge 1, maxUnavailable 0
- Termination grace period: 60 seconds

Security context:
- runAsNonRoot: true | runAsUser: 1000
- readOnlyRootFilesystem: true

כתוב כל resource בקובץ נפרד עם --- separator ועם הסבר קצר על כל section.

כמה דברים חשובים בבקשה זו:

• Startup probe, שדה שרוב tutorials מדלגים עליו. בלעדיו, Java/Node.js apps שלוקחות זמן לעלות מקבלים Liveness kill לפני שהם מוכנים.
• Termination grace period: 60 seconds, מאפשר ל-Node.js לסיים בקשות בתהליך לפני shutdown. קריטי ב-rolling deploy.
• Security context, runAsNonRoot ו-readOnlyRootFilesystem הם best practice שאם לא תבקש במפורש, Claude עלול לוותר עליהם.
• maxUnavailable: 0, zero-downtime rolling update. pod חדש עולה קודם, ורק אחרי שהוא ready ה-pod הישן נמחק.

אבחון CrashLoopBackOff בלי לנחש

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

ה-pod נמצא במצב CrashLoopBackOff. עזור לי לאבחן:

kubectl describe pod api-7d4f9c-xkp2q:
[הדבק את הפלט המלא]

kubectl logs api-7d4f9c-xkp2q --previous:
[הדבק logs של 50 שורות אחרונות]

קובץ ה-Deployment שלי:
[הדבק את ה-YAML]

אבחן:
1. מה הגורם המיידי ל-crash
2. האם זו בעיית configuration, resource limit, או קוד
3. צעדי debugging נוספים
4. Fix מוצע
5. איך למנוע בעתיד

הדגל --previous הוא קריטי, הוא מציג logs של ה-container שמת, לא של ה-container החדש שעדיין לא קרס. Claude יבדיל בין OOMKilled (חריגת memory limit), ImagePullBackOff (אין access ל-ECR), וexception ב-startup.

Kustomize, ניהול סביבות בלי copy-paste

אחת הטעויות הנפוצות: deployment-staging.yaml, deployment-production.yaml, deployment-dev.yaml, שלושה קבצים שמסתנכרנים בקושי. Claude יכול לכתוב מבנה Kustomize מלא:

כתוב מבנה Kustomize עם:
- base/: Deployment, Service, ConfigMap בסיסיים
- overlays/staging/: 1 replica, resources קטנים, ingress ל-staging.myapp.co.il
- overlays/production/: 3 replicas, HPA, PDB, ingress ל-api.myapp.co.il
השתמש ב-patches ולא בגרסאות מלאות של ה-resources.

Kustomize מובנה ב-kubectl מגרסה 1.14 ואינו דורש התקנה נוספת. Claude יכתוב את kustomization.yaml לכל סביבה עם patches מדויקים.

MCP Kubernetes, Claude ישירות לקלסטר (2026)

נכון לתחילת 2026, ניתן לחבר Claude Desktop לקלסטר K8s אמיתי דרך MCP servers. שני כלים פופולריים:

עם MCP, Claude יכול לבצע kubectl get pods, לנתח events, ולהציע fixes, הכל בצ'אט. Anthropic פרסמו ש"צוותים פנימיים פותרים בעיות K8s שדרשו בעבר מעורבות צוותי תשתית שלמים" דרך Claude Code עם MCP.

הטעויות שהורסות פרודקשן

הקהילה מדווחת שהבעיה הגדולה עם AI-generated manifests היא overconfidence: הכלי כותב YAML שנראה מושלם אבל חסר הגדרות קריטיות. "The YAML looks perfect until you realize there are no resource limits and the pod is OOMKilling your node.", דיון נפוץ ב-r/devops.

• אין resource limits: pod ללא limits גונב CPU/memory מה-node ומוריד pods אחרים. זו הטעות הכי נפוצה ב-AI-generated manifests. תמיד בקשו במפורש.
• Secrets ב-ConfigMap: ConfigMap לא מוצפן, JWT secrets, DB passwords, API keys שמורים שם חשופים לכל מי שיש לו kubectl get cm. תמיד Secret, ועדיף עם External Secrets Operator.
• Liveness probe אגרסיבי: initialDelaySeconds=5 ל-Java app שלוקח 45 שניות לקום גורם ל-K8s להרוג ולהפעיל מחדש ללא הפסקה. Startup probe פותר זאת.
• בלי PodDisruptionBudget: kubectl drain node יסיר את כל ה-pods בבת אחת. PDB עם minAvailable 1 מבטיח שתמיד יהיה pod אחד פעיל בזמן maintenance.

Pro Tip: Runbook אוטומטי

כשמשתמשים ב-Claude לכתיבת manifests מורכבים, בקשו גם runbook קצר:

כתוב runbook קצר לצוות On-Call:
- מה לעשות אם ה-pod ב-CrashLoopBackOff
- מה לעשות אם ב-OOMKilled
- מה לעשות אם ב-Pending יותר מ-5 דקות
- הפקודות המדויקות לכל מקרה

שמרו את ה-runbook ב-Notion/Confluence. זה חוסך שעות debugging בשעות הלילה כשהstress גבוה והזיכרון קצר.