آموزش ۵۰۰+ سوال و جواب مصاحبه کوبرنتیز (Kubernetes) ۲۰۲۶ - آخرین آپدیت

پوشش تفصیلی حوزه‌های آزمون

این مخزن آزمون‌های تمرینی به طور سیستماتیک سازماندهی شده تا دقیقا بازتاب‌دهنده توزیع فنی و سناریوهای معماری پیچیده در مصاحبه‌های مهندسی مدرن Cloud-Native باشد.

• ارکستراسیون کانتینر (۲۰٪): معماری Kubernetes (Control plane و Data plane)، وضعیت‌های چرخه حیات Pod، مکانیسم‌های ReplicaSet، استراتژی‌های پیشرفته Deployment و مقیاس‌بندی خودکار (HPA/VPA).

• سرویس مش (۱۵٪): پیاده‌سازی Service Mesh از طریق Istio و Linkerd، مدیریت پیشرفته ترافیک، استقرار‌های Canary خودکار و اعمال مدل Zero-trust با Mutual TLS (mTLS).

• امنیت (۱۵٪): کنترل دسترسی دقیق مبتنی بر نقش (RBAC)، اسکن امنیتی تصاویر کانتینر، مدیریت امن Secrets، امنیت زمان اجرا و سیاست‌های شبکه سخت‌گیرانه.

• شبکه‌سازی (۱۰٪): پلاگین‌های Container Network Interface (CNI)، لایه‌های Container Runtime Interface (CRI)، حالت‌های مسیریابی kube-proxy (IPVS/iptables)، کشف سرویس (Service Discovery) و ادغام با Load Balancing ابری.

• عیب‌یابی (۱۵٪): تحلیل ریشه (Root-cause) برای Split-brain یا خرابی کلاستر etcd، تشخیص وضعیت‌های Pod OOMKilled، رفع تأخیر در تکثیر (Replication lag)، دیباگ اتصال شبکه در سطح کلاستر و حل مشکلات عملکردی نودها.

• ذخیره‌سازی و مدیریت داده (۱۰٪): تامین پویا با Persistent Volumes (PV/PVC)، مدیریت ورک‌لودهای Stateful با استفاده از StatefulSets، تضمین سازگاری داده‌ها، مدیریت CSI Volume Snapshots و ایجاد فرآیندهای قابل اعتماد پشتیبان‌گیری و بازیابی.

• مانیتورینگ و لاگینگ (۵٪): استخراج متریک‌ها با Prometheus، تجسم عملکرد از طریق داشبوردهای Grafana، راهکارهای متمرکز لاگینگ در سطح کلاستر، جمع‌آوری متریک‌های با کاردینالیتی بالا و بهینه‌سازی هشدارها و اعلان‌ها.

• CI/CD و اتوماسیون (۱۰٪): خط لوله‌های GitOps از طریق GitHub Actions و Jenkins، تحویل GitOps، تامین deklarative کلاستر با Terraform، مدیریت پیکربندی با Ansible و نوشتن اسکریپت‌های اتوماسیون مقاوم.

درباره دوره

موفقیت در مصاحبه‌های زیرساخت DevOps یا Kubernetes در سطح سازمانی، نیازمند چیزی فراتر از حفظ کردن دستورات پایه kubectl است. کلاسترهای عملیاتی چالش‌های پیچیده و چندلایه ای دارند که در آن شبکه، امنیت، ذخیره‌سازی و ارکستراسیون با هم تلاقی می‌کنند. مدیران استخدام به دنبال افرادی نیستند که صرفاً بتوانند یک کلاستر را بالا بیاورند؛ آن‌ها مهندسانی را می‌خواهند که بتوانند برای در دسترس بودن بالا (High Availability) معماری کنند، محیط‌های چندمستاجری را ایمن سازند، شکست‌های شبکه گذرا را ردیابی کنند و اجزای معیوب Control Plane را تحت فشار دیباگ نمایند. من این بانک سوالات جامع را ایجاد کردم تا دقیقاً همان سطح از سخت‌گیری مورد نیاز برای عبور از این مراحل فنی حساس را فراهم کنم.

