کوبرنتیز چیست؟ معماری، استقرار، امنیت و هزینه واقعی

سه Replica از API دارید، داشبورد همه را سبز نشان می‌دهد و نام کلاستر هم «Production-HA» است. اما هر سه Pod روی یک Node افتاده‌اند، Readiness فقط پاسخ صفحه اصلی را می‌سنجد، Resource request ندارید و دیتابیس روی یک دیسک بدون Restore test است. با خرابی همان Node، سرویس قطع می‌شود. Kubernetes خراب نشده؛ فقط Desired state ناقصی را دقیق اجرا کرده است.

کانتینرسازی، اپلیکیشن و وابستگی‌های Runtime آن را به Image قابل‌نسخه‌بندی تبدیل می‌کند. Kubernetes این Workloadهای کانتینری را با API اعلانی، Scheduler و Controllerها روی مجموعه‌ای از Nodeها هماهنگ می‌کند. اما نه Container تضمین می‌کند «همه‌جا دقیقاً یکسان» اجرا شوید و نه Kubernetes به‌تنهایی High availability، Zero downtime، امنیت، کاهش هزینه یا حذف Vendor lock-in می‌سازد.

کانتینر، Docker و Kubernetes چه تفاوتی دارند؟

مستند رسمی Docker درباره Container آن را Process ایزوله با فایل‌های لازم معرفی می‌کند؛ Containerها معمولاً Kernel میزبان را به‌اشتراک می‌گذارند، درحالی‌که VM سیستم‌عامل و Kernel خود را دارد. VM و Container نیز رقیب مطلق نیستند؛ بسیاری از Nodeهای Kubernetes خود VM هستند.

آیا Kubernetes هنوز Docker را اجرا می‌کند؟

Kubernetes برای اجرای Pod به Runtime سازگار با CRI نیاز دارد. ادغام داخلی Docker Engine با نام Dockershim از Kubernetes ۱.۲۴ حذف شد؛ صفحه رسمی Container runtimeهای Kubernetes گزینه‌هایی مثل containerd و CRI-O را توضیح می‌دهد. این تغییر مانع Build کردن Image با Docker نیست؛ Image سازگار همچنان می‌تواند روی Runtime مناسب اجرا شود.

Portability کانتینر مرز دارد

Image وابستگی‌های User-space را ثابت می‌کند، نه کل جهان اجرا را. Architecture پردازنده، Kernel feature، Runtime، Cgroup، Filesystem، DNS، Storage class، Load balancer، IAM، GPU، Secret store و سرویس‌های Cloud می‌توانند رفتار را عوض کنند. Image لینوکسی روی Node ویندوزی به‌صورت جادویی اجرا نمی‌شود و Image با Tag شناور نیز Artifact ثابت نیست.

آیا واقعاً به Kubernetes نیاز دارید؟

پرسش خوب «آیا Kubernetes مدرن است؟» نیست؛ «کدام پیچیدگی موجود را با کدام پیچیدگی جدید عوض می‌کنیم؟» است. اگر هنوز مرز سرویس‌ها، Deployment contract و مالکیت عملیات روشن نیست، Kubernetes مشکل معماری را پنهان نمی‌کند. انتخاب Monolith، Modular monolith یا Microservice را ابتدا با راهنمای مونولیت و میکروسرویس حل کنید.

نشانه‌های تناسب

• چند Workload با چرخه Release، Scale و مالک مستقل دارید.
• تیم‌ها به یک API استاندارد برای Deploy، Policy، Secret، Traffic و Telemetry نیاز دارند.
• بار متغیر یا Batch/Job دارید و می‌توانید معیار Scale قابل‌اعتماد تعریف کنید.
• SLO هزینه Platform team، On-call، Upgrade و Capacity reserve را توجیه می‌کند.
• Pipeline، Registry، Observability، Security ownership و Infrastructure as Code حداقل بلوغ را دارند.

نشانه‌های Overkill

• یک وب‌سایت استاتیک، WordPress ساده یا Monolith کوچک دارید.
• Release کم، بار قابل‌پیش‌بینی و تیم عملیاتی محدود است.
• دلیل اصلی «رزومه»، Trend یا امید به کاهش خودکار هزینه است.
• هیچ‌کس مسئول Upgrade، Incident، Security patch و Restore نیست.
• State، Backup و Dependencyها هنوز خارج از هر Runbook قرار دارند.

