مدتی بود که می خواستم مدتی بنشینم و در مورد آن بنویسم کوبرنتیس. زمان آن رسیده است.
به طور خلاصه، Kubernetes یک سیستم منبع باز برای است خودکارسازی و مدیریت برنامه های کاربردی کانتینری. Kubernetes همه چیز در مورد ظروف است.
❗ اگر تصور زیادی از چیستی ندارید یک ظرف استلطفاً ابتدا به سری Docker 101 من مراجعه کنید و سپس به این سری برگردید. بدین ترتیب برای درک Kubernetes آمادگی بیشتری خواهید داشت.
سلب مسئولیت گفت، بیایید مشکلی را ببینیم که همه این «چیزی K8s» سعی در حل آن دارد.
📦 مدیریت کانتینر
فرض کنید ما یک سیستم پیچیده داریم که توسط:
- Backoffice نوشته شده در روبی
- پایگاه داده های مختلفی که PostgreSQL را اجرا می کنند
- یک سیستم گزارش که به زبان جاوا نوشته شده است
- یک برنامه چت که به زبان Erlang نوشته شده است
- یک فرانت آفیس که با NodeJS نوشته شده است
خوب، این معماری کاملاً ناهمگن است، اما هدف این مقاله را برآورده می کند. علاوه بر این، ما همه چیز را در ظروف اجرا کنید:
فرض کنید ما باید از حداکثر در دسترس بودن و مقیاس پذیری برنامه “Frontoffice” اطمینان حاصل کنیم، زیرا در نهایت این برنامه ای است که کاربران نهایی مصرف می کنند. اینجا، سیستم حداقل نیاز دارد 2 کانتینر دفتر جلو در حال اجرا:
علاوه بر این، یک نیاز کاربردی دیگر وجود دارد که برنامه چت نمی تواند برای مدت زیادی خاموش باشد و در صورت خاموش شدن، باید مطمئن شوید که دوباره شروع شده است، داشتن قابلیت خود درمانی:
حالا به معماری فکر کنید که در آن ما داریم ده ها اگر نه صدها ظروف:
مدیریت کانتینر آسان نیست، اینجاست که Kubernetes وارد می شود.
📜 کمی تاریخ
پس از 15 سال اجرای بارهای کاری پیچیده داخلی، گوگل تصمیم گرفتند ابزار مدیریت کانتینر سابق خود را به نام “بورگ” عمومی کنند.
در سال 2014 پرتاب انجام شد و نام آن را “Kubernetes” گذاشتند. ابزار رفت متن باز و جامعه به زودی آن را پذیرفت.
Kubernetes در نوشته شده است گولنگ، در ابتدا فقط از کانتینرهای Docker پشتیبانی می کرد اما بعداً از سایر زمان های اجرا کانتینر نیز پشتیبانی می شد ، مانند ظرف و CRI-O.
☁️ Cloud Native Computing Foundation
در سال 2015 بنیاد لینوکس یک شعبه بنیادی ایجاد کرد که هدف آن پشتیبانی از پروژه های منبع باز است کانتینرها را اجرا و مدیریت کنید در رایانش ابری
سپس بنیاد محاسبات بومی ابرییا CNCF ایجاد شد.
کمتر از یک سال بعد، Kubernetes معرفی شد به عنوان اولین پروژه فارغ التحصیل CNCF تا کنون.
در حال حاضر از سال 2023، الف بسیاری از شرکت ها و بازیکنان بزرگ Kubernetes را اداره می کنند در زیرساخت آنها، آمازون، گوگل، مایکروسافت، RedHat، VMWare به نام چند.
معماری Kubernetes
در اینجا تصویر مختصری از نحوه ظاهر معماری Kubernetes آمده است:
در سناریوی بالا، ما یک خوشه k8s داریم که از “4 ماشین” (یا ماشین های مجازی که امروزه رایج تر است)، که:
- 1 دستگاه تماس گرفت کنترل هواپیما، که در آن خوشه ایجاد می شود و است مسئول پذیرش ماشین آلات جدید (یا گره ها) روی خوشه
- 3 دستگاه دیگر تماس گرفتند گره ها، که شامل خواهد شد همه کانتینرهای مدیریت شده توسط خوشه
👍 یک قانون سرانگشتی
همه کانتینرهای در حال اجرا آنچه را که ما می نامیم ایجاد کنید حالت خوشه ای.
در Kubernetes، وضعیت مطلوب را اعلام می کنیم از خوشه با ایجاد درخواست های HTTP به API Kubernetes، و Kubernetes برای رسیدن به وضعیت مطلوب “سخت کار خواهد کرد”.
با این حال، ایجاد درخواست‌های HTTP ساده به منظور اعلام وضعیت می‌تواند تا حدودی دشوار، مستعد خطا و کاری خسته‌کننده باشد. چگونه در مورد داشتن برخی از CLI در خط فرمان کدام کار سخت احراز هویت و ایجاد درخواست های HTTP را انجام می دهد؟
با کوبکتل آشنا شوید.
👤 ایجاد اشیاء در خوشه
Kubernetes رفتار می کند همه چیز در خوشه به عنوان اشیا، جایی که اشیاء می توانند داشته باشند انواع متفاوت (نوع).
$ kubectl run nginx --image=nginx
pod/nginx created
تصویر زیر چنین تعاملی را در جایی که ما از آن استفاده می کنیم توضیح می دهد kubectl CLI که درخواستی را به API صفحه کنترل انجام می دهد:
ولی پاد چیست؟، ممکن است تعجب کنید. Pod کوچکترین واحد شی است می توانیم با آن تعامل داشته باشیم.
با این حال، غلاف ها می توانند مانند ظروف باشند غلاف ها می توانند حاوی چندین ظرف باشند.
🔎 جریان معماری
حالا بیایید به آن بپردازیم جریان ایجاد اشیاء، در مورد نحوه اجرای خوشه زمانبندی غلاف و به‌روزرسانی‌های وضعیت.
این یک جریان معماری مختصر است، بنابراین ما می‌توانیم معماری k8s را بهتر درک کنیم.
👉 زمانبندی هواپیمای کنترلی
این زمانبندی هواپیمای کنترلی به دنبال گره بعدی در دسترس است و شی/پاد را برای آن برنامه ریزی می کند.
👉 Node Kubelet
هر گره شامل یک جزء به نام Kubelet، که اشیایی که از Scheduler می آیند را می پذیرد و با استفاده از زمان اجرا کانتینر نصب شده در گره (می تواند Docker، containerd و غیره باشد)، شی را در گره ایجاد می کند.
👉 و غیره
در صفحه کنترل مولفه ای به نام etcd وجود دارد که a است فروشگاه ارزش کلیدی توزیع شده که در سیستم های توزیع شده و خوشه ماشین ها به خوبی کار می کند. برای Kubernetes مناسب است.
K8s از etcd برای تداوم و حفظ وضعیت فعلی استفاده می کند.
✋ کمی شبکه در Kubernetes
فرض کنید ما دو غلاف NGINX در خوشه داریم، a سرور و الف مشتری:
$ kubectl run server --image=nginx
pod/server created
$ kubectl run client --image=nginx
pod/client created
فرض کنید می خواهیم به آن برسیم server، چگونه در پورت 80 به چنین غلاف برسیم؟
در برنامه های کانتینری، به طور پیش فرض، ظروف جدا شده اند و شبکه میزبان را به اشتراک نگذارید. Pods هم همینطور.
ما فقط می توانیم درخواست کنیم localhost:80 در داخل server غلاف. ما چطور دستورات را در یک غلاف در حال اجرا اجرا کنید?
$ kubectl exec server -- curl localhost
<html>
...
کار می کند، اما فقط درخواست در غلاف.
چگونه در مورد درخواست سرور از مشتری، آیا امکان دارد؟ بله، زیرا هر پاد یک IP داخلی دریافت می کند در خوشه
$ kubectl describe pod server | grep IP
IP: 172.17.0.6
اکنون می‌توانیم درخواست را از سرور به سرور انجام دهیم client با استفاده از IP داخلی سرور:
$ kubectl exec client -- curl 172.17.0.6
<html>
...
با این حال، در صورتی که ما یک Deploy انجام دهیم، یعنی قدیمی را تغییر دهیم server غلاف به a پاد جدیدتر، هیچ تضمینی وجود ندارد که پاد جدید همان IP قبلی را دریافت کند.
ما به مکانیزمی نیاز داریم کشف غلاف، جایی که می توانیم a را اعلام کنیم شی خاص در Kubernetes که نام خواهد داد به یک غلاف داده شده بنابراین، در داخل خوشه، ما می توانیم با نام آنها به Pods برسد به جای IP های داخلی
چنین شی خاص نامیده می شود سرویس.
👉 مدیر کنترلر
این کنترل هواپیما همچنین از یک جزء به نام مدیر کنترلر. این مسئول دریافت درخواست برای اشیاء خاص مانند خدمات و آنها را از طریق کشف سرویس افشا کنید.
تنها کاری که باید انجام دهیم صدور است kubectl expose و هواپیمای کنترل کار را انجام خواهد داد.
$ kubectl expose pod server --port=80 --target-port=80
service/server exposed
سپس ما قادریم رسیدن به server غلاف با نام آن، به جای IP داخلی آن:
$ kubectl exec client -- curl server
<html>
...
بیایید به آنچه در جریان معماری رخ داد نگاه کنیم. اول، kubectl expose فرمان ایجاد را صادر کرد شی سرویس:
سپس مدیر کنترلر Pod را از طریق سرویس کشف می کند:
پس از آن، مدیر کنترلر مسیرها به kube-proxy مؤلفه ای که در گره در حال اجرا است، که این کار را انجام می دهد شی Service را ایجاد کنید برای Pod مربوطه در پایان فرآیند، دولت در آن پافشاری می‌کند etcd.
👉 کنترلر ابر
کنترلر دیگری که در صفحه کنترل وجود دارد، کنترلر است کنترلر ابری، مسئول دریافت درخواست برای ایجاد اشیاء و تعامل با ارائه دهنده ابر اساسی در صورت نیاز
به عنوان مثال، وقتی یک شیء Service از نوع ایجاد می کنیم LoadBalancer، کنترلر ابری یک LB ایجاد خواهد کرد در ارائه دهنده اصلی، خواه AWS، GCP، Azure و غیره باشد
💯 مروری نهایی
پس از یادگیری در مورد معماری kubernetes، اجازه دهید به طور خلاصه جریان اصلی معماری در یک عکس:
این پست یک مقدمه ای بر Kubernetes همراه با مروری بر آن معماری اصلی.
ما همچنین در مورد برخی از اشیاء بلوک ساختمانی مانند غلاف و خدمات.
در پست های بعدی، نمای دقیق تری در مورد Kubernetes خواهیم دید حجم کار، پیکربندی و شبکه.
گوش به زنگ باشید!
