Kubernetes، Networking و Find VMware of Cloud Native

توماس گراف یکی از بنیانگذاران و CTO است ایزووالانت، و خالق یک فناوری شبکه محبوب منبع باز (و بومی ابری) به نام سیلیوم. Cilium بر روی یک فناوری لینوکس در سطح هسته به نام ساخته شده است eGMP.

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

---

آینده: چگونه باید در مورد eBPF و Cilium در زمینه محاسبات و شبکه، به طور کلی، و سپس به طور خاص در زمینه اکوسیستم بومی ابر?

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

در مورد eBPF نیز همین اتفاق می افتد، اگرچه در سطح سیستم عامل، زیرا ناگهان می توانیم کارهایی را در سطح هسته یا سیستم عامل انجام دهیم که در آن همه چیز را می بینیم و همه چیز را کنترل می کنیم - که برای امنیت بسیار مهم است - بدون نیاز به تغییر هسته. کد منبع اساساً می‌توانیم برنامه‌ها را در هسته بارگذاری کنیم تا عملکرد آن را گسترش دهیم و قابلیت‌های جدیدی را با آن بیاوریم. این همچنین موج عظیمی از نوآوری را باز کرده است. فرامقیاس‌کننده‌ها مانند فیس‌بوک، گوگل و نتفلیکس به تنهایی، مستقیماً و با تیم‌های هسته‌شان از آن استفاده می‌کنند. 

چیزی که Cilium به جدول می آورد این است که از فناوری سطح پایین eBPF برای ارائه موج جدیدی از زیرساخت های نرم افزاری، به ویژه برای موج بومی ابری استفاده می کند. به این فکر کنید مانند شبکه های نرم افزاری تعریف شده و کاری که Nicira که تبدیل به VMware NSX شد، برای صنعت مجازی سازی انجام داد. ما همین کار را برای بومی ابر انجام می دهیم، جایی که ترکیبی از ارائه دهنده ابر یا زیرساخت ابر عمومی و همچنین زیرساخت داخلی است. و ما در حال حل موارد استفاده از شبکه، امنیت و قابلیت مشاهده با آن در لایه زیرساخت هستیم.

و Cilium Service Mesh که به تازگی عرضه شده، تکامل یافته این قابلیت هاست؟

چیزی که در حال حاضر اتفاق می افتد، از حدود یک سال پیش، این است که این دو فضا در حال برخورد هستند. کاری که Cilium تاکنون انجام داده است بر روی شبکه سازی، شبکه مجازی سازی شده و سپس شبکه بومی ابری متمرکز شده است – اما همچنان شبکه سازی. اما پس از آن، تیم‌های اپلیکیشن توییتر و گوگل، از بالا به پایین این کار را انجام دادند مش سرویس چیزها - ابتدا در برنامه، و سپس مدل مبتنی بر سایدکار، مدل مبتنی بر پروکسی، که پروژه ها مانند آن هستند. ایستیو ارائه. و اکنون این دو لایه نزدیکتر می شوند زیرا شرکت‌های سنتی در حال ورود به دنیای بومی ابری هستند و نیازمندی‌های شبکه‌سازی سازمانی هستند، اما تیم‌های برنامه آن‌ها همچنین خواهان یک مش خدمات هستند.. 

گارتنر این لایه جدید را "اتصال سرویس" می نامد - خواهیم دید که آیا این اصطلاح به کار می رود - اما اساساً لایه ای است که شامل بخش شبکه سازمانی و قطعه مش سرویس است که از تیم های برنامه می آید. و چون این چیزی است که مشتریان خواستار آن هستند، ما این قابلیت ها را به خود Cilium اضافه کرده ایم. بنابراین، اساسا، Cilium از سمت شبکه سازمانی به سمت بالا می رود و مش های سرویس به سمت قسمت های بیشتری از شبکه رو به پایین می روند.

چرا این همه تمرکز روی شبکه و سطح مش سرویس پشته Kubernetes وجود دارد؟

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

و در ابر بومی، به ویژه، چند ابری کاملاً ضروری است. همه ارائه دهندگان ابر لایه های شبکه خود را دارند، اما، البته، متناسب با ابرهای خودشان. آنها پیشنهادات اولیه دارند، اما واقعاً چند ابری نیستند. سیلیوم و eBPF آن لایه چند ابری و آگنوستیک را روی میز می آورند. دقیقاً همان عملکردی را که در فضای ابری عمومی انجام می‌دهد، در محل است. تعدادی از ارائه دهندگان ابر عمومی از Cilium در زیر هود برای ارائه های مدیریت شده Kubernetes خود استفاده می کنند و شرکت های مخابراتی از آن برای زیرساخت های 5G اولیه استفاده می کنند. این در مورد صحبت کردن به هر دو زبان و اتصال این دنیاها به یکدیگر است.