ماتریس انتخاب میزبانی

Managed K8s پاسخ پیش‌فرض معقول‌تری برای شروع جدی است، اما حتی آن نیز CNI، Ingress/Gateway، Node pool، Upgrade policy، Backup، Observability و امنیت Workload را کامل به ارائه‌دهنده واگذار نمی‌کند. Scope مسئولیت را خط‌به‌خط در قرارداد سرویس بخوانید.

معماری کلاستر Kubernetes

طبق مستند رسمی اجزای Kubernetes، کلاستر از Control plane و یک یا چند Worker node تشکیل می‌شود.

Control plane سالم به معنی اپلیکیشن سالم نیست؛ همچنین اختلال Control plane الزاماً همه Podهای جاری را فوراً متوقف نمی‌کند. Control plane، Data plane و Dependencyهای بیرونی را جدا پایش و آزمایش کنید.

Desired state و Reconciliation چگونه کار می‌کنند؟

شما می‌گویید سه Replica با Image مشخص می‌خواهید. Controller وضعیت فعلی را می‌بیند و برای نزدیک‌شدن به آن وضعیت اقدام می‌کند. این مدل همگرایی است، نه Transaction فوری: Scheduling، Pull image، Attach volume، Probe و Endpoint update زمان می‌برند. پس Timeout، Backoff، Pending capacity و شرایط شکست بخشی از قراردادند.

Objectهای اصلی را براساس رفتار انتخاب کنید

مسیر Request را پیش از Manifest رسم کنید

User → DNS/CDN/WAF → Load balancer/Gateway → Service → Ready Pod → API → Queue/Cache/Database/Third party

برای هر پیکان Owner، Timeout، Retry، TLS، Authentication، Limit، SLI و رفتار شکست بنویسید. Kubernetes فقط بخش‌هایی از این مسیر را مدیریت می‌کند. اگر API به Dependency کند وابسته است، افزایش Replica ممکن است فشار را بیشتر و Incident را بدتر کند. قرارداد Timeout/Idempotency/Backpressure را با راهنمای قابلیت اطمینان API تکمیل کنید.

قرارداد Workload قبل از Deploy

Image امن و تکرارپذیر بسازید

• Build once و Promote همان Digest میان محیط‌ها؛ در Production از Tag شناور مثل latest پرهیز کنید.
• Base image کوچک، مشخص و Patch‌شونده انتخاب کنید؛ Multi-stage build و Dependency lock به کاهش سطح حمله کمک می‌کنند.
• SBOM، Vulnerability scan، Provenance/Attestation و سیاست Admission را به Risk tier وصل کنید.
• Container را تا حد ممکن Non-root، با Read-only root filesystem و Capability حداقلی اجرا کنید.
• Secret را داخل Image یا Repository نگذارید و Build credential را در Layer باقی نگذارید.

Pipeline باید Artifact را بسازد، تست کند و همان Artifact تأییدشده را Deploy کند. جزئیات Digest، SBOM، Provenance، OIDC، Canary و Rollback در راهنمای CI/CD امن</a آمده است.

Resource request و limit پایه Scheduling و هزینه‌اند

مستند Resource management Kubernetes توضیح می‌دهد Scheduler براساس Request تصمیم می‌گیرد Pod روی کدام Node جا می‌شود و Kubelet Limit را اعمال می‌کند. Request کم می‌تواند Overcommit و Eviction بسازد؛ Request زیاد ظرفیت را قفل و هزینه را پنهان می‌کند. CPU limit ممکن است Throttling و Memory limit می‌تواند OOM kill ایجاد کند.

LimitRange، ResourceQuota و Policy جلوی Workload بی‌قرارداد را می‌گیرند. Sidecar، Init container و DaemonSet را در هزینه/ظرفیت فراموش نکنید.

Scheduling فقط «بهینه‌ترین توزیع» نیست

Scheduler قیود و امتیازها را اعمال می‌کند؛ هدف کسب‌وکار یا کمترین قبض شما را خودکار نمی‌داند. Node selector/affinity، Taint/Toleration، Topology spread، Anti-affinity، Priority و Preemption باید براساس Failure domain و اهمیت سرویس طراحی شوند. سه Replica بدون Spread ممکن است روی یک Node یا Zone جمع شوند.

