چگونه eBPF آینده لینوکس و مهندسی پلتفرم را شکل می دهد

eBPF به کاربران این امکان را می دهد تا برنامه های سفارشی را در هسته لینوکس بارگذاری و اجرا کنند، بدون اینکه نیازی به تغییرات مستقیم در خود هسته داشته باشند. امکانات بی پایان هستند.

وقتی Docker در سال ۲۰۱۳ وارد صحنه شد، کانتینرهای لینوکس موفقیت یک شبه به نظر می رسید. اما تکامل به کانتینرها—و میکروسرویس ها و Kubernetes — در واقع چندین دهه در حال ساخت بود که بر اساس اصول اولیه هسته در سیستم عامل لینوکس بود. داکر از این اولیه‌ها، یعنی cgroup‌ها و فضاهای نام، به‌عنوان بلوک‌های سازنده برای ایجاد قالب بسته‌بندی نرم‌افزاری سبک وزن و با استفاده آسان استفاده کرد. ظروف لینوکس برای سال‌ها توسط Google و دیگران [آشنایی‌ها؟] استفاده می‌شد، اما داکر آنها را به راحتی برای توسعه‌دهندگان جریان اصلی در دسترس قرار داد.

و این چیزی است که امروز در اطراف eBPF می‌بینیم—فناوری دیگری که از هسته‌های اولیه لینوکس به وجود آمده است. امروزه هر فروشنده بزرگ شبکه، قابلیت مشاهده و امنیت ادعای ارائه‌های «بر پایه eBPF» را دارد. ابزارهای eBPF مانند Cilium، Tetragon و Falco به طور یکسان در معماری سازمانی و ارائه‌دهندگان خدمات ابری جا افتاده‌اند. و به گفته یکی از سازندگان آن، این تازه شروعی برای پیشرفت‌های مبتنی بر eBPF است.

InfoWorld با دانیل بورکمن – یکی از خالقان eBPF و همکار فعلی eBPF برای هسته لینوکس – صحبت کرد تا درباره منشأ این فناوری بیشتر بدانید، چرا eBPF به عنوان یک رویکرد استاندارد برای برنامه نویسی و سفارشی سازی هسته لینوکس و آنچه که برای آینده لینوکس و مهندسی پلت فرم ظاهر شده است. .

از دانشجوی Solaris تا نگهدارنده هسته لینوکس

مسیر دانیل بورکمن به سمت eBPF با تلاش برای درک درونیات سولاریس، که هنوز در برنامه های درسی C.S در دانشگاه او تدریس می شد، آغاز شد. با این حال، یک مانع بزرگ، فقدان کد منبع برای دیدن اینکه “جادو کجا اتفاق می افتد” بود. بورکمن این تئوری را در کلاس‌های سیستم‌عامل بسیار جالب می‌دانست، اما لامپ در اواخر شب برای او که روی کد منبع هسته لینوکس، گزارش‌های Git و لیست‌های پستی مطالعه می‌کرد، واقعاً خاموش شد. او شروع به نوشتن برنامه های کاربری سطح پایینی کرد که با هسته ارتباط داشتند.

بزودی بورکمن در حال بررسی فیلترهای بسته، tcpdump و libpcap و نحوه عملکرد پشته شبکه در هنگام عبور بسته‌ها بود. لایه های مختلف می آیند و می روند. او در اوقات فراغت خود یک کلون tcpdump کارآمدتر نوشت و شروع به ارسال بهبودهای کوچک کد به پشته شبکه لینوکس کرد. در آغاز تحصیلات کارشناسی ارشد خود، او در نهایت اولین کنسرت پولی خود را برای توسعه کد هسته لینوکس برای یک راه اندازی محلی در لایپزیگ، آلمان دریافت کرد.

