خب مثل بقیه پست هایی که تو ویرگول(یا هر جایی دیگه) مینویسم همین اول اعلام کنم که این نوشته ممکنه کلی کم و کاستی داشته باشه (نگارشی٬فنی ...) بابتش عذر میخوام ولی امیدوارم که قابل استفاده باشه.
خب بریم سر اصلا داستان:
نمیخوام از صفر صفر شروع کنم پس واسه فهمیدن این نوشته لازمه که از قبل اطلاعات کوچیکی درباره K8S داشته باشین.
خب تصور کنید که ما یه کلاستر اماده داریم که داره کار میکنه٬ حالا ما اومدیم app خودمون رو توی این کلاستر deploy کردیم ( واسه سادگی app رو یه nginx ساده ببینید ) این pod یه ip گرفته و شما اگه از داخل کلاستر requests بزنید به اون پاد میتونید صفحه اصلی nginx تون رو ببینید.
ولی یه مرحله که جلو تر بریم به یه مشکل بر میخوریم! مشکل چیه؟ مشکل اینه که حالا من چجوری این app رو واسه بقیه مردم تو کل جهان قابل نمایش کنم؟ این جاست که سرویس ها میان تو بازی.
خب تا این جا فهمیدیم که service ها نقششون چیه حالا بیایید نقشی رو که واسش گفتیم مرور کنیم و یه نقش دیگه هم اضافه کنیم بهش.
نقش اول: قابل دسترس کردن pod ای که داخل کلاستر بالا اوردین واسه کاربرایی که خارج از کلاسترن
نقش دوم: گفتیم که وقتی یه pod بالا میاریم یه ip بهش assign میشه و ما از این ip واسه دسترسی بهش استفاده میکنیم. حالا تصور کنید به هر دلیلی( اپدیت٬ خارج شدن یه نود از کلاستر و ....) pod شما از بین رفته و یه pod جدید بالا اوردین ( یا خود کلاستر این کارو کرده). حالا چی پیش میاد ؟ یه pod جدید یه ip جدید داره و از طریق ip که شما قبلا از app تون داشتید قابل دسترسی نیست! ای بابا داستان شد که :( این جاست که service ها مثل یه قهرمان ظاهر میشن.
خب ما تا این جا فهمیدیم که سرویس ها به چه دردی میخورن و اصلا چرا به وجود اومدن. حالا بریم ببینیم چجوری کار میکنن.
اول بریم سراغ اینکه ببینیم سرویس ها تو k8s چجوری مشکل دوم مارو حل میکنن ( نقش دوم سرویس ها):
خب الان سیستم فرضی ما بدین صورته: یک پاد با قالب زیر
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
خب به همین راحتی میشه یه پاد nginx تو کوبرنتیز بالا اورد.
پاد ما بالا اومده و ما به این شکل داریمش
تو تصویر اطلاعات کلی پاد رو میبینید حالا بیایید واس پادمون سرویس ایجاد کنیم.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
خب با توجه به کانفیگ بالا ما یه سرویس ساختیم به اسم my-service و تو قسمت selector گفتیم که وصل شو به pod ای که lable ش با این قانون match بشه : app:nginx . تو ادامه هم گفتیم که port 80 این سرویس رو به port 80 پادمون روی پروتوکل tcp وصل کنه.
خب حالا این سرویس چطور مشکل مارو حل میکنه ؟ یه چیز جالب سرویس ها با اسمشون به جای ip قابل دسترسی هستن.
حالا متوجه شدین که مشکل ما چطور حل شد ؟
اجازه بدین یه شکل واستون بیارم
این شکل کاملا گویای service هست. چون سرویس به وسیله match شدن قانونی که واسش تو قسمت selector فایل کانفیگش نوشتیم میاد به پاد ها وصل میشه عوض شدن ip پاد هاتون تو مسیر دسترسی شما به پاد ها خللی وارد نمیکنه از سمت دیگه اس چون شما با name به سرویستون وصل میشید عوض شدن ip سرویس هم مشکلی نیست.
به همین راحتی مشکل ما حل شد :)
حالا شما اگه تو کلاسترتون دستور
curl my-service
رو بزنید صفحه nginx تون رو میبینید حتی اگه هزار بار ip پادتون عوض شه.
البته سرویس کار های دیگه ای رو هم برای ما انجام میده ولی چون دوست دارم که نوشته هام واسه کسایی که تازه کوبرنتیز رو شروع کردن مناسب باشه فعلا در ساده ترین و مینیموم ترین حالت پیش میریم.
خب به نظر میاد بهتره بیش تر از این طولانیش نکینم واسه پست اول کافیه.
اگه سوالی داشتین یا جایی نا مفهوم بود اصلا نگران نباشید٬ به گیرنده هاتون دست نزنید مشکل از فرستنده است:)
سوال ها و نظراتتون رو کامنت کنید من حتما جواب میدم:)
تو ادامه بقیه ماجرا رو هم میگم.