Kubernetes چیست؟ از Container تا Production
معرفی Kubernetes، Container Orchestration و راه‌حل‌های مدیریت سیستم‌های درجه Production
اگر با Docker کار کرده باشید، احتمالاً خیلی زود به یک سؤال مهم می‌رسید:
وقتی تعداد Containerها زیاد شود، چه کسی باید آن‌ها را مدیریت کند؟
فرض کنید یک سرویس ساده دارید:
1Application
2 ↓
3Docker Container
4 ↓
5Server
در ابتدا همه‌چیز ساده است. یک Container اجرا می‌کنید، Port را باز می‌کنید و سرویس در دسترس قرار می‌گیرد.
اما وقتی سیستم بزرگ‌تر می‌شود، شرایط کاملاً تغییر می‌کند:
- چندین سرویس دارید.
- هر سرویس چند Replica دارد.
- Containerها ممکن است Crash کنند.
- باید بین چند Server توزیع شوند.
- باید Load Balancing داشته باشید.
- باید Deployment بدون Downtime انجام شود.
- باید Storage پایدار داشته باشید.
- باید Secretها را مدیریت کنید.
- باید Health Check داشته باشید.
- باید Scaling انجام شود.
- باید وضعیت کل سیستم را Monitor کنید.
اینجاست که Kubernetes وارد می‌شود.
Kubernetes چیست؟
Kubernetes یک Container Orchestration Platform است که برای اجرای، مدیریت و مقیاس‌دهی workloadهای containerized طراحی شده است.
به زبان ساده:
Kubernetes سیستمی است که وضعیت مطلوب Application شما را تعریف می‌کند و تلاش می‌کند همیشه زیرساخت واقعی را به آن وضعیت نزدیک نگه دارد.
این مفهوم بسیار مهم است.
در Kubernetes شما معمولاً نمی‌گویید:
«این Container را روی این Server اجرا کن.»
بلکه می‌گویید:
«من می‌خواهم ۳ Replica از این Application همیشه در حال اجرا باشند.»
و Kubernetes مسئول رسیدن به این وضعیت است.
چرا Docker به‌تنهایی کافی نیست؟
Docker برای اجرای Container فوق‌العاده است، اما Docker به‌تنهایی مسئله‌ی orchestration در مقیاس بزرگ را حل نمی‌کند.
فرض کنید ۲۰ سرویس دارید و هر سرویس ۵ Replica دارد:
120 Services
2 ×
35 Replicas
4 =
5100 Containers
حالا چند سؤال ایجاد می‌شود:
اگر یک Container خراب شود چه؟
باید Container جدیدی جایگزین شود.
اگر یک Server از کار بیفتد چه؟
Containerهای آن Server باید روی Nodeهای دیگر اجرا شوند.
اگر Traffic افزایش پیدا کند چه؟
باید Replicaهای بیشتری ایجاد شوند.
اگر نسخه‌ی جدید Application آماده شد چه؟
باید Deployment انجام شود بدون اینکه سرویس قطع شود.
اگر نسخه‌ی جدید مشکل داشت چه؟
باید بتوانیم Rollback کنیم.
اگر یک Container بیش از حد CPU مصرف کرد چه؟
باید Resource Limit داشته باشیم.
اگر Application به Storage نیاز داشت چه؟
باید Persistent Storage در اختیار آن قرار گیرد.
حل این مسائل در مقیاس بالا با Scriptهای دستی بسیار سخت و شکننده می‌شود.
Kubernetes دقیقاً برای همین مشکلات ساخته شده است.
معماری کلی Kubernetes
یک Kubernetes Cluster معمولاً از دو بخش اصلی تشکیل می‌شود:
1 Kubernetes Cluster
2 │
3 ┌──────────────┴──────────────┐
4 │ │
5 Control Plane Worker Nodes
6 │ │
7 ┌────┼────┐ ┌─────────┼─────────┐
8 │ │ │ │ │ │
9 API Scheduler Controller Pod Pod Pod
10 Server Manager Manager
11 │
12 ▼
13 etcd
Control Plane چیست؟
Control Plane مغز Kubernetes است.
اجزای اصلی آن عبارت‌اند از:
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
در برخی معماری‌ها اجزای دیگری مانند Cloud Controller Manager نیز وجود دارند.
kube-apiserver
تمام ارتباطات اصلی Kubernetes از طریق API Server انجام می‌شود.
وقتی شما اجرا می‌کنید:
1kubectl get pods
در واقع kubectl مستقیماً با Kubernetes API ارتباط برقرار می‌کند.
مسیر کلی:
1kubectl
2 │
3 ▼
4kube-apiserver
5 │
6 ▼
7Kubernetes State
API Server نقطه‌ی مرکزی ارتباط با Cluster است.
etcd
etcd یک distributed key-value store است که Kubernetes از آن برای نگهداری state مربوط به Cluster استفاده می‌کند.
برای مثال اطلاعاتی مانند:
- Podها
- Deploymentها
- Serviceها
- ConfigMapها
- Secretها
- Nodeها
- Desired State
در state مربوط به Kubernetes ذخیره می‌شوند.
به همین دلیل:
Backup مناسب etcd یکی از بخش‌های مهم Disaster Recovery در Kubernetes است.
kube-scheduler
Scheduler تصمیم می‌گیرد یک Pod روی کدام Worker Node اجرا شود.
فرض کنید سه Node داریم:
1worker-01
2worker-02
3worker-03
و یک Pod جدید ایجاد شده است.
Scheduler عواملی مانند موارد زیر را بررسی می‌کند:
- CPU
- Memory
- Requests
- Limits
- Taints
- Tolerations
- Affinity
- Anti-Affinity
- Node Constraints
و در نهایت Node مناسب را انتخاب می‌کند.
Controller Manager
Kubernetes بر اساس مفهوم Desired State کار می‌کند.
مثلاً شما تعریف می‌کنید:
1replicas: 3
یعنی:
من سه Replica می‌خواهم.
اگر یکی از Podها Crash کند:
1Desired:
23 Pods
3
4Actual:
52 Pods
Controller متوجه اختلاف می‌شود و تلاش می‌کند:
12 Pods
2 ↓
3Create new Pod
4 ↓
53 Pods
این یکی از مهم‌ترین ویژگی‌های Kubernetes است:
Reconciliation
Worker Node چیست؟
Worker Node جایی است که Workloadهای واقعی اجرا می‌شوند.
اجزای اصلی Worker Node معمولاً شامل:
- kubelet
- Container Runtime
- kube-proxy یا مکانیزم‌های شبکه‌ی معادل
- Network Plugin / CNI
است.
kubelet
kubelet Agent مربوط به Node است.
وظیفه‌ی آن این است که وضعیت Workloadهای Node را مدیریت و گزارش کند.
به‌صورت ساده:
1Control Plane
2 │
3 ▼
4 kubelet
5 │
6 ▼
7Container Runtime
8 │
9 ▼
10 Container
Container Runtime
Kubernetes برای اجرای Containerها به Container Runtime نیاز دارد.
یکی از Runtimeهای رایج:
1containerd
است.
در این معماری:
1Kubernetes
2 ↓
3kubelet
4 ↓
5CRI
6 ↓
7containerd
8 ↓
9Container
Pod چیست؟
Pod کوچک‌ترین واحد Deployable در Kubernetes است.
در ساده‌ترین حالت:
1Pod
2 └── Container
اما Pod می‌تواند چند Container نیز داشته باشد:
1Pod
2 ├── Application Container
3 └── Sidecar Container
Containerهای داخل یک Pod معمولاً:
- Network Namespace مشترک دارند.
- IP مشترک دارند.
- می‌توانند از localhost یکدیگر استفاده کنند.
- می‌توانند Volume مشترک داشته باشند.
چرا مستقیماً Container ایجاد نمی‌کنیم؟
Kubernetes معمولاً Application را با abstractionهایی مثل Deployment مدیریت می‌کند.
مثلاً:
1apiVersion: apps/v1
2kind: Deployment
3
4metadata:
5 name: nginx
6
7spec:
8 replicas: 3
9
10 selector:
11 matchLabels:
12 app: nginx
13
14 template:
15 metadata:
16 labels:
17 app: nginx
18
19 spec:
20 containers:
21 - name: nginx
22 image: nginx:latest
23 ports:
24 - containerPort: 80
اینجا ما نگفته‌ایم:
روی Node شماره‌ی ۲ یک Container اجرا کن.
بلکه گفته‌ایم:
من سه Replica از nginx می‌خواهم.
Kubernetes بقیه‌ی کار را انجام می‌دهد.
Deployment چیست؟
Deployment یکی از مهم‌ترین Resourceهای Kubernetes است.
Deployment معمولاً برای مدیریت Stateless Applicationها استفاده می‌شود.
مثلاً:
1Deployment
2 │
3 ├── Replica 1
4 ├── Replica 2
5 └── Replica 3
اگر یکی از Replicaها از بین برود:
1Replica 1
2Replica 2
3Replica 3
4 X
Kubernetes تلاش می‌کند Replica جایگزین ایجاد کند.
Service چیست؟
Podها موجودیت‌هایی Dynamic هستند.
ممکن است Pod امروز روی:
110.244.1.10
باشد و بعد از Restart روی:
110.244.2.15
قرار بگیرد.
بنابراین نباید Applicationها را مستقیماً به IP Podها متصل کنیم.
اینجا Service وارد می‌شود.
1 Service
2 │
3 ┌────────┼────────┐
4 ▼ ▼ ▼
5 Pod 1 Pod 2 Pod 3
Service یک abstraction پایدار برای دسترسی به مجموعه‌ای از Podها فراهم می‌کند.
Ingress چیست؟
Service معمولاً برای دسترسی داخلی Cluster استفاده می‌شود.
برای HTTP/HTTPS ورودی از خارج Cluster، می‌توان از Ingress استفاده کرد.
مثلاً:
1Internet
2 │
3 ▼
4Ingress
5 │
6 ├── api.example.com
7 │ ↓
8 │ API Service
9 │
10 └── app.example.com
11 ↓
12 Web Service
در معماری‌های جدیدتر Kubernetes، Gateway API نیز برای مدیریت ترافیک HTTP و L4/L7 مورد استفاده قرار می‌گیرد.
ConfigMap و Secret
Applicationها معمولاً به configuration نیاز دارند.
مثلاً:
1DATABASE_HOST
2DATABASE_PORT
3LOG_LEVEL
برای configuration غیرحساس می‌توان از ConfigMap استفاده کرد.
برای داده‌های حساس مانند:
1DATABASE_PASSWORD
2API_TOKEN
3PRIVATE_KEY
از Secret استفاده می‌شود.
البته Secret به‌تنهایی به معنی یک سیستم کامل Secrets Management نیست و در محیط‌های حساس Production باید encryption، access control و secret lifecycle نیز در نظر گرفته شود.
Kubernetes Storage
Containerها ذاتاً ephemeral هستند.
یعنی اگر Container از بین برود، filesystem داخلی آن را نباید محل مناسبی برای نگهداری داده‌ی دائمی در نظر گرفت.
برای داده‌های Persistent از abstractionهایی مانند:
- PersistentVolume
- PersistentVolumeClaim
- StorageClass
استفاده می‌شود.
معماری:
1Application
2 │
3 ▼
4 Pod
5 │
6 ▼
7 PVC
8 │
9 ▼
10StorageClass
11 │
12 ▼
13Storage Backend
در Production می‌توان backendهایی مانند:
- Rook-Ceph
- Longhorn
- OpenEBS
- Cloud Block Storage
- Network Storage
را استفاده کرد.
Kubernetes Networking
Networking یکی از پیچیده‌ترین بخش‌های Kubernetes است.
در یک Cluster باید مواردی مانند این‌ها حل شوند:
- Pod-to-Pod Communication
- Pod-to-Service Communication
- Service Discovery
- External Traffic
- NetworkPolicy
- DNS
- Load Balancing
این وظایف معمولاً با استفاده از CNI حل می‌شوند.
نمونه‌هایی از CNI:
- Cilium
- Calico
- Flannel
Cilium با استفاده از eBPF قابلیت‌های پیشرفته‌ای برای Networking، Security و Observability فراهم می‌کند.
Kubernetes و High Availability
در محیط Production، یک Kubernetes Cluster نباید به یک Control Plane Node وابسته باشد.
معماری HA معمولاً به شکل زیر است:
1 Load Balancer
2 │
3 ┌───────────┼───────────┐
4 ▼ ▼ ▼
5 Master-01 Master-02 Master-03
6 │ │ │
7 └───────────┼───────────┘
8 │
9 etcd
در کنار آن Worker Nodeهای متعدد قرار می‌گیرند.
هدف این است که failure یک Node باعث از دست رفتن کل Cluster نشود.
Kubernetes و GitOps
یکی از الگوهای مهم در محیط‌های مدرن، GitOps است.
در GitOps، Git به منبع اصلی Desired State تبدیل می‌شود.
مثلاً:
1Git Repository
2 │
3 ▼
4Kubernetes Manifests
5 │
6 ▼
7GitOps Controller
8 │
9 ▼
10Kubernetes Cluster
ابزارهایی مانند:
- Argo CD
- Flux
می‌توانند این مدل را پیاده‌سازی کنند.
مزیت اصلی این مدل:
- Auditability
- Version Control
- Reproducibility
- Rollback
- Review
- Automation
است.
Kubernetes و Observability
Deploy کردن Application پایان کار نیست.
در Production باید بتوانیم بفهمیم:
سیستم الان چه وضعیتی دارد؟
سه سیگنال اصلی Observability:
1Logs
2Metrics
3Traces
معماری متداول:
1Application
2 │
3 ├── Logs ──────→ Elasticsearch
4 │
5 ├── Metrics ───→ Prometheus
6 │
7 └── Traces ────→ Jaeger
8 │
9 ▼
10 Grafana
OpenTelemetry نیز می‌تواند به‌عنوان لایه‌ی استاندارد جمع‌آوری و انتقال telemetry در این معماری قرار گیرد.
Kubernetes فقط یک ابزار نیست
یکی از اشتباهات رایج این است که Kubernetes را صرفاً یک ابزار برای اجرای Container بدانیم.
Kubernetes در واقع مجموعه‌ای از مفاهیم مهندسی را در اختیار ما قرار می‌دهد:
1Desired State
2 +
3Reconciliation
4 +
5Scheduling
6 +
7Service Discovery
8 +
9Scaling
10 +
11Self Healing
12 +
13Rolling Deployment
14 +
15Declarative Configuration
به همین دلیل یادگیری Kubernetes فقط حفظ کردن دستورات kubectl نیست.
مسیر یادگیری پیشنهادی
اگر تازه وارد Kubernetes شده‌اید، پیشنهاد می‌شود این مسیر را طی کنید:
1Linux
2 ↓
3Networking
4 ↓
5Git
6 ↓
7Docker
8 ↓
9Container Networking
10 ↓
11Kubernetes Fundamentals
12 ↓
13Pods
14 ↓
15Deployments
16 ↓
17Services
18 ↓
19Ingress
20 ↓
21ConfigMap / Secret
22 ↓
23Storage
24 ↓
25Networking
26 ↓
27Security
28 ↓
29Observability
30 ↓
31Helm
32 ↓
33Kustomize
34 ↓
35GitOps
36 ↓
37Production Kubernetes
بعد از این مرحله می‌توانید وارد مباحث پیشرفته‌تر شوید:
1Kubernetes
2 ↓
3CNI / Cilium
4 ↓
5Service Mesh
6 ↓
7Advanced Scheduling
8 ↓
9Distributed Storage
10 ↓
11HA
12 ↓
13Disaster Recovery
14 ↓
15Cluster Security
16 ↓
17Platform Engineering
جمع‌بندی
Kubernetes پاسخی به یک مسئله‌ی ساده اما بسیار مهم است:
چگونه تعداد زیادی Workload را به‌صورت قابل اعتماد، قابل تکرار و خودکار اجرا و مدیریت کنیم؟
اما یادگیری Kubernetes نباید با حفظ کردن دستورات شروع و با اجرای یک Deployment تمام شود.
برای تبدیل شدن به یک Kubernetes Engineer واقعی باید لایه‌های مختلف سیستم را بشناسید:
1Linux
2 ↓
3Networking
4 ↓
5Container
6 ↓
7Kubernetes
8 ↓
9Storage
10 ↓
11Security
12 ↓
13Observability
14 ↓
15Automation
16 ↓
17GitOps
18 ↓
19Production Engineering
و مهم‌تر از همه باید بتوانید با Failure کار کنید.
چون Kubernetes واقعی جایی است که:
1Node Down
2Pod Crash
3Network Failure
4Storage Failure
5Registry Failure
6Certificate Expired
7High CPU
8Memory Pressure
9DNS Failure
10Deployment Failure
اتفاق می‌افتد.
مهندس واقعی کسی نیست که فقط بتواند سیستم را بالا بیاورد؛
مهندس واقعی کسی است که بتواند بفهمد چرا سیستم پایین آمده، چگونه آن را برگرداند و چگونه کاری کند که دفعه‌ی بعد همان اتفاق تکرار نشود.
در ادامه چه چیزهایی یاد می‌گیریم؟
در سری مقالات Kubernetes در گیتنامی، مرحله‌به‌مرحله وارد مباحث زیر می‌شویم:
- Kubernetes Architecture
- نصب Kubernetes با kubeadm
- Pod و Container Lifecycle
- Deployment و ReplicaSet
- Service و Service Discovery
- Ingress و Gateway API
- ConfigMap و Secret
- Kubernetes Networking
- CNI و Cilium
- Persistent Storage و CSI
- StatefulSet
- Resource Management
- Scheduling
- Kubernetes Security
- Monitoring با Prometheus و Grafana
- Logging با Elasticsearch
- Distributed Tracing با Jaeger و OpenTelemetry
- Helm
- Kustomize
- GitOps با Argo CD
- High Availability
- Backup و Disaster Recovery
- Troubleshooting Production Cluster
- Kubernetes در معماری‌های Production
گیتنامی — From Infrastructure to Production AI Engineering