الان که اینجا هستیم، فکر میکنم که آشنایی اولیه با اینکه کوبرنتیز چیه و چه کاری تحت عنوان Container Orchestration Platform انجام میده دارید؛ در غیر این صورت بهتره که کمی درمورد این ابزار مطالعه‌ی اولیه داشته باشید تا بهتر بتونیم فایده نکاتی که در ادامه‌ی مطلب بهشون اشاره میکنیم رو متوجه بشیم.
همونطور که میدونید، بعد از اینکه ریلیز جدیدی از اپلیکیشنمون ایجاد میشه، احتمالا با استفاده از CI Pipeline ها فرایند ایجاد Container Image رو در پیش میگیرید؛ کوبرنتیز یک ابزار بسیار جذاب برای ارائه ی امکانات مختلف به شماست و یکی از فوایدش، پیاده سازی Deployment Strategy های پیچیده هستش.
کوبرنتیز برای ما در سازمان ها، تحت عنوان یک یک پلتفرم سرویس دهی میکنه و افراد مختلفی در جایگاه های مختلف(دواپس، SRE، توسعه دهنده و...) ممکنه با این پلتفرم به شکلی روزانه درگیر باشند؛ چالش موضوع ایجاست که ممکنه برخی از این استفاده کننده ها در جریان یکسری Best Practice ها و الزامات پیاده سازی یک اپلیکیشن در سطح کوبرنتیز باشن، اما قطعا افرادی هم وجود دارند که پالیسی ها و Right thing و Bad thing را درمورد این پلتفرم نمیدونن!
جدا از راه های درست و غلط در استفاده از پلتفرم کوبرنتیز و باید نبایدهای تکنیکال که ممکنه به شکل تجربی بدست بیاد، در سازمان های مختلف بنا به سیاست ها و محدودیت ها و ساختار های موجود، یکسری الزامات و استاندارد ها میبایستی در پیاده سازی سرویس ها درنظر گرفته شوند که اگر با استفاده از فرایندهای عادی سازمانی بخوایم یکسری پالیسی ها و استانداردهای سازمانی رو اعمال کنیم، احتمالا درگیر فرایندهای سازمانیِ بسیار وقت گیر و طولانی ای میشیم(مثل مکاتبات زیاد، جلسات زیاد و...).
ابزار Kyverno یک Kubernetes-native policy engine هستش که بهتون این امکان رو میده که پالیسی ها و ساختار های موردنظرتون، Best Practiceهای موردنظرتون، سیاست ها و استانداردهای موردنظرتون رو As a code تعریف و پیاده سازی کنید؛ Kyverno به شکل مستقیم بروی Kubernetes Cluster دیپلوی میشه و از Custom Resource برای تعریف Policyها استفاده میکنه. با استفاده از Admission Webhookها، Kyverno میتونی Policy violation ها رو تشخیص بده و حتی از اعمال اونها، جلوگیری کنه.
برای بهتر متوجه شدن موضوع، یک مثال رو باهم بررسی میکنیم:
فرض کنید یک دولوپر در سازمان شما، از تگ های latest برای ایمیجهای اپلیکیشنش استفاده کنه و خب هممون میدونیم که این موضوع چه در کوبرنتیز و حتی در داکر، میتونه ایجاد ریسک کنه و عملکرد اپلیکیشن رو تحت تاثیر قرار بده؛ اگر policy engine ای در این سناریو وجود نداشته باشه، تا زمان اینکه دولوپر اپلیکیشن خودش رو روی عملیات ببره و یک نفر متوجه اشتباهش بشه و بهش خبر بده که اشکالش رو ویرایش کنه، ممکنه که ضررهای زیادی متحمل شده باشیم! اما اگر این policy engine وجود داشته باشه، درصورتی که این پالیسی تعریف شده باشه که نباید از ایمیج های دارای تگ latest استفاده کرد، کاربر به محض تلاش برای دیپلوی با یک خطا روبرو میشه که مشخصا بهش اطلاع میده که میبایستی از تگ های specific استفاده کنه.
که البته، حتی این قابلیت وجود داره که CI/CD Workflow ما با این ابزار Integrate بشه و زودتر مارو در جریان اشتباهمون قرار بده که در ادامه، مثال این موضوع با Argo CD رو میبینیم...
قبل از هرچیز، باید بدونیم که مثل هر Kubernetes Manifest ای، پالیسی های Kyverno هم میتونن به شکل Git based مدیریت بشن؛ ابزار Argo CD، یک ابزار GitOps هستش که یکی از فواید اون اینه که به شکل مداوم تفاوت های بین desired state (وضعیت قابل انتظار باتوجه به کد) که به شکل کد در داخلش تعریف شده و live state ای که درحال اجرا در کلاستر هستش رو بررسی میکنه؛ احتمالا قابل حدس هستش واستون که با ترکیب این دو ابزار، میتونیم به شکل شفاف پالیسی های درحال اعمال رو مشخص کنیم و با استفاده از Argo CD که درصورت تشخیص Difference بهمون اطلاع میده(و یا به شکل اتومات وضعیت رو به قبل برمیگردونه ویا از اعمال تغییرات جلوگیری میکنه) enforce کردن پالیسی ها را اجرایی کنیم.
در مثال زیر، میخوایم که پالیسیِ require-resource-requests رو تعریف کنیم که الزام تعریف resource requests رو پیاده سازی میکنه و در ادامه، در Argo CD اعمالِ این پالیسی رو تعریف میکنیم:
در ادامه، سعی میکنیم دو پاد nginx رو در کلاستر دیپلوی کنیم، که یکیشون پالیسی رو رعایت میکنه و دیگری نمیکنه!
همونطور که میبینید، nginx ای که پالیسی رو رعایت کرده بود pass و nginx ای که پالیسی رو رعایت نکرده بود، fail میشن:
امیدوارم که این مقاله واستون مفید بوده باشه و بتونید ازش استفاده ی لازم رو ببرید!
برای نوشتن این مطلب، با ویرایش هایی از این مقاله کمک گرفتم که میبایستی بهش اشاره داشته باشم.
موفق باشید!
سجاد غفاریان.
