من در مورد شما نمی دانم، اما هر وقت کسی داستانی را با کلمات شروع می کند.. تصور کنید که… توجه من را به خود جلب کرد. من مشتاق روش تدریس داستان نویسی هستم.
من برای درک اصول کوبرنتس تلاش کردم و وقتی فهمیدم، فکر کردم اگر به عنوان یک داستان برایم تعریف می شد، آن را سریعتر می فهمیدم.
بنابراین اگر با مفهوم کوبرنتس (که اتفاقاً 10 ساله است، بنابراین فشاری وجود ندارد!) تازه کار هستید، این داستان ممکن است فقط برخی از مفاهیمی را که برای درک آنها به کمک نیاز داشتید (همانطور که من انجام دادم) را روشن کند یا درک شما را از اصول اولیه آسان کند. از کوبرنتس
در پایان این داستان؛
- شما باید دید کلی بهتری از شی kubernetes به شیوه ای سرگرم کننده داشته باشید.
- کارکردهای اشیاء مشترک کوبرنت ها را درک کنید.
- اشیاء ضروری را که برای ایجاد یک خوشه امن Kubernetes با هم جمع می شوند، درک کنید.
اجازه دهید با یک مقدمه کلاسیک شروع کنیم…..
من: شب های عربی…. شما: سرگرمی ها
من: پسرا و دخترا حاضرید داستان من رو بشنوید…. شما: بله ما هستیم، داستان از چه قرار است …..
10 سال پیش، در شهر پر جنب و جوش و پرجنب‌وجوش Kubernetes، جایی که میکروسرویس‌ها و کانتینرها رشد می‌کردند، ساکنان قابل توجه زیادی زندگی می‌کردند که هر کدام نقش منحصر به فردی داشتند. کوبرنتس که در سراسر جهان تحسین شده بود، وظیفه کنترل و ارکستراسیون را بر عهده داشت و اطمینان می داد که همه چیز مانند یک باله کیهانی طراحی شده خوب حرکت می کند.
قبل از اینکه شهر Kubernetes بیش از حد مشهور و سازمان‌یافته شود، Kubernetes فقط با کانتینرهای خود زندگی می‌کرد و آرزوی همراهی و کمک در سازماندهی مسئولیت گسترده خود در مدیریت کانتینرهای خود را داشت.
از این آرزو، پادز، کوچک‌ترین و اساسی‌ترین خالقان جهان سربرآوردند. Kubernetes در این Pods که همیشه آماده میزبانی از کانتینرها بودند، همراهی پیدا کردند، به عنوان مجریان فردی در باله ارکستر شده عمل می‌کردند و به زیبایی با لحن Kubernetes می‌رقصیدند.
بعد، خدمات آمد. در کیهان بزرگ، آنها مانند پیام رسان های بین Pods و جهان بیرونی عمل می کردند – جذاب، ثابت و بسیار مفید. سرویس‌ها با Pods دست در دست گرفتند و به آنها کمک کردند تا ارتباط برقرار کنند و محبت Kubernetes را جلب کردند
مشخص شد که اطلاعات مربوط به فعالیت ها نیاز به ذخیره سازی دارد، بنابراین Volumes استخدام شد. اینها کتابداران وفادار بودند که تمام جزئیات مهم را به خاطر می آوردند و ذخیره می کردند. پشتکار و حافظه آنها مانند پتوی گرم در یک شب سرد برای کوبرنتس بود که راحتی و سطحی از امنیت را فراهم می کرد.
Kubernetes به نظم در قلمرو خود نیاز داشت، غلاف ها باید مدیریت شوند و چه کسی غیر از استقرار مدیران قدرتمند و انعطاف پذیر ما. سپس Kubernetes با Deployments و ReplicaSets آشنا شد که دوقلو بودند. استقرارها مانند مدیران دلسوز بودند و وضعیت مطلوب برنامه ها را تضمین می کردند، در حالی که ReplicaSets مانند ژنرال های سخت کوش بودند و تعداد مورد نیاز Pods را ایمن می کردند. آنها با هم به تعادل و ثبات افزودند و قلب کوبرنتیس را به لرزه درآوردند. با این حال، استقرار همیشه همه چیز را در یک وضعیت موقتی رها می کرد و باعث هرج و مرج و بی ثباتی می شد
یک روز، Deployment وارد یک جلسه Kubernetes شد و StatefulSet را ملاقات کرد. استقرار بلافاصله اسیر لطف و ثبات StatefulSet شد. آنها شروع به گذراندن زمان بیشتری با هم کردند و Deployment به سرعت متوجه شد که چقدر یکدیگر را تکمیل می کنند. در اینجا برخی از ویژگی هایی که StatefulSet را غیرقابل مقاومت کرده است آورده شده است:
- هویت قابل اعتماد آن این مانند داشتن شریکی بود که هرگز شماره تلفن یا آدرس ایمیل خود را تغییر نداد – همیشه قابل دسترس و قابل اعتماد.
- ذخیره سازی دائمی: مثل این بود که با کسی باشید که هیچ وقت کلیدهای خود را گم نکرده یا تاریخ های مهم را فراموش نکرده است.
- به‌روزرسانی‌های برازنده: پادها یکی یکی به‌روزرسانی شدند تا از ثبات و حداقل اختلال اطمینان حاصل شود
- استقرار سفارشی: رویکرد روشی برای استقرار و مقیاس‌بندی غلاف
با شکوفا شدن روابط Deployment و StatefulSet، اغلب دوست ثابت قدم آنها، DaemonSet به آنها ملحق می شد. DaemonSet تضمین کرد که سرویس‌های ضروری، مانند عوامل ورود به سیستم و ابزارهای نظارت، در هر گره در خوشه اجرا می‌شوند. دقت و فداکاری DaemonSet مورد تحسین همه قرار گرفت.
استقرار، ایاب را استخدام کرد، خدمتکاری سخت کوش، مسئول اجرای وظایف خاص تا تکمیل. آنها اطمینان حاصل کردند که پردازش دسته ای و سایر وظایف محدود به زمان با موفقیت اجرا می شوند.
Secrets یک محرم بود و اطلاعات حساس مانند رمز عبور و کلیدهای API را ایمن نگه می داشت. آنها اطمینان حاصل کردند که این داده ها به طور ایمن ذخیره می شود و فقط برای کسانی که به آن نیاز دارند دسترسی دارند.
ConfigMaps به دوستان سازمانی Deployment تبدیل شد و داده های پیکربندی را برای Pods فراهم کرد. آنها اطمینان دادند که برنامه ها می توانند به صورت پویا و بدون نیاز به بازسازی تصاویر پیکربندی شوند.
با رشد شهر کوبرنتس، نظم باید حفظ می شد. فضاهای نام برای ایجاد انبوهی از واقعیت ها در شهر استخدام شدند. آنها برنامه های کاربردی را در حوزه های مجازی خود جدا کردند.
با این دستاورد، کوبرنیت ها یک مهمانی خانه دار ترتیب دادند. مهمانان دعوت شده از راه دور آمده بودند. کوبرنتس باید برای آنها آماده می شد. بنابراین افسران امنیتی Networkpolicy را نامیدند، که تضمین می کند که فقط مهمانان منتخب و مجاز با پادها صحبت می کنند و یک محیط امن را برای همه در شهر ایجاد می کنند.
یک دروازه بان به نام اینگرس نیز استخدام شد که یک مدیر ترافیک متعهد بود که به طور موثر ترافیک ورودی و خروجی را کنترل می کرد. Ingress میهمانان را با خدمات مربوطه خود نقشه برداری کرد و از جریان روان و کارآمد ترافیک اطمینان حاصل کرد.
با بزرگ شدن مهمانی و افزایش ارتباطات بین مهمان، خدمات به کمک نیاز داشتند، بنابراین Endpoints استخدام شدند! آنها مانند اپراتورهای تلفن پویا عمل می کردند. آنها ارتباط را با مسیریابی تماس ها از سرویس ها به پادهای مربوطه تسهیل کردند.
برای اطمینان از اینکه هیچ کس در مهمانی غرق نشده است، نیازها برآورده می شود و منابع هدر نمی رود، برادران دوقلو Limits و درخواست ها استخدام شدند. در حالی که درخواست‌ها میزان مصرف هر کوئست برای سرگرمی را بررسی می‌کردند، محدودیت‌ها باعث می‌شد که مصرف کلی در مقدار توافق شده باقی بماند.
مهمانانی دعوت شده بودند که به آنها حساب های خدماتی با وظایف تعیین شده گفته می شد. نقش‌ها و نقش‌بندی برای مدیریت کنترل دسترسی و مجوزها به مکان‌های مختلف مهمانی به شیوه‌ای سازمان‌یافته و ایمن استخدام شدند.
Clusterrole و Clusterrolebinding یک اصل حاکم را در نظر گرفتند و آن را در سطح شهر گسترش دادند.
در شهر همیشه در حال تکامل Kubernetes، ساکنان از ساختارها و سیستم های موجود راضی بودند. اما با گذشت زمان، شهروندان رویای ساختمان‌های جدید و منحصربه‌فردی را در سر می‌پرورانند که می‌توانند اهدافی فراتر از آنچه در حال حاضر امکان‌پذیر بود، داشته باشند.
از این تمایل، تعاریف منابع سفارشی (CRDs) پدید آمدند، معماران رویایی شهر Kubernetes. آنها توانایی طراحی انواع جدیدی از ساختمان ها را با خود به ارمغان آوردند – سازه هایی که در ابتدا بخشی از نقشه های شهر نبودند اما اکنون برای رشد و تنوع آن ضروری بودند.
این CRDها به ساکنان این امکان را می‌دادند تا انواع Pods، سرویس‌ها و کنترل‌کننده‌های مخصوص به خود را تعریف کنند – هر کدام با ویژگی‌ها و رفتارهای خاص خود. آنها مانند خانه‌ها و دفاتر سفارشی بودند که بر اساس نیازهای خاص صاحبانشان طراحی شده بودند، اما به طور یکپارچه با چشم‌انداز شهر ادغام شدند.
با غروب خورشید در شهر Kubernetes، همه اشیا جمع می شوند تا از قدرت همکاری و نوآوری لذت ببرند.
اما این فقط پایان داستان ما نیست. این آغاز سفر شما در شهر Kubernetes است. همانطور که در خیابان های آن پرسه می زنید، اسرار بیشتری را کشف خواهید کرد، با چالش های جدیدی روبرو خواهید شد و شاید به میراث آن کمک کنید.
اکنون، خواننده عزیز، نوبت شماست که افکار خود را به اشتراک بگذارید. آیا شخصیت مورد علاقه ای در داستان ما پیدا کردید؟ آیا مفهومی وجود دارد که بخواهید بیشتر بررسی کنید؟ بینش و سوالات شما آجر و ملات است که به ساخت فصل بعدی شهر Kubernetes کمک می کند.
لطفا وارد میدان شهر شوید و ایده های خود را بیان کنید:
چه چیزی در مورد روایت Kubernetes ما بیشتر از همه لذت بردید؟
دوست دارید درباره کدام شی کوبرنتس بیشتر بشنوید؟
آیا پیشنهادی برای شخصیت ها یا ویژگی های جدید برای افزودن به داستان دارید؟
بازخورد شما بسیار ارزشمند است، و با هم، ما می‌توانیم به ابهام زدایی از دنیای Kubernetes ادامه دهیم و آن را برای همه در دسترس و لذت‌بخش کنیم.
از اینکه در این ماجراجویی به من پیوستید متشکرم. من مشتاقانه منتظر شنیدن داستان ها و تجربیات شما در شهر Kubernetes هستم. تا دفعه بعد، به کاوش و نوآوری ادامه دهید!
