ارتقاء یک خوشه Kubernetes بدون خرابی

فرآیند ارتقا برای خوشه Kubernetes شما

در برخی موارد، هنگام استفاده از خوشه Kubernetes، نیاز به به روز رسانی گره های در حال اجرا وجود دارد. این ممکن است شامل به‌روزرسانی‌های بسته، به‌روزرسانی هسته یا استقرار تصاویر ماشین مجازی جدید باشد. در اصطلاح Kubernetes به این می گویند "اختلال داوطلبانه".

این پست بخشی از یک مجموعه 4 پستی است:

1. این پست.
2. خاموش کردن صحیح غلاف ها در یک خوشه Kubernetes
3. پایان تأخیر یک غلاف هنگام حذف آن
4. چگونه با استفاده از PodDisruptionBudgets از خرابی خوشه Kubernetes جلوگیری کنیم

(تقریباً منتظر ترجمه مقالات باقی مانده در این مجموعه در آینده نزدیک باشید)

در این مقاله، ما تمام ابزارهایی را که Kubernetes برای دستیابی به خرابی صفر برای گره‌های در حال اجرا در خوشه شما ارائه می‌کند، شرح خواهیم داد.

تعریف مشکل

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

برای شروع سفرمان، بیایید یک مثال عینی بزنیم. فرض کنید یک خوشه Kubernetes از دو گره داریم که در آن یک برنامه با دو پاد در پشت آن در حال اجرا است. Service:

بیایید با دو پاد با Nginx و Service در حال اجرا بر روی دو گره خوشه Kubernetes شروع کنیم.

ما می خواهیم نسخه هسته دو گره کارگر را در خوشه خود به روز کنیم. چطور این کار را انجام دهیم؟ یک راه حل ساده این است که گره های جدید را با پیکربندی به روز راه اندازی کنید و سپس گره های قدیمی را در حین شروع گره های جدید خاموش کنید. در حالی که این کار می کند، چند مشکل با این رویکرد وجود خواهد داشت:

• هنگامی که گره های قدیمی را خاموش می کنید، غلاف هایی که روی آنها کار می کنند نیز خاموش می شوند. اگر غلاف ها برای خاموش شدن دلپذیر نیاز به پاکسازی داشته باشند چه باید کرد؟ سیستم مجازی سازی که استفاده می کنید ممکن است منتظر تکمیل فرآیند پاکسازی نباشد.
• اگر همه گره ها را همزمان خاموش کنید چه؟ زمانی که غلاف ها به گره های جدید منتقل می شوند، زمان خرابی مناسبی خواهید داشت.

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

توزیع مجدد همه غلاف ها از یک گره

عملیات تخلیه به شما امکان می دهد همه غلاف ها را از یک گره دوباره توزیع کنید. در طول اجرای تخلیه، گره به عنوان غیرقابل برنامه ریزی علامت گذاری می شود (پرچم NoSchedule). این از ظاهر شدن غلاف های جدید روی آن جلوگیری می کند. سپس تخلیه شروع به خارج کردن غلاف ها از گره می کند، ظروف را که در حال حاضر روی گره در حال اجرا هستند خاموش می کند و سیگنال ارسال می کند. TERM ظروف در یک غلاف

هر چند kubectl drain کار بسیار خوبی برای بیرون راندن غلاف ها انجام می دهد، دو عامل دیگر وجود دارد که می تواند باعث شکست عملیات تخلیه شود:

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

اجتناب از توقف

برای به حداقل رساندن زمان خرابی ناشی از اختلال داوطلبانه، مانند عملیات تخلیه در یک گره، Kubernetes گزینه های مدیریت خرابی زیر را ارائه می دهد:

• خاتمه برازنده
• قلاب چرخه حیات
• PodDisruptionBudgets

در ادامه این سری، از این ویژگی های Kubernetes برای کاهش تأثیر مهاجرت غلاف استفاده خواهیم کرد. برای سهولت در پیروی از ایده اصلی، از مثال بالا با پیکربندی منابع زیر استفاده خواهیم کرد:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

این پیکربندی یک نمونه حداقلی است Deployment، که غلاف های nginx را در خوشه مدیریت می کند. علاوه بر این، پیکربندی منبع را توصیف می کند Service، که می تواند برای دسترسی به پادهای nginx در یک خوشه استفاده شود.

در طول چرخه، ما به طور مکرر این پیکربندی را گسترش خواهیم داد تا در نهایت شامل تمام قابلیت‌هایی باشد که Kubernetes برای کاهش زمان خرابی ارائه می‌کند.

برای یک نسخه کاملاً پیاده‌سازی‌شده و آزمایش‌شده از به‌روزرسانی‌های خوشه Kubernetes برای زمان توقف صفر در AWS و فراتر از آن، به Gruntwork.io.

همچنین سایر مقالات وبلاگ ما را بخوانید:

• عدم استقرار و پایگاه داده صفر
• Kubernetes: چرا پیکربندی مدیریت منابع سیستم بسیار مهم است؟
• خط لوله Tekton - خطوط لوله بومی Kubernetes
• ساخت ماژول های پویا برای Nginx
• مقدمه ای بر مجوز Kubernetes کنسول Hashicorp
• مهاجرت از ClickHouse بدون مجوز به ClickHouse با مجوز منجر به چه چیزی شد؟

منبع: www.habr.com