این بخش از مستندات کوبرنتیز شامل آموزش‌ها می‌باشد.
این آموزش ها برگرفته از انجام یک راهکار برای رسیدن به هدف های بزرگ است. معمولاً یک آموزش چندین بخش دارد، که هرکدام شامل چند مرحله می‌شوند.
قبل از شروع هر آموزش، ممکن است بخواهید صفحه واژه‌نامه استاندارد را برای مراجعه بعدی ذخیره کنید.
مقدمات
Kubernetes Basics is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
If you would like to write a tutorial, see
Content Page Types
for information about the tutorial page type.
1 - آغاز کار با مینی کیوب (minikube)
این آموزش به شما نشان می دهد که چگونه یک برنامه را در کوبرنتیز توسط مینی کی یوب (Minikube) اجرا کنید.
این آموزش یک کانتینر NGINX را برای شما محیا می کند که به تمام درخواست هایتان پاسخ می دهد.
اهداف
برنامه نمونه را در مینی کی یوب پیاده سازی کنید.
برنامه را اجرا کنید.
لاگ های برنامه را بررسی کنید.
قبل از آغاز
این آموزش با این باور شروع می شود که شما در حال حاضر مینی کی یوب را نصب کرده اید.
در صورت نیاز به راهنمای نصب مینی کی یوب به Step1 در این سایت مراجعه کنید.
توجه:
در صورتی که مینی کی یوب را از لینک بالا نصب می کنید تنها Step 1, Installation را دنبال کنید. قسمتهای بعدی در این صفحه موجوداند.
یک ترمینال جدید باز کرده و دستور زیر را اجرا کنید:
minikube dashboard
بدون پایان دادن به این دستور به ترمینال قبلی که دستور minikube start را در آن اجرا کردید بازگردید.
توجه:
دستور dashboard افزونه داشبورد را فعال کرده و آن را در مرورگر اصلی شما باز می کند.
می‌توانید منابع کوبرنتیز مانند دیپلویمنت و سرویس را در داشبورد ایجاد کنید.
برای اینکه بدانید چگونه بدون باز کردن مرورگر مستقیماً از ترمینال، یک آدرس برای داشبورد وب دریافت کنید، به برگه "کپی آدرس" مراجعه کنید.
به‌طور پیش‌فرض، داشبورد فقط از شبکه مجازی داخلی کوبرنتیز قابل دسترسی است.
دستور dashboard یک پراکسی موقت ایجاد می‌کند تا داشبورد از خارج از شبکه مجازی کوبرنتیز نیز قابل دسترسی باشد.
To stop the proxy, run Ctrl+C to exit the process.
After the command exits, the dashboard remains running in the Kubernetes cluster.
You can run the dashboard command again to create another proxy to access the dashboard.
If you don't want minikube to open a web browser for you, run the dashboard subcommand with the
--url flag. minikube outputs a URL that you can open in the browser you prefer.
دستور زیر را در یک ترمینال جدید اجرا کنید و آن را نبندید.
minikube dashboard --url
اکنون می‌توانید از این آدرس استفاده کرده و به ترمینالی که در آن دستور minikube start را اجرا کرده‌اید بازگردید.
یک دیپلویمنت بسازید
هر پاد (Pod) در کوبرنتیز گروهی از یک یا چند کانتینر است که به دلیل مدیریت یا شبکه با هم گروه شده اند.
پاد استفاده شده در این آموزش تنها یک کانتینر دارد. هر دیپلویمنت (Deployment) در کوبرنتیز پادهای خود را به صورت مداوم چک کرده و در صورت خاطمه یافنن کانتینر آن را دو باره راه اندازی می کنند
.دیپلویمنت ها روش پیشنهادی استقرار، مدیریت و مقیاس بندی پاد ها در کوبرنتیز هستندد
۱. با استففاده از دستور kubectl create یک دیپلویمنت بسازید که پاد این آموزش را مدیریت کند.
این پاد که یک کانتینر دارد بر پایه ایمیج (image) داکر مستقر می شود.
# Run a test container image that includes a webserverkubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
۲. دیپلویمنت را بررسی کنید:
kubectl get deployments
خروجی چیزی شبیه به این خواهد بود:
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
(امکان دارد که بالا آمدن پاد چند لحظه طول بکشد. اگر خروجی به شما "0/1" را نشان می دهد بعد از چند لحظه مکس دوباره تلاش کنید.)
۳. پاد را بررسی کنید:
kubectl get pods
خروجی چیزی شبیه به این خواهد بود:
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
۴. ایونت های کلاستر را بررسی کنید:
kubectl get events
۵. تنظیمات kubectl را بررسی کنید:
kubectl config view
۶. بررسی لاگ های یک کانتینر در پاد .از دستور kubectl get pods استفاده کنید تا نام پاد خود را بدست آورید.
توجه:
در دستور kubectl logs نام پاد خود را که از مرحله قبلی دارید با hello-node-5f76cf6ccf-br9b5 جایگزین کنید.
kubectl logs hello-node-5f76cf6ccf-br9b5
خروجی چیزی شبیه به این خواهد بود:
I0911 09:19:26.677397 1 log.go:195] Started HTTP server on port 8080
I0911 09:19:26.677586 1 log.go:195] Started UDP server on port 8081
توجه:
برای دریافت اطلاعات بیشتر در مورد دستور kubectl به صفحه اختصاصی نگاه کلی kubectl بروید.
ایجاد سرویس
به صورت پیش فرض پادها تنها در شبکه داخلی کوبرنتیز با ای پی (IP) های داخلی قابل دسترس هستند.
در این آموزش برای ایجاد دسترسی خارجی به کانتینر hello-node شما باید این پاد را از طریق یک سرویس منتشر کنید.
اخطار:
The agnhost container has a /shell endpoint, which is useful for
debugging, but dangerous to expose to the public internet. Do not run this on an
internet-facing cluster, or a production cluster.
Expose the Pod to the public internet using the kubectl expose command:
The --type=LoadBalancer flag indicates that you want to expose your Service
outside of the cluster.
The application code inside the test image only listens on TCP port 8080. If you used
kubectl expose to expose a different port, clients could not connect to that other port.
View the Service you created:
kubectl get services
خروجی چیزی شبیه به این خواهد بود:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
On cloud providers that support load balancers,
an external IP address would be provisioned to access the Service. On minikube,
the LoadBalancer type makes the Service accessible through the minikube service
command.
Run the following command:
minikube service hello-node
This opens up a browser window that serves your app and shows the app's response.
فعال کردن افزونه ها
The minikube tool includes a set of built-in addons that can be enabled, disabled and opened in the local Kubernetes environment.
این آموزش یک مرور کلی از اصول سیستم کوبرنتیز ارائه میدهد. هر قسمت شامل اطلاعات پیش زمینه‌ای در مورد ویژگی‌ها و مفاهیم اصلی کوبرنتیز است و یک آموزش برای شما جهت دنبال کردن آن وجود دارد.
در این آموزش شما موارد ذیل را یاد خواهید گرفت:
استقرار یک برنامه کانتینری برروی کلاستر.
افزایش مقیاس برنامه.
به روز رسانی برنامه کانتینری با ویرایش جدید تری از آن.
عیب یالی برنامه کانتینری.
کوبرنتیز چه امکاناتی برای شما فراهم می‌کند؟
کاربران وب سرویس های مدرن انتظار دارند که این برنامه ها به صورت شبانه روزی و هفت روز هفته قابل دسترسی باشند.
سازنده های این برنامه ها هم انتظار دارند که ویرایش های جدید این برنامه ها را چند بار در روز به روز رسانی نمایند.
کانتینر کردن یک برنامه به شما امکان می دهد که به این اهداف به رسید و ویرایش های جدید برنامه خود را بدون وقفه منتشر و به روزرسانی نمایید. کوبرتنیز به شما این اجازه را می دهد که برنامه های کانتینری خود را جایی که می خواهید در زمانی که می خواهید اجرا نمایید. کوبرنتیز یک پروژه متن باز و آماده برای محیط های عملیاتی است که بر اساس سالها تجربه گوگل در سامان دهی و اجرای برنامه های کانتینری و کمک گرفتن از بهترین ایده های جامعه متن باز شکل گرفته.
یادگیری کلاستر کوبرنتیز و ساخت یک کلاستر ساده با مینی کی یوب.
2.1.1 - با استفاده از مینی کی یوب یک کلاستر بسازید
اهداف
یاد خواهید گرفت کلاستر چیست
یاد خواهید گرفت مینی کی یوب (Minikube) چیست
یک کلاستر کوبرنتیز را در کامپیوتر خود راه اندازی خواهید کرد
کلاستر های کوبرنتیز
کوبرنتیز یک پلتفرم متن‌باز و عملیاتی است که زمان‌بندی و اجرای کانتینرهای کلاسترها را مدیریت می‌کند.
کوبرنتیز یک کلاستر همیشه در دسترس از کامپیوترهای به هم پیوسته را که به صورت واحد کار خواهند کرد را اداره می کند
جداسازی های منطقی در کوبرنتیز به شما این امکان را خواهد داد تا برنامه های کانتینری خود را در یک کلاستر پیاده سازی کنید بدون اینکه این برنامه ها به ماشین خاصی تعلق داشته باشند.
برای استفاده از این شیوه مدرن پیاده سازی، برنامه ها باید به صورت بسته های تجزیه شده و بی نیاز از سیستم پایه آماده شوند: به عبارت دیگر آن ها باید به کانتینر تبدیل شوند. برنامه های کانتینر شده انعطاف پذیری بیشتری نسبت به برنامه های قدیمی دارند که برای اجرا نیاز به نصب بر روی سیستم را دارند.
کوبرنتیز یک پروژه متن باز است که توزیع و زمان‌بندی برنامه های کانتینری را در یک کلاستر به‌صورت خودکار و کارآمدتر امکان میدهد.
یک کلاستر کوبرنتیز از دو نوع منبع تشکیل شده است:
کنترل پلین (Control plane) که مدیریت کلاستر را بر عهده دارد
نودها (Node) که کارگرانی هستند که برنامه ها را اجرا می کنند
معماری کلاستر
وظیفه کنترل پلین مدیریت کلاستر است.
کنترل پلین تمام فعالیت‌های کلاستر شما را هماهنگ می‌کند، مانند زمان‌بندی اجرای برنامه‌ها، حفظ وضعیت مطلوب آنها، مقیاس‌دهی به برنامه‌ها، و انتشار به‌روزرسانی‌های جدید.
کنترل پلین ها اداره کننده کلاستر و نودهای کارگر آن ها هستند و مدیریت برنامه های اجرایی در کلاستر را هم بر عهده دارند.
نود یک ماشین مجازی یا کامپیوتر هست که به عنوان کارگر در کلاستر کوبرنتیز انجام وظیفه می کند.
هر نود یک پروسه Kubelet دارد که عاملی برای مدیریت نود و ارتباط با صفحه کنترل کوبرنتیز است.
هر نود باید ابزارهایی برای مدیریت عملیات کانتینر نیز داشته باشد، مانند containerd یا CRI-O.
کلاستر کوبرنتیزی که ترافیک عملیاتی را مدیریت می کند باید حداقل سه نود داشته باشد تا بتواند پایداری را رعایت کند. داشتن بیش از ۱ کنترل پلین هم توصیه می شود زمانی که شما می خواهید پایداری را برای پایگاه داده etcd کوبرنتیز رعایت کنید.
زمانی که شما برنامه ای را برروی کوبرنتیز مستقر می کنید به کنترل پلین اجازه می دهید که کانتینر برنامه را اجرا کند.
کنترل پلین زمان بندی کانتینرها را برای اجرا شدن بر نودهای کلاستر برعهده دارد.
اجزای یک نود اعم از Kubelet با استفاده از رابط کاربری کوبرنتیز با کنترل پلین ارتباط برقرار می کنند.
لازم به ذکر است که رابط کاربری کوبرنتیز برای همه کاربران قابل دسترس است.
کلاستر کوبرنتیز می تواند برروی یک سرور واقعی یا ماشین های مجازی راه اندازی شود. برای شروع به کار با کوبرنتیز شما می توانید از مینی کی یوب استفاده کنید.
مینی کیوب یک نسخه کوچک از کوبرنتیز است که بر روی کامپیوتر شما یک ماشبن مجازی می سازد و کلاستر ساده ای به همراه یک نود را برای شما آماده سازی می کند.
مینی کی یوب بر روی سیستم عامل های لینوکس، مک و ویندوز قابل اجرا است. رابط دستوری مینی کی یوب به شما این اجازه را می دهد که کلاستر خود را بسازید، متوقف کنید و یا حذف کنید.
با استفاده از کوب کتل (kubectl) اولین برنامه خود را بر روی کوبرنتیز مستقر خواهید کرد.
دیپلویمنت های کوبرنتیز
دیپلوبمنت وظیفه ساخت و برروزرسانی نسخه های برنامه شما را دارد
توجه:
این آموزش از کانتینری استفاده می کند که برای سیستم های ۶۴ بیتی طراحی شده است. اگر معماری پردازنده سیستمی که مینی کوب را بر آن اجرا می کنید به غیر از این است می توانید از درابور شبیه ساز مینی کی یوب استفاده کنید.
بعد از راه اندازی یک کلاستر کوبرنتیز شما می توانید برنامه های کانتینری خود را بر روی آن اجرا کنید. برای انجام این کار شما تنها باید یک دیپلویمنت کوبرنتیز بسازید. بعد از ساخت دیپلویمنت کنترل پلین کوبرنتیز شما نسخه های از برنامه هایتان را برروی نودهای کلاستر اجرا می کند.
بعد از اینکه نسخه های برنامه ایجاد شدند، دیپلویمنت کوبرنتیز به صورت پیوسته آن ها را نظارت خواهد کرد.
اگر نودی که برنامه را میزبانی می کند خاموش یا حذف شود دیپلویمنت کنترلر آن نسخه را بر روی نودی دیگر در کلاستر اجرا خواهد کرد.
این مکانیزم باعث می شود که محیط شما در مواردی همچون مشکل سروری یا تعمیر و نگهداری خود به خود احیا شود
در محیط های قدیم بیشتر اسکریپت های نصب برای شروع برنامه ها استفاده می شدند، اما این اسکریپت ها امکان احیا محیط را فراهم نمی کردند. کوبرنتیز به صورت بنیادی با حالت قدیمی نگهداری فرق دارد و با استفاده از نودهای مختلف که توسط دیپلویمنت ها برنامه های شما را اجرا می کنند این مهم را مدیریت می کند.
اولین برنامه خود را برروی کوبرنتیز مستقر کنید
برای استقرار برنامه ها در کوبرنتیز باید آن ها را به حالت کانتینری که در کوبرنتیز پشتیبانی می شود تبدیل کنید
شما می توانید یک دیپلویمنت را با استفاده از دستور کوب کتل ساخته و مدیریت کنید.
شما می توانید دیپلویمنت های کوبرنتیز را با استفاده از رابط دستوری کوب کتل ساخته و مدیریت کنید.کوب کتل با استفاده از رابط کاربری کوبرنتیز این مهم را فراهم می سازد.در این قسمت شما رایج ترین دستورات را برای ساخت یک دیپلویمنت فرا خواهید گرفت.
زمانی که یک دیپلویمنت می سازید باید ایمیج کانتینری برنامه خود و تعداد کپی هایی (replicas) که در محیط تان می خواهید اجرا شوند را مشخص کنید.
شما می توانید این مشخصات را بعد از ساخت دیپلویمنت خود تغییر دهید.
بخش ۵ و بخش ۶ این دوره آموزشی که در مورد مقیاس بندی و تغییر دیپلویمنت ها می باشد.
برای اولین دیپلویمنت تان شما از برنامه پکیج شده داکری hello-node که یک کانتینر NGINX است و به تمام درخواست های شما پاسخ میدهد استفاده خواهید کرد.
اگر هنوز برنامه hello-node را در محیط خود مستقر نکرده اید می توانید از دستورالعمل های آموزشی صفحه آغاز کار با مینی کوب استفاده کنید.
برای ادامه به نرم افزار کوب کتل هم احتیاج دارید که می توانید از اینجا نصب کنید.
حالا که با دیپلویمنت ها آشنا شدید، بی یایید اولین دیپلویمنت خود را مستقر کنید!
مقدمات کوب کتل
برای دنبال کردن این آموزش شما نیاز به نرم افزار کوب کتل دارید.
به طور کلی دستور کوب کتل به این نحو استفاده می شود: kubectl action resource.
این دستور یک فعالیت (مانند create, describe یا delete) را برروی یک منبع خاص (مانند node یا deployment) اجرا می کند.
شما می توانید با استفاده از --help در اخر هر دستور اطلاعات بیشتری در مورد پارمترهای قابل قبول آن به دست آورید.
برای مثال: kubectl get nodes --help
شما می توانید با استفاده از kubectl version می توانید از اینکه کوب کتل می تواند با کلاستر شما ارتباط برقرار کند اطمینان حاصل کنید. با استفاده از این دستور می توانید از اینکه این ابزار برروی سیستم و سرور نصب است اطمینان یابید.
برای بررسی نود ها در کلاستر از دستور kubectl get nodes استفاده کنید.
با استفاده از این دستور می توانید نود های قابل دسترس را ببینید. بعدا، یاد خواهید گرفت که چگونه برنامه هایتان را برروی یک نود خاص اجرا کنید.
استقرار یک برنامه
بی یایید تا اولین برنامه خود را با دستور kubectl create deployment برروی کوبرنتیز نصب کنیم.
برای اینکار ما نیاز به نامی برای دیپلویمنت (در این مثال kubernetes-bootcamp) و آدرس ایمیج برنامه کانتینر شده را داریم.
توجه داشته باشید که در مواردی که ایمیج برروی سایت های دیگیری به غیر از داکر میزبانی می گردد آدرس کامل ایمیج لازم است.
آفرین! شما اولین برنامه خود را به صورت دیپلویمنت مستقر کردید.
خلاصه مواردی که یک دیپلویمنت انجام می دهد اینگونه است:
بررسی می کند که کدام نود در کلاستر بهترین مکام برای اجرای برنامه است.
اجرای برنامه بر روی نود ایده ال را برنامه ریزی می کند.
برنامه به نحوی تنظیم می کند تا در زمان مورد نیاز ان را به نود های دیگر انتقال دهد.
برای دریافت فهرست دیپلویمنت ها می توانید از دستور زیر استفاده کنید.
kubectl get deployments
اینجا می بینیم که ۱ دیپلویمنت نسخه ای از برنامه ما را اجرا کرده است. این نسخه از برنامه به صورت یک کانتینر بر روی نود ما در حال اجرا است.
بررسی برنامه
تمامی پادهایی که در کوبرنتیز در حال اجرا هستند بر روی یک شبکه خصوصی و مجزا می باشند.
به صورت پیش فرض این پادها و سرویس ها از داخل کلاستر قابل دسترس هستند اما از خارج از کلاستر کسی به آن ها دسترسی ندارد.
وقتی شما از دستور kubectl استفاده می کنید در اصل دارید از طریق رابط کاربری کوبرنتیز با برنامه ها ارتباط بر قرار می کنید.
در فصل ۴ این دوره آموزشی بیشتر با نحوه انتشار یک برنامه برای دسترسی از خارج از محیط کلاستر آشنا خواهید شد.
درضمن چون این آموزش ابتدایی است ما به جزییات پادها نخواهیم پرداخت.
دستور kubectl proxy به شما امکان می دهد که با ایجاد یک پروکسی به شبکه خصوصی کلاستر وصل شوید.
برای خاتمه این دستور می توانید از control-c استفاده کنید.
برای اجرای دستور زیر از یک ترمینال جدید استفاده کنید
kubectl proxy
در زمانی که این دستور در حال اجرا می باشد ما به رابط کاربری داخل کوبرتنیز دسترسی داریم.
این دسترسی به شما این امکان را می دهد تاتمامی API های کوبرتنیز را بررسی و یا از طریق برنامه های دیگر با آن ها ارتباط برقرار کنید.
به عنوان مثال از طریث دستور زیر شما می توانید با استفاده از ابزار curl ویرایش کوبرتنیز خود را ببینید.
curl http://localhost:8001/version
توجه:
در صورتی که درگاه 8001 قابل دسترسی نمی باشد دستور kubectl proxy را دوباره چک کنید.
سرور رابط کاربری به صورت خودکار برای هر پاد بر اساس نامش یک پایانه می سازد که از طریق پروکسی ساخته شده در این آموزش قابل دسترس می باشد.
برای استفاده از این قابلیت شما نیاز به نام پاد ها دارید.
دستور زیر در مرحله اول نام پاد را گرفته و در یک متغیر محیطی به نام POD_NAME ذخیره می کند.
exportPOD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')echo Name of the Pod: $POD_NAME
بعد از بدست آوردن نام پاد مورد نظرتان شما می توانید از طریق رابط کاربری اطلاعات بیشتری در مورد آن پاد دریافت نمایید:
در این قسمت شما با استفاده از پروکسی به دیپلویمنت خود دسترسی یافتید، در قسمت ۴ این دوره شما با سرویس ها آشنا می شوید که به شما این امکان را می دهند تا بدون استفاده از پروکسی برنامه های خود را منتشر کنید.
یادخواهید گرفت چگونه برنامه های خود را در کوبرتنیز عیب یابی کنید.
پادهای کوبرنتیز
هر پاد گروهی از یک یا چند برنامه کانتینر شده است که دارای منبع ذخیره سازی مشترک (Volumes) ، ای پی و دستوراتی در مورد اجرای آن هاست.
هنگامی که در فصل دوم یک دیپلویمنت ساختید کوبرنتیز یک پاد که متشکل از نسخه ای از برنامه شما است را در سرورتان اجرا کرد. هر پاد در کوبرتنیز یک انتزاع است که متشکل از یک یا چند برنامه کانتینری می باشد و این کانتینر ها به صورت مشترک به این موارد دسترسی خواهند داشت:
منبع ذخیره سازی مشترک یا Volume
پیکر بندی شبکه و یک ای پی (IP)
اطلاعاتی در مورد نحوه اجرای هر کانتینر همانند ایمیج، ویرایش و درگاه های شبکه ای مورد نیاز.
هر پاد برگرفته از مدلی منطقی از یک برنامه برروی سروری است که می تواند برنامه های مختلفی را که به هم مربوط هستند در بر بگیرد.
برای مثال: یک پاد شاید دو کانتینر داشته باشد که یکی از آنها برنامه میزبانی Node.js شما را در بر بگیرد و کانتینر دیگری که اطلاعات مورد نیاز Node.js را فراهم می سازد.
ساخت هر پاد در پلتفرم کوبرنتیز یک دسته عملیات را شامل می شود که پلتفرم تمام آن ها را به صورت متحد اعمال می کند(Atomic).
وقتی که شما یک دیپلویمنت می سازید، پادها به همراه کانتینرهایشان ساخته می شوند.
وظیفه اجرای این پادها به نودهای کلاستر واگذارشده و تا زمانی که این پادها قطع (terminate) یا حذف شوند اعمال می گردد.
در صورتی که نود کلاستر دچار مشکل شود یک پاد برار بر روی نود های دیگر کلاستر برپا شده و اجرا می گردد.
مرور کلی پاد
کانتینرها تنها زمانی باید در یک پاد گروه شوند که از نظر احرایی به هم مرتبط باشند و نیاز به دسترسی به اطلاعات هم داشته باشند.
نودها
پادها همیشه بر روی نودها اجرا می شوند. در کوبرتنیز نودها کارگرانی هستند که می توانند یک سرور فیزیکی یا ماشین مجازی باشند. نودها توسط کنترل پلین ها (Control Plane) مدیریت می شود. هر نود می تواند تعداد متعددی پاد را در بر بگیرد و کنترل پلین کوبرنتیز این پادهارا برروی نودهای مختلف کلاستر مستقر و مدیریت کند.
کنترل پلین برای تقسیم خودکار وظایف بین نودها مواردی اعم از مقدار منابع آزاد سیستم ها را بررسی می کند.
هر نود در کوبرنتیز حداقل باید این شرایط را داشته باشد:
نرم افزار کوبلت (Kubelet) که یک برنامه برای ارتباط نودها و کنترل پلین است باید بر روی آن نصب و راه اندازی شده باشد. کوبلت وظیفه راه اندازی و مدیریت پادها برروی ماشین را دارد.
یک برنامه اجرای کانتینری (مانند داکر) که وظیفه گرفتن ایمیج های کانتینر ها و اجرای آن ها را بر عهده می گیرد.
نگاه کلی بر نودها
عیب یابی با استفاده از کوب کتل (kubectl)
در فصل ۲ این آموزش شما از رابط دستوری کوب کتل استفاده کردید. در فصل ۳ شما از این رابط دستوری استفاده می کنید تا اطلاعات بیشتری در مورد نرم افزار مستقر شده و عملیات های روزمره ای که می توان بر روی محیط انجام داد آشنا شوید.
تعدادی از عملیات های روزمره ای که می توان انجام داد به شرح زیر می باشد:
لیست کردن منابع توسط - kubectl get
نمایش جزییات یک منبع توسط - kubectl describe
بررسی لاگ های یک کانتینر در یک پاد توسط - kubectl logs
اجرای یک دستور داخل کانتینری از یک پاد توسط - kubectl exec
با استفاده از این دستورات شما می توانید اطلاعاتی همانند چه زمانی برنامه ها مستقر شده اند، در چه وضعیتی هستنند، کجا در حال اجرا هستند و یا چه تنظیماتی را شامل می شوند.
حالا که با جزییات عملیاتی کلاستر و دستورات آن آشنا شدیم بییاید تا دانش خودمان را امتحان کنیم.
بررسی تنظیمات برنامه مستقر شده
بیایید برنامه مستقر شده را بررسی کنیم و اطمینان حاصل کنیم که برنامه در حال اجرا است.
برای این کار ما می توانیم از دستور زیر استفاده کرده تا وضعیت پادهای جاری را بررسی کنیم.
kubectl get pods
توجه:
اگر پادی در حال اجرا نبود بعد از چند لحظه مکس دستور بالا را دوباره اجرا کنید.
برای بررسی اطلاعات بیشتری در مورد پاد همانند ایمیج در حال استفاده می توانید از دستور زیر استفاده کنید:
kubectl describe pods
در پاسخ دستور قبل اطاعات جامع تری همانند آدرس ای پی (IP) و درگاه های در حال استفاده و لیستی از رویدادهای پاد از لحظه شروعش را خواهید دیدی.
توجه داشته باشید که پاسخ دریافتی دستور describe بسیار زیاد است و مواردی از آن را ما هنوز مرور نکرده ایم، اما نگران نباشید شما با تمام این مفاهیم تا پایان این دوره آموزش آشنا خواهید شد.
توجه:
توجه داشته باشید که دستور describe تنها برای پاد ها نبوده و شما می توانید از آن برای گرفتن اطلاعات جامعی در خصوص دیگر منابع کوبرتنیز همانند نودها و دیپلویمنت ها هم استفاده نمایید. توصیه ما این است که از جواب این دستور برای نوشتن اسکریپت استفاده نکنید.
بررسی برنامه ها در ترمینال
اگر به خاطر داشته باشید پادها در یک محیط ایزوله و با یک شبکه خصوصی ساخته می شوند پس در حال حاضر برای دسترسی و عیب یابی آن ها از دستور kubectl proxy استفاده خواهیم کرد.
دستور زیر را در ترمینال دیگری اجرا کنید:
kubectl proxy
دوباره نام پاد را استخراج کرده تا در مرحله بعد استفاده کنیم.
exportPOD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"echo Name of the Pod: $POD_NAME
با استفاده از نام پاد و دستور curl یک درخواست را به رابط کاربری کوبرنتیز بفرستید:
در این مثال نیازی به نام کانتینر نداریم چون پاد ما تنها یک کانتینر دارد.
اجرای دستورات برروی کانتینر
با استفاده از دستور exec می توانید به صورت مستقیم داخل یک کانتینر که پاد آن در حال اجرا است دستوراتی را اجرا کنید.
با استفاده از دستور زیر لیست متغییر های محیطی را بررسی کنید:
kubectl exec"$POD_NAME" -- env
توجه داشته باشید که در این مثال ما از نام کانتینر استفاده نمی کنیم چون تنها یک کانتینر داریم.
با استفاده از دستور زیر به رابط کاربری داخل کانتینر در پاد مورد نظر می توانید وصل شوید.
kubectl exec -ti $POD_NAME -- bash
حالا که به کانتینر وصل هستید می توانید با نرم افزار NodeJS نصب شده در آن کار کنید. به طور مثال با استفاده از دستور زیر سورس کد برنامه اجرایی در این پاد را خواهید دید:
cat server.js
می توانید با استفاده از دستور curl از بالا بودن برنامه اطمینان برقرار کنید.
curl http://localhost:8080
توجه:
توجه داشته باشید که در اینجا ما از آدرس localhost استفاده کردیم چون داخل کانتینر هستیم، اگر شما نتوانستید دستور بالا را به اجرا کنید دستور exec را دوباره اجرا کنید.
برای خروج از کانتینر می توانید از دستور exit استفاده کنید
2.4.1 - برنامه خود را با استفاده از سرویس ها منتشر کنید
اهداف
یاد خواهید گرفت سرویس ها کوبرنتیز چیستند.
یاد خواهید گرفت برچسب ها (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 برگردید و مجدداً دیپلویمنت را ایجاد کنید. لطفاً چند ثانیه صبر کنید و سپس دوباره پادها را فهرست کنید. زمانی که یک پاد در حال اجرا را مشاهده کردید، می‌توانید ادامه دهید.
در قدم بعدی با استفاده از دستور زیر، لیست سرویس های کلاستر را بررسی کنید:
kubectl get services
در حال حاضر سرویسی به نام (kubernetes-bootcamp) داریم و اگر دقیق تر نگاه کنیم می بینیم که سرویس ما یک cluster-IP یکتا با یک درگاه داخلی و یک external-IP را در پاسخ از دستور قبل را به ما گزارش می دهد.
برای اینکه متوجه شویم چه درگاه هایی برای این سرویس ما تخصیص یافته اند از دستور زیر استفاده کنیم:
kubectl describe services/kubernetes-bootcamp
با استفاده از دستور زیر یک متغییر محیطی با نام NODE_PORT بسازید و درگاه اختصاصی را در آن ذخیره کنید:
exportNODE_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"
توجه:
در صورتی که از نرم افزار Docker Desktop برای minikube استفاده می کنید باید یک تونل مینی کیوب بزنید.
این تونل به این دلیل باید برپا شود که به شما اجازه دهد تا به کانتینر های داخل محیط Docker Desktop از طریق سیستم خودتان متصل شوید.
در ترمینال دیگری دستور زیر را اجرا کنید:
minikube service kubernetes-bootcamp --url
The output looks like this:
http://127.0.0.1:51082
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
آدرس بازگردانده شده را استفاده کنید تا به برنامه متصل شوید:
curl 127.0.0.1:51082
پاسخ سرور را در این مرحله باید ببنید. سرویس ما برنامه را منتشر کرد!
مرحله دوم : استفاده از برچسب ها
برنامه جاری که از طریق دیپلویمنت مستقر کرده اید به صورت خودکار برچسبی از دیپلویمنت خود می گی رد.
با استفاده از دستور زیر برچسب دیپلویمنت را بررسی کنید:
kubectl describe deployment
حالا بیایید از این برچسب استفاده کنیم. یکی از روش های استفاده از برچسب ها اضافه کردن آن ها به پارامتر -l در دستورات است.
kubectl get pods -l app=kubernetes-bootcamp
شما می توانید این برچسب را برای دیدن سرویس ها هم بکار به برید.
kubectl get services -l app=kubernetes-bootcamp
برای قسمت بعد اول اسم پاد را در یک متغییر محیطی با نام POD_NAME ذخیره کنید:
exportPOD_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 آن را بررسی کنید:
با استناد به پاسخ دستور قبل می توانیم بگوییم که برنامه ما هنوز در حال اجرا است. این مهم به این دلیل می باشد که برنامه ما از طریق دیپلویمنت مدیریت می شود و سرویسی که با آن طعلق داشت تنها برای منتشر کردن برنامه در سطح خارج از کلاستر بوده است.
توجه:
توجه داشته باشید که برای حذف پاد هایی که برنامه شما را در یک کلاستر بارگذاری می کنند باید آن دیپلویمنت را حذف کنید.
این آموزش قسمتی از دوره آموزش مقدماتی است و با این باور نوشته شده که شما قسمت های قبلی دوره را کامل کرده اید.
در آموزش های گذشته ما یک دیپلویمنت (Deployment) ایجاد کردیم و از طریق سرویسی (Service) آن را در خارج از کلاسترمان منتشر کردیم و دیپلویمنت آموزشی ما یک نسخه از برنامه را درون پاد اجرا کرد.
در صورتی که تعداد کاربران برنامه ما افزایش یابد ما باید مقیاس برنامه خود را افزایش دهیم.
توجه:
اگر سرویس را در آموزش قبلی حذف نکرده اید اول آن را حذف کنید و سپس از طریق اجرای دستور زیر یک سرویس جدید از نوع LoadBalancer را بسازید:
توجه داشته باشید که این آموزش با این پیش فرض نوشته شده که شما یک سرویس از نوع LoadBalancer دارید.
مرور کلی مقیاس دهی
مقیاس دهی در دیپلویمنت ها از طریق تغییر تعداد کپی های همسان (replicas) امکان پذیر است.
Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes
with available resources. Scaling will increase the number of Pods to the new desired
state. Kubernetes also supports autoscaling
of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also
possible, and it will terminate all Pods of the specified Deployment.
Running multiple instances of an application will require a way to distribute the
traffic to all of them. Services have an integrated load-balancer that will distribute
network traffic to all Pods of an exposed Deployment. Services will monitor continuously
the running Pods using endpoints, to ensure the traffic is sent only to available Pods.
Once you have multiple instances of an application running, you would be able to
do Rolling updates without downtime. We'll cover that in the next section of the
tutorial. Now, let's go to the terminal and scale our application.
مقیاس دهی دیپلویمنت
To list your Deployments, use the get deployments subcommand:
kubectl get deployments
The output should be similar to:
NAME READY UP-TO-DATE AVAILABLE AGE
kubernetes-bootcamp 1/1 1 1 11m
We should have 1 Pod. If not, run the command again. This shows:
NAME lists the names of the Deployments in the cluster.
READY shows the ratio of CURRENT/DESIRED replicas
UP-TO-DATE displays the number of replicas that have been updated to achieve the desired state.
AVAILABLE displays how many replicas of the application are available to your users.
AGE displays the amount of time that the application has been running.
To see the ReplicaSet created by the Deployment, run:
kubectl get rs
Notice that the name of the ReplicaSet is always formatted as
[DEPLOYMENT-NAME]-[RANDOM-STRING].
The random string is randomly generated and uses the pod-template-hash as a seed.
Two important columns of this output are:
DESIRED displays the desired number of replicas of the application, which you
define when you create the Deployment. This is the desired state.
CURRENT displays how many replicas are currently running.
Next, let’s scale the Deployment to 4 replicas. We’ll use the kubectl scale command,
followed by the Deployment type, name and desired number of instances:
To list your Deployments once again, use get deployments:
kubectl get deployments
The change was applied, and we have 4 instances of the application available. Next,
let’s check if the number of Pods changed:
kubectl get pods -o wide
There are 4 Pods now, with different IP addresses. The change was registered in
the Deployment events log. To check that, use the describe subcommand:
kubectl describe deployments/kubernetes-bootcamp
You can also view in the output of this command that there are 4 replicas now.
Load Balancing
Let's check that the Service is load-balancing the traffic. To find out the exposed
IP and Port we can use describe service as we learned in the previous part of the tutorial:
kubectl describe services/kubernetes-bootcamp
Create an environment variable called NODE_PORT that has a value as the Node port:
exportNODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"echoNODE_PORT=$NODE_PORT
Next, we’ll do a curl to the exposed IP address and port. Execute the command multiple times:
curl http://"$(minikube ip):$NODE_PORT"
We hit a different Pod with every request. This demonstrates that the load-balancing is working.
The output should be similar to:
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-hs9dj | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
توجه:
If you're running minikube with Docker Desktop as the container driver, a minikube
tunnel is needed. This is because containers inside Docker Desktop are isolated
from your host computer.
In a separate terminal window, execute:
minikube service kubernetes-bootcamp --url
The output looks like this:
http://127.0.0.1:51082
! Because you are using a Docker driver on darwin, the terminal needs to be open to run it.
Then use the given URL to access the app:
curl 127.0.0.1:51082
کوچک کردن مقایس برنامه
To scale down the Deployment to 2 replicas, run again the scale subcommand:
به روزرسانی مقطعی توسط دیپلویمنت ها به شما این امکان را می دهد که بدون از دسترس خارج کردن برنامه هایتان پادهایتان را تک تک به روز نمایید.
Users expect applications to be available all the time, and developers are expected
to deploy new versions of them several times a day. In Kubernetes this is done with
rolling updates. A rolling update allows a Deployment update to take place with
zero downtime. It does this by incrementally replacing the current Pods with new ones.
The new Pods are scheduled on Nodes with available resources, and Kubernetes waits
for those new Pods to start before removing the old Pods.
In the previous module we scaled our application to run multiple instances. This
is a requirement for performing updates without affecting application availability.
By default, the maximum number of Pods that can be unavailable during the update
and the maximum number of new Pods that can be created, is one. Both options can
be configured to either numbers or percentages (of Pods). In Kubernetes, updates are
versioned and any Deployment update can be reverted to a previous (stable) version.
Rolling updates overview
If a Deployment is exposed publicly, the Service will load-balance the traffic
only to available Pods during the update.
Similar to application Scaling, if a Deployment is exposed publicly, the Service
will load-balance the traffic only to available Pods during the update. An available
Pod is an instance that is available to the users of the application.
Rolling updates allow the following actions:
Promote an application from one environment to another (via container image updates)
Rollback to previous versions
Continuous Integration and Continuous Delivery of applications with zero downtime
In the following interactive tutorial, we'll update our application to a new version,
and also perform a rollback.
Update the version of the app
To list your Deployments, run the get deployments subcommand:
kubectl get deployments
To list the running Pods, run the get pods subcommand:
kubectl get pods
To view the current image version of the app, run the describe pods subcommand
and look for the Image field:
kubectl describe pods
To update the image of the application to version 2, use the set image subcommand,
followed by the deployment name and the new image version:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2
The command notified the Deployment to use a different image for your app and initiated
a rolling update. Check the status of the new Pods, and view the old one terminating
with the get pods subcommand:
kubectl get pods
Verify an update
First, check that the service is running, as you might have deleted it in previous
tutorial step, run describe services/kubernetes-bootcamp. If it's missing,
you can create it again with:
The rollout undo command reverts the deployment to the previous known state
(v2 of the image). Updates are versioned and you can revert to any previously
known state of a Deployment.
Use the get pods subcommand to list the Pods again:
kubectl get pods
To check the image deployed on the running Pods, use the describe pods subcommand:
kubectl describe pods
The Deployment is once again using a stable version of the app (v2). The rollback
was successful.
