שירותי פריסה וניהול של Kubernetes

Pod במצב CrashLoopBackOff בזמן שהצמתים עמוסים ב-15%? מתחילים מהבעיה האמיתית

תמונה טיפוסית: kubectl describe pod מציג OOMKilled, מגבלות מוגדרות באקראי, ניטור לא מוגדר, אוטוסקיילינג לא קיים. הקלאסטר "הושק רק עכשיו" — ועכשיו הוא אוכל תקציב אבל לא מתמודד עם עומס. פרסנו מעל 50 קלאסטרים פרודקשן בעננים מרובים, הקמנו צוות של 10 מהנדסים מוסמכים, ואנחנו יודעים להפוך כאוס לאורקסטרציה צפויה. אנחנו בוחרים שירות מנוהל (EKS, GKE, AKS) לתשתית שלכם, מגדירים HPA/VPA/KEDA, מיישמים GitOps דרך Helm ו-ArgoCD, ומבטיחים פעילות קלאסטר תקינה.

למה Kubernetes מנוהל: EKS, GKE או AKS?

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

ארכיטקטורת הבסיס של Kubernetes זהה, אבל הבחירה בשירות מנוהל קובעת את עלויות התפעול. EKS מציעה תאימות מקסימלית ל-AWS: IRSA, ALB דרך AWS Load Balancer Controller, EBS CSI Driver. ב-EKS עדיף להשתמש ב-Karpenter במקום Cluster Autoscaler — צמתים עולים תוך 30–60 שניות לעומת 3–5 דקות, והוא יכול לערבב spot/on-demand דרך NodePool. Karpenter מריץ צמתים עד פי 6 מהר יותר מהאוטוסקיילר הסטנדרטי, מה שמקצר ישירות עיכובי סקיילינג.

GKE הוא ה-Kubernetes הכי "ילידי" (גוגל יצרה אותו, פרויקט Kubernetes). GKE Autopilot מבטל את הצורך בניהול node pools — משלמים רק על פודים. AKS נוח בסביבת מיקרוסופט: Azure AD ל-RBAC, Key Vault דרך CSI, pipelines דרך GitHub Actions.

איך עובדים HPA, VPA ו-KEDA? דוגמה עם חיסכון אמיתי

אוטוסקיילינג לא תקין או שלא מתמודד עם עומס או שורף כסף. נבחן שלושה מנגנונים. HPA (Horizontal Pod Autoscaler) — סקיילינג לפי CPU. מניפסט בסיסי:

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 — חובה. בלעדיו, HPA מתנודד בין רפליקות תחת עומס פועם. מדיניות stabilizationWindowSeconds: 300 מגבילה את מהירות ה-scale-down. בפרודקשן אמיתי משתמשים במדדים מותאמים: RPS דרך Prometheus Adapter, עומק תור RabbitMQ.

VPA (Vertical Pod Autoscaler) מתקן requests/limits נכונים. מצב Percent: 10 נותן המלצות, Off מאתחל פודים. בפרודקשן, אנחנו מרבים להשתמש ב-Auto עם Rolling Update שבועי. VPA במצב Off לא תואם ל-HPA על CPU — הם מתנגשים.

KEDA (Kubernetes Event-Driven Autoscaling) מבצע סקיילינג לפי מקורות חיצוניים: אורך תור SQS, פיגור Kafka, RPS HTTP. הוא יכול לסקל לאפס — נוח לעובדי batch.

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-scaledobject spec: scaleTargetRef: name: queue-worker minReplicaCount: 0 maxReplicaCount: 50 triggers: - type: aws-sqs-queue metadata: queueURL: https://sqs.eu-west-1.amazonaws.com/123456789/jobs queueLength: "5" awsRegion: eu-west-1 authenticationRef: name: keda-aws-credentials 

Auto — עובד אחד לכל 5 הודעות. מגיעות 100 הודעות — מופעלים 20 עובדים. התור ריק למשך 5 דקות — העובדים יורדים לאפס. החיסכון ב-instances יכול להגיע ל-40–60% מעלות של מספר קבוע של פודים. במונחים כספיים, מדובר בחיסכון חודשי של $2,000–$5,000 לפרויקט ממוצע של 50 מיקרוסרוויסים.

מקרה: סטארטאפ של 50 מיקרוסרוויסים חסך סכום משמעותי בחודש. ללקוח היו צמתים קבועים בעלות $8,000/חודש, העומס היה פועם (משימות batch ליליות). יישמנו HPA לפי RPS ו-KEDA לתורים — בלי לשנות קוד, החשבון ירד ל-$3,200/חודש עם אותה תפוקה. החזר השקעה לפרויקט — 3 שבועות. צרו קשר לביקורת אוטוסקיילינג חינמית ותראו כמה אפשר לחסוך.

איך Helm מפשט ניהול גרסאות?

Helm הוא התקן דה-פקטו לפריסה. אבל apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-scaledobject spec: scaleTargetRef: name: queue-worker minReplicaCount: 0 maxReplicaCount: 50 triggers: - type: aws-sqs-queue metadata: queueURL: https://sqs.eu-west-1.amazonaws.com/123456789/jobs queueLength: "5" awsRegion: eu-west-1 authenticationRef: name: keda-aws-credentials בלי flags הוא דרך לאסון. מבנה דרך overlay:

charts/api/ Chart.yaml values.yaml # base values values.prod.yaml # production overrides values.staging.yaml # staging overrides templates/ 

queueLength: "5" — דגל helm upgrade --install מחזיר את הגרסה לאחור אם פודים לא עולים תוך 5 דקות. בלעדיו, הקלאסטר עלול להישאר במצב מעודכן חלקית.

Helm מתקן ניהול פריסה וגרסאות. Helm Secrets דרך SOPS + Age או AWS KMS מאחסן סודות מוצפנים במאגר. חלופה — External Secrets Operator, שמביא סודות מ-AWS Secrets Manager או HashiCorp Vault.

מתי צריך Kubernetes Operators?

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

• CloudNativePG — PostgreSQL: failover אוטומטי, גיבויי PiTR ל-S3, ניהול רפליקות דרך CRD.
• Strimzi — Kafka: מנהל brokers, topics, users; TLS מובנה.
• VictoriaMetrics Operator — ניטור: תואם ל-Prometheus CRD, צורך הרבה פחות זיכרון.

אם אין operator מוכן, אנחנו כותבים משלנו באמצעות Kubebuilder (Go). מקרה טיפוסי — operator לטעינה חמה של קונפיגורציה: עוקב אחרי שינויים ב-charts/api/ Chart.yaml values.yaml # base values values.prod.yaml # production overrides values.staging.yaml # staging overrides templates/ , קורא ל-endpoint helm upgrade api ./charts/api -f values.yaml -f values.prod.yaml --atomic --timeout 5m של היישום.

איך מגדירים RBAC בלי cluster-admin?

RBAC זה לא "קובעים ושוכחים". טעות אופיינית: לתת לצוות cluster-admin "בשביל המהירות". ואז --atomic מקרי.

עקרון ההרשאות המינימליות דרך ConfigMap ו-/reload:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: production rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] 

עבור kubectl delete namespace production, צריך להוסיף במפורש Role, עבור port-forward — RoleBinding. מערכות CI/CD מקבלות ServiceAccount עם הרשאות רק על apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: production rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] ב-namespaces ספציפיים.

יומן ביקורת מופעל כברירת מחדל בקלאסטרים מנוהלים. מדיניות ביקורת לפרודקשן מתעדת את כל פעולות הכתיבה ו-kubectl exec.

למה Network Policies קריטיות לאבטחה?

כברירת מחדל ב-Kubernetes, כל הפודים יכולים לתקשר זה עם זה — לא מקובל בפרודקשן.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-ingress namespace: production spec: podSelector: matchLabels: app: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: nginx-ingress ports: - protocol: TCP port: 8080 

pods/exec מקבל תעבורה רק מ-ingress controller. מסד הנתונים — רק מ-pods/portforward. ניטור — רק מ-namespace Deployment patch. היישום דורש CNI עם תמיכה ב-Network Policy: Calico או Cilium (eBPF מהיר יותר).

לוחות זמנים והיקף עבודה אופייניים

העלות מחושבת באופן אישי לאחר ביקורת. חיסכון ממוצע בתשתית לאחר יישום אוטוסקיילינג — $2,000–$5,000 בחודש, פרויקטים מחזירים את ההשקעה תוך 3–6 חודשים.

תהליך

1. ביקורת — פרופיל עומס, ניתוח אבטחה, הערכת עלויות נוכחית.
2. תכנון — בחירת שירות מנוהל, תכנית אוטוסקיילינג, RBAC, מדיניות רשת.
3. פריסה — הגדרת קלאסטר, Helm charts, ניטור (Prometheus + Grafana) והתראות.
4. בדיקות — מבחני עומס, תרחישי כשל (כשל פוד, כשל צומת), פריסה canary.
5. השקה — העברת תעבורה, blue-green או canary, התחייבות SLO.
6. תמיכה — runbook, תמיכה לאחר השקה למשך חודש עם SLA 99.9%.

מה כלול

• ביקורת קלאסטר נוכחי והמלצות ארכיטקטוניות.
• פריסת קלאסטר מנוהל עם אוטוסקיילינג מוגדר, RBAC, Network Policies, ניטור (Prometheus + Grafana).
• תיעוד ארכיטקטורה ו-runbook.
• הכשרת צוות (סדנה של 2–4 שעות).
• תמיכה לאחר השקה למשך חודש עם SLA 99.9%.

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