به همین دلیل است که تمرکز زیادی روی این موضوع وجود دارد: زیرا یکی از ساده‌ترین راه‌ها برای ارائه‌دهندگان ابری برای قفل کردن مشتریان، داشتن آن لایه اتصال است. من فکر می کنم از منظر زیرساخت استراتژیک، درست همانطور که لایه مجازی سازی کلید بود، اکنون لایه اتصال و شبکه کاملاً کلیدی است.

منبع نوآوری [آینده] منبع باز خواهد بود، و مشتریان و کاربرانی که تقاضا را افزایش می‌دهند، شرکت‌هایی هستند که یک سطح پایین‌تر از ابرمقیاس‌گرها قرار دارند – شرکت‌های در حال حاضر قابل توجهی که هنوز به شدت مخرب هستند.

Kubernetes در این مرحله به طور گسترده پذیرفته و پذیرفته شده است، اما هنوز در برخی از محافل صحبت از بیش از حد آن وجود دارد. به نظر شما Kubernetes و به طور کلی اکوسیستم بومی ابر برای چه کسی است؟

این برای تیم های کاربردی مدرن است. من فکر می‌کنم درک این موضوع آغاز شده است که اگر می‌خواهید تیم‌های کاربردی مدرن را جذب کنید و بتوانید زمان‌های ورود سریع به بازار داشته باشید، باید زیرساخت‌های بومی ابری را برای آنها فراهم کنید. ما اغلب نمونه سازی – اولیه، قبل از MVP، حتی اثبات مفهوم یا فروش داخلی – را در بدون سرور، چیزی شبیه به لامبدا می بینیم. و سپس در Kubernetes، زیرا تیم های برنامه می توانند مستقیماً زیرساخت را در اختیار داشته باشند. و سپس، همانطور که به سمت تولید حرکت می کند، آنها به سمت توزیع های سازمانی و اولیه Kubernetes می روند. اما این در واقع بخش نسبتا کوچکی از کل زیرساخت است، شاید یک درصد دو رقمی تک یا کم. 

اگرچه به وضوح استاندارد جدید خواهد بود. درست مانند پذیرش مجازی سازی در ابتدا بسیار کند بود و مردم می گفتند که بیش از حد است - اما با گذشت زمان، البته، شروع به جایگزینی بسیاری از چیزها کرد - ما در اینجا هم همین را خواهیم دید. یا درست مثل زبان های مدرن. مردم می گفتند جاوا بیش از حد است، و احتمالاً هنوز هم برای بسیاری از برنامه ها وجود دارد، اما زمانی بود که انجام هر گونه برنامه نویسی خارج از جاوا بسیار سخت شد، زیرا اکثر توسعه دهندگان برنامه می توانستند در آن بنویسند. برای تیم های کاربردی مدرن صادق باشد: آنها انتظار دارند که Kubernetes را در اطراف خود داشته باشند تا بتوانند چابک تر شوند و محصول را به سرعت به بازار عرضه کنند.

در بخش زیرساخت، ممکن است کمی زیاده روی باشد، اما اگر جایگزین بازنویسی یک برنامه از سرور بدون سرور به روی پرم باشد، این یک کار بزرگ است. بنابراین Kubernetes حد وسط آنجاست که بسیار جذاب است. 

در مورد این ایده که Kubernetes هنوز به یک تجربه توسعه دهنده بهتر نیاز دارد، چطور؟

اگر به OpenShift اصلی نگاه کنیم، قبل از اینکه دوباره بر روی Kubernetes قرار گیرد، این چنین بود. حتی به تیم برنامه نزدیکتر بود و تجربه توسعه دهنده برنامه حتی بهتری بود. می توانید به Git فشار دهید و به طور خودکار مستقر می شود. Heroku نیز این را امتحان کرد، اما مبتنی بر SaaS. 

Kubernetes یک گام به عقب برداشت و گفت: «ما باید برخی از جنبه‌های عملیاتی را در آن نگه داریم و آن را کمی به آنچه که یک sysadmin انتظار دارد نزدیک‌تر کنیم. ما نمی‌توانیم فقط برای برنامه‌های کاربردی مناسب باشیم.» این حد وسط است: باید جذابیت کافی برای تیم های برنامه داشته باشد، اما همچنان باید امکان اجرای آن برنامه در خارج از یک محیط خاص و مدیریت آن توسط افرادی غیر از توسعه دهندگان برنامه وجود داشته باشد.

می‌توانم بگویم بزرگ‌ترین قدم بین داکر و کوبرنتیس این بود که داکر تماماً در مورد تجربه توسعه‌دهنده بود. آن بخش را حل کرد، اما بخش اکوسیستم ابر عمومی را حل نکرد.

چگونه به این نقطه رسیدیم؟ آیا این تکامل طبیعی از پلتفرم به عنوان یک سرویس (PaaS) و ظروف برنامه بود؟

