راهنمای گام‌به‌گام استقرار کوبرنتیز برای اولین اپلیکیشن

استقرار کوبرنتیز: از صفر تا اولین اپلیکیشن زنده

اگر تا به حال اپلیکیشن خود را روی یک سرور مجازی یا VPS اجرا کرده باشید، می‌دانید که مدیریت مقیاس، آپدیت‌ها و خطاها چقدر می‌تواند طاقت‌فرسا باشد. کوبرنتیز (Kubernetes) این معادله را تغییر می‌دهد: شما توصیف می‌کنید که اپلیکیشن شما چه شکلی باید باشد، و کوبرنتیز مسئولیت رساندن سیستم به آن حالت و نگه‌داشتن آن را بر عهده می‌گیرد. اما نقطه‌ی شروع برای بسیاری از توسعه‌دهندگان مبهم است: دقیقاً از کجا باید شروع کرد؟ در این مقاله، یک مسیر عملی و بدون حاشیه برای استقرار کوبرنتیز اولین اپلیکیشن شما ترسیم می‌کنیم — از ساخت Deployment تا اکسپوز کردن سرویس به بیرون از خوشه.

فرض می‌کنیم که یک خوشه‌ی کوبرنتیز در دسترس دارید (محلی با Minikube، یا یک خوشه‌ی ابری) و ابزار kubectl روی سیستم شما نصب و به خوشه متصل است. اگر خوشه ندارید، minikube start سریع‌ترین راه برای شروع است. تمام مثال‌های این مقاله با یک اپلیکیشن ساده‌ی Nginx کار می‌کنند تا روی اصل ماجرا متمرکز بمانید.

قدم اول: ساخت Deployment — قلب استقرار کوبرنتیز

در کوبرنتیز، شما مستقیماً کانتینر اجرا نمی‌کنید؛ بلکه یک Deployment تعریف می‌کنید که وضعیت مطلوب اپلیکیشن شما را توصیف می‌کند. Deployment به‌صورت خودکار یک ReplicaSet می‌سازد که تعداد مشخصی از Podها را زنده نگه می‌دارد. اگر یک Pod از بین برود، ReplicaSet بلافاصله یک Pod جدید جایگزین می‌کند.

یک فایل به نام deployment.yaml بسازید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "200m"

نکات کلیدی این فایل:

• replicas: 3 — یعنی همیشه سه نسخه از اپلیکیشن در حال اجرا باشد.
• selector.matchLabels — تعیین می‌کند Deployment کدام Podها را مدیریت کند. این برچسب باید با برچسب قالب Pod (template) یکسان باشد.
• resources — تعیین حداقل و حداکثر منابع به کوبرنتیز کمک می‌کند Podها را هوشمندانه‌تر روی گره‌ها توزیع کند. عدد 100m یعنی ۰.۱ هسته‌ی CPU.

برای اعمال این فایل روی خوشه:

kubectl apply -f deployment.yaml

وضعیت را بررسی کنید:

kubectl get deployments
kubectl get pods

بعد از چند ثانیه، باید سه Pod با وضعیت Running ببینید. اگر یکی از Podها را عمداً حذف کنید (kubectl delete pod <pod-name>)، کوبرنتیز بلافاصله یک Pod جدید می‌سازد — این قدرت خودترمیمی است.

خطای رایج: فراموش کردن selector

یکی از رایج‌ترین خطاها در استقرار کوبرنتیز، ناسازگاری بین selector.matchLabels و برچسب‌های قالب Pod است. اگر این دو با هم مطابقت نداشته باشند، Deployment ساخته می‌شود اما هیچ Podی مدیریت نمی‌کند. همیشه با kubectl describe deployment nginx-deployment خطاها را چک کنید.

قدم دوم: ساخت Service — دروازه‌ی ورود به Podها

Podها در کوبرنتیز موقتی هستند و IP آن‌ها با هر بار ایجاد تغییر می‌کند. برای اینکه اپلیکیشن شما یک آدرس پایدار داشته باشد، به یک Service نیاز دارید. Service یک لایه‌ی انتزاعی است که ترافیک را بین مجموعه‌ای از Podها توزیع می‌کند.

فایل service.yaml را بسازید:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

در این تعریف:

• selector — مشخص می‌کند Service به کدام Podها ترافیک بفرستد (در اینجا همه‌ی Podهایی که برچسب app: nginx دارند).
• port — پورتی که Service روی آن در دسترس است.
• targetPort — پورتی که کانتینر واقعاً روی آن گوش می‌دهد.
• type: ClusterIP — یعنی Service فقط داخل خوشه قابل دسترسی است. این نوع پیش‌فرض و امن‌ترین گزینه است.

اعمال کنید:

kubectl apply -f service.yaml
kubectl get services

حالا از داخل خوشه می‌توانید با آدرس nginx-service به اپلیکیشن دسترسی پیدا کنید. برای تست سریع از یک Pod موقت:

kubectl run test-pod --image=busybox --rm -it -- wget -qO- http://nginx-service

اگر پاسخ HTML از Nginx دریافت کردید، یعنی Service به‌درستی کار می‌کند.