Borkmann اولین وصله خود را در سال ۲۰۱۰ به عنوان یک “noob کامل” (به قول او) برای گسترش netpoll برای اجازه اجرای چندین rx_hooks در هر رابط، به کرنل لینوکس ارسال کرد و به طور تصادفی باگی را معرفی کرد که باعث بن بست در سیستم می شد. هسته، جایی که به سرعت توسط یک مشارکت کننده دیگر کشف و رفع شد. اما او گیر کرده بود. توسعه هسته لینوکس یک محیط جذاب بود که او می‌دانست فراخوانش بود.

بورکمن به زوریخ نقل مکان کرد تا پایان نامه کارشناسی ارشد خود را در مورد توسعه یک پشته شبکه قابل ترکیب برای هسته تکمیل کند. آزمایش او با الهام گرفتن از نتگراف FreeBSD این بود که بلوک های شبکه را روی یک FPGA بارگذاری کند و نمودارهایی را برای پردازش بسته بسازد. اما در طول مسیر، او گاهی اوقات مقالات آکادمیک را بسیار کسل‌کننده با تأثیر بسیار کم درازمدت و دنیای واقعی می‌دید و متوجه می‌شد که مشارکت تمام وقت در هسته لینوکس چقدر سودمندتر است. او یکی از مشارکت کنندگان لینوکس به نام توماس گراف را کشف کرد (در نهایت هر دو یکی از خالقان Cilium شدند) که ایمیلش دارای دامنه سوئیسی (.ch) بود، به طور خود به خود با او تماس گرفت — و از او دعوت شد تا به تیم شبکه هسته لینوکس در Red Hat بپیوندد.< /p>

و اکنون Borkmann یکی از ۱٪ از مشارکت کنندگان برتر جهان در هسته لینوکس است.

بازنگری شبکه در سیستم عامل لینوکس

داستان اصلی پشت eBPF واقعاً از سال ۲۰۱۱ شروع می‌شود، زمانی که شبکه‌های تعریف‌شده با نرم‌افزار (SDN) در حال افزایش بود و پذیرش لینوکس در حال افزایش بود. زیرسیستم‌های لینوکس باید با الگوی جدید معماری میکروسرویس‌ها و برنامه‌های کاربردی توزیع‌شده همگام باشند، که در میان خوشه‌های ماشین‌های لینوکس به جای یک سرور و سیستم عامل میزبان اجرا می‌شوند.

کار بورکمن روی توسعه هسته در پشته شبکه، او را در خط مقدم برآوردن نیازهای شبکه SDN و شبکه ابری قرار داد. لینوکس به انتزاعات جدیدتری نیاز داشت، زیرا بسیاری از بلوک های سازنده آن بیش از ۱۰ سال پیش طراحی شده بودند – cgroups (CPU، مدیریت حافظه)، فضاهای نام (net، mount، pid)، SELinux، seccomp، Netfilter، Netlink، AppArmor، Auditd، Perf، و غیره و بورکمن دید که فناوری‌هایی مانند nftable‌های netfilter به عنوان شبکه‌های لینوکس «نسل بعدی» و همچنین Open vSwitch (OVS) که در آن زمان پیشرفته‌ترین پروژه SDN بود، تحت فشار قرار گرفتند. او معتقد بود که رویکرد بهتری وجود دارد.

هسته لینوکس قبلاً در حال گسترش بود تا با سرعت‌های بالاتر شبکه سازگاری داشته باشد، اما انعطاف‌پذیری کافی برای برنامه‌نویسی عملکردهای جدید و سفارشی فراهم نمی‌کرد. محدودیت دیگر این بود که «هرگز فضای کاربر را از بین نبریم». یعنی هسته لینوکس باید به پشتیبانی از تمام نرم افزارهای توسعه یافته مدت ها قبل از ورود برنامه های کاربردی ابری به صحنه ادامه دهد. متأسفانه، این “چمدان میراث” برخی از نوآوری های شبکه را از هسته به سمت فضای کاربر منتقل کرد.