این تصاویر داکر و جنبه بسته بندی داکر بود. مدرسه قدیمی نحوه استقرار در ماشین های مجازی بود و انواع اتوماسیون در اطراف آن وجود داشت. و سپس کاری بود که فیس بوک با تاپرور انجام می داد - بسیار سفارشی و در مقیاس بسیار بزرگ. و سپس داکر آمد و اساساً این تصویر ظرف را ارائه داد و همه می‌توانستند با آن مانند یک ماشین مجازی مینیاتوری رفتار کنند. اکنون می توانم برنامه خود را توزیع کنم و به جای یک تصویر مجازی 600 مگابایتی، اکنون یک ظرف 10 مگابایتی است. اما شما می توانید آن را به همان صورت درمان کنید، همه چیز مورد نیازش را دارد. 

این امکان را فراهم کرد که ارکستراتوری مانند Kubernetes را وارد کنید که همچنان به شما امکان می دهد با برنامه هایی مانند مینی VM رفتار کنید، اما سپس یک قدم جلوتر بروید و در واقع آنها را به عنوان ریزسرویس ها در نظر بگیرید. این به شما امکان می دهد هر دو را انجام دهید.

من می‌توانم بگویم بزرگترین قدم بین Docker و Kubernetes این بود که Docker تماماً در مورد تجربه توسعه‌دهندگان بود. آن بخش را حل کرد، اما بخش اکوسیستم ابر عمومی را حل نکرد. ادغام نزدیک با ارائه دهندگان ابری نداشت یا لزوماً می خواست. Kubernetes آن را حل کرد. 

چه کسی Kubernetes را در شرکت ها اجرا می کند؟ آیا این تیم های کاربردی فردی است؟

یک تغییر جالب در مورد بومی ابر اتفاق افتاد، این است که ما آن را به نام "تیم پلتفرم" داریم. آنها مهندس برنامه نیستند. آنها کمی دانش عملیات شبکه و اطلاعات امنیتی کمی دارند. آنها دانش SRE دارند و می دانند چگونه اتوماسیون ابری انجام دهند. آنها بستر را برای تیم های برنامه فراهم می کنند و با آن تیم های برنامه به عنوان مشتریان خود رفتار می کنند.

تیم‌های پلتفرم کسانی هستند که Kubernetes و فن‌آوری‌های مرتبط را خریداری می‌کنند و از آن‌ها استفاده می‌کنند زیرا وظیفه دارند زیرساخت‌های نسل بعدی را برای خوشحال کردن تیم‌های برنامه مدرن فراهم کنند.

من فکر می کنم قطعاً فضایی برای بدون سرور وجود دارد، به ویژه برای توسعه برنامه بسیار سریع. اما در شرکت ها، ما شاهد ابر بومی به عنوان لایه جدید در بالای مجازی سازی هستیم

آیا این یک خریدار خالص جدید است یا یک تیم خالص-جدید؟ یا آیا تیم های پلتفرم مانند چیزی هستند که در مکان هایی مانند گوگل یا فیس بوک وجود دارد و اکنون در حال تبدیل شدن به جریان اصلی هستند؟

آنها عمدتا یک تیم جدید هستند. من فکر می کنم آنها تا حدودی مانند تیم های SRE در گوگل و فیس بوک هستند. با این حال، تیم‌های برنامه احتمالاً مالک بیشتری از استقرار برنامه در شرکت‌ها هستند، زیرا شرکت‌ها این تمایز واضح را بین مهندسان نرم‌افزار و SREهایی مانند Google و Facebook ندارند. من می‌توانم بگویم این تکامل بسیار شبیه به روشی است که شما تیم‌های مجازی‌سازی داشتید، و سپس بسیاری از عملیات‌های شبکه از شبکه مهاجرت کردند - یا تکامل یافتند یا پیشرفت کردند. سخت افزار در مورد شبکه بودن مجازی سازی. و این تیم ها برای مثال شروع به کار با VMware NSX کردند. اینجا هم همین اتفاق می افتد. 

اگرچه، لزوماً بودجه جدیدی نیست. ما شاهد تغییر بودجه از امنیت و شبکه به این تیم پلتفرم هستیم، به عنوان مثال، با افزایش هزینه های ابری و هزینه کمتری برای سخت افزار شبکه. آنها اغلب با تیم امنیتی و تیم عملیات شبکه برای خرید خرید کار می کنند، اما در واقع حجم قابل توجهی از بودجه را در اختیار دارند.

چگونه می بینید بنیاد رایانش بومی ابر در حال تکامل، و آیا Kubernetes همیشه در مرکز آن خواهد بود - یا به طور کلی جنبش بومی ابر؟

