برنامه خود را با استفاده از سرویس ها منتشر کنید

اهداف

  • یاد خواهید گرفت سرویس ها کوبرنتیز چیستند.
  • یاد خواهید گرفت برچسب ها (label) و انتخاب کننده (selector).
  • یک برناهه را در خارج از کوبرنتیز منتشر خواهید کرد.

نگاه کلی بر سرویس های کوبرنتیز

پادها در کوبرنتیز فانی بوده و هرلحظه امکان دارد حذف شوند. به عبارت دیگر همه پادها یک طول عمر دارند. هنگامی که نود کارگری از بین برود پادهایی که بر روی آن نود درحال اجرا بوده اند هم از بین می روند. در این هنگام کپی های همسان (Replicaset) می توانند به صورت خودکار با ساخت پادهای جدید کلاستر شما را به حالت ایده ال بازگرداند.

به عنوان مثالی دیگر فرض کنید که ۳ کپی همسان (replicas) بک اند سیستم پردازش تصویر شما را تشکیل می دهند. سیستم فرانت‌اند در این مثال نباید گونه ای طراحی شده باشد که تعداد نسخه‌های بک‌اند یا حتی از بین رفتن و بازسازی یک پاد در وظایفش مشکلی ایجاد کند. با این حال، هر پاد در کلاستر کوبرنتیز یک آدرس IP منحصر‌به‌فرد دارد، حتی پادهایی که روی یک نودهمسان هستند. بنابراین، باید راهی برای هماهنگ‌سازی خودکار تغییرات میان پادها وجود داشته باشد تا برنامه‌های شما بتوانند به عملکرد خود ادامه دهند.

سرویس در کوبرنتیز یک انتزاع (abstraction) است که مجموعه‌ای منطقی از پادها و سیاستی برای دسترسی به آن‌ها را تعریف می‌کند. سرویس‌ها باعث می‌شوند پادهای وابسته به‌طور متغییر (loose coupling) به هم متصل باشند. یک سرویس مانند سایر منابع کوبرنتیز با استفاده از YAML یا JSON تعریف می‌شود. مجموعه‌ی پادهایی که یک سرویس هدف قرار می‌دهد معمولاً توسط یک selector بر اساس برچسب (label) مشخص می‌شود (در ادامه توضیح داده می‌شود که چرا ممکن است بخواهید سرویسی بدون مشخص‌کردن selector در spec ایجاد کنید).

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

سرویس‌ها را می‌توان با تعیین یک نوع type در بخش spec به روش‌های مختلفی در معرض دسترس قرار داد:

  • ClusterIP (پیش فرض) - این نوع سرویس با استفاده از ای پی داخلی برنامه را در کلاستر منتشر می کند. توجه داشته باشید که این نوع سرویس تنها از داخل کلاستر قابل دسترسی می باشد.

  • NodePort - این نوع سرویس با استفاده از NAT بر روی تمامی نودهای کلاستر برنامه شما را منتشر می کند. منابع خارجی با استفاده از فرمت NodeIP:NodePort می توانند به سرویس منتشر شده دسترسی یابند.

  • LoadBalancer - این نوع سرویس در فزاهای ابری پشتیبانی شده یک متعادل کننده بار خارجی می سازد که ای پی مختص وایستا می گیرد.

  • ExternalName - این نوع سرویس محتوای externalName را به درخواست هامرتبط می کند و آن را به عنوان CNAME بازمی گرداند. در این حالت هیچ گونه پروکسی استفاده نشده و تنها لازم است از kube-dns ویرایش ۱.۷ یا بالاتر و یا CoreDNS ویرایش ۰.۰..۸ یا بالاتر استفاده شود.

برای اطلاعات بیشتر به آموزش استفاده از ای پی مبدا (Source IP) که در مورد سرویس ها اطلاعات تکمیلی تری می دهد نگاهی بندازید. بازدید از آموزش اتصال برنامه ها و سرویس ها هم خالی از لطف نیست.

درضمن، توجه داشتع باشید در برخی از موارد سرویس های ساخته می شوند که انتخاب کننده (selector) ندارند. این سرویس ها به کاربر این اجازه را می دهند تا سرویس خود را به صورت دستی به نقاط مقصد وصل کند. یکی دیگر از جاهایی که امکان دارد با سرویس بدون انتخاب گر مواجه شوید در سرویس نام خارجی (ExternalName) است.

برچسب ها و سرویس ها

سرویس در کوبرنتیز ترافیک را بین مجموعه‌ای از پادها مسیردهی می‌کند. سرویس‌ها همان لایه‌ی انتزاعی هستند که اجازه می‌دهند پادها بدون تأثیر بر عملکرد برنامه‌ی شما از بین بروند یا مجدداً ساخته شوند. کشف (discovery) و مسیردهی (routing) بین پادهای وابسته به یکدیگر (مانند بخش‌های فرانت‌اند و بک‌اند در یک برنامه) توسط سرویس‌های کوبرنتیز مدیریت می‌شود.

