چرا کوبرنتیز این شکلی طراحی شده؟ - قسمت اول

مقدمه

کوبرنتیز که این همه سر و صدا کرده چجوری طراحی شده؟ و دلیل این طراحی چیه؟ جواب این دو تا سوال می‌تونه به افرادی که در زمینه‌ی زیرساخت کار می‌کنن کمک کنه درک بهتری از این ابزار محبوب داشته باشن. تو این قسمت و قسمت‌های بعد می‌خوام راجع به این موضوع صحبت کنم. این مطالب برگرفته از ارائه‌ی سعد علی از شرکت گوگل در kubecon سال ۲۰۱۸ هست. ایشون جزو توسعه‌دهندگان کوبرنتیز هست و تو این ارائه توضیح میده که اصول معماری کوبرنتیز چه چیزهایی هستن و دلیل هر کدوم چیه. ما هم اینجا اون اصول رو بررسی می‌کنیم.

اگه در حوزه‌ی زیرساخت هستید و با کوبرنتیز کار می‌کنید این نوشته می‌تونه به شما دید خوبی بده تا علاوه بر ساختار کوبرنتیز علتش رو هم بدونید و عمیق‌تر با کوبرنتیز آشنا بشید. تو این نوشته فرض شده شما با کوبرنتیز آشنایی ابتدایی دارید. اگر هم تجربه‌ی عملی داشته باشید که چه بهتر.

کوبرنتیز چیه؟

خب فرض کرده بودیم کسایی که این متن رو می‌خونن می‌دونن کوبرنتیز چیه. پس این بخش رو فاکتور می‌گیریم :)

برای اطلاعات بیشتر به سایت رسمی کوبرنتیز مراجعه کنید.

حالا که معلوم شد کوبرنتیز چیه، به اصول طراحی کوبرنتیز می‌رسیم.

اصل اول - declarative به جای imperative

تفاوت imperative با declarative

این دو تا عبارت رو احتمالا در ابزارهای دواپس زیاد دیدید و شنیدید. imperative یعنی من وقتی می‌خوام یه کاری انجام بشه تمام دستورات لازم برای اون رو بگم. مثلا یه برنامه نوشتم و از روش یک ایمیج ساختم و تو یه رجیستری پوش کردم. می‌خوام همیشه سه تا کانتینر از این بالا باشه.‌ برای انجامش به شکل imperative باید بگم اول ایمیج رو پول کنم، بعد از روی ایمیج سه تا کانتینر بسازم و حواسم باشه هر وقت تعداد کانتینرها کم شد (مثلا یکیش OOM شد) دوباره یه دونه بالا بیارم. تازه اگه چند تا ماشین مجازی یا حقیقی داشته باشم که بحث scheduling هم پیش میاد.

اما declarative برخلاف این هست. یعنی من حالت مورد انتظارم رو میگم و بقیه‌اش رو می‌سپارم به یه ابزاری که خودش اون حالت رو برآورده کنه. مثلا میگم سه تا کانتینر از ایمیج nginx:1.21.1. دیگه کاری ندارم چه اتفاقی می‌افته. ابزاری که دارم خودش حواسش هست و سعی می‌کنه به اون حالت مطلوب برسه. اینجا اون ابزار کوبرنتیزه.

یک مثال

تفاوت این دو تا رو میشه با یه مثال بهتر درک کرد. imperative مثل وقتی هست که خلبان هواپیما خودش داره هواپیما رو کنترل می‌کنه. تو این شرایط خلبان همه چیز رو مانیتور می‌کنه و اگه کاری لازم باشه انجام میده. در مقابلش declarative حالت auto pilot هست که سیستم خود هواپیما کنترل‌کننده است و تغییرات رو زیر نظر داره و همیشه سعی می‌کنه وضعیت رو اون طور که خلبان گفته نگه داره.

در کوبرنتیز چه شکلی پیاده شده؟

حالا بیاید ببینیم در کوبرنتیز چجوری از declarative API استفاده میشه. به عنوان مثال فرض کنید ما با kubectl به API server دستور میدیم که یک object (مثلا یک ReplicaSet) ساخته بشه و اون هم داخل etcd ذخیره‌اش می‌کنه. تعریف ReplicaSet تو این مثال این شکلی هست:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: cache
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
       -name: web-server
        image: nginx:1.21.1

خواستم که ۳ تا پاد از ایمیج nginx:1.21.1 رو همیشه بالا نگه داره. از این به بعد دیگه کاری نداریم که چه اتفاقی می‌افته. خود کوبرنتیز حواسش هست که همیشه این ۳ تا بالا باشن. تو این شکل‌های پایین به شکل ساده شده این موضوع رو می‌بینین:

گفتم کوبرنتیز خودش حواسش هست که ۳ تا رپلیکا همیشه داشته باشیم؛ اما چجوری حواسش هست؟ آیا API server خودش این رو مدیریت می‌کنه؟ یا شکل دیگه‌ای پیاده شده؟ این که چجوری این اتفاق در کوبرنتیز می‌افته موضوع اصل دوم هست که ایشالا در قسمت بعد صحبت می‌کنیم.

جمع‌بندی

در این نوشته یکی از اصول طراحی کوبرنتیز که داشتن declarative API به جای imperative بود رو بررسی کردیم و تفاوت این دو رو هم دیدیم. در قسمت بعد در مورد اصل دوم حرف می‌زنیم.

امیدوارم این نوشته براتون مفید بوده باشه. اگر نظر یا سوالی دارین این پایین بفرمایین.

قسمت بعد