این دوره با دارای بودن ۵۵۰ سوال تمرینی بسیار دقیق و اورجینال، بر سناریوهای عمیق فنی، تنگناهای معماری و موارد عیب‌یابی واقعی تمرکز دارد. هر سوال با یک تحلیل مهندسی جامع همراه است که مکانیسم‌های اصلی مشکل را بررسی کرده و دقیقاً توضیح می‌دهد که چرا رویکرد صحیح به درستی عمل می‌کند و چرا پیکربندی‌های معماری جایگزین یا مراحل عیب‌یابی اشتباه در یک کلاستر تولیدی شکست می‌خورند. چه در حال ارتقاء به نقش Cloud Engineer باشید، چه بخواهید دانش میدانی خود را قبل از یک جلسه فنی ارشد اعتبارسنجی کنید، یا به دنبال یک معیار قوی برای عبور از ارزیابی‌های فنی Cloud-Native باشید، این مطالب آموزشی تضمین می‌کند که برای عبور از مصاحبه‌های آتی خود در اولین تلاش آماده باشید.

نمونه سوالات تمرینی

این سه نمونه سوال سطح تولید را بررسی کنید تا با ساختار عمیق و عمق فنی موجود در کل این بانک سوالات آشنا شوید.

سوال ۱: تحلیل ریشه کدهای خاتمه Podهای گذرا

یک میکروسرویس حیاتی در پس‌زمینه که در یک Namespace با محدودیت حافظه اجرا می‌شود، در ساعات پیک ترافیک به طور متناوب شکست می‌خورد. دستور kubectl describe pod نشان می‌دهد که کانتینر با Exit Code 137 خاتمه یافته است. کدام مکانیسم زیر باعث تحریک این رویداد خاص در کلاستر شده است؟

• الف) باینری اپلیکیشن یک استثنای زمان اجرای مدیریت نشده ایجاد کرد که باعث شد پروسه اصلی کانتینر به طور طبیعی بسته شود.

• ب) کرنل سیستم عامل در Worker Node، ابزار OOM killer را فراخواند زیرا کانتینر از حد حافظه تعریف شده در پیکربندی خود فراتر رفت.

• ج) Liveness probe مربوط به kubelet به طور مداوم شکست خورد و باعث شد Control Plane سیگنال استاندارد SIGTERM را ارسال کند که پاسخ داده نشد.

• د) پلاگین CNI ورودی جدول مسیریابی خود را برای Pod از دست داد و منجر به Timeout خودکار در اخراج شبکه شد.

• ه) رابط Runtime کانتینر هنگام نوشتن لاگ‌های کانتینر روی دیسک میزبان، با خطای درایور لایه ذخیره‌سازی مواجه شد.

• و) Admission Controller مجوزهای اجرای Pod را به دلیل به‌روزرسانی سیاست امنیتی RBAC متداخل، به طور پویا لغو کرد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: Exit Code 137 به طور خاص نشان می‌دهد که یک پروسه توسط سیستم عامل با استفاده از سیگنال استاندارد SIGKILL خاتمه یافته است (۹ + ۱۲۸ = ۱۳۷). در محیط کوبرنتیز، وقتی مصرف حافظه لحظه‌ای کانتینر از آستانه تعیین شده در بلوک resources.limits.memory فراتر رود، OOM killer کرنل نود وارد عمل شده و برای محافظت از پایداری میزبان، پروسه را به اجبار متوقف می‌کند و وضعیت Pod را به OOMKilled تغییر می‌دهد.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: استثناهای مدیریت نشده اپلیکیشن معمولاً منجر به کدهای خروجی استاندارد مانند ۱ یا ۲ می‌شوند و منجر به CrashLoopBackOff بدون فراخوانی صریح OOM killer می‌گردند.

  • گزینه ج نادرست است: اگر liveness probe شکست بخورد، kubelet ابتدا کانتینر را با SIGTERM (کد خروجی ۱۴۳) می‌کشد و تنها در صورت انقضای زمان خاموشی graceful، به SIGKILL روی می‌آورد.

  • گزینه د نادرست است: ناهنجاری‌های مسیریابی CNI منجر به تایم‌اوت‌های شبکه، قطع اتصال یا وضعیت‌های CreateContainerConfigError می‌شود، نه کد خاتمه فوری ۱۳۷.

  • گزینه ه نادرست است: خطاهای درایور ذخیره‌سازی یا لاگینگ معمولاً وضعیت FailedCreatePodSandBox یا Taintهای فشار دیسک (disk pressure) روی نود ایجاد می‌کنند.

  • گزینه و نادرست است: رد درخواست توسط Admission Controller، پاد را در مرحله اعتبارسنجی API قبل از زمان‌بندی (Scheduling) مسدود می‌کند و به جای متوقف کردن یک پروسه در حال اجرا، خطای Forbidden می‌دهد.