سرویس ها از طریق برچسب ها و انتخاب کننده ها به پادها متصل می شوند که راه حلی ساده برای گروه کردن منطقی منابع در کوبرنتیز هست. برچسب ها به صورت کلید و محتوا (key/value) به منابع متصل شده تا این کارها را انجام دهند:

  • اختصاص دادن یک منبع برای آزمایش، عملیات یا بهینه سازی
  • الصاق برچسب ویرایش و نسخه
  • دسته بندی یک منبع از طریق برچسب

برچسب منابع هر زمانی می تواند اختصاص یابد یا تغییر کند. حالا بیایید با استفاده از برچسب ها برنامه تان را منتشر کنید.

مرحله اول:‌ ساخت یک سرویس

بیایید بررسی کنیم که برنامه‌ی ما در حال اجراست. از دستور kubectl get استفاده می‌کنیم و به‌دنبال پادهای موجود می‌گردیم:

kubectl get pods

در قدم بعدی با استفاده از دستور زیر، لیست سرویس های کلاستر را بررسی کنید:

kubectl get services

در حال حاضر سرویسی به نام (kubernetes-bootcamp) داریم و اگر دقیق تر نگاه کنیم می بینیم که سرویس ما یک cluster-IP یکتا با یک درگاه داخلی و یک external-IP را در پاسخ از دستور قبل را به ما گزارش می دهد.

برای اینکه متوجه شویم چه درگاه هایی برای این سرویس ما تخصیص یافته اند از دستور زیر استفاده کنیم:

kubectl describe services/kubernetes-bootcamp

با استفاده از دستور زیر یک متغییر محیطی با نام NODE_PORT بسازید و درگاه اختصاصی را در آن ذخیره کنید:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

حالا می توانید از خارج از کلاستر خود برنامه نشر شده را آزمایش کنید.

curl http://"$(minikube ip):$NODE_PORT"

پاسخ سرور را در این مرحله باید ببنید. سرویس ما برنامه را منتشر کرد!

مرحله دوم : استفاده از برچسب ها

برنامه جاری که از طریق دیپلویمنت مستقر کرده اید به صورت خودکار برچسبی از دیپلویمنت خود می گی رد.

با استفاده از دستور زیر برچسب دیپلویمنت را بررسی کنید:

kubectl describe deployment

حالا بیایید از این برچسب استفاده کنیم. یکی از روش های استفاده از برچسب ها اضافه کردن آن ها به پارامتر -l در دستورات است.

kubectl get pods -l app=kubernetes-bootcamp

شما می توانید این برچسب را برای دیدن سرویس ها هم بکار به برید.

kubectl get services -l app=kubernetes-bootcamp

برای قسمت بعد اول اسم پاد را در یک متغییر محیطی با نام POD_NAME ذخیره کنید:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo "Name of the Pod: $POD_NAME"

برای ایجاد برچسب می توانید از زیردستور label و منبع مورد نظر استفاده کنید تا برچسب جدید الصاق شود:

kubectl label pods "$POD_NAME" version=v1

بعد از اجرای دستور قبل یک برچسب جدید به پاد ما وصل می شود کی می توانید با کمک گرفتن از زیردستور describe آن را بررسی کنید:

kubectl describe pods "$POD_NAME"

همانطور که می بینید برچسب جدید به پاد ما وصل شده و به ما این امکان را می دهد که از طریق این برچسب لیست پادها را تهیه کنیم.

kubectl get pods -l version=v1

مرحله سوم: حذف سرویس

برای حذف سرویس ها می توانید از زیر دستور delete service استفاده نمایید. این زیر دستور قابلیت استفاده هم زمان با برچسب ها را دارد و مانند مثال زیر می توانید این دو خاصیت را با هم ادغام کنید:

kubectl delete service -l app=kubernetes-bootcamp

تأیید کنید که سرویس حذف شده است:

kubectl get services

پاسخ دستور قبل تایید می کند که سرویس حذف شده است، برای اطمینان بیشتر می توانید این مورد را دوباره با استفاده از درگاه و ای پی قبلی آن از طریق دستور curl آزمایش کنید:

curl http://"$(minikube ip):$NODE_PORT"

این نشان می‌دهد که برنامه دیگر از خارج از کلاستر قابل دسترسی نیست.

برای اطمینان از اینکه برنامه همچنان در حال اجراست، می‌توانید از داخل پاد با استفاده از دستور curl آن را بررسی کنید:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

با استناد به پاسخ دستور قبل می توانیم بگوییم که برنامه ما هنوز در حال اجرا است. این مهم به این دلیل می باشد که برنامه ما از طریق دیپلویمنت مدیریت می شود و سرویسی که با آن طعلق داشت تنها برای منتشر کردن برنامه در سطح خارج از کلاستر بوده است.

گام بعدی

آخرین تغییرات May 06, 2025 at 10:12 AM PST: new pages (07050e30d3)