به گزارش از وبسایت cncf پروژههای CNCF که در این نوشته برجسته شدهاند، سالهاست بخش مهمی از مسیر حرفهای من بودهاند. بهعنوان یک مهندس فعال در اکوسیستم بومی ابری، پنج سال گذشته را صرف ساخت و مشارکت در فناوریهایی پیرامون Kubernetes، Envoy Proxy، دروازههای API و service meshها کردهام. این ابزارها نیروی محرکه پلتفرمهای مدرن در مقیاس بالا هستند و در قلب بسیاری از پروژههای CNCF قرار دارند که آینده زیرساختهای ابری را رقم میزنند. 😊
اوایل امسال فرصت پیدا کردم تا از طریق پروژه kgateway در برنامه مربیگری بنیاد لینوکس (LFX) شرکت کنم. آنچه در ابتدا یک پروژه مربیگری بهنظر میرسید، خیلی زود به یک مسیر برای تبدیل شدن به مشارکتکننده بلندمدت و نگهدارنده احتمالی در جامعهای تبدیل شد که بودن در آن برایم لذتبخش است.
چرا kgateway؟ در کار روزمرهمان، در پروژه OpenChoreo — یک پلتفرم توسعهدهنده داخلی متنباز برای Kubernetes و یک پروژه در CNCF Sandbox — شروع به استفاده از kgateway کردیم و از معماری فنی، پایداری و تطابق آن با استانداردهای بومی ابری مدرن تحت تأثیر قرار گرفتیم. kgateway که بر پایه Envoy Proxy و Kubernetes Gateway API ساخته شده، یک پایه قدرتمند و قابل توسعه برای مدیریت ترافیک در محیطهای Kubernetes فراهم میآورد. بلوغ پروژه، فعالیت توسعهای مداوم و تعهد به استانداردهای باز، آن را در ارزیابی راهحلهای پلتفرمی برای ما جذاب کرد.
در حین بررسی پروژه متوجه فرصت مربیگری LFX شدم که دقیقاً روی حوزهای متمرکز بود که با سابقه من همخوانی داشت. زمان مناسبی بود تا به جای مصرف صرفِ پروژه بهعنوان کاربر، به آن کمک کرده و نقش فعالی در جامعه ایفا کنم؛ و برنامه مربیگری نقطه شروعی منظم و ساختاری ارائه داد.
سؤالی که اغلب مطرح میشود این است که چرا یک مهندس باتجربه باید به مربیگری LFX بپیوندد؟ یک تصور اشتباه این است که این برنامه تنها برای دانشجویان یا مهندسین نوپا است. با پنج سال تجربه در حوزه دروازههای API بومی ابری و آشنایی با Go، Kubernetes و Envoy Proxy، من در سطح فنی آماده بودم، اما ورود به یک اکوسیستم متنباز بالغ بهعنوان تازهوارد هنوز میتواند چالشبرانگیز باشد. هر پروژه دارای معماری، مدل حاکمیتی، روشهای آزمایش و هنجارهای اجتماعی خاص خود است که یادگیری آنها زمانبر است. علاوه بر این، ترکیب کار تماموقت و تعهدات زندگی شخصی باعث میشود مشارکت متنباز بدون ساختار، اغلب پراکنده و نامنظم بماند.
برنامه مربیگری LFX برای kgateway راهحلی خوب ارائه داد: چارچوبی ساختاریافته، محدوده پروژهای شفاف و هماهنگی هفتگی مستقیم با نگهبانان اصلی. درخواست دادم، پذیرفته شدم و سفرم آغاز شد.
از روز اول مربیگری، بهطور نزدیک با نگهبانان اصلی همکاری کردم که این امر درک من از پروژه را بهطرز قابلتوجهی تسریع کرد. بهجای صرف هفتهها برای رمزگشایی تصمیمات طراحی بهتنهایی، توانستم زمینههای معماری، ملاحظات و جهتگیری بلندمدت پروژه را بهطور مستقیم بشناسم.
تمرکز اصلی مربیام اضافه کردن پشتیبانی برای engineering chaos به kgateway از طریق پیادهسازی HTTP fault injection بود. هدف این بود که به تیمهای پلتفرم اجازه دهیم بهطور عمدی خرابیهایی مانند تأخیر و قطع را در ترافیک تزریق کنند تا پیش از رخداد در تولید، میزان تحمل خطا و انعطافپذیری سرویسها را آزمون کنند. تحویل اصلی من شامل گسترش TrafficPolicy برای پشتیبانی از تزریق تأخیر، متوقفسازی تزریق با استفاده از کدهای وضعیت HTTP و gRPC، محدودسازی نرخ پاسخ و قابلیت نادیدهگرفتن هر مسیر برای غیرفعالسازی تزریق بود. در سطح پیادهسازی، این قابلیت به فیلتر HTTP fault در Envoy اضافه شد که بهصورت پیشفرض غیرفعال است و بهطور انتخابی برای هر مسیر یا virtual host فعال میشود؛ بنابراین تا زمانی که سیاستی صراحتاً آن را فعال نکند، این ویژگی بیاثر باقی میماند.
منحنی یادگیری واقعاً وجود داشت چون kgateway در تقاطع Kubernetes، Envoy Proxy و Gateway API قرار دارد؛ بنابراین حتی تغییرات کوچک اغلب نیازمند درک چند لایهای سیستم بود. اما مسیر ساختاریافته و همگامسازی منظم باعث شد پیشرفت پیوسته و متمرکز بماند. برخی از حوزههای کلیدی که در طول دوره مربیگری عمیقاً با آنها آشنا شدم عبارت بودند از: درک معماری داخلی control plane در kgateway، نحوه استفاده از Kubernetes Gateway API در معماری افزونه kgateway برای طراحی سیاستها، و فرآیند توسعهای تکراری و مشارکتی که هر مشارکت را نه تنها از نظر درستی بلکه از نظر نگهداری بلندمدت و همسویی با جهت پروژه ارزیابی میکند.
در پایان دوره مربیگری، نه تنها تکلیف مشخصشده را تکمیل کرده بودم، بلکه زمینه و اعتمادبهنفس لازم برای مشارکت مستقل در پروژه را نیز بهدست آوردم بدون آنکه نیاز به راهنمایی مرحلهبهمرحله داشته باشم.
برای من مربیگری هرگز یک مشارکت مقطعی نبود؛ هدف اولیه این بود که از این برنامه بهعنوان دریچهای برای ورود عمیقتر به جامعه و ادامه همکاری استفاده کنم. پس از پایان رسمی مربیگری، با افزودن ویژگیهای جدید، رفع اشکال، شرکت در بحثهای فنی و بازبینی مشارکتهای دیگران به همکاری با kgateway ادامه دادم. گذار از وضعِ شاگرد به مشارکتکنندهٔ معمولی امری طبیعی بود چرا که مربیگری پیشزمینه، روابط و اطمینان لازم برای مشارکت مستقل را فراهم کرده بود.
از زمان اتمام برنامه من به بهبود kgateway کمک کردهام: ارتقای ویژگیها، رفع اشکال و افزایش پایداری پروژه، شرکت در مباحث فنی، بررسی و همکاری در مشارکتهای جامعه و کمک به شکلدهی جهتگیریهای آتی پروژه. چند مشارکت که بهویژه به آنها افتخار میکنم عبارتاند از:
رفع ناسازگاری رفتار هنگام ادغام BackendConfigPolicy و حل همپوشانیها: وقتی چندین سیاست هدفگیر یک backend یکسان بودند رفتار ناسازگار ایجاد میشد. همچنین BackendConfigPolicy و BackendTLSPolicy در پیکربندی TLS همپوشانی داشتند و راهحل مشخصی برای حل تعارض نداشتند. من هر دو مشکل را برطرف کردم: ادغام در سطح فیلد برای BackendConfigPolicy بهصورتی که فیلدهای سیاستهای قدیمیتر اولویت داشته باشند و سیاستهای جدیدتر فیلدهای خالی را پُر کنند، و قاعدهای روشن برای برخورد با تداخلهای TLS که اولویت را به BackendTLSPolicy بهعنوان منبع استاندارد Gateway API میدهد.
قراردهی مرحله فیلتر قابل تنظیم برای ExtProc — این امکان را اضافه کرد که محل قرارگیری فیلتر ExtProc در زنجیره فیلتر HTTP Envoy تعیین شود، که زمانی اهمیت دارد که ExtProc باید قبل یا بعد از فیلترهایی مانند احراز هویت یا rate limiting اجرا شود. چالش اصلی در طراحی API نمایش یک مرحله (مثلاً Fault، AuthN، AuthZ، RateLimit، Route)، یک گزاره زمانی (قبل، حین، بعد) و وزن برای ترتیبدهی چند فیلتر در همان مرحله بود، آنهم بهصورتی که استفاده از آن برای توسعهدهندگان شهودی و قابلفهم باشد.
علاوه بر اینها، چند قابلیت دیگر نیز ارائه کردم از جمله: TLS termination برای TLSRoute در listenerهای TLS، پشتیبانی از upstream proxy protocol از طریق BackendConfigPolicy، ارسال جزئیات client certificate به upstream، و fetch غیرهمزمان با پشتیبانی retry برای JWKSهای از راه دور.
این تجربهها به من قدردانی عمیقتری از کار نگهبانان پروژههای متنباز داد؛ افرادی که روزانه وقت میگذارند تا پروژهها سالم، پایدار و رو به جلو باقی بمانند. ارزش واقعی مربیگری LFX نیز در همین است: مشارکتکنندگان بزرگ ساخته میشوند، نه صرفاً کشف. بسیاری از مهندسان ظرفیت فنی لازم را دارند اما از راهنمایی یا اعتمادبهنفس لازم برای برداشتن گام اول محروماند. برنامههای مربیگری محیطی فراهم میکنند که در آن افراد جدید میتوانند یاد بگیرند، رشد کنند و در نهایت رهبران جامعه شوند — تجربه من نمونهای روشن از این مسیر است.
آنچه با یک پروژه مربیگری آغاز شد، به تعهدی مداوم به جامعه kgateway و هدف بلندمدت تبدیل شده است که روزی نگهبان پروژه باشم. امروز همچنان به همکاری با kgateway ادامه میدهم و فعالانه برای رسیدن به نقش نگهبانی تلاش میکنم؛ پروژهای که در تقاطع فناوریهایی قرار دارد که من به آنها علاقهمندم: Kubernetes، Envoy Proxy، دروازههای API و شبکههای بومی ابری. همکاری در پروژهای که با علاقههای حرفهای من همخوانی دارد، این مسیر را بسیار پربار کرده است. 🚀
اگر قصد شرکت در برنامه مربیگری LFX را دارید، توصیهام ساده است: آن را آغاز سفر خود ببینید، نه مقصد. باارزشترین دستاورد، نه صرفاً پروژهای که در طول مربیگری تکمیل میکنید، بلکه جامعهای است که پس از آن جزو آن خواهید شد. از مربیانم، تیم فلاناگان و عمر همامی، و از نگهبانان و اعضای جامعه برای زمان، راهنمایی و حمایتی که در طول فرآیند ارائه دادند صمیمانه سپاسگزارم. پیشرفت متنباز با کمک افرادی ممکن میشود که آمادهاند دیگران را یاری دهند تا بیاموزند، مشارکت کنند و موفق شوند؛ من مشتاق ادامه مشارکت و کمک به شکلدهی آینده دروازههای API بومی ابری همراه با جامعه هستم. 🙏