اشتباه رایج: اشتباه در targetPort

اگر اپلیکیشن شما روی پورت 8080 گوش می‌دهد اما targetPort را 80 گذاشته باشید، Service ساخته می‌شود اما هیچ پاسخی نمی‌گیرید. همیشه targetPort را با پورت واقعی کانتینر تنظیم کنید، نه پورت دلخواه.

قدم سوم: اکسپوز کردن اپلیکیشن به بیرون از خوشه

تا اینجا اپلیکیشن فقط داخل خوشه قابل دسترسی است. برای اینکه کاربران بیرونی بتوانند به آن وصل شوند، سه گزینه‌ی اصلی دارید:

گزینه‌ی ۱: NodePort — سریع برای تست

با تغییر نوع Service به NodePort، کوبرنتیز یک پورت از محدوده‌ی ۳۰۰۰۰ تا ۳۲۷۶۷ را روی هر گره باز می‌کند و ترافیک آن پورت را به Service هدایت می‌کند.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service-nodeport
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30080
  type: NodePort

بعد از اعمال، از بیرون با آدرس http://<IP-گره>:30080 قابل دسترسی است. این روش برای تست سریع عالی است اما برای تولید (Production) مناسب نیست، چون پورت‌ها محدود و مدیریت آن‌ها سخت است.

گزینه‌ی ۲: LoadBalancer — مناسب برای ابر

در خوشه‌های ابری (مثل GKE، EKS یا AKS)، تغییر نوع به LoadBalancer باعث می‌شود ارائه‌دهنده‌ی ابر یک Load Balancer واقعی با IP عمومی بسازد:

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80

بعد از چند دقیقه، kubectl get svc یک EXTERNAL-IP نشان می‌دهد که می‌توانید مستقیماً از مرورگر به آن دسترسی پیدا کنید. این روش برای سرویس‌های عمومی ساده مناسب است.

گزینه‌ی ۳: Ingress — مسیریابی هوشمندانه

اگر چند سرویس دارید و می‌خواهید بر اساس نام دامنه یا مسیر، ترافیک را مسیریابی کنید، Ingress بهترین انتخاب است. Ingress یک لایه‌ی ورودی در سطح خوشه است که قوانین مسیریابی HTTP را مدیریت می‌کند. ابتدا باید یک Ingress Controller نصب کنید (مثل NGINX Ingress Controller یا Traefik). سپس یک منبع Ingress تعریف کنید:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

با این تعریف، تمام ترافیک ورودی به app.example.com به سرویس nginx-service هدایت می‌شود. Ingress همچنین مدیریت SSL/TLS را با تعریف tls در spec بر عهده می‌گیرد.

اشتباه رایج: فراموش کردن Ingress Controller

بسیاری از توسعه‌دهندگان تازه‌کار، منبع Ingress را تعریف می‌کنند اما فراموش می‌کنند که Ingress Controller نصب کنند. بدون Controller، منبع Ingress هیچ اثری ندارد. قبل از تعریف Ingress، حتماً Controller را نصب و اجرا کنید.

قدم چهارم: به‌روزرسانی و بازگشت به نسخه‌ی قبلی

یکی از مزیت‌های اصلی استقرار کوبرنتیز، به‌روزرسانی بدون توقف (Rolling Update) است. برای آپدیت نسخه‌ی Nginx، کافی است image را تغییر دهید:

kubectl set image deployment/nginx-deployment nginx=nginx:1.28

کوبرنتیز به‌صورت تدریجی Podهای قدیمی را با جدید جایگزین می‌کند. اگر مشکلی پیش بیاید، با دستور زیر به نسخه‌ی قبلی برمی‌گردید:

kubectl rollout undo deployment/nginx-deployment

تاریخچه‌ی نسخه‌ها را هم می‌توانید ببینید:

kubectl rollout history deployment/nginx-deployment

جمع‌بندی و مسیر بعدی

در این مقاله، چرخه‌ی کامل استقرار کوبرنتیز را برای یک اپلیکیشن ساده طی کردیم: ساخت Deployment برای مدیریت Podها، تعریف Service برای دسترسی پایدار، و اکسپوز کردن به بیرون با سه روش NodePort، LoadBalancer و Ingress. این پایه‌ی اصلی است؛ از اینجا می‌توانید به سراغ مباحث پیشرفته‌تر مثل ConfigMap و Secret برای مدیریت پیکربندی، PersistentVolume برای داده‌های ماندگار، و HorizontalPodAutoscaler برای مقیاس خودکار بروید.

اگر به دنبال زیرساختی هستید که اجرای کوبرنتیز روی آن روان و بدون دغدغه باشد، سرویس‌های ابری ServerNet می‌توانند بستر مناسبی برای میزبانی خوشه‌ی شما فراهم کنند. اما مهم‌ترین قدم، تمرین عملی است: همین حالا یک خوشه‌ی آزمایشی بسازید و اولین Deployment خود را اجرا کنید. بعد از چند بار تکرار، این فرآیند به طبیعت دوم شما تبدیل می‌شود.