امشب از resourceهای تخصصی Kubernetes به خودکارسازی تحویل می‌رسیم. محور مشترک reconciliation است: StatefulSet هویت Pod را حفظ می‌کند، GitOps وضعیت اعلام‌شده را با کلاستر مقایسه می‌کند و راهبرد انتشار تغییر را با blast radius کنترل‌شده جلو می‌برد.

پرسش‌های ۸۱ تا ۸۵: ارکستراسیون پیشرفتهٔ container#

۸۱. StatefulSet چیست؟#

پاسخ کوتاه: StatefulSet کنترلری برای Podهایی است که هویت شبکه‌ای پایدار، storage متناظر یا ترتیب ایجاد و به‌روزرسانی می‌خواهند. هر replica ordinal و نام ثابتی دارد و می‌تواند PersistentVolumeClaim جدا دریافت کند.

StatefulSet پایگاه داده را به‌تنهایی highly available نمی‌کند؛ replication و membership منطق خود برنامه یا operator است. حذف یا scale-down به‌طور پیش‌فرض volume را خودکار پاک نمی‌کند تا داده ناخواسته از بین نرود. headless Service معمولاً هویت DNS را فراهم می‌کند. برای workload stateless که replicaها قابل تعویض‌اند، Deployment ساده‌تر است. نیاز واقعی به هویت و ترتیب باید انتخاب StatefulSet را توجیه کند.

۸۲. DaemonSet چیست؟#

پاسخ کوتاه: DaemonSet تضمین می‌کند روی همه یا مجموعه‌ای از nodeهای واجد شرایط یک Pod اجرا شود. agent جمع‌آوری log، monitor node، network plugin و storage daemon نمونه‌های رایج‌اند.

با اضافه‌شدن node، Pod متناظر زمان‌بندی می‌شود و با حذف node از بین می‌رود. selector، affinity، taint و toleration تعیین می‌کنند کجا اجرا شود. DaemonSet برای scale بر اساس تقاضای کاربر نیست؛ تعداد replica تابع nodeهاست. agent سطح میزبان ممکن است mount و privilege حساس بخواهد، پس service account، capability و hostPath باید حداقلی باشند. rollout خراب می‌تواند همهٔ nodeها را تحت تأثیر بگذارد.

۸۳. Helm چیست؟#

پاسخ کوتاه: Helm package manager رایج Kubernetes است. chart قالب‌ها، default value و metadata منابع را بسته‌بندی می‌کند و release نمونهٔ نصب‌شدهٔ chart با valueهای مشخص است.

Helm تکرار YAML را کم و نصب نسخه‌دار را آسان می‌کند، اما template پیچیده می‌تواند manifest نهایی را پنهان کند. پیش از اعمال، render و diff را ببینید و schema value داشته باشید. secret را در فایل value عمومی commit نکنید. rollback Helm لزوماً داده و تغییر بیرونی را برنمی‌گرداند؛ migration پایگاه باید راهبرد جدا داشته باشد. chart نیز باید با نسخهٔ Kubernetes و CRDها سازگار آزموده شود.

۸۴. Istio چیست؟#

پاسخ کوتاه: Istio یک service mesh است که مدیریت ترافیک، telemetry، هویت workload و policy امنیتی را برای ارتباط سرویس‌ها ارائه می‌دهد. control plane پیکربندی را توزیع می‌کند و data plane ترافیک را پردازش می‌کند.

مدل کلاسیک از proxy sidecar استفاده می‌کند و حالت‌های جدیدتر می‌توانند معماری متفاوت داشته باشند؛ پس پاسخ را به sidecar محدود نکنید. قابلیت‌هایی مانند mTLS، retry و traffic split مفیدند، اما retry نادرست بار خرابی را بیشتر می‌کند. Istio پیچیدگی certificate، upgrade، latency و debugging می‌آورد. قبل از انتخاب باید نیاز و توان عملیات mesh روشن باشد.

۸۵. Container Runtime Interface چیست؟#

پاسخ کوتاه: CRI رابط gRPC میان kubelet و container runtime است. این قرارداد اجازه می‌دهد Kubernetes با runtimeهای سازگار مانند containerd و CRI-O، بدون وابستگی مستقیم به پیاده‌سازی داخلی آن‌ها، Pod sandbox و container را مدیریت کند.

CRI با OCI یکسان نیست. OCI مشخصات image و runtime سطح پایین را تعریف می‌کند؛ CRI API مورد انتظار kubelet را. حذف dockershim از Kubernetes به معنی پایان imageهای Docker نبود، زیرا imageهای سازگار با OCI در runtimeهای دیگر اجرا می‌شوند. در عیب‌یابی باید بدانیم فرمان docker ممکن است containerهای Kubernetes را نبیند و ابزار runtime مانند crictl برای مشاهده از راه CRI مناسب‌تر باشد.

پرسش‌های ۸۶ تا ۹۰: ابزار و automation دوآپس#

۸۶. infrastructure automation چیست؟#