Startup، Readiness و Liveness را جدا تعریف کنید

مستند رسمی Probeهای Kubernetes سه معنا را تفکیک می‌کند: Startup یعنی برنامه آغاز شده؛ Readiness یعنی اکنون Traffic بگیرد؛ Liveness یعنی Restart احتمالاً بازیابی می‌کند. Liveness بد می‌تواند زیر بار، Containerهای سالم را پشت سر هم Restart و Cascading failure ایجاد کند.

Self-healing با High availability یکی نیست

Kubernetes می‌تواند Container را Restart و Pod جایگزین ایجاد کند، اما Node خراب را «به‌همراه state همان لحظه منتقل» نمی‌کند. تشخیص Failure، Eviction، Scheduling، Image pull، Volume attach و Warm-up زمان دارند. Replica، ظرفیت آزاد، Spread، Readiness و Dependency مقاوم باید از قبل موجود باشند.

Autoscaling را به سیگنال صف و SLO وصل کنید

HPA تعداد Replica را براساس Metric تنظیم می‌کند؛ Node autoscaler ظرفیت Node را تغییر می‌دهد و این دو Loop زمان و محدودیت جدا دارند. در مستند رسمی HPA آمده که برای CPU utilization، نبود Resource request متناظر می‌تواند Metric را تعریف‌نشده کند و مانع اقدام HPA شود.

• برای Web، فقط CPU کافی نیست؛ RPS، concurrency، queue depth، latency و saturation را بررسی کنید.
• Scale-up را با زمان Provision Node، Pull image، Startup و Warm cache بسنجید.
• Scale-down با Connection، Job، Session و Graceful termination هماهنگ باشد.
• Min replica و Headroom را از SLO و Failure domain بگیرید؛ Scale-to-zero رایگان نیست.
• Load test باید هم App scaling و هم Cluster capacity را فعال کند.

Service، Gateway و مسیر ورودی

Service مجموعه متغیر Podها را پشت Endpoint پایدار قرار می‌دهد. برای HTTP بیرونی، Gateway/Ingress controller یا Load balancer لازم است. مستند Ingress Kubernetes اعلام می‌کند API آن Frozen است و پروژه برای قابلیت‌های جدید Gateway را توصیه می‌کند؛ این به معنی حذف فوری Ingressهای موجود نیست.

Controller/Implementation را جدا از API Object ارزیابی کنید. TLS termination، Client IP، Timeout، body size، WebSocket/gRPC، health check، rate limit، WAF، log، upgrade و failure mode Vendor-specific می‌شوند. DNS، CDN و Origin protection نیز بیرون از Manifest ساده‌اند.

NetworkPolicy بدون CNI پشتیبان فقط YAML است

مدل شبکه Kubernetes به Podها ارتباط می‌دهد؛ محدودکردن East-west و Egress نیازمند NetworkPolicy و پیاده‌سازی CNI سازگار است. Default deny ورودی/خروجی را در Namespace آزمایشی شروع کنید، سپس DNS، Telemetry، Registry و Dependencyهای مجاز را دقیق Allow کنید. Egress بی‌حد، SSRF و Exfiltration را ساده می‌کند.

State و Storage: PVC معادل Backup نیست

Volume موقت با حذف Pod از بین می‌رود؛ PersistentVolume چرخه‌ای جدا دارد، اما دوام آن به CSI، Reclaim policy، Zone، Snapshot و Backend وابسته است. StatefulSet هویت و ترتیب را مدیریت می‌کند، نه Consistency دیتابیس یا Restore.

طرح Backup و Disaster recovery را با راهنمای RPO/RTO و Restore drill کامل کنید. Backup بدون بازیابی آزموده‌شده فقط امید است.

Rolling update تضمین Zero downtime نیست

Deployment می‌تواند Replica جدید را تدریجی جایگزین کند، ولی موفقیت به ظرفیت Surge، Readiness صحیح، Drain، Shutdown، Load balancer، Dependency و سازگاری نسخه‌ها وابسته است.

قرارداد Release امن