Kubernetes چیزی است که جرقه CNCF را برانگیخت و در چند سال اول همه چیز در مورد Kubernetes و ابر عمومی بود. چیزی که از حدود یک سال پیش دیده‌ایم این است که اکنون دیگر فقط مربوط به Kubernetes نیست، بلکه در واقع بیشتر در مورد بومی ابر است. از اصول. این در واقع به این معنی است که دیگر لزوماً ابر نیست، حتی ابر خصوصی. اغلب حتی شبکه‌های سنتی سازمانی، زیرساخت‌های اولیه خسته‌کننده، سرورهای فلزی خالی و همه این‌ها، اما با اصول بومی ابری ساخته شده است. 

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

ما شاهد تقاضای بسیار قوی برای اتصال به دنیای قدیم و صحبت با MPLS، VLAN، sFlow، و NetFlow هستیم - مجموعه‌ای از الزامات موجود سازمانی. هیچ کدام از آنها دور نشده اند.

با گذشت حدود یک دهه از آن، به نظر نمی رسد فضای بومی ابر یک مد روز باشد. چقدر فضا برای ادامه تکامل وجود دارد؟

قطعا زمانی چنین بود، "اوه، Kubernetes احتمالا کوتاه مدت است و بدون سرور لایه بعدی خواهد بود." یا، «Kubernetes شبیه OpenStack است. یا، "این ناپدید خواهد شد و جزییات اجرایی خواهد بود." و این اتفاق نیفتاده است. 

من فکر می کنم قطعاً فضایی برای بدون سرور وجود دارد، به ویژه برای توسعه برنامه بسیار سریع. اما در شرکت‌ها، ما شاهد ابر بومی به عنوان لایه جدید در بالای مجازی‌سازی هستیم و معتقدیم که عمر مفیدی مشابه مجازی‌سازی دارد. این بدان معناست که ما در همان ابتدای مهاجرت بومی ابر هستیم.

چه مشکلات بزرگی هنوز باید در سطح زیرساخت حل شود؟

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

بنابراین این چالش بزرگ بعدی است: چه کسی قرار است آن لایه آگنوستیک برای چند ابری و بومی ابری باشد، مانند آنچه VMware تبدیل شد؟ چه کسی VMware برای ابر بومی خواهد بود؟

من فکر می‌کنم درک این موضوع آغاز شده است که اگر می‌خواهید تیم‌های کاربردی مدرن را جذب کنید و بتوانید زمان‌های ورود سریع به بازار داشته باشید، باید زیرساخت‌های بومی ابری را برای آنها فراهم کنید.

و اگرچه پذیرش بومی ابری ممکن است برای شرکت‌های وب مدرن که قبلاً از آنها استفاده می‌کردند آسان باشد، چالش از دیدگاه شما ایجاد فناوری‌های جدیدی است که شکاف بین این دنیای مدرن و ابزارها و سیستم‌های سازمانی موجود را پر می‌کند؟

بخش سخت این است که تیم‌های برنامه مدرن عادت دارند که لایه زیرساختی را به همان سرعتی که آنها توسعه می‌دهند. و این باعث شد که لایه زیرساخت حتی قابل برنامه ریزی تر و قابل تنظیم تر باشد. به همین دلیل است که در واقع یک لایه شبکه و یک لایه امنیتی در بالای لایه شبکه ابری می بینیم. اما اکنون ما شرکت‌هایی داریم که وارد می‌شوند، و ما شاهد تقاضای بسیار قوی برای اتصال به دنیای قدیم و صحبت با MPLS، VLAN، sFlow و NetFlow هستیم - مجموعه‌ای از الزامات موجود سازمانی. هیچ یک از آنها ناپدید نشده اند، همه قوانین انطباق هنوز یکسان هستند. و حتی برخی از شرکت‌های مدرن SaaS هم اکنون با این چالش‌ها مواجه هستند که بزرگ‌تر می‌شوند و به رعایت آنها اهمیت می‌دهند و الی آخر. 

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

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

خیلی جالبه من می توانم بگویم که احتمالا از گوگل و فیس بوک نمی آید. منبع نوآوری منبع باز خواهد بود و مشتریان و کاربرانی که تقاضا را افزایش می‌دهند، شرکت‌هایی هستند که یک سطح پایین‌تر از هایپرمقیاس‌کننده‌ها قرار دارند – شرکت‌های در حال حاضر قابل توجهی که هنوز به شدت مخرب هستند، مانند Adobe، Shopify یا GitHub. اما همچنین شرکت‌هایی مانند خدمات مالی، ارائه‌دهندگان بیمه و مخابرات، در معرض خطر مختل شدن توسط فناوری هستند. همه این شرکت‌ها علاقه مشترکی به استانداردسازی زیرساخت‌ها با مدل‌های توسعه و زیرساخت تکرارپذیر دارند.

ارسال شده در 26 ژوئیه 2022