مدیریت اشیاء اعلامی در مقابل قطعی Kubernetes – CloudSavvy IT

Kubernetes معمولاً به عنوان یک سیستم اعلامی توصیف می شود. اغلب اوقات شما با YAML کار می کنید، وضعیت نهایی سیستم را مشخص می کند. Kubernetes از API های ضروری نیز پشتیبانی می کند، جایی که شما دستوری را صادر می کنید و خروجی فوری دریافت می کنید.

در این مقاله به بررسی تفاوت های این دو شکل مدیریت شی می پردازیم. احتمالاً قبلاً از هر دو استفاده کرده اید حتی اگر با اصطلاحات آشنا نباشید.

اعلامی در مقابل قطعی: تعاریف

ابتدا، بررسی اصطلاحات مفید است.

یه چیزی بیانیه من بیانیه ای از نتیجه نهایی می دهد و به جای روند دستیابی به آن، هدف را نشان می دهد. در Kubernetes، این می گوید “باید یک ReplicaSet با سه کپسول وجود داشته باشد.”

که ضروری به عنوان یک سفارش در حالی که اعلان غیرفعال است، موارد ضروری فعال و فوری هستند: “یک ReplicaSet با سه پاد ایجاد کنید.”

اکوسیستم Kubernetes مکانیسم هایی برای تعامل با گروه شما در هر یک از این مدل ها فراهم می کند. روش های ضروری با دستورات CLI و فایل های YAML فردی برآورده می شوند. پیکربندی اعلامی با استفاده از دایرکتوری های فایل که در نمایش منبع نهایی ترکیب می شوند، تسهیل می شود.

تاکید بر مدیریت اشیا

در اینجا نمونه ای از ایجاد اجباری یک پست است:

kubectl create deployment my-deployment --image my-image:latest

شما از Kubernetes می خواهید که فوراً یک استقرار جدید را به کلاستر شما اضافه کند. دستور شامل یک فعل (create) و نام نوع تامین کننده ای که با آن کار می کنیدdeployment).

همچنین می توانید اجباراً یک فایل YAML را با پسوند . بنویسید و اعمال کنید create مرتب سازی:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: ۳
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
        # ...

kubectl create -f deployment.yml

مانند قبل، شما در حال ساخت یک فرمان فوری از طریق یک فعل فعال هستید. Kubernetes پیکربندی را از فایل شما می گیرد و منابع مربوطه را در خوشه ایجاد می کند. اگر نیاز به به روز رسانی یک منبع دارید، باید YAML خود را تغییر دهید و از پسوند . استفاده کنید replace دستور اعمال تغییر:

kubectl replace -f deployment.yml

این روند خواهد شد حذف منابع موجود را مشخص کنید و آنها را با نسخه موجود در فایل پیکربندی خود جایگزین کنید. این با نام منتقل می شود replace مرتب سازی. این به این معنی است که شما تغییراتی را که در ارگانیسم‌های خود که در YAML شما نیستند از دست خواهید داد.

هنگامی که Kubernetes دستورات ضروری را مصرف می کند، باید دقیقاً به آن گفته شود که چه کاری انجام دهد. بنابراین، هیچ راهی برای اعمال انتخابی تنها بخش‌های متغیر YAML وجود ندارد. بنابراین شما باید به فرآیندهای اعلامی تغییر دهید.

مدیریت اعلامی را امتحان کنید

مدیریت اعلامی تنها در صورت استفاده از فایل های پیکربندی YAML در دسترس است. چیزی به نام دستور اعلامی وجود ندارد. هنگامی که از عملیات اعلانی استفاده می کنید، به Kubernetes نمی گویید که با معرفی یک فعل چه کاری انجام دهد (create/replace). به طور متناوب، می توانید از یکی استفاده کنید apply به Kubernetes فرمان دهید و به آن اعتماد کنید تا بر روی اقداماتی که باید انجام شود عمل کند.

kubectl apply -f deployment.yml

در ادامه با مثال پست بالا، پیاده سازی YAML فوق برای گروه شما در ابتدا به درستی کار خواهد کرد create مرتب سازی. هیچ منبع منطبقی برای شروع وجود نخواهد داشت، بنابراین Kubernetes باید یک منبع جدید ایجاد کند.

سپس می توانید فایل را تغییر دهید replicas دامنه برای ۵ و تکرار کن apply مرتب سازی. این بار، Kubernetes با منبع فعلی مطابقت می‌کند، تغییر در YAML شما را تشخیص می‌دهد و استقرار را بدون تأثیر بر هیچ فیلد دیگری مقیاس می‌دهد.