1. Image با Digest و Config version مشخص Deploy شود.
2. maxSurge و maxUnavailable با ظرفیت و SLO تنظیم شوند.
3. Pod پیش از Ready شدن Cache/Connection لازم را Warm کند.
4. با SIGTERM پذیرش کار جدید متوقف، درخواست جاری Drain و سپس Process بسته شود.
5. Schema DB به‌صورت Expand→Migrate→Contract با نسخه قبل/بعد سازگار باشد.
6. Canary براساس Error/Latency/Business SLI ارزیابی و Rollback تمرین شود.

Blue-green و Canary معمولاً به Controller/Service mesh/CD system اضافه نیاز دارند. ابزار بیشتر بدون Decision rule و Ownership فقط مسیر شکست جدید می‌سازد.

PodDisruptionBudget چه کاری نمی‌کند؟

مستند Disruptionهای Kubernetes تصریح می‌کند PDB تعداد اختلال هم‌زمان ناشی از Evictionهای داوطلبانه را محدود می‌کند؛ جلوی خرابی غیرارادی را نمی‌گیرد و Deployment rollout هم مستقیماً با PDB محدود نمی‌شود. Replica، ظرفیت، topology و تنظیم خود Workload همچنان ضروری‌اند.

امنیت Kubernetes چهار سطح دارد

چک‌لیست رسمی امنیت Kubernetes نقطه شروع است، نه گواهی امنیت. Threat model را برای Control plane، Node، Workload و Supply chain جدا کنید.

Namespace برای سازمان‌دهی و بخشی از کنترل دسترسی مفید است، اما Isolation سخت مانند VM جدا را به‌تنهایی نمی‌دهد. برای Tenantهای با اعتماد متفاوت، Dedicated cluster/Node یا Runtime isolation قوی‌تر را براساس ریسک بررسی کنید.

Secret در Kubernetes به‌طور پیش‌فرض Secret کامل نیست

راهنمای رسمی Secretها یادآوری می‌کند مقدار Secret با Base64 رمزنگاری نشده و داده در etcd به‌طور پیش‌فرض می‌تواند بدون Encryption at rest ذخیره شود. Encryption، RBAC حداقل، محدودیت List/Watch، Secret کوتاه‌عمر، Rotation و در صورت نیاز Secret store بیرونی را طراحی کنید. هر کسی که اجازه ساخت Pod با Secret را دارد ممکن است عملاً به مقدار آن دسترسی پیدا کند.

امنیت API داخل Pod تمام نمی‌شود

Gateway، Service mesh یا NetworkPolicy جای Authorization سطح Object/Property/Function در برنامه را نمی‌گیرد. Identity سرویس، mTLS، Token audience، Timeout، Rate/Cost limit، Egress و Third-party API را تهدیدمدل کنید. برای BOLA، OAuth/JWT، SSRF، Webhook و Incident از راهنمای امنیت API استفاده کنید.

Observability باید کاربر، اپ و کلاستر را پیوند دهد

Kubernetes Pod سالم را می‌بیند، نه لزوماً Checkout موفق را. مستند Observability Kubernetes Metric، Log و Trace را توضیح می‌دهد. Kubernetes برای Logهای Cluster-level Backend ذخیره‌سازی بومی کامل ارائه نمی‌کند؛ جمع‌آوری، Retention، Redaction و هزینه با شماست.

Trace ID، release version، cluster/namespace/workload/pod و business key غیرحساس را همبسته کنید و Cardinality/Retention را بودجه‌بندی کنید. طراحی SLO و Telemetry در راهنمای Observability و پایش بیرونی DNS/TLS/HTTP از چند نقطه در راهنمای Uptime monitoring آمده است.

Runbook عیب‌یابی از اثر کاربر شروع می‌شود

1. Scope: کدام کاربر، مسیر، Region، Release و زمان؟
2. Change: Deployment، Config، Secret، Node upgrade یا Policy اخیر؟
3. Traffic: DNS/LB/Gateway/Service/Endpoint آماده‌اند؟
4. Workload: Ready/Restart/Pending/OOM/Event و Log قبلی Container چیست؟
5. Resource: Saturation، Quota، Volume attach و Node pressure؟
6. Dependency: DB/Queue/Cache/Third party و Timeout/Pool؟
7. Mitigate: Rollback، Scale، Route shift یا Feature flag با Guardrail؟
8. Learn: Timeline، علت سیستمی، اقدام با Owner/Deadline و Regression test.

