پرش به مطلب اصلی

اتصال به اپلیکیشن

برای اتصال به اپلیکیشن می‌توانید با توجه به نیازمندی‌هایتان راهکارهای متفاوتی را انتخاب کنید. امکان اتصال به اپلیکیشن از داخل کلاستر به‌کمک سرویس یا از خارج کلاستر به‌کمک Ingress در اختیارتان قرار دارد.

از داخل کلاستر

در کوبرنتیز، سرویس‌ها (service) امکان دسترسی شبکه‌ای به اپلیکیشن‌ها را از داخل کلاستر فراهم می‌کنند. این سرویس‌ها مانند یک نقطه‌ی ورودی برای مجموعه‌ای از پادها، ترافیک ورودی را میان آن‌ها توزیع می‌کنند. سرویس‌ها انواع مختلفی دارند:

  • ClusterIP

    در این حالت، یک IP داخلی به اپلیکیشن اختصاص می‌یابد تا سایر سرویس‌ها از طریق آن بتوانند با اپلیکیشن ارتباط بگیرند. نامی که برای صدا زدن اپلیکیشن‌ها به این شیوه استفاده می‌شود در قالب service-name>.<namespace>.svc.cluster.local> قرار می‌گیرد.

    برای نمونه، اگر یک اپلیکیشن Wordpress و یک اپلیکیشن MySQL داشته باشید؛ برای فراخوانی MySQL از داخل WordPress می‌توانید از mysql.project.svc.cluster.local استفاده کنید.

  • NodePort

    زمانی که پورت‌های اپلیکیشن را در تنظیمات شبکه داخلی آن باز می‌کنید به‌کمک NodePort در کوبرنتیز می‌توانید به اپلیکیشن‌های داخل کلاستر متصل شوید. برای نمونه با باز کردن پورت 3306 اپلیکیشن MySQL می‌توانید از mysql:3306 برای ارتباط با آن در داخل کلاستر استفاده کنید.

از خارج کلاستر

برای دسترسی به اپلیکیشن‌ها از خارج کلاستر، می‌توان از LoadBalancer در سرویس یا Ingress استفاده کرد.

  • LoadBalancer

    لود بالانسر که نوعی از سرویس است، دسترسی به پاد را از خارج کلاستر با یک IP عمومی امکان‌پذیر می‌کند. در کانتینر ابری آروان می‌توانید با تنظیم IP اختصاصی از خارج کلاستر به اپلیکیشن‌تان متصل شوید.

  • Ingress

    به‌کمک Ingress می‌توانید برای ترافیک ورودی HTTP/HTTPS قوانین مسیریابی تعریف و دسترسی‌ به یک یا چند سرویس را از طریق URL مدیریت کنید. با اتصال دامنه به اپلیکیشن در پشت صحنه یک Ingress برای آن ایجاد می‌شود.

    تصور کنید یک اپلیکیشن به‌نام nginx روی پورت ۸۰ داریم و می‌خواهیم به آن را از طریق آدرس http://example.com متصل شویم. برای این کار باید یک Ingress به‌شکل زیر نوشته و اجرا شود:

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
generation: 1
name: nginx-ingress
namespace: arvandocs
annotations:
# Example annotation for enabling SSL redirect. Actual annotations depend on your ingress controller
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: example.com
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: Prefix

این فایل YAML از بخش‌های مختلفی ساخته شده است:

  • apiVersion: مشخص‌کننده‌ی نسخه‌ی API اینگرس است.
  • kind: Ingress: مشخص‌کننده‌ی نوع منبع کوبرنتیز که در این‌جا Ingress است.
  • metadata: شامل جزییاتی مانند نام، پروژه و Annotation است.
  • spec: تعیین‌کننده‌ی وضعیت Ingress از جمله قوانین مسیریابی است.
    • rules: قوانین مسیریابی ترافیک HTTP در این‌ بخش مشخص می‌شود. در هر قانون یک host و مجموعه‌ای از مسیر‌های HTTP قرار می‌گیرد.
      • host: نشان‌دهنده‌ی دامنه‌ای که ترافیک به آن ارسال می شود.
      • http: قوانین مسیردهی HTTP را مشخص می‌کند.
        • paths: مسیرهای مربوط به هر نود را تعیین می‌کند.
          • path: مسیر URLای که باید ترافیک به آن ارسال شود در این‌جا نوشته می‌شود.
          • pathType: شیوه‌ی تطبیق مسیر را مشخص می‌کند.
          • backend: تعیین‌کننده‌ی سرویس و پورتی که ترافیک باید به آن ارسال شود.

Ingressها می‌توانند بر اساس نیازمندی‌هایتان پیچیده‌تر و شامل تنظیمات بیش‌تری باشند. یکی از قابلیت‌های پرکاربرد آن Multi-Tenancy است. با این ویژگی می‌توانید با استفاده از Wildcard در قوانین مسیریابی (مثلن example.com.*)، یک Ingress را با چند اپلیکیشن به اشتراک بگذارید.

برای نمونه:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: wildcard-ingress
namespace: default
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
rules:
- host: "*.example.com"
http:
paths:
- path: /service1(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: service1
port:
number: 80
- path: /service2(/|$)(.*)
pathType: ImplementationSpecific
backend:
service:
name: service2
port:
number: 80

در این نمونه، Ingress به‌گونه‌ای پیکربندی شده است که با هر زیردامنه‌ای از example.com مطابقت داشته باشد. هم‌چنین بر اساس مسیرهای مختلف، درخواست‌ها را به سرویس‌های مختلفی ارسال می‌کند:

  • درخواست‌های http://<any-subdomain>.example.com/service1 به اپلیکیشن service1 ارسال می‌شوند.
  • درخواست‌های http://<any-subdomain>.example.com/service2 به اپلیکیشن service2 ارسال می‌شوند.

توجه داشته باشید که:

  • استفاده از Wildcard (*) در host و شیوه‌ی اجرای آن به Ingress Controller بستگی دارد. در این نمونه، فرض شده از NGINX استفاده شده که از این تنظیمات پشتیبانی می‌کند.
  • بخش pathType: ImplementationSpecific امکان تفسیر مسیرها بر اساس Regular Expression یا قوانین دیگر را فراهم می‌کند.
  • nginx.ingress.kubernetes.io/rewrite-target در Annotation برای تغییر مسیر ارسال‌شده به اپلیکیشن استفاده می‌شود. در این مثال، هر چیزی پس از /service1/ یا /service2/ قرار بگیرد را به‌عنوان بخشی از درخواست به اپلیکیشن ارسال می‌کند.