چرا این موضوع مهم است؟
Kubernetes سیستم desired-state است. شما وضعیت مطلوب را به API Server می‌دهید؛ controllerها اختلاف را می‌بینند، scheduler جای Pod را انتخاب می‌کند و kubelet وضعیت node را به اجرا نزدیک می‌کند. etcd state مهم control plane را نگه می‌دارد.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع اجزای اصلی Kubernetes و reconciliation loop، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
kubectl get -o yaml و eventها را همراه با controller/scheduler/kubelet log ببینید. برای troubleshooting همیشه بپرسید object در کدام مرحله از control loop متوقف شده است.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
Pod Pending همیشه scheduler مشکل‌دار نیست؛ admission، quota، volume یا image pull می‌تواند علت باشد. همچنین restart کردن component قبل از جمع‌آوری evidence تشخیص را سخت می‌کند.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک Deployment بسازید، replica را تغییر دهید، یک scheduling constraint ناممکن اضافه کنید و eventها را دنبال کنید. سپس مشکل را رفع و زمان reconciliation را اندازه بگیرید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ اجزای اصلی Kubernetes و reconciliation loop ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Kubernetes انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
دنبال کردن یک درخواست واقعی، از ثبت تا سرویس‌دهی
فرض کنید تیم فروش می‌خواهد سه نمونه از برنامه سفارش داشته باشد. فایل Deployment شرح خواسته است و به معنای اجرای فوری سه فرایند نیست. درخواست ابتدا به API Server می‌رسد و باید احراز هویت، مجوز و کنترل‌های پذیرش را بگذراند. پذیرش موفق فقط می‌گوید شیء معتبر ثبت شده است. کنترل‌گر Deployment با مشاهده وضعیت، ReplicaSet مناسب را مدیریت می‌کند و آن کنترل‌گر تعداد Pod مورد نیاز را دنبال می‌کند. پس میان درخواست اولیه و اجرای برنامه چند تصمیم مستقل وجود دارد؛ برای یافتن تأخیر باید همین تصمیم‌ها را جدا مشاهده کرد.
Scheduler برای Pod بدون میزبان، گره مناسب را با توجه به درخواست منابع و محدودیت‌های زمان‌بندی انتخاب می‌کند. این انتخاب تصویر برنامه را دریافت نمی‌کند و برنامه را اجرا نمی‌کند. Kubelet روی گره منتخب، از طریق محیط اجرای کانتینر و اجزای مرتبط شبکه و ذخیره‌سازی، شرایط اجرای Pod را فراهم می‌کند. بنابراین اگر نام گره برای Pod ثبت شده ولی کانتینر بالا نیامده است، بررسی صرف صف زمان‌بند مسیر مناسبی نیست. وضعیت دریافت تصویر، اتصال دیسک، تنظیمات شبکه و رخدادهای همان گره در اولویت قرار می‌گیرند.
تفاوت اجرای برنامه با آماده بودن آن
سه نمونه در وضعیت Running الزاماً سه پاسخ‌دهنده سالم نیستند. برنامه می‌تواند فرایند زنده داشته باشد اما اتصال پایگاه داده برقرار نباشد. Readiness باید نشان دهد آیا این نمونه برای دریافت ترافیک مناسب است. Liveness برای تشخیص شرایطی است که راه‌اندازی مجدد احتمالاً مفید است؛ وابسته کردن آن به هر قطعی کوتاه پایگاه داده می‌تواند تمام نمونه‌ها را هم‌زمان وارد چرخه بازراه‌اندازی کند. Startup probe نیز برای برنامه‌هایی که آغاز کار طولانی دارند امکان تفکیک دوره راه‌اندازی از خرابی واقعی را فراهم می‌کند.
برای آزمایش این تفاوت، یک برنامه آزمایشی با مسیر سلامت مستقل بسازید و موقتاً فقط پاسخ آمادگی را ناموفق کنید. انتظار دارید فرایند همچنان اجرا شود اما نمونه از مقصدهای آماده سرویس کنار برود. سپس همان برنامه را با توقف فرایند آزمایش کنید و تغییر شمارنده بازراه‌اندازی را ببینید. این دو آزمایش به تیم پشتیبانی نشان می‌دهد که افزایش خطا همیشه به معنی نیاز به حذف Pod نیست و حذف بی‌دلیل ممکن است شواهد مفید را از بین ببرد.
خرابی صفحه کنترل و ادامه کار موجود
صفحه کنترل مسئول تصمیم‌های مدیریتی است، اما بسته‌های عادی هر درخواست وب لازم نیست از API Server عبور کنند. با اختلال صفحه کنترل ممکن است برنامه‌های موجود مدتی کار کنند، در حالی که تغییر مقیاس یا جایگزینی نمونه خراب به مشکل بخورد. این تفاوت نباید به اطمینان کاذب تبدیل شود: از دست رفتن یک گره در همین بازه می‌تواند ظرفیت را کاهش دهد و تنظیمات جدید نیز اعمال نمی‌شوند. آزمون سلامت باید هم یک درخواست واقعی برنامه و هم امکان مشاهده و تغییر کنترل‌شده یک شیء آزمایشی را بسنجد.
etcd محل نگهداری وضعیت خوشه است و با دیسک داده برنامه یکی نیست. نسخه پشتیبان آن جای پشتیبان پایگاه داده داخل PersistentVolume را نمی‌گیرد. برای برنامه سفارش، بازیابی تنظیمات Deployment بدون بازیابی داده سفارش‌ها تنها پوسته سرویس را بازمی‌گرداند. از طرف دیگر، داشتن پشتیبان داده بدون اطلاعات Secret، تنظیمات شبکه و وابستگی‌ها ممکن است راه‌اندازی مجدد را طولانی کند. سناریوی بازیابی باید این دو نوع دارایی را جدا نام ببرد و ترتیب استفاده از آن‌ها را توضیح دهد.
تمرین تشخیص مرحله شکست
یک تصویر ناموجود، یک درخواست حافظه بیش از ظرفیت گره و یک نام Secret اشتباه، سه خرابی متفاوت ایجاد می‌کنند. هر مورد را جدا در فضای آزمایش بسازید و برای آن وضعیت شیء، رخدادها و پیام کانتینر را ثبت کنید. بعد از رفع علت، بررسی کنید کنترل‌گر بدون دخالت اضافی به خواسته اولیه نزدیک می‌شود یا نه. اگر تیم برای هر سه مسئله یک دستور بازراه‌اندازی پیشنهاد کند، هنوز مرز مسئولیت اجزا روشن نشده است. خروجی مفید این تمرین یک نقشه تصمیم کوتاه است که از نشانه به مشاهده بعدی می‌رسد، نه مجموعه‌ای از فرمان‌های تصادفی.