kubectl get pods شروع است، نه تشخیص. Eventها ممکن است Retention محدود داشته باشند؛ Log و Audit را خارج از عمر Node/Pod نگه دارید.

Backup و Disaster recovery کلاستر

از این اجزا Inventory بگیرید: Manifest/GitOps state، CRD و Operator، Secret/Key، Volume/DB، Registry artifact، DNS/TLS، IAM، Network/Gateway، Policy و Telemetry config. در Self-managed، Snapshot سازگار etcd مهم است؛ در Managed، دقیقاً بررسی کنید Provider از چه چیزی Backup می‌گیرد و مسئول Restore کدام بخش است.

Multi-zone بودن مساوی Multi-region DR نیست. RPO/RTO، Failover trigger، Data replication، DNS TTL، Capacity مقصد، Reconciliation و بازگشت را در Drill اندازه بگیرید. دو کلاستر بدون تمرین می‌توانند دو برابر Configuration drift بسازند.

هزینه واقعی Kubernetes

قبض Compute فقط بخشی از TCO است. Control plane، Node idle، System/DaemonSet، Headroom، Storage/IOPS/Snapshot، Load balancer، NAT/Egress، Registry، Log/Metric/Trace، Security tooling، Support، Upgrade و زمان Platform/On-call را حساب کنید.

TCO ماهانه = زیرساخت + سرویس‌های مدیریت‌شده + Telemetry/Security + Egress/Data + نیروی Platform/On-call + ریسک/قطعی + استهلاک مهاجرت و خروج

برای Reconciliation قبض، تخصیص هزینه مشترک، Request/usage/idle، Unit economics و FX از راهنمای مدیریت هزینه کلود و FinOps استفاده کنید.

Managed Kubernetes یا Self-managed؟

Self-managed را فقط وقتی انتخاب کنید که Requirement مشخصی Managedها برآورده نمی‌کنند و تیم توان Upgrade، Security response، etcd، CNI/CSI و ۲۴/۷ Incident را اثبات کرده است.

Vendor lock-in با Kubernetes صفر نمی‌شود

Manifestهای پایه قابل‌حمل‌ترند، اما LoadBalancer annotation، IAM، KMS، Registry، StorageClass، Database، DNS، Observability، Operator و Data gravity وابستگی می‌سازند. Exit plan باید شامل Export نیست؛ باید Cluster مقصد را بسازد، Artifact/Secret/Data را منتقل کند، Traffic را جابه‌جا و SLO/Integrity را اثبات کند.

ملاحظات Kubernetes برای تیم ایرانی

• Eligibility و حقوقی: شرایط حساب، تحریم، محل داده و امکان استفاده/پشتیبانی را پیش از وابستگی بررسی کنید.
• Registry: Pull image و Package از داخل/خارج، Rate limit، قطعی و Mirror مجاز/امن را آزمایش کنید؛ Artifact حیاتی را در Registry تحت‌کنترل Replicate کنید.
• شبکه: Latency و Packet loss میان کاربر، Control plane، Node، Registry و سرویس خارجی را از ISPهای واقعی بسنجید.
• ارز و پرداخت: TCO را با سناریوی نرخ ارز، کارمزد، تمدید و تاخیر صورتحساب بسازید.
• ابر داخلی: صرف داشتن API Kubernetes کافی نیست؛ Version، Upgrade، CNI/CSI، LB، Snapshot، SLA، Export و Support را Pilot کنید.
• نیروی انسانی: Bus factor، مستندات فارسی/انگلیسی، On-call و زمان آموزش را وارد تصمیم کنید.
• Failover: Route داخل/خارج، DNS و Dependencyها ممکن است در هر ISP متفاوت باشند؛ Probe چندنقطه‌ای لازم است.

از توصیه Provider خاص و ادعای «بهترین برای ایران» بدون آزمون جاری پرهیز کنید. Snapshot قیمت، Region، Version و شرایط استفاده عمر کوتاهی دارد.

Scorecard انتخاب پلتفرم Kubernetes