سوال ۲: طراحی مرزهای امن چندمستاجری با استفاده از سیاست‌های پیشرفته شبکه

یک مدیر می‌خواهد یک کلاستر چندمستاجری حاوی دو Namespace حساس tenant-alpha و tenant-beta را ایمن کند. هدف این است که یک NetworkPolicy در tenant-alpha پیکربندی شود که ترافیک ورودی را فقط از پادهایی با لیبل role: frontend که در Namespace مربوط به tenant-beta هستند، اجازه دهد. کدام الگوی طراحی ساختاری باید در مشخصات (spec) سیاست پیاده‌سازی شود؟

• الف) تعریف یک قانون ingress شامل یک آیتم واحد که هر دو بلوک podSelector و namespaceSelector را به عنوان فیلدهای مجزا در یک عنصر آرایه واحد شامل شود.

• ب) تعریف یک قانون ingress شامل یک بلوک namespaceSelector واحد و استفاده از بلوک تو در تو matchExpressions که مستقیماً به لیبل‌های پاد خارجی ارجاع می‌دهد.

• ج) تعریف یک قانون ingress با دو آیتم لیست مجزا: یک آیتم شامل بلوک namespaceSelector و یک آیتم مجزا شامل بلوک podSelector.

• د) تعریف یک قانون egress در Namespace هدف که مستقیماً از طریق یک بلوک CIDR اختصاصی به نقاط انتهایی API server خارجی ارجاع می‌دهد.

• ه) تعریف یک ClusterNetworkPolicy سراسری که پیش‌فرض‌های ایزولاسیون Namespace را با استفاده از یک بایندینگ سرویس اکانت Wild-card بازنویسی کند.

• و) تعریف یک قانون ingress که سلکتورها را به طور کامل حذف کرده و منحصراً به هدرهای شناسایی mutual TLS در runtime کانتینر تکیه می‌کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: الف

• دلیل صحت: هنگام پیکربندی NetworkPolicies در کوبرنتیز، ترکیب namespaceSelector و podSelector در یک عنصر آرایه، یک تقاطع (منطق AND) ایجاد می‌کند. این کار باعث می‌شود موتور سیاست‌ها فقط پادهایی را مطابقت دهد که هم لیبل مشخص شده را داشته باشند و هم متعلق به Namespaceهایی باشند که با لیبل Namespace مطابقت دارند، و در نتیجه یک مرز امن چندمستاجری ایجاد شود.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه ب نادرست است: یک namespaceSelector لیبل‌های اعمال شده روی خود اشیای Namespace را می‌خواند؛ نمی‌تواند برای خواندن لیبل‌های تکی پادها در یک بلوک واحد به داخل Namespace نفوذ کند.

  • گزینه ج نادرست است: قرار دادن سلکتورها در عناصر آرایه مجزا، یک اجتماع (منطق OR) ایجاد می‌کند. این پیکربندی خطرناک اجازه می‌دهد ترافیک از هر پادی در Namespace مشخص شده، یا هر پادی با آن لیبل در هر Namespace در کل کلاستر عبور کند.

  • گزینه د نادرست است: هدف کنترل ترافیک ورودی با استفاده از قانون ingress است، بنابراین تعریف قانون egress با بلوک‌های CIDR استاتیک کاملاً بی‌ربط است.

  • گزینه ه نادرست است: منابع استاندارد API کوبرنتیز به طور بومی از شیء "ClusterNetworkPolicy" بدون استفاده از ارائه‌دهندگان CNI شخص ثالث مانند Calico یا Cilium پشتیبانی نمی‌کنند.

  • گزینه و نادرست است: حذف کامل سلکتورها از یک قانون ingress، بسته به ساختار، رفتاری از نوع default-deny یا default-allow ایجاد می‌کند و الزامات لیبل خاص را کاملاً نادیده می‌گیرد.

