امشب از اجرای یک container به مدیریت تعداد زیادی workload و سپس به مسیر تحویل تغییر می‌رسیم. هدف، حفظ‌کردن نام اجزای Kubernetes یا syntax یک ابزار CI نیست؛ باید بدانید هر کنترلر چه وضع مطلوبی را دنبال می‌کند و pipeline چگونه یک commit را به artifact قابل اعتماد تبدیل می‌کند.

پرسش‌های ۱۱ تا ۱۵: Kubernetes#

۱۱. Kubernetes چیست؟#

پاسخ کوتاه: Kubernetes سامانه‌ای متن‌باز برای ارکستراسیون workloadهای کانتینری است. کاربر وضع مطلوب—مانند تعداد replica، image و سیاست شبکه—را از طریق API اعلام می‌کند و کنترلرها پیوسته وضع واقعی را به آن نزدیک می‌کنند.

ارزش Kubernetes فقط «اجرای container» نیست؛ زمان‌بندی روی nodeها، service discovery، rollout، مدیریت تنظیم و secret، اتصال storage و بازیابی از خرابی فرایند را هماهنگ می‌کند. با این حال پایگاه داده را خودبه‌خود توزیع‌شده یا برنامه را امن نمی‌کند. پیچیدگی control plane، شبکه و بهره‌برداری هزینه دارد؛ برای یک سرویس کوچک، راه‌حل ساده‌تر ممکن است مناسب‌تر باشد.

۱۲. اجزای اصلی معماری Kubernetes کدام‌اند؟#

پاسخ کوتاه: control plane معمولاً شامل kube-apiserver، etcd، kube-scheduler و kube-controller-manager است. روی nodeها kubelet و container runtime اجرا می‌شوند؛ kube-proxy نیز در معماری رایج بخشی از پیاده‌سازی Service است، هرچند در بعضی شبکه‌ها جایگزین می‌شود.

API server درگاه کنترل و اعمال سیاست است؛ etcd دادهٔ وضعیت کلاستر را نگه می‌دارد؛ scheduler برای Pod بدون node مقصد انتخاب می‌کند؛ controller manager حلقه‌های reconciliation را اجرا می‌کند؛ و kubelet اجرای Podهای محول‌شده را با runtime هماهنگ می‌کند. در مصاحبه اصطلاح قدیمی master node را به‌عنوان نام اصلی به کار نبرید. پشتیبان‌گیری etcd و دسترس‌پذیری API برای بازیابی control plane حیاتی‌اند.

۱۳. Pod چیست؟#

پاسخ کوتاه: Pod کوچک‌ترین واحد زمان‌بندی‌شونده در Kubernetes و پوششی برای یک یا چند container هم‌مکان است. containerهای یک Pod فضای شبکه و volumeهای تعریف‌شده را به اشتراک می‌گذارند و چرخهٔ عمرشان به هم وابسته است.

هر container را بی‌دلیل در یک Pod مشترک نگذارید. چند container زمانی منطقی‌اند که یک واحد استقرار باشند؛ مثلاً برنامه و sidecar نزدیک آن. Pod هویت دائمی سرور نیست و پس از جایگزینی ممکن است IP تازه بگیرد. معمولاً Pod را مستقیم برای production نمی‌سازیم و از Deployment، StatefulSet یا Job می‌خواهیم آن را مدیریت کند. readiness آمادگی دریافت ترافیک را تعیین می‌کند؛ liveness مشخص می‌کند container چه زمانی باید دوباره راه‌اندازی شود.

۱۴. Service در Kubernetes چیست؟#

پاسخ کوتاه: Service یک نقطهٔ دسترسی پایدار برای مجموعه‌ای پویا از Podها فراهم می‌کند. selector معمولاً Podهای مقصد را انتخاب می‌کند و EndpointSlice نشانی backendهای آماده را نگه می‌دارد؛ DNS و virtual IP باعث می‌شوند مصرف‌کننده به IP گذرای Pod وابسته نباشد.

نوع ClusterIP دسترسی داخلی می‌دهد، NodePort روی nodeها درگاه باز می‌کند و LoadBalancer از یک یکپارچه‌سازی بیرونی برای ورودی استفاده می‌کند. Service به‌تنهایی HTTP routing بر اساس host و path انجام نمی‌دهد؛ این کار معمولاً به Ingress یا Gateway API مربوط است. اگر selector اشتباه یا readiness ناموفق باشد، وجود Service تضمین نمی‌کند backend سالمی در دسترس است.

۱۵. Docker Swarm و Kubernetes چه تفاوتی دارند؟#

پاسخ کوتاه: هر دو workload کانتینری را روی چند node مدیریت می‌کنند، اما Kubernetes API و اکوسیستم گسترده‌تر، مدل منبع غنی‌تر و قابلیت توسعه با controller و CRD دارد. Swarm در Docker یکپارچه‌تر و شروع آن ساده‌تر است، ولی دامنه و اکوسیستم کوچک‌تری دارد.

پاسخ نباید به «Kubernetes بهتر است» ختم شود. معیارها شامل اندازه و مهارت تیم، نیاز شبکه و storage، چندمستاجری، سیاست، اکوسیستم و هزینهٔ عملیات‌اند. مهاجرت نیز رایگان نیست؛ مدل secret، rollout و شبکه تفاوت دارد. برای محیطی کوچک که سادگی اولویت است Swarm ممکن است کفایت کند، اما سازمانی که به کنترلرهای سفارشی و یک اکوسیستم استاندارد cloud-native نیاز دارد معمولاً Kubernetes را بررسی می‌کند.