پاسخ کوتاه: automation زیرساخت تبدیل provision، پیکربندی، validation، patch و عملیات تکراری به گردش کار قابل اجرا و ممیزی است. IaC یکی از روش‌هاست، اما automation چرخهٔ گسترده‌تری از درخواست تا بازنشستگی resource دارد.

خودکارکردن فرایند نامطمئن فقط خطا را سریع‌تر می‌کند. ورودی، idempotence، مجوز، concurrency، rollback و مشاهدهٔ نتیجه باید طراحی شوند. API و queue معمولاً از script دستی مقیاس‌پذیرترند. approval برای تغییر پرخطر می‌تواند باقی بماند، ولی اجرا پس از آن تکرارپذیر باشد. معیار موفقیت کاهش زمان، خطا و toil است؛ نه صرفاً تعداد jobهای خودکار.

۸۷. GitOps چیست؟#

پاسخ کوتاه: GitOps یک مدل عملیات برای سامانه‌های اعلانی است که وضعیت مطلوب نسخه‌دار و تغییرناپذیر در Git نگه‌داری می‌شود، تغییر با pull request انجام می‌گیرد و agent به‌طور پیوسته وضع واقعی را با آن reconcile می‌کند.

Git فقط محل فایل نیست؛ audit و فرایند تغییر را فراهم می‌کند. credential کلاستر نباید در repo باشد و secret به روش امن رمز یا ارجاع شود. تغییر دستی در کلاستر یا به‌عنوان drift بازگردانده می‌شود یا باید به Git منتقل شود. rollback معمولاً revert وضعیت مطلوب است، ولی داده و migration را خودکار به عقب نمی‌برد. pull-based بودن blast radius credential CI را کاهش می‌دهد.

۸۸. Argo CD چیست؟#

پاسخ کوتاه: Argo CD ابزار Continuous Delivery اعلانی و GitOps برای Kubernetes است. manifest مورد انتظار را از Git یا منبع تعریف‌شده می‌خواند، با live state مقایسه می‌کند و تفاوت را نمایش یا بر اساس policy همگام می‌کند.

وضعیت Synced فقط برابری تعریف را می‌گوید و Healthy از health assessment resourceها می‌آید؛ هیچ‌کدام موفقیت کسب‌وکار را به‌تنهایی ثابت نمی‌کنند. auto-sync و self-heal باید با پنجرهٔ تغییر و مدیریت drift هماهنگ شوند. پروژه‌ها و RBAC دامنهٔ repo و destination را محدود می‌کنند. دسترسی Argo CD پرقدرت است و حفاظت controller، credential repo و audit اهمیت دارد.

۸۹. Tekton چیست؟#

پاسخ کوتاه: Tekton چارچوب cloud-native برای ساخت pipelineهای CI/CD روی Kubernetes است. Custom Resourceهایی مانند Task، TaskRun، Pipeline و PipelineRun مراحل و اجرای آن‌ها را مدل می‌کنند و stepها در Pod اجرا می‌شوند.

Tekton building block است، نه تجربهٔ کامل تحویل بدون طراحی. workspace، result، credential، timeout و cleanup باید تعریف شوند. اجرای build داخل Kubernetes نیازمند جداسازی tenant و محدودکردن privilege است؛ ساخت image با socket پرقدرت Docker ریسک دارد. version API و componentهای Tekton باید pin و ارتقا آزموده شوند. Tekton با Argo CD می‌تواند مکمل باشد: یکی artifact می‌سازد و دیگری وضعیت را reconcile می‌کند.

۹۰. راهبردهای deployment کدام‌اند؟#

پاسخ کوتاه: recreate نسخهٔ قبلی را متوقف و جدید را جایگزین می‌کند؛ rolling update replicaها را تدریجی عوض می‌کند؛ blue/green دو محیط کامل و سوییچ ترافیک دارد؛ canary ابتدا درصد کمی از ترافیک را به نسخهٔ جدید می‌دهد.

انتخاب به ظرفیت اضافه، state، سازگاری نسخه‌ها، rollback و توان مشاهده بستگی دارد. rolling با schema ناسازگار ممکن است هنگام هم‌زیستی دو نسخه شکست بخورد. blue/green سوییچ سریع دارد ولی هزینهٔ دو محیط و مسئلهٔ داده باقی است. canary بدون metric و معیار توقف فقط rollout کند است. A/B testing معمولاً آزمایش محصول بر اساس cohort است و با canary کاهش ریسک فنی یکسان نیست.

جمع‌بندی مصاحبه‌ای#

هر abstraction چیزی را مدیریت می‌کند و چیزهایی را نه: StatefulSet هویت را می‌دهد، نه replication برنامه؛ Helm manifest را بسته‌بندی می‌کند، نه rollback داده؛ GitOps drift را reconcile می‌کند، نه صحت منطق؛ و canary بدون signal تصمیمی نمی‌گیرد. گفتن این مرزها پاسخ را قابل اعتماد می‌کند.

منابع#