به طور خلاصه، مدل‌های عملیات ابری جدید، اتوماسیون، ریزش، و مقیاس بسیار بیشتر و الزامات عملکرد شبکه سخت‌تر را به همراه داشتند. اما زیرسیستم‌های مستقل در هسته لینوکس هیچ قراردادی برای فشار دادن، جمع‌آوری و عمل بر روی تمام این زمینه ابری جدید در هسته نداشتند.

در برنامه‌نویسی لینوکس، پردازش بسته‌ها – تجزیه، دستکاری، فیلتر کردن و ارسال – یک نگرانی اساسی برای “آنچه ممکن است” است. این مکانیسمی است برای نحوه مسیریابی، کنترل و بازرسی بسته های شبکه توسط توسعه دهندگان هسته در حین حرکت در پشته. پردازش بسته به پشته شبکه هسته همان چیزی است که کاربراتور برای یک موتور، خازن Flux تا Doc’s DeLorean.

توسعه دهندگان برنامه عمدتاً برنامه های خود را در فضای کاربر می نویسند و از انتزاعی هایی استفاده می کنند که آنها را از تماس های سیستمی که باید با هسته انجام شود محافظت می کند. بنابراین، زمانی که یک برنامه نیاز به رابط با سخت افزار دارد – نوشتن روی صفحه، نوشتن روی یک فایل، ارسال یک بسته شبکه – باید از هسته کمک بخواهد. فضای کاربر نمی تواند مستقیماً این کار را انجام دهد (به دلایل مختلف مانند امنیت سیستم). هسته رابط مشترک و عمومی بین برنامه های کاربردی فضای کاربر و سخت افزار را فراهم می کند و چندین فرآیند فضای کاربر را که به طور همزمان در حال اجرا هستند هماهنگ می کند.

در تکامل از مجازی‌سازی به کانتینرها، بسیاری از رویکردهای مختلف برای فیلتر کردن بسته‌ها برای مکانی در هسته لینوکس رقابت کردند: iptables، nftables، OVS، Linux Traffic Control (TC) و غیره. eBPF به دلیل بیانی بودن آن همراه با ایمنی توسط تأییدکننده (در حین اجرای برنامه ها با عملکرد بومی) به عنوان رویکرد ترجیحی برنده شد. به عبارت دیگر، eBPF به کاربران اجازه می‌دهد تا هسته را به روش‌هایی برنامه‌ریزی کنند که با این گزینه‌ها امکان‌پذیر نیست و خطر خرابی هسته را تهدید نمی‌کند.

یک هسته لینوکس “قابل برنامه ریزی” بیشتر

در حالی که بورکمن در ابتدا به دلیل انعطاف‌پذیری و عملکردی که برای شبکه به ارمغان می‌آورد به سمت eBPF کشیده شد، آشکار شد که مزایای فناوری جدید می‌تواند بسیار فراتر از شبکه‌سازی باشد.

Borkmann گفت: «وقتی eBPF این قابلیت پایه را وارد کرد که در آن می‌توانید موارد را بسازید و فوراً آن را مستقر کنید، مشکل بزرگی حل شد. شما می توانید برنامه های ارکستراسیون خود را با eBPF تعبیه شده در آن بنویسید و بدون توجه به نسخه هسته اصلی آن را اجرا کنید. و به جای پرداخت پول زیاد به یک فروشنده بزرگ برای پایداری هسته هسته ABI، اکنون می توانید به جای نیاز به یک ماژول برای گسترش هسته برای موارد استفاده مختلف، فقط از eBPF استفاده کنید.”

eBPF به یک زبان اسمبلی جهانی تبدیل شد که به کاربران اجازه می‌دهد برنامه‌های سفارشی را در هسته لینوکس بارگیری و اجرا کنند—روشی برای افزودن همه انواع قابلیت‌ها به عملیات سیستم در زمان اجرا این به شدت تایپ شده است، دارای یک مجموعه دستورالعمل پایدار است، و پسوندهای آن سازگار با عقب هستند.