پرسش‌های ۱۶ تا ۲۰: CI/CD#

۱۶. CI/CD pipeline چیست؟#

پاسخ کوتاه: pipeline زنجیره‌ای نسخه‌پذیر و قابل مشاهده از کنترل‌هایی است که تغییر کد را می‌سازند، می‌آزمایند، به artifact تبدیل می‌کنند و آن را میان محیط‌ها ارتقا می‌دهند. مرحله‌ها می‌توانند lint، آزمون، اسکن امنیت، بسته‌بندی، انتشار و بررسی پس از استقرار باشند.

ترتیب و gateها باید بازخورد سریع و ریسک را متعادل کنند: کنترل ارزان زود اجرا شود و آزمون سنگین پس از آن. secret نباید در لاگ چاپ شود و runner غیرقابل اعتماد نباید دسترسی production داشته باشد. artifact را یک بار بسازید و همان را ارتقا دهید؛ ساخت دوباره در هر محیط، چیزی متفاوت از نسخهٔ آزموده‌شده ایجاد می‌کند. نتیجهٔ pipeline باید قابل ردگیری تا commit و قابل بازتولید باشد.

۱۷. Jenkins چیست؟#

پاسخ کوتاه: Jenkins یک automation server متن‌باز و قابل توسعه است که معمولاً برای ساخت و اجرای pipelineهای CI/CD به کار می‌رود. controller پیکربندی و زمان‌بندی را مدیریت می‌کند و agentها کار را در executorهای خود اجرا می‌کنند.

اصطلاح‌های قدیمی master و slave در مستندات جدید Jenkins با controller و agent جایگزین شده‌اند. اجرای build روی built-in node توصیه نمی‌شود، چون jobهای آن به فایل‌سیستم و سطح دسترسی controller نزدیک‌اند؛ agent جدا دامنهٔ اثر خطا یا کد نامطمئن را محدودتر می‌کند. انعطاف افزونه‌ها مزیت و هم‌زمان مسئولیت نگه‌داری است: نسخه، آسیب‌پذیری، سازگاری و پشتیبان‌گیری تنظیمات باید مدیریت شود. Jenkins یک راه ممکن برای CI/CD است، نه خود مفهوم CI/CD.

۱۸. Jenkins Pipeline چیست؟#

پاسخ کوتاه: Pipeline مدل اجرای فرایند تحویل در Jenkins است و معمولاً در Jenkinsfile کنار کد نگه‌داری می‌شود. نسخهٔ Declarative ساختار محدودتر و خواناتری دارد؛ Scripted آزادی برنامه‌نویسی بیشتری می‌دهد، ولی می‌تواند پیچیده‌تر شود.

stage یک بخش منطقی مانند Build یا Test و step یک عمل اجرایی است. agent محل اجرا را تعیین می‌کند. نگه‌داری pipeline در Git امکان بازبینی و تاریخچه می‌دهد، اما کد pipeline نیز باید مانند نرم‌افزار آزموده و حداقل‌دسترسی داشته باشد. کتابخانهٔ مشترک تکرار را کم می‌کند، ولی پنهان‌کردن منطق زیاد در آن می‌تواند فهم هر پروژه را دشوار کند.

۱۹. GitLab CI چیست؟#

پاسخ کوتاه: GitLab CI/CD قابلیت pipeline یکپارچه با مخزن GitLab است. فایل .gitlab-ci.yml job، stage، rule، artifact و نیازها را تعریف می‌کند و GitLab Runner کارها را در executorهایی مانند shell، container یا Kubernetes اجرا می‌کند.

کنترل اصلی، جداسازی coordinator از runner و محدودکردن اعتماد runner است. runner مشترک برای کد نامطمئن نباید credential حساس یا شبکهٔ production را ببیند. cache برای سرعت است و artifact خروجی قابل انتقال؛ این دو را یکی نگیرید. rules تعیین می‌کند job در چه رویدادی اجرا شود و protected branch یا environment می‌تواند دامنهٔ انتشار را محدود کند. وجود فایل YAML به‌تنهایی pipeline امن نمی‌سازد.

۲۰. Continuous Delivery و Continuous Deployment چه تفاوتی دارند؟#

پاسخ کوتاه: هر دو به CI و خودکارسازی قوی تکیه دارند. در Delivery هر تغییر موفق آمادهٔ انتشار است، ولی رفتن به production می‌تواند تصمیم دستی داشته باشد؛ در Deployment همان تغییر پس از گذر از کنترل‌ها خودکار به production می‌رود.

این تفاوت را با «استقرار در staging» اشتباه نگیرید. تیم Delivery نیز می‌تواند ده‌ها استقرار خودکار پیش از production داشته باشد. همچنین دکمهٔ دستی اگر اجرای مجموعه‌ای از عملیات شکننده باشد، Continuous Delivery واقعی نیست. پاسخ خوب علت انتخاب را می‌گوید: ریسک محصول، الزام تفکیک وظایف، اندازهٔ blast radius و کیفیت کنترل‌ها تعیین می‌کنند کدام مدل مناسب‌تر است.

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

در هر دو بخش، مدل «وضع مطلوب و کنترل بازخورد» را ببینید. Kubernetes پیوسته منابع واقعی را با spec مقایسه می‌کند؛ pipeline نیز تغییر را از کنترل‌های تعریف‌شده عبور می‌دهد. هیچ‌کدام صحت کسب‌وکار را حدس نمی‌زنند: spec، آزمون، دسترسی و شاخص سلامت باید درست طراحی شوند.

منابع#