با رویکرد فرمان، باید از آن استفاده کنید kubectl scale دستور تغییر تعداد کپی ها برای استقرار فعلی. اگر YAML مورد استفاده خود را تغییر دهید kubectl createشما باید بدوید kubectl replace – اما این جایگزین کل نشریه خواهد شد spec، به جای اینکه فقط شماره ماکت آن را کوچک کنید.

اعلامی در مقابل قطعی: مقایسه معاملات

درک و توضیح عملیات قطعی آسان است. هر عمل به عنوان یک فعل با یک نتیجه کاملاً مشخص بیان می شود. به همین دلیل، اکثر مردم اولین تعاملات خود را با Kubernetes با دستورات ضروری شروع می کنند که می توانند به راحتی به فناوری های دیگری مانند Docker اختصاص داده شوند.

مدیریت اعلامی قدرت واقعی Kubernetes را آشکار می کند. شما اعلام می کنید که حالت نهایی چگونه باید باشد، سپس بقیه را به Kubernetes بسپارید. هر فرمان همان عمل ضروری را دارد – apply این مجموعه ای از فایل های YAML است و بلوک را به حالتی که شما مشخص کرده اید رندر می کند.

مدیریت اعلامی برای استقرار خودکار ایده آل است. هر بار که یک منبع را به روز می کنید، نیازی به صرف زمان برای ایجاد مجموعه ای از دستورالعمل های مهاجرت ندارید. متناوباً، YAML خود را طوری تنظیم کنید که اگر در آن لحظه از نو ایجاد شده باشند، اشیاء به درستی مقداردهی اولیه شده تولید کند. Kubernetes به روز رسانی اشیاء موجود را برای مطابقت با وضعیت جدید نیز مدیریت خواهد کرد.

کپی کردن، بررسی و ادغام فایل های تعریف YAML به عنوان بخشی از سیستم کنترل منبع شما آسان است. اگر از دستورات اجباری استفاده کنید، هیچ راهی برای پیگیری نحوه توسعه گروه خود نخواهید داشت و بازگشت به حالت قبلی دشوارتر خواهد بود. برخلاف عملیات اجباری، به‌روزرسانی‌های حاشیه‌نویسی کل شی را بازنویسی نمی‌کنند، بنابراین بدون توجه به فایل‌های YAML، تغییرات خود را از طریق مکانیسم‌های دیگر حفظ خواهید کرد.

با این حال، مدیریت قطعی برخی از مزایای را حفظ می کند. پیکربندی اعلانی لایه‌هایی از پیچیدگی را اضافه می‌کند و ممکن است اشکال‌زدایی آن دشوار باشد، به‌ویژه زمانی که Kubernetes یک اقدام غیرمنتظره را تعریف می‌کند. هر تغییر منجر به یک فرآیند ادغام و اصلاح می شود تا عناصر شما را با حالتی که می خواهید مطابقت دهد. با فرم فرمان، آنچه می‌پرسید چیزی است که می‌گیرید، مگر اینکه مشکلی پیش بیاید.

مانند همیشه هنگام ارائه دو روش، هر دو استراتژی مفید هستند و انتخاب آنها باید به زمینه بستگی داشته باشد. برای دسته‌های تولیدی که میزبان برنامه‌های زنده با تغییرات مکرر هستند، احتمالاً فایل‌های تعریف انتشار YAML را می‌خواهید. اگر به سرعت کانتینرهای جدیدی را در یک مجموعه توسعه منتشر می کنید، دستورات اجباری باعث صرفه جویی در زمان و کار با آن ها می شود.

نتیجه

مدیریت اعلامی و اجباری دو راه برای تعامل با خوشه Kubernetes و منابع آن است. Kubectl از هر دوی این استراتژی‌ها پشتیبانی می‌کند، اما تکنیک‌ها نباید بر اساس هر شیء مخلوط شوند. اگر یک شی را به صورت اعلامی ایجاد می کنید، باید در طول عمرش به این ترتیب مدیریت شود – استفاده از دستورات با آن می تواند منجر به رفتار غیرمنتظره شود.

فرآیندهای قطعی بر موجودات درون گروه شما تأثیر می گذارد. شما می توانید فعل، منبع و پیکربندی را از طریق آرگومان های فرمان و پرچم مشخص کنید. مدیریت اعلامی مبتنی بر تغییرات فایل‌های پیکربندی محلی است که Kubectl با آن‌ها متفاوت است و هنگام استفاده از آن از طریق وصله‌ها روی خوشه اعمال می‌شود. kubectl diff و kubectl apply سفارشات