مقدمه
CRI-O درخواست kubelet را به lifecycle pod/container و runtime سازگار با OCI وصل می‌کند. این راهنما بر مستندات رسمی CRI-O تکیه دارد و هدفش ساختن مدل ذهنی برای deployment و عیب‌یابی است، نه کپی‌کردن configuration نمونه.
اجزای اصلی
پنج جزء را جدا ببینید: CRI، pod sandbox، OCI runtime، image management و CNI و metrics. برای هرکدام مشخص کنید configuration است یا state، در control plane قرار دارد یا data plane، و در زمان failure چه چیزی باید حفظ شود.
مسیر داده و state
در طراحی واقعی، state ماندگار را از cache و state قابل بازسازی جدا کنید. اگر در incident ندانیم کدام داده authoritative است، restart یا restore می‌تواند مشکل را بزرگ‌تر کند. مسیر ایجاد، تغییر، replication و حذف state باید مستند باشد.
ظرفیت و مقیاس
مقیاس‌دادن فقط افزایش replica نیست. CPU، memory، I/O، network، تعداد objectها و queueها را جدا اندازه بگیرید. bottleneck را از metric واقعی پیدا کنید و پیش از افزایش resource، retry و backpressure را بررسی کنید.
امنیت
identity و least privilege را نقطه شروع قرار دهید. secretها نباید در manifest یا log رها شوند. مسیر admin و data plane را تا جای ممکن جدا کنید و تغییر policy را audit کنید. certificate و rotation نیز بخشی از lifecycle هستند.
مشاهده‌پذیری
حداقل health، latency، error rate و saturation را ثبت کنید. در سامانه توزیع‌شده correlation id و metadata محیطی برای دنبال‌کردن درخواست مهم‌اند. alert باید owner و runbook داشته باشد و failure dependency را از failure خود سرویس جدا کند.
failure mode مهم
ناسازگاری نسخه Kubernetes و CRI-O یا تنظیم CNI و SELinux می‌تواند node را NotReady کند. قبل از production سناریوهای قطع شبکه، پرشدن storage، credential منقضی، restart هم‌زمان و ناسازگاری نسخه را روی کاغذ مرور کنید و معلوم کنید سیستم fail closed می‌کند یا fail open.
rollout ایمن
تغییر را مرحله‌ای کنید: export وضعیت فعلی، اجرای canary، مقایسه metric قبل و بعد، و توسعه scope فقط پس از رسیدن به معیار پذیرش. اگر format داده یا API تغییر می‌کند، rollback ممکن است صرف نصب نسخه قدیمی نباشد.
runbook
runbook باید endpoint health، محل log، دستورهای read-only تشخیصی، dependencyها، backup و escalation را داشته باشد. فرمان destructive را از diagnosis جدا نگه دارید و در incident یک متغیر را در هر مرحله تغییر دهید.
آزمایش پیشنهادی
در محیط lab، یک workload یا dataset غیرحساس بسازید و مسیر سالم، failure و recovery را ثبت کنید. زمان بازیابی و signalهای قابل مشاهده را اندازه بگیرید تا پیش از production بدانید چه alertی واقعاً مفید است.
جمع‌بندی
ارزش CRI-O فقط feature list نیست. معماری زمانی قابل اتکاست که اجزای بالا observable، recoverable و دارای owner باشند. ابتدا requirement و failure budget خود را مشخص کنید، بعد configuration نمونه را با محیط خود تطبیق دهید.