نمونه Deployment حداقلی، نه نسخه آماده Production

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels: {app: api}
  template:
    metadata:
      labels: {app: api}
    spec:
      securityContext:
        seccompProfile: {type: RuntimeDefault}
      containers:
        - name: api
          image: registry.example/api@sha256:REPLACE_WITH_DIGEST
          ports: [{name: http, containerPort: 8080}]
          resources:
            requests: {cpu: 250m, memory: 256Mi}
            limits: {memory: 512Mi}
          securityContext:
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: {drop: ["ALL"]}
          startupProbe:
            httpGet: {path: /health/startup, port: http}
            failureThreshold: 30
            periodSeconds: 5
          readinessProbe:
            httpGet: {path: /health/ready, port: http}
            periodSeconds: 5
          livenessProbe:
            httpGet: {path: /health/live, port: http}
            periodSeconds: 10
          lifecycle:
            preStop:
              exec: {command: ["/bin/sh", "-c", "sleep 5"]}
      terminationGracePeriodSeconds: 30

اعداد مثال نیستند که Copy شوند. Request/limit، Threshold، Grace period، Replica و Endpoint باید از Profiling، Load test، Shutdown behavior و SLO همان برنامه بیایند. Service، PDB، HPA، Spread، NetworkPolicy، Secret و Telemetry نیز جدا لازم‌اند.

برنامه ۹۰روزه پذیرش Kubernetes

روز ۱ تا ۳۰: Fit و قرارداد

• Use case، SLO، RPO/RTO، Peak، Compliance، Budget و Exit را ثبت کنید.
• یک Alternative ساده‌تر را کنار Managed K8s در TCO و زمان عملیات مقایسه کنید.
• مسیر Request/Dependency/State و RACI App/Platform/Security/Data را رسم کنید.
• Golden path برای Image، Manifest، Secret، Telemetry و Deployment بسازید.
• دو Provider/Distribution را با Knockoutهای ایران غربال کنید.

روز ۳۱ تا ۶۰: Thin-slice Production-like

• یک سرویس کم‌ریسک اما واقعی با Traffic و Dependency نماینده Deploy کنید.
• Digest/SBOM/Admission، RBAC، Pod security، NetworkPolicy و Secret rotation را تست کنید.
• Load/HPA/Node scale، Rolling/Canary، Node drain و Zone failure را اجرا کنید.
• Log/Metric/Trace/Synthetic و Cost allocation را تا Business outcome وصل کنید.
• Backup/Restore و Runbook Incident را زمان‌گیری کنید.

روز ۶۱ تا ۹۰: Decision و Rollout

• SLO، Change failure، MTTR، Platform toil و Cost per outcome را با Alternative مقایسه کنید.
• Gapهای Security، Capacity، Upgrade، Data و Exit را Owner/Deadline بدهید.
• Go/No-go را با Knockout و شواهد بنویسید؛ Sunk cost معیار انتخاب نیست.
• در صورت Go، Migration موجی با Canary، Freeze window و Rollback تعریف کنید.
• Quarterly upgrade، restore، access review، capacity و exit drill را تقویم کنید.

اشتباه‌های پرتکرار

• انتخاب Kubernetes چون اپلیکیشن «مدرن» یا Microservice است.
• یکی‌دانستن Docker، Container و Runtime کلاستر.
• استفاده از Tag شناور و Build مجدد در هر محیط.
• نداشتن Request/limit و انتظار Scheduling/Autoscaling کم‌هزینه.
• قرار دادن Dependency بیرونی در Liveness و ساخت Restart storm.
• سه Replica در یک Failure domain و ادعای HA.
• اتکا به Rolling update برای Zero downtime بدون Drain و DB compatibility.
• فرض اینکه PDB خرابی Node یا Deployment rollout را متوقف می‌کند.
• ذخیره Secret Base64 و فرض Encryption.
• قرار دادن Database در StatefulSet بدون Backup/Restore/Operator expertise.
• خرید Managed K8s و حذف نقش Platform/On-call از بودجه.
• Export YAML و نام‌گذاری آن به‌عنوان Exit plan.

چک‌لیست Production readiness

