در ۲۵ اوت ۲۰۲۶، Joep Piscaer از Portainer.io در این یادداشت به این نکته اشاره میکند که پروژههای CNCF که در این نوشته برجسته شدهاند، برای خیلیها Kubernetes در ابتدا موضوعی پیچیده و گیجکننده بوده است؛ موضوعی که فقط مخصوص او نیست. 🧩
او میگوید از توسعهدهندگانی که در تیم خودشان باید خیلی سریع Kubernetes را یاد بگیرند تا کارشان را پیش ببرند، تا نیروهای IT عمومی در سمت مشتری که سالها با vSphere کار کردهاند و حالا با گسترش containerها در حال مهاجرت از آن هستند، همه با یک سؤال مشترک روبهرو میشوند: از کجا باید یادگیری را شروع کنم؟ 😕
به گزارش از وبسایت cncf
جوابهایی که معمولاً در فضای آنلاین پیدا میشود هم چندان کمککننده نیست؛ مستندات Kubernetes، یک دوره پولی که همان مطالب docs را تکرار میکند، مسیرهای certification که خیلی زود وارد جزئیات عمیق میشوند، فهرستی از podcastها که اطلاعات مفیدی در آنها دیده نمیشود، یا مقالههایی از نوع «بهترین منابع» که پر از لینکاند و در عمل بیشترشان به blogهای شرکتی اشاره میکنند. از نگاه نویسنده، هیچکدام از اینها بهتنهایی کمک نمیکنند فرد مفاهیم کلیدی Kubernetes را واقعاً درک کند و بتواند برای خودش یک چارچوب ذهنی بسازد. 📚
اول چارچوب ذهنی را یاد بگیرید
او توضیح میدهد که پیش از ورود عمیق به Kubernetes، پنج پایه مهم وجود دارد که به ساختن این مدل ذهنی کمک میکنند. نخست، مفهوم desired state و reconciliation؛ ایدهای که زیرساخت اصلی همه رفتارهای Kubernetes است. شما به سیستم نمیگویید یک container را اجرا کن، بلکه اعلام میکنید چنین containerی باید وجود داشته باشد، و سپس سیستمی دائماً واقعیت را با آن وضعیت مطلوب مقایسه میکند و اختلافها را اصلاح میکند؛ بدون اینکه دوباره از آن خواسته شود. self-healing، scaling و rollout همگی از همین منطق پیروی میکنند. اگر این اصل را درست نفهمید، بقیه قابلیتها شبیه مجموعهای از ویژگیهای پراکنده به نظر میرسند، نه یک سازوکار واحد با شکلهای مختلف. ⚙️
دوم، جدایی میان control plane و worker و معنای واقعی «disposable» بودن. نویسنده میگوید این همان بخشی است که سالهای کار با vSphere ممکن است ذهن را علیه Kubernetes شرطی کرده باشد. در ESXi اگر یک host دچار مشکل شود، معمولاً آن را نگه میدارند، workloadها را جابهجا میکنند، patch میزنند و دوباره به چرخه برمیگردانند. اما در Kubernetes اگر یک node مشکل پیدا کند، قرار نیست نجات داده شود؛ جایگزین میشود. هر node سالمی میتواند هر workloadی را اجرا کند، بنابراین سیستم تلاش نمیکند ماشین معیوب را حفظ کند، بلکه از آن عبور میکند. اگر این نگاه را از دنیای vSphere با خودتان به cluster بیاورید، ممکن است انرژی زیادی را صرف محافظت از چیزی کنید که Kubernetes اساساً برای رها کردن آن طراحی شده است. 🔄
سوم، چهار لایه networking از container تا بیرون: container به pod، pod به service، service به ingress و در نهایت ingress به دنیای خارج. بسیاری از سردرگمیهای networking در Kubernetes در واقع مشکل networking نیستند، بلکه به این برمیگردند که دقیقاً مشخص نیست مسئله در کدام لایه رخ میدهد. pod IP واقعی است اما موقتی و ناپایدار؛ در مقابل service IP مجازی و پایدار است و بهطور مستقیم چیزی روی آن گوش نمیدهد. اگر بدانید در کدام لایه در حال عیبیابی هستید، نیمی از ابهامها قبل از اجرای حتی یک command از بین میرود. 🌐
چهارم، requests و limits را نه یک توصیه، بلکه یک قرارداد بقا در نظر بگیرید. request چیزی است که scheduler بر اساس آن تصمیم میگیرد workload شما کجا جا میشود. limit هم سقفی است که workload اجازه عبور از آن را ندارد. اگر این دو را اشتباه تعیین کنید، یا ظرفیت را بیش از حد اشغال میکنید چون منابع بیشتری از نیاز واقعی اعلام کردهاید، یا در بدترین زمان ممکن podها evict میشوند چون کمتر از نیاز واقعی اعلام کردهاید و node دیگر جایی برای ادامه ندارد. این یکی از رایجترین فاصلهها میان «در staging درست کار میکند» و «در production از کار میافتد» است و ربطی به کد برنامه ندارد. 🚨
پنجم، دلیل وجود CNI و CSI بهصورت plugin. Kubernetes عمداً networking و storage را بهصورت داخلی ارائه نمیکند. این پلتفرم فقط قرارداد را تعریف میکند و پیادهسازی را به pluginها میسپارد، چون یک edge cluster کوچک و یک محیط multi-zone تحت نظارت سختگیرانه، از نظر عملیاتی هیچ شباهتی به هم ندارند. مجبور کردن هر دو به یک طراحی واحد، از نداشتن هیچچیز هم بدتر بود. این موضوع فقط یک نکته فنی نیست، بلکه توضیح میدهد چرا اکوسیستم ابزارها اینقدر گسترده شده است. وقتی بفهمید این شکافها عمدی هستند، دیگر وجود چندین گزینه CNI در بازار نشانه آشفتگی نیست، بلکه نتیجه طبیعی سیستمی است که انعطافپذیری را به یک نظر واحد ترجیح داده است. 🛠️
بقیه مفاهیم، درسهای روز دیگری هستند. بعضی از آنها زودتر به کار میآیند، مثل GitOps و Observability، و بعضی دیگر میتوانند دیرتر مطرح شوند. روم هم یک روزه ساخته نشد و درک کامل cloud-native هم همینطور. لازم نیست برای مسائلی که هنوز با آنها روبهرو نشدهاید، همین حالا جواب داشته باشید. ⏳
کل نقشه را یکجا دنبال نکنید
اگر میخواهید Kubernetes را یاد بگیرید اما نمیدانید از کجا شروع کنید، توصیه اصلی این است: تلاش نکنید همه نقشه را یکجا پوشش دهید. در هفته اول نیازی نیست درباره service mesh نظر قطعی داشته باشید. پیش از آنکه حتی یک workload عملی را deploy کرده باشید، نیازی به تصمیمگیری درباره policy engine هم ندارید. ابتدا سازوکار را یاد بگیرید: desired state و reconciliation، همان چیزی که باعث میشود کل سیستم همانطور رفتار کند که باید. بعد سراغ ماشین بروید: control plane، worker nodeها و اینکه مفهوم disposable چطور عادتهای قبلی شما را بههم میزند. سپس نوبت plumbing است: یک request دقیقاً چطور به یک container میرسد و چرا storage و networking بهصورت plugin باقی ماندهاند و داخل هسته محصول قرار نگرفتهاند. این مقدار برای مدتی کافی است. 🌱
بقیه مسیر هم از بین نمیرود؛ در طول کار با مسئلههای جدید روبهرو میشوید و همانها به شما کمک میکنند بفهمید بعداً چه چیزی را باید یاد بگیرید. آنوقت، هر وقت به مسئلهای برسید که service mesh یا policy engine را معنادار کند، یادگیریاش هم سریعتر خواهد بود؛ چون بالاخره میدانید دقیقاً چه سؤالی میپرسید. 💡
اگر دنبال یک معرفی در همین سطح هستید؛ یعنی بیشتر روی architecture و mental model تمرکز دارد تا walkthroughهای configuration، وبسایت kubeschool.portainer.io برای شماست. این منبع رایگان و vendor-neutral است. ✨