بورکمن توضیح داد: «به eBPF به عنوان نوع جدیدی از نرم افزار فکر کنید که شکاف بین هسته یکپارچه معمولی و میکروکرنل را پر می کند. “این یک برنامه افزودنی ایمن از هسته از فضای کاربر مورد اعتماد شما است. و نکته مهم در مورد eBPF این است که به همان سرعت کد هسته معمولی است که eBPF یک جعبه سند نیست، اما برنامه کاملاً توسط تأیید کننده درک می شود تا تعیین کند آیا اجرای آن در یک محیط قابل اعتماد ایمن است یا خیر، و سپس JIT [فقط در- time compiled] به کد بومی.”

eBPF نه تنها ایمن و سریع است، بلکه با سرعت اصلی کار می کند. بسیار انعطاف پذیر است و به کاربران مختلف اجازه می دهد از آن به روش های مختلف استفاده کنند. بورکمن می‌گوید: «قدرت eBPF واقعاً در این است که شما می‌توانید کد را از دیدگاه کاربر تنها زمانی فعال کنید که به‌عنوان کاربر آن مورد استفاده را داشته باشید یا نیاز به پردازش چیزی به روش خاصی داشته باشید. “این دیگران را جریمه نمی کند. مانند چیزی نیست که در هسته سخت کدگذاری شده باشد که مسیر بحرانی را کندتر و کندتر کند—مرگ عملکرد با هزار کاهش.”

Cilium’s Graf گفت: «قبل از eBPF، اکثر کاربران از توزیع‌های لینوکس سازمانی استفاده می‌کردند یا هر نسخه هسته‌ای را که روی دستگاهشان نصب شده بود اجرا می‌کردند. “eBPF این را به طور اساسی تغییر داد، زیرا با وجود زمان اجرا، هر ایده ای می تواند به یک برنامه eBPF تبدیل شود و در زمان اجرا به جای چند سال، ظرف چند روز بارگذاری شود. این بدان معنی بود که ما می توانستیم همه چیز را بهتر از نو بسازیم. ابتدا باید تصمیم می‌گرفتیم چه چیزی را بازسازی کنیم.»

مهندسی هسته به جریان اصلی می رود

همانند Google Borg و سایر فناوری‌هایی که در hyperscalers متولد شده‌اند، eBPF در ابتدا تنها توسط تعدادی از فروشگاه‌های مهندسی نرم‌افزار که دارای مهارت‌های توسعه هسته بودند، مورد استفاده قرار گرفت. تعداد زیادی از توسعه دهندگان مهارت های برنامه نویسی سطح پایین C لازم برای انجام مهندسی هسته و نوشتن برنامه های eBPF را ندارند.

اما امروز تعداد کمی از متخصصان در حال نوشتن برنامه هایی هستند که میلیون ها کاربر را تحت تأثیر قرار می دهند. برنامه‌های مبتنی بر eBPF هیجان‌انگیزترین زمین برای تیم‌های مهندسی پلتفرم هستند که مسئولیت شبکه، امنیت و قابلیت مشاهده را بر عهده دارند و بسیاری از کسانی که از این برنامه‌ها استفاده می‌کنند نیازی به دانستن چیزی در مورد انتزاعات eBPF ندارند که آنها را ممکن می‌سازد. همانطور که بورکمن در سخن اصلی در کارگاه آموزشی در مورد eBPF.

در اینجا نگاهی اجمالی به بسیاری از برنامه های کاربردی در چشم انداز وسیع eBPF آورده شده است:

Cilium به عنوان اجرای رابط شبکه کانتینر (CNI) برای ارائه اتصال لایه ۳ و لایه ۴ بین بارهای کاری کانتینر، اما برای تبدیل شدن به لایه شبکه واقعی برای اکثر خدمات ابری تکامل یافته است. پیشنهادات Kubernetes ارائه دهندگان در میان سایر ویژگی‌ها، Cilium تعادل بار توزیع شده را برای ترافیک بین پادهای Kubernetes و سرویس‌های خارجی پیاده‌سازی می‌کند و قادر است به طور کامل جایگزین kube-proxy با استفاده از جداول هش کارآمد در eBPF برای مقیاس تقریبا نامحدود شود. همچنین از عملکردهای پیشرفته‌ای مانند اجرای سیاست لایه ۳ تا لایه ۷، دروازه‌های ورودی و خروجی یکپارچه، مدیریت پهنای باند، مش سرویس در ترکیب با Envoy، و دید عمیق شبکه پشتیبانی می‌کند.