• Fit، Alternative، SLO، RPO/RTO، Budget و Owner تصویب شده‌اند.
• نسخه Kubernetes/Add-on و برنامه Upgrade/Deprecation ثبت شده است.
• Image با Digest، SBOM، Scan و Provenance قابل‌ردیابی Deploy می‌شود.
• Resource request/limit با Load test و Headroom تنظیم شده‌اند.
• Startup/Readiness/Liveness و Graceful shutdown در Failure test پاس شده‌اند.
• Replica، Spread، PDB و ظرفیت جایگزین با Failure domain سازگارند.
• HPA و Node scale با Metric، Stabilization و Burst واقعی آزمایش شده‌اند.
• Gateway/TLS/DNS، NetworkPolicy و Egress contract مستندند.
• RBAC، Pod security، Secret encryption/rotation و Audit فعال و آزموده‌اند.
• State/Backup/Restore، Key و Dependency order به RPO/RTO رسیده‌اند.
• Metric/Log/Trace/Synthetic/Cost با Release و Outcome همبسته‌اند.
• Incident، Rollback، Node drain، Zone failure و Exit drill اجرا شده‌اند.
• TCO شامل نیروی Platform، Telemetry، Egress، FX و Idle است.

پرسش‌های متداول

تفاوت Docker و Kubernetes چیست؟

Docker مجموعه ابزار محبوب برای Build و اجرای Container image است؛ Kubernetes پلتفرم Orchestration برای مدیریت Workload کانتینری روی کلاستر است. Kubernetes جدید از Runtimeهای سازگار با CRI استفاده می‌کند و ادغام داخلی Dockershim از نسخه ۱.۲۴ حذف شده، اما Image ساخته‌شده با Docker همچنان قابل استفاده است.

آیا Kubernetes برای استارتاپ کوچک مناسب است؟

گاهی، اما نه به‌صورت پیش‌فرض. اگر چند Workload/تیم و نیاز واقعی به Platform API دارید و Managed service بار را توجیه می‌کند، Pilot ارزش دارد. برای یک Monolith کوچک، PaaS یا VPS/Compose معمولاً سریع‌تر و کم‌هزینه‌تر است. انتخاب را با SLO، TCO و ظرفیت تیم انجام دهید.

آیا Kubernetes هزینه هاستینگ را کاهش می‌دهد؟

تضمینی نیست. Packing و Autoscaling می‌توانند مصرف را بهتر کنند، اما Control plane، ظرفیت بیکار، Add-on، Storage، Egress، Telemetry و نیروی Platform هزینه می‌سازند. Cost per business outcome و Reliability-adjusted TCO را با Alternative مقایسه کنید.

آیا Rolling update یعنی استقرار بدون قطعی؟

خیر. Replica و ظرفیت Surge، Readiness درست، Graceful shutdown، Drain، Gateway، سازگاری Database و Dependency، Canary و Rollback لازم‌اند. Rolling update فقط مکانیسم جایگزینی تدریجی Replicaهاست.

برای Production، Managed Kubernetes بهتر است یا Self-managed؟

برای بیشتر تیم‌هایی که Requirement ویژه ندارند، Managed گزینه شروع کم‌ریسک‌تری است؛ اما Workload، Node/Add-on، Data، Security و Observability همچنان مسئولیت مشترک‌اند. Self-managed زمانی موجه است که نیاز مشخص و تیم اثبات‌شده برای Control plane، etcd، شبکه، Storage و On-call داشته باشید.

جمع‌بندی: Kubernetes یک API برای عملیات است، نه جایگزین عملیات

Container، Artifact و Runtime را منظم‌تر می‌کند؛ Kubernetes Desired state، Scheduling و Reconciliation را استاندارد می‌کند. ارزش واقعی زمانی ساخته می‌شود که اپلیکیشن Lifecycle روشن، Resource درست، Failure domain مستقل، State بازیابی‌پذیر، Supply chain امن، Telemetry قابل‌اقدام و تیم پاسخ‌گو داشته باشد.

اگر امروز بین Kubernetes و گزینه ساده‌تر مردد هستید، ابتدا یک صفحه قرارداد بنویسید: Workloadها، SLO، Failureها، State، Peak، تعداد تیم، TCO و Exit. سپس یک Thin slice را روی Managed K8s و بهترین Alternative اجرا کنید. لوگوی معماری تصمیم را نمی‌گیرد؛ شاهد Pilot و هزینه نگهداریِ فردا تصمیم را می‌گیرد.