سوال ۳: منطق مسیریابی مدیریت ترافیک در سرویس مش Istio

یک تیم مهندسی نسخه جدیدی از یک میکروسرویس (v2) را در یک سرویس مش مدیریت شده توسط Istio مستقر می‌کند. آن‌ها می‌خواهند یک استراتژی انتشار Canary را پیاده‌سازی کنند که در آن ۹۰٪ از ترافیک تولیدی به نسخه پایدار v1 و ۱۰٪ به نسخه جدید v2 هدایت شود. کدام ترکیب از تعریف‌های منبع سفارشی (CRDs) Istio باید برای اجرای دقیق این تقسیم ترافیک ایجاد شود؟

• الف) یک منبع Gateway واحد که تعاریف پورت فیزیکی را مستقیماً به آدرس‌های IP مجزای کلاستر هدف نگاشت می‌کند.

• ب) یک منبع ServiceEntry که نقاط انتهایی را ثبت می‌کند، به همراه یک سیاست PeerAuthentication برای رمزگذاری لایه انتقال.

• ج) یک منبع VirtualService که مقادیر وزن درصد را تعیین می‌کند، در کنار یک منبع DestinationRule که به طور صریح زیرمجموعه‌های (subsets) v1 و v2 را تعریف می‌کند.

• د) یک منبع EnvoyFilter که کلاسترهای upstream خام را تغییر می‌دهد، به همراه یک شیء Service استاندارد کوبرنتیز.

• ه) یک منبع Telemetry که تعداد اتصالات را ردیابی می‌کند و یک پیکربندی Sidecar که جداول مسیریابی egress را به طور سراسری بازنویسی می‌کند.

• و) یک منبع WorkloadGroup که قالب‌های پاد را به یک نمونه ماشین مجازی خارجی در خارج از کلاستر نگاشت می‌کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل صحت: در معماری سرویس مش Istio، تقسیم ترافیک به دو منبع سفارشی همکار متکی است. DestinationRule مقصدهای واقعی یا زیرمجموعه‌های ورک‌لودها را بر اساس لیبل‌های پاد (مثلاً تگ‌های نسخه) تعریف می‌کند. سپس VirtualService لایه ترافیک را رهگیری کرده و با استفاده از فیلد weight در بلوک مسیریابی خود، ترافیک را به صورت متناسب (۹۰/۱۰) بین آن زیرمجموعه‌های تعریف شده تقسیم می‌کند.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: یک Istio Gateway لودبالانسرهای لبه را برای پذیرش اتصالات HTTP/TCP ورودی پیکربندی می‌کند؛ این منبع وزن‌های مسیریابی دقیق را در داخل مش داخلی مدیریت نمی‌کند.

  • گزینه ب نادرست است: ServiceEntry برای افزودن وابستگی‌های خارجی غیر-مش (مانند یک دیتابیس ابری خارجی) به رجیستری سرویس داخلی استفاده می‌شود، نه برای مسیریابی ترافیک سرویس‌های داخلی.

  • گزینه د نادرست است: اگرچه EnvoyFilter اجازه تنظیمات سطح پایین پیکربندی‌های پروکسی Envoy را می‌دهد، اما استفاده از آن برای تقسیم‌های ساده Canary پیچیدگی زیادی ایجاد کرده و ابزارهای استاندارد مدیریت ترافیک را دور می‌زند.

  • گزینه ه نادرست است: منابع Telemetry و Sidecar رفتار لاگینگ و محدوده شبکه پروکسی را کنترل می‌کنند؛ آن‌ها توزیع درصدی ترافیک اپلیکیشن را تغییر نمی‌دهند.

  • گزینه و نادرست است: یک WorkloadGroup ورک‌لودهای VM غیر-کوبرنتیزی را توصیف می‌کند که وارد مش شده‌اند، که هیچ ارتباطی به جابجایی ترافیک بین استقرار پادهای داخلی ندارد.

آنچه انتظار داشته باشید

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را برای موفقیت در آزمون تمرینی سوالات مصاحبه کوبرنتیز آماده کنیم.

• می‌توانید هر چند بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات جامع و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح مفصل است.

• سازگار با موبایل از طریق اپلیکیشن Udemy.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.