Tetragon یکی دیگر از برنامه‌های eBPF است که قابلیت مشاهده امنیتی و اجرای زمان اجرا را فراهم می‌کند. با بهره‌برداری از سربار پایین eBPF، Tetragon به تیم‌های پلتفرم اجازه می‌دهد تا جریان‌های شبکه و سایر رویدادهای درون هسته را به اشیاء Kubernetes (برچسب‌ها، پادها، فضاهای نام) تا فرآیندهای بسیار خاص و درخت فرآیند مربوط به آن‌ها مرتبط کنند. در پی سوء استفاده های امنیتی زنجیره تامین نرم افزار مانند XZ Utils، Tetragon یک پروژه متن باز است که هدف آن ارائه راه های عمیق تر به تیم های پلت فرم برای یافتن مکان هایی که نرم افزار خاص در محیط آنها در حال اجرا است و اقدامات خط مشی خاصی در سطح هسته است. .

Pixie یک ابزار قابل مشاهده است که از eBPF برای “گرفتن خودکار داده های تله متری بدون نیاز به ابزار دقیق دستی” استفاده می کند. این به یک بلوک ساختمانی محبوب برای مدیریت عملکرد برنامه های نسل بعدی و نظارت بر فروشندگان تبدیل شده است. یک جستجوی ساده در گوگل برای “مشاهده پذیری و eBPF” نشان می دهد که چقدر این فناوری غنای داده های تله متری را که با عملکرد eBPF ممکن می شود، تغییر می دهد. استنباط وضعیت بلادرنگ سیستم های ابری بومی از لحاظ تاریخی شامل جمع آوری داده های نظارتی است که باید در آینده با هم مرتبط شوند. نزدیک‌تر کردن این مجموعه داده‌های تله‌متری به هسته، سازگاری بسیار بیشتر و استفاده کمتر از منابع را نوید می‌دهد.

کاتران یک کتابخانه ++C است که می‌تواند با رویکرد جدیدی که بر روی پردازش بسته‌های درون هسته‌ای ساخته شده است، وضعیت موجود در بار متعادل‌کننده‌های اختصاصی لایه ۳ و لایه ۴ را به چالش بکشد. همه نمی توانند برنامه های eBPF ایجاد کنند، اما برنامه هایی که در حال ایجاد هستند عرصه هایی را هدف قرار می دهند که قبلا در زیرساخت‌های سازمانی نسبتاً راکد است و برای موارد استفاده بومی ابری برای نوسازی فریاد می‌زند.

بورکمن گفت: «دهه بعدی نرم افزار زیرساخت توسط مهندسان پلتفرم تعریف می شود که می توانند از eBPF و پروژه هایی که از آن برای ایجاد انتزاعات مناسب برای پلتفرم های سطح بالاتر استفاده می کنند، استفاده کنند. “فشار زمینه ابری بومی به هسته وجود نداشت، و eBPF آن را حل کرد.”

همانطور که ۱۰ سالگی کوبرنتیس را گرامی می داریم< /a> در این ماه، ما هنوز در روزهای اولیه برنامه های کاربردی توزیع شده، ارکستراسیون کانتینر و مهندسی پلت فرم هستیم. تعداد کمی ممکن است مستقیماً eBPF را در سطح هسته مهندسی کنند، اما میلیون ها نفر از برنامه های مبتنی بر eBPF استفاده خواهند کرد. و اگر بارهای کاری را روی Kubernetes در یکی از پلتفرم‌های بزرگ ارائه‌دهنده ابر عمومی اجرا می‌کنید، به احتمال زیاد قبلاً این کار را کرده‌اید.