https://virgool.ir/feed/@mimsheبرنامه نویس٬ کنجکاو حوزه ی آی تیfa2026-11-11 01:50:52https://files.virgool.ir/upload/users/626500/avatar/ny2UWv.pnghttps://virgool.ir/@mimshehttps://virgool.ir/@mimshe/star-cnu9lccgg8tdمتد STAR برای مصاحبهفرض کنید در یک مصاحبه از شما می‌پرسند:از یک موقعیت سخت در محل کار قبلی‌ات بگو که توانستی آن را مدیریت کنی.احتمالاً اولین چیزی که به ذهنمان می‌رسد این است که شروع کنیم به تعریف کردن یک داستان.اما خیلی زود ممکن است داستانمان از مسیر اصلی خارج شود؛ از اینکه پروژه چطور شروع شد، چه کسانی درگیر بودند، چه اتفاق‌هایی افتاد و در نهایت اصلاً معلوم نباشد نقش خودمان چه بوده است.اینجاست که روش STAR به کمکمان می‌آید.STAR یک چارچوب ساده برای پاسخ دادن به سؤال‌های تجربی در مصاحبه است که کمک می‌کند پاسخمان منظم، کوتاه و قابل فهم باشد.STAR از چهار بخش تشکیل شده:Situation: چه اتفاقی افتاده بود؟اول باید کمی درباره شرایط توضیح بدهیم. مصاحبه‌کننده باید بداند داستان از کجا شروع شده است.مثلاً:در شرکت قبلی، روی پروژه‌ای کار می‌کردیم که قرار بود در مدت کوتاهی آماده شود، اما در میانه کار متوجه شدیم زمان‌بندی پروژه به مشکل خورده است.همین مقدار برای شروع کافی است. لازم نیست تمام تاریخچه پروژه را تعریف کنیم.هدف این بخش فقط پاسخ دادن به یک سؤال است:شرایطی که در آن قرار داشتی چه بود؟Task: وظیفه تو چه بود؟حالا باید مشخص کنیم از ما چه انتظاری وجود داشت.مثلاً:من مسئول هماهنگی تیم و برنامه‌ریزی کارها بودم و باید کمک می‌کردم پروژه در زمان تعیین‌شده آماده شود.این قسمت اهمیت زیادی دارد، چون نشان می‌دهد نقش خودمان در داستان چه بوده است.مثلاً این دو پاسخ را مقایسه کنید:تیم باید پروژه را به موقع تحویل می‌داد.با:من مسئول برنامه‌ریزی و هماهنگی تیم بودم و باید راهی برای جبران تأخیر پیدا می‌کردم.در پاسخ دوم، نقش فرد کاملاً مشخص است.Action: چه کاری انجام دادی؟این قسمت مهم‌ترین بخش پاسخ است. حالا باید توضیح بدهیم خودمان چه کاری انجام دادیم.مثلاً:ابتدا با اعضای تیم صحبت کردم تا مشخص شود دلیل اصلی تأخیر چیست. بعد کارها را دوباره اولویت‌بندی کردیم و بخش‌هایی را که اهمیت کمتری داشتند به مرحله بعد منتقل کردیم. همچنین برای چند روز جلسات کوتاه روزانه گذاشتیم تا مشکلات سریع‌تر مشخص شوند.دقت کنید که اینجا نباید فقط بگوییم:مشکل را حل کردم.باید توضیح بدهیم چطور این کار را انجام دادیم.این بخش به مصاحبه‌کننده کمک می‌کند بفهمد:چطور فکر می‌کنیم؟چطور تصمیم می‌گیریم؟چطور با دیگران همکاری می‌کنیم؟در شرایط سخت چه واکنشی داریم؟چقدر مسئولیت‌پذیر هستیم؟Result: نتیجه چه شد؟در پایان باید بگوییم چه اتفاقی افتاد.مثلاً:در نهایت توانستیم پروژه را با چند روز تأخیر کمتر از چیزی که پیش‌بینی می‌کردیم تحویل دهیم و تجربه خوبی برای برنامه‌ریزی پروژه‌های بعدی به دست آوردیم.اگر نتیجه قابل اندازه‌گیری باشد، حتی بهتر است:با تغییر برنامه توانستیم زمان تحویل را از سه هفته تأخیر به حدود یک هفته کاهش دهیم.البته همیشه نتیجه را نمی‌توان با عدد بیان کرد. گاهی نتیجه می‌تواند یک تجربه، یادگیری یا تغییر مثبت در تیم باشد.مثلاً:بعد از این اتفاق، روش برنامه‌ریزی پروژه‌های بعدی را تغییر دادیم تا مشکلات مشابه زودتر شناسایی شوند.چرا STAR کاربردی است؟یکی از مشکلات رایج در مصاحبه این است که افراد درباره خودشان صحبت می‌کنند، اما مثال مشخصی ارائه نمی‌دهند.مثلاً:من مسئولیت‌پذیر هستم.من در کار تیمی خیلی خوبم.من توانایی حل مسئله خوبی دارم.این جملات لزوماً بد نیستند، اما مصاحبه‌کننده نمی‌تواند فقط بر اساس آن‌ها قضاوت کند.STAR کمک می‌کند به جای گفتن:من مسئولیت‌پذیر هستم.بگوییم:در یک پروژه، زمانی که مسئول اصلی پروژه برای مدتی در دسترس نبود، من هماهنگی کارها را بر عهده گرفتم...حالا فرد مقابل می‌تواند از روی رفتار واقعی ما برداشت کند.چه سؤال‌هایی را می‌توان با STAR جواب داد؟سؤال‌های بسیار زیادی را می‌توان با این روش پاسخ داد.درباره موفقیتاز یک موفقیت مهم در کارتان بگویید.درباره شکستاز یک اشتباه یا شکست کاری بگویید.درباره کار تیمیمثالی از یک کار تیمی موفق بزنید.درباره اختلافتا حالا با همکارتان اختلاف نظر داشته‌اید؟درباره مدیریت فشارزمانی که فشار کاری زیادی داشتید چه کردید؟درباره حل مسئلهاز یک مشکل سختی که حل کردید بگویید.درباره مسئولیت‌پذیریمثالی از زمانی بزنید که مسئولیت بیشتری از وظیفه معمولتان پذیرفتید.یک اشتباه رایج: خیلی طولانی صحبت کردنیکی از رایج‌ترین مشکلات در استفاده از STAR این است که فرد از بخش Situation شروع می‌کند و دیگر تمام نمی‌کند! مثلاً پنج دقیقه درباره پروژه توضیح می‌دهد، در حالی که هنوز به Action نرسیده است.بهتر است Situation کوتاه باشد. از خودتان بپرسید:مصاحبه‌کننده برای فهمیدن ادامه داستان واقعاً چه اطلاعاتی لازم دارد؟همان را بگویید. قرار نیست تمام داستان زندگی پروژه را تعریف کنیم.اشتباه دوم: فراموش کردن نقش خودمانگاهی فرد بیشتر درباره کاری که تیم انجام داده صحبت می‌کند.مثلاً:ما پروژه را طراحی کردیم، ما مشکل را حل کردیم و ما محصول را تحویل دادیم.مصاحبه‌کننده ممکن است در پایان هنوز نداند٬ خود این فرد دقیقاً چه کاری انجام داده؟ بهتر است سهم خودمان را مشخص کنیم.مثلاً:من مسئول طراحی بخش X بودم و برای حل مشکل Y این کارها را انجام دادم.این به معنی نادیده گرفتن کار تیم نیست؛ فقط باید نقش خودمان را شفاف کنیم.اشتباه سوم: نتیجه را فراموش کردنگاهی پاسخ این‌طور تمام می‌شود:... و بعد این کارها را انجام دادیم.تمام!اما چه شد؟آیا موفق شدید؟آیا مشکلتان حل شد؟چه چیزی یاد گرفتید؟چه تغییری ایجاد شد؟حتماً پاسخ را با یک Result تمام کنید.حتی اگر نتیجه خیلی بزرگ نبوده باشد.مثلاً:در نهایت مشکل حل شد و از آن تجربه برای پروژه‌های بعدی استفاده کردیم.آیا باید همیشه دقیقاً چهار بخش STAR را بگوییم؟نه. قرار نیست وسط مصاحبه بگوییم:حالا می‌روم سراغ بخش Action!STAR یک چارچوب ذهنی است، نه فرمی که باید با صدای بلند پر شود. داستان باید طبیعی باشد.مثلاً:در پروژه X با این مشکل مواجه شدیم. من مسئول بخش Y بودم، بنابراین ابتدا... بعد از بررسی موضوع تصمیم گرفتم... در نهایت توانستیم...در واقع شما دارید STAR را اجرا می‌کنید، بدون اینکه اسم بخش‌ها را بگویید.STAR را حفظ نکنید؛ تجربه‌هایتان را آماده کنیدبهتر است به جای اینکه برای ۳۰ سؤال مختلف جواب حفظ کنیم، چند تجربه واقعی از زندگی کاری یا تحصیلی‌مان آماده داشته باشیم.مثلاً:یک موفقیت مهمیک شکست یا اشتباهیک مشکل سختیک اختلاف نظریک تجربه کار تیمییک تجربه مدیریت فشاریک تجربه یادگیرییک موقعیت که مسئولیت بیشتری پذیرفتیمبعد برای هرکدام این چهار سؤال را جواب دهیم:Situation: چه اتفاقی افتاد؟Task: مسئولیت من چه بود؟Action: چه کاری انجام دادم؟Result: چه نتیجه‌ای گرفتیم؟با آماده داشتن این تجربه‌ها، بسیاری از سؤال‌های غیرمنتظره مصاحبه دیگر چندان غیرمنتظره نخواهند بود.یک نکته مهم: داستان واقعی بهتر از داستان ایده‌آل استلازم نیست تمام داستان‌هایتان پایان فوق‌العاده‌ای داشته باشند. اتفاقاً یک تجربه واقعی که در آن اشتباه کرده‌اید، اما از آن چیزی یاد گرفته‌اید، می‌تواند پاسخ خوبی باشد.مثلاً:در ابتدا تصور می‌کردم این روش سریع‌ترین راه است، اما بعد متوجه شدم تصمیمم مشکل داشته است. اشتباه را اصلاح کردم و از آن تجربه یاد گرفتم که قبل از تصمیم‌گیری، نظر افراد بیشتری را بررسی کنم.این نوع پاسخ نشان می‌دهد که فرد می‌تواند: اشتباه کند٬ مسئله را بپذیرد٬ اصلاح کند و در نهایت یاد بگیرد و این در بسیاری از محیط‌های کاری ارزشمند است.فرمول ساده STARاگر بخواهیم تمام این مقاله را در یک فرمول خلاصه کنیم:موقعیت - وظیفه - اقدام - نتیجهیا حتی ساده‌تر:چه اتفاقی افتاد؟ - وظیفه من چه بود؟ - چه کار کردم؟ - چه شد؟قبل از مصاحبه فقط چند تجربه واقعی خودتان را با همین چهار سؤال مرور کنید. لازم نیست جواب‌ها را کلمه‌به‌کلمه حفظ کنید٬ فقط داستان را بدانید. چون هدف STAR این نیست که پاسخ‌های از پیش آماده و مصنوعی ارائه کنیم؛ هدفش این است که تجربه واقعی خودمان را واضح، منظم و قابل فهم بیان کنیم.در نهایت، یک پاسخ خوب در مصاحبه لزوماً طولانی یا پیچیده نیست.گاهی یک داستان دو دقیقه‌ای که به‌خوبی توضیح دهد چه اتفاقی افتاد، شما چه کردید و چه نتیجه‌ای گرفتید، از ده دقیقه صحبت پراکنده بسیار تأثیرگذارتر است.محسن شهبازیمحسن شهبازیFri, 02 Oct 2026 13:20:55 +0330https://virgool.ir/@mimshe/tech-debt-zvddsm1bcp62تقریباً همه استارتاپ‌ها یک مسیر مشابه را طی می‌کنند و در ابتدای راه فقط یک سؤال مهم وجود دارد:«آیا اصلاً کسی حاضر است از محصول ما استفاده کند یا بابتش پول بدهد؟»وقتی سؤال اصلی این باشد، طبیعی است که سرعت از هر چیز دیگری مهم‌تر شود. تیم‌ها سعی می‌کنند هرچه سریع‌تر محصول را به دست کاربر برسانند، بازخورد بگیرند و ببینند آیا در مسیر درستی هستند یا نه.به همین خاطر معمولاً تصمیم‌هایی گرفته می‌شود مثل:تست‌ها را بعداً می‌نویسیم.فعلاً معماری خیلی ایده‌آل لازم نیست.این بخش را بعداً Refactor می‌کنیم.Deployment دستی هم فعلاً جواب می‌دهد.مانیتورینگ را بعداً اضافه می‌کنیم.اگر این تصمیم‌ها آگاهانه گرفته شوند، لزوماً اشتباه نیستند. اتفاقاً شاید تنها راهی باشند که یک استارتاپ بتواند قبل از تمام شدن سرمایه، به Product-Market Fit برسد.مشکل از جایی شروع می‌شود که همان تصمیم‌های موقتی، سال‌ها در سیستم باقی بمانند و کسی هم سراغشان نرود.گلوگاه‌های مقیاس‌پذیریبدهی فنی همیشه چیز بدی نیستوقتی صحبت از Tech Debt می‌شود، معمولاً اولین چیزی که به ذهن می‌رسد «کد بد» است.اما بدهی فنی همیشه چیز بدی نیست.فرض کنید با چند هفته میانبر زدن می‌توانید محصول را یک ماه زودتر منتشر کنید و همین باعث شود اولین مشتری یا اولین سرمایه‌گذار را جذب کنید. در چنین شرایطی، احتمالاً این معامله ارزشش را دارد.در واقع شما آگاهانه کیفیت را با سرعت معامله کرده‌اید تا شانس موفقیت کسب‌وکار بیشتر شود.پس خود بدهی فنی مشکل نیست؛ مشکل زمانی است که هیچ برنامه‌ای برای بازپرداخت آن نداشته باشیم.هر مشکل فنی، بدهی فنی نیستیکی از نکات مهم مقاله همین است. خیلی وقت‌ها هر مشکلی که در تیم پیش می‌آید را به حساب بدهی فنی می‌گذاریم.سرعت توسعه کم شده؟ Tech Debt.فیچرها دیر آماده می‌شوند؟ Tech Debt.اما همیشه اینطور نیست و ممکن است مشکل اصلی چیز دیگری باشد؛ مثلاً:زیرساخت هنوز برای این حجم از کاربران طراحی نشده باشد.Deployment کاملاً دستی باشد.مانیتورینگ مناسبی نداشته باشیم.هنوز CI/CD راه‌اندازی نشده باشد.یا محصول آن‌قدر بزرگ شده باشد که به قابلیت‌های جدیدی نیاز داشته باشد.قبل از اینکه تصمیم بگیریم سیستم را بازنویسی کنیم، باید مطمئن شویم واقعاً با بدهی فنی طرف هستیم، نه صرفاً نیازهای جدید یک محصول در حال رشد.انواع رایج بدهی فنیمن بدهی فنی را فقط محدود به کیفیت کد نمی‌دانم و چند دسته مختلف برای آن معرفی می‌کنم.بدهی کد (Code Debt)کدی که تغییر دادنش سخت شده، خوانایی پایینی دارد یا تست مناسبی برای آن وجود ندارد.بدهی معماری (Architecture Debt)معماری‌ای که زمانی برای یک تیم کوچک مناسب بوده، حالا دیگر پاسخگوی رشد محصول نیست و هر تغییر کوچکی روی بخش‌های مختلف سیستم اثر می‌گذارد.بدهی پلتفرم (Platform Debt)کمبود ابزارهایی مثل CI/CD، مانیتورینگ، اتوماسیون یا محیط‌های توسعه استاندارد که باعث کند شدن کار تیم می‌شوند.بدهی عملیاتی (Operational Debt)کارهایی که هنوز به صورت دستی انجام می‌شوند؛ از انتشار نسخه گرفته تا مدیریت Incidentها و بازیابی سرویس‌ها.از کجا بفهمیم بدهی فنی به گلوگاه تبدیل شده است؟داشتن بدهی فنی به معنی این نیست که باید فوراً همه چیز را Refactor کنیم.سؤال مهم‌تر این است:آیا این بدهی دارد روی کسب‌وکار اثر می‌گذارد یا نه؟اگر پاسخ مثبت باشد، وقت سرمایه‌گذاری روی آن رسیده است.۱. زمان رساندن ارزش به کاربر بیشتر شده استیکی از معیارهایی باید روی آن تاکید کرد Value Lead Time است.یعنی از زمانی که تصمیم می‌گیریم یک قابلیت جدید بسازیم تا وقتی که آن قابلیت به دست کاربر می‌رسد، چقدر زمان می‌گذرد.اگر این زمان مدام بیشتر می‌شود، احتمال زیادی وجود دارد که بدهی فنی یکی از دلایل آن باشد.۲. توسعه هر فیچر سخت‌تر از قبل شده استاگر برای اضافه کردن یک تغییر کوچک مجبور باشید چندین سرویس را تغییر دهید یا همیشه نگران خراب شدن بخش‌های دیگر باشید، احتمالاً سیستم دارد هزینه بدهی فنی را از شما می‌گیرد.۳. کیفیت محصول افت کرده استباگ‌های بیشتر، قطعی‌های مکرر یا کاهش Performance فقط مشکل تیم فنی نیست؛ این‌ها مستقیماً روی تجربه کاربر و حتی درآمد کسب‌وکار اثر می‌گذارند.۴. نیروهای جدید دیر به تیم اضافه می‌شونداگر یک توسعه‌دهنده جدید چند هفته یا حتی چند ماه زمان نیاز داشته باشد تا بتواند اولین تغییر مفیدش را انجام دهد، این هم می‌تواند یکی از نشانه‌های پیچیدگی بیش از حد سیستم باشد.۵. تیم دیگر به کد اعتماد نداردوقتی جمله‌هایی مثل این زیاد شنیده می‌شود:«به این قسمت دست نزن.»«کسی نمی‌داند این کد دقیقاً چه کار می‌کند.»«اگر اینجا را تغییر دهیم احتمالاً جای دیگری خراب می‌شود.»یعنی اعتماد تیم به سیستم از بین رفته است و همین موضوع سرعت توسعه را به شدت کاهش می‌دهد.حالا باید چه کار کرد؟یکی از مهم‌ترین نکته ها این است که کاهش بدهی فنی هم باید مثل توسعه یک فیچر مدیریت شود.یعنی به جای اینکه فقط بگوییم:«می‌خواهیم کدها را تمیز کنیم.»باید بتوانیم توضیح دهیم:این تغییر چه مشکلی را حل می‌کند؟چه شاخصی را بهتر می‌کند؟چه هزینه‌ای را کاهش می‌دهد؟چه ارزشی برای کسب‌وکار ایجاد می‌کند؟به جای مشکلات فنی، درباره اثرات آن صحبت کنیدمدیر محصول یا مدیر کسب‌وکار معمولاً با اصطلاحاتی مثل Coupling یا Architecture Debt تصمیم نمی‌گیرد.اما اگر بگویید:انتشار نسخه از دو ساعت به پانزده دقیقه می‌رسد.سرعت توسعه بیشتر می‌شود.احتمال رخ دادن Incident کاهش پیدا می‌کند.آن وقت تصمیم‌گیری خیلی ساده‌تر خواهد بود.بازنویسی کامل معمولاً بهترین راه نیستوقتی بدهی فنی زیاد می‌شود، اولین پیشنهادی که مطرح می‌شود این است:«بیایید همه چیز را از اول بنویسیم.»این تصمیم، در بیشتر مواقع، هزینه زیادی دارد و ممکن است ماه‌ها طول بکشد بدون اینکه ارزشی برای کاربر ایجاد شود.در عوض پیشنهاد می‌کند سیستم به صورت تدریجی و هم‌زمان با توسعه محصول بهتر شود.همان قانونی که به Scout Rule معروف است:هر بار که روی بخشی از سیستم کار می‌کنی، سعی کن آن را کمی بهتر از قبل تحویل بدهی.روی مهم‌ترین گلوگاه تمرکز کنیدهمه بدهی‌های فنی ارزش یکسانی ندارند.لازم نیست لیست بلندبالایی از مشکلات تهیه کنید و بخواهید همه را یکجا حل کنید.بهتر است از خودتان بپرسید:امروز بزرگ‌ترین مانع رشد محصول چیست؟همان را حل کنید و بعد سراغ مورد بعدی بروید.جمع‌بندیبدهی فنی بخشی طبیعی از مسیر رشد هر استارتاپ است.حتی گاهی وجود آن نشانه این است که تیم توانسته با سرعت بالا حرکت کند و محصول را به بازار برساند. اما اگر این بدهی مدیریت نشود، کم‌کم تبدیل به گلوگاهی می‌شود که سرعت توسعه را کاهش می‌دهد، کیفیت محصول را پایین می‌آورد و رشد کسب‌وکار را محدود می‌کند.شاید مهم‌ترین پیام این مقاله همین باشد:بدهی فنی دشمن ما نیست؛ بدهی فنیِ مدیریت‌نشده است که به بزرگ‌ترین مانع رشد تبدیل می‌شود.منبعاین مقاله با الهام و بازنویسی از مقاله زیر نوشته شده است:Bottlenecks of Scaleups #1: Tech Debt نوشته Martin Fowler و Tim Cochran و Carl Nygardhttps://martinfowler.com/articles/bottlenecks-of-scaleups/01-tech-debt.htmlمحسن شهبازیمحسن شهبازیSat, 11 Jul 2026 17:20:48 +0330https://virgool.ir/risman/contour-ingress-w07xa4u5pg3mمقدمهامروزه، با افزایش استفاده از Kubernetes برای مدیریت برنامه‌ها، یکی از چالش‌های مهم، مدیریت ترافیک ورودی به کلاسترهاست. Contour به عنوان یک کنترلر Ingress متن‌باز، این کار رو برای ما آسون‌تر می‌کنه. توی این مقاله، می‌خواهیم Contour رو معرفی کنیم، ویژگی‌هاش رو بررسی کنیم، چند تا از رقباش رو نام ببریم و در نهایت یه نمونه ساده از راه‌اندازیش رو آموزش بدیم.contour ingressمعرفی Contourبرای معرفی باید بگم که Contour یه کنترلر Ingress متن‌بازه که توسط Heptio (که الان بخشی از VMware شده) توسعه داده شده. این ابزار از Envoy Proxy استفاده می‌کنه و به طور خاص برای مسیریابی Layer 7 طراحی شده. این یعنی Contour می‌تونه ترافیک HTTP و HTTPS رو به خوبی مدیریت کنه.ویژگی‌های Contourپشتیبانی از Envoy Proxy: Envoy یه پراکسی قدرتمنده که قابلیت‌های پیشرفته‌ای مثل مسیریابی هوشمند، بالانس بار و امنیت بالا داره.پشتیبانی از HTTP/2 و gRPC: این ویژگی‌ها ارتباطات سریع‌تر و کارآمدتری بین سرویس‌ها فراهم می‌کنن.قابلیت انعطاف‌پذیری بالا: Contour به راحتی با بقیه ابزارها و سرویس‌های Kubernetes سازگاره.مدیریت TLS: امکان مدیریت و ترمینیت کردن TLS رو به صورت امن و کارآمد فراهم می‌کنه.پیکربندی ساده: تنظیماتش ساده و قابل فهمه و نیاز به کدنویسی پیچیده نداره.رقبامورد اول NGINX Ingress Controller: یکی از معروف‌ترین کنترلرهای Ingress که به خاطر عملکرد بالا و پشتیبانی گسترده شناخته شده.مورد دوم Traefik: یه کنترلر Ingress که به سرعت داره محبوب می‌شه و به خاطر سادگی و ویژگی‌های مدرنش، طرفدارای زیادی پیدا کرده.مورد سوم Istio: بیشتر به عنوان یه سرویس مش شناخته می‌شه، ولی می‌تونه به عنوان یه کنترلر Ingress هم استفاده بشه.مزیت‌های رقابتی Contourیکپارچگی با Envoy: استفاده از Envoy باعث می‌شه Contour از قابلیت‌های پیشرفته و عملکرد بالا بهره‌مند بشه.سادگی و کارایی: Contour به خاطر پیکربندی ساده و کارآمدش، زمان راه‌اندازی و مدیریت رو کاهش می‌ده.پشتیبانی از ویژگی‌های مدرن: شامل HTTP/2، gRPC و TLS که برای برنامه‌های مدرن خیلی مهمه.راه‌اندازی ساده Contourبرای راه‌اندازی Contour، مراحل زیر رو دنبال کنید:نصب Contour با Helm:helm repo add bitnami https://charts.bitnami.com/bitnami‍ helm install my-release bitnami/contourپیکربندی ابتدایی: یه فایل پیکربندی برای IngressRoute بسازید:apiVersion: projectcontour.io/v1 kind: HTTPProxymetadata: name: example namespace: default spec: virtualhost: fqdn: example.com routes: - conditions: - prefix: / services: - name: example-service port: 80اعمال فایل پیکربندی به کلاستر:kubectl apply -f example-httpproxy.yamlبررسی وضعیت Contour: مطمئن بشید که همه پادها و سرویس‌های مربوطه به درستی در حال اجرا هستن:kubectl get pods -n projectcontourkubectl get svc -n projectcontourنتیجه‌گیریاگه بخواییم نتیجه گیری کنیم Contour یه کنترلر Ingress قدرتمند و کارآمده که امکانات زیادی برای مدیریت ترافیک ورودی به کلاسترهای Kubernetes داره. با ویژگی‌های برجسته و یکپارچگی با Envoy، این ابزار می‌تونه نیازهای پیچیده مسیریابی و بالانس بار رو به خوبی پوشش بده. در مقایسه با رقباش، Contour با سادگی در پیکربندی و عملکرد بالا متمایز می‌شه و گزینه مناسبی برای تیم‌های توسعه و عملیات به حساب میاد.محسن شهبازیمحسن شهبازیMon, 20 May 2024 14:23:03 +0330