כאשר אפליקציית אינטרנט גדלה לעשרות מיקרוסרוויסים, ניהול שרתים ידני הופך לסיוט. קונטיינרים קורסים, עומסים קופצים, ופריסות נכשלות. Kubernetes הוא התקן לסביבות ייצור, ומבצע אוטומציה של ניהול קונטיינרים: אתחול מחדש, קנה מידה, ועדכונים מתגלגלים. הצוות שלנו הקים Kubernetes ליותר מ-30 פרויקטים — מסטארטאפים ועד ארגונים גדולים. אנו מבטיחים פעילות יציבה תחת כל עומס.
איך להקים Kubernetes לאורקסטרציה של אפליקציות אינטרנט?
Kubernetes מנוהל (Yandex Managed Service for Kubernetes, Selectel VK Cloud) מבטל את כאב הראש של צמתי master, etcd ועדכונים. אתה משלם רק על צמתי עובדים. אנו ממליצים להשתמש בו לייצור כדי להתמקד באפליקציה ולא בתשתית. השוואה: קלאסטר מנוהל משתלם עם 5+ צמתים לעומת פריסה עצמית, ועלויות הניהול יורדות בעד 40%.
סט מינימלי של מניפסטים
כדי להתחיל, מספיקים חמישה משאבים: Namespace, Deployment, Service, Ingress, HPA. להלן תבנית עובדת עם הסברים.
---
# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: myapp
---
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-web
namespace: myapp
spec:
replicas: 3
selector:
matchLabels: { app: myapp-web }
template:
metadata:
labels: { app: myapp-web }
spec:
containers:
- name: web
image: registry.example.com/myapp:v1.0.0
ports:
- containerPort: 8080
envFrom:
- configMapRef: { name: myapp-config }
- secretRef: { name: myapp-secrets }
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 30
periodSeconds: 30
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-web
namespace: myapp
spec:
selector: { app: myapp-web }
ports:
- port: 80
targetPort: 8080
---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
namespace: myapp
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/rate-limit: "100"
nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
ingressClassName: nginx
tls:
- hosts: [example.com]
secretName: myapp-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-web
port: { number: 80 }
שילבנו את המניפסטים לבלוק אחד לקיצור. ConfigMap ו-Secret מתוארים בטקסט — המבנה שלהם טריוויאלי. חשוב: סודות מקודדים ב-base64; אל תשמור אותם במאגר, השתמש ב-# namespace.yaml apiVersion: v1 kind: Namespace metadata: name: myapp --- # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-web namespace: myapp spec: replicas: 3 selector: matchLabels: { app: myapp-web } template: metadata: labels: { app: myapp-web } spec: containers: - name: web image: registry.example.com/myapp:v1.0.0 ports: - containerPort: 8080 envFrom: - configMapRef: { name: myapp-config } - secretRef: { name: myapp-secrets } resources: requests: cpu: "100m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" readinessProbe: httpGet: { path: /health/ready, port: 8080 } initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: { path: /health/live, port: 8080 } initialDelaySeconds: 30 periodSeconds: 30 --- # service.yaml apiVersion: v1 kind: Service metadata: name: myapp-web namespace: myapp spec: selector: { app: myapp-web } ports: - port: 80 targetPort: 8080 --- # ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myapp-ingress namespace: myapp annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/rate-limit: "100" nginx.ingress.kubernetes.io/proxy-body-size: "50m" spec: ingressClassName: nginx tls: - hosts: [example.com] secretName: myapp-tls rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: myapp-web port: { number: 80 } או בחנות סודות חיצונית (Hashicorp Vault, AWS Secrets Manager).
קנה מידה אופקי ואוטוסקיילינג
HPA (HorizontalPodAutoscaler)
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
namespace: myapp
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-web
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
HPA מוסיף רפליקות אוטומטית כאשר חריגות מסף CPU או זיכרון. זה זול יותר מאשר להחזיק 20 פודים כל הזמן: בעומס נמוך הוא רץ עם 2, בשיא עד 20. ראינו את זה חוסך פרויקטים במהלך קמפיינים פרסומיים, ומפחית עלויות תשתית ב-30-50%.
משימות תקופתיות: CronJob
למשימות רקע (ניקוי קבצים, שליחת דוחות), אנו משתמשים ב-CronJob.
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: cleanup-old-files
namespace: myapp
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: cleanup
image: registry.example.com/myapp:latest
command: ["php", "artisan", "files:cleanup"]
envFrom:
- secretRef: { name: myapp-secrets }
תהליך העבודה: מניתוח לפריסה
- ניתוח — אנו לומדים את ארכיטקטורת האפליקציה, דרישות SLA ובעיות נוכחיות.
- עיצוב — אנו מתכננים את הקלאסטר: מספר צמתים, מחלקת אחסון, רשת, ingress controller.
- יישום — אנו כותבים מניפסטים, מגדירים CI/CD (GitLab CI, GitHub Actions), ומשלבים ניטור (Prometheus + Grafana).
- בדיקות — בדיקות עומס, אימות סובלנות לתקלות (chaos engineering).
- פריסה — פריסה לסטייג'ינג וייצור, הדרכת הצוות.
מה כלול בתוצאה
- מניפסטים של Kubernetes: Deployment, Service, Ingress, HPA, CronJob, ConfigMap, Secret.
- צינור CI/CD: בניית תמונות אוטומטית, פריסה דרך Helm או Kustomize.
- ניטור והתראות: לוחות מחוונים של Grafana, התראות ל-Telegram/Slack.
- תיעוד: דיאגרמת ארכיטקטורה, הוראות למפתחים.
- הדרכת צוות: 2-3 מפגשים על תפעול קלאסטר.
- שבועיים של תמיכה לאחר השקה — תיקוני באגים, שאלות ותשובות.
לוח זמנים
| שלב | זמן |
|---|---|
| מניפסטים בסיסיים + פריסה | 3–4 ימים |
| Ingress + cert-manager + TLS | +1–2 ימים |
| HPA + מגבלות משאבים | +1 יום |
| צינור GitOps מלא | 7–10 ימים |
העלות מחושבת באופן אישי לפי מורכבות הפרויקט. בקש ייעוץ — נעריך את הפרויקט שלך.
השוואה עם Docker Compose
| מאפיין | Docker Compose | Kubernetes |
|---|---|---|
| קנה מידה | ידני | אוטומטי (HPA) |
| ריפוי עצמי | לא | כן |
| גילוי שירותים | ידני | DNS מובנה |
| פשטות | גבוהה | בינונית |
Docker Compose טוב לפיתוח מקומי, אבל בייצור הוא לא יכול להתמודד עם עומס גבוה. Kubernetes מציע קנה מידה מובנה, ריפוי עצמי, גילוי שירותים ועדכונים מתגלגלים. לדוגמה, ב-1000 RPS, Kubernetes שורד כשל בצומת ללא אובדן בקשות, בעוד Docker Compose לא.
למה חשובה הגדרת משאבי קונטיינר נכונה?
SealedSecrets ו-apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa namespace: myapp spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp-web minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 שגויים מובילים להרג OOM או לניצול חסר של הקלאסטר. אנו משתמשים ב-Vertical Pod Autoscaler המבוסס על נתונים היסטוריים כדי לבחור ערכים אופטימליים. זה מפחית עלויות תשתית בעד 40% ומגביר יציבות. למידע נוסף על משאבים, ראה תיעוד Kubernetes.
טעויות נפוצות בהקמת Kubernetes
- חוסר ב-readiness ו-liveness probes: הפוד נחשב בריא אך לא מגיב לבקשות.
- מגבלות גדולות מדי מעמיסות על הקלאסטר ומפחיתות ביצועי פודים שכנים.
- אחסון סודות בטקסט פשוט יוצר סיכון דליפה.
- התעלמות ממכסות משאבים מאפשרת לפוד אחד לצרוך את כל המשאבים.
אנו עוזרים להימנע מהמלכודות הללו. צור קשר לייעוץ מפורט.
מקרה בוחן: פלטפורמת מסחר אלקטרוני
לקוח עם פלטפורמת מסחר אלקטרוני בעומס גבוה (800 RPS בממוצע, 5000 RPS בשיא ב-Black Friday) השתמש ב-Docker Compose בייצור. שרתים קרסו מדי חודש, וקנה המידה לקח 30 דקות ידנית. עברנו לקלאסטר Kubernetes על Yandex Managed Kubernetes עם HPA ועדכונים מתגלגלים. תוצאה: זמן הפריסה ירד מ-30 דקות ל-2 דקות, עלויות התשתית ירדו ב-35% בזכות התאמת גודל ואוטוסקיילינג. בעומס שיא, המערכת גדלה מ-5 ל-25 פודים אוטומטית ללא השבתה.
סיכום
Kubernetes הוא כלי חזק אך מורכב. הגדרה נכונה דורשת ניסיון. לצוות שלנו יש 10+ שנות ניסיון ב-DevOps ויותר מ-50 הטמעות. אנו מבטיחים יציבות ומהירות. קבל ייעוץ — בואו נדון בפרויקט שלך ונציע את הפתרון הטוב ביותר.







