Kubernetes, сети и поиск VMware для Cloud Native

Томас Граф является соучредителем и техническим директором Изоваленти создатель популярной сетевой технологии с открытым исходным кодом (и облачной) под названием ресница. Cilium построен на основе технологии Linux на уровне ядра, называемой eGMP.

В этом интервью Граф обсуждает роли, которые Cilium и eBPF играют в растущей облачной сетевой экосистеме, а также некоторые более широкие тенденции, связанные с внедрением и развитием Kubernetes. Он объясняет, кто использует и покупает Kubernetes на крупных предприятиях, где облачная инфраструктура все еще нуждается в улучшении, и как стремление к стандартизации стимулирует инновации.

---

БУДУЩЕЕ: Как мы должны думать о eBPF и Cilium в контексте вычислений и сетей в целом, а затем конкретно в контексте облачная экосистема?

ТОМАС ГРАФ: В целом, eBPF — это технология, и она крайне низкого уровня. Он был разработан для разработчиков ядра, а мой опыт связан с разработкой ядра. eBPF для ядра и операционной системы — то же, что JavaScript для браузера. Он делает операционную систему программируемой так же, как JavaScript делает программируемым браузер. В прошлом нам приходилось обновлять версии наших браузеров, чтобы фактически использовать определенные веб-сайты. А затем появился JavaScript, и внезапно команды разработчиков приложений и разработчики смогли создавать масштабные приложения — до такой степени, что самое популярное приложение для обработки текстов было заменено приложением в браузере. Это привело к огромной волне инноваций. 

То же самое происходит с eBPF, хотя и на уровне операционной системы, потому что внезапно мы можем делать что-то на уровне ядра или операционной системы, где мы все видим и все контролируем — что очень важно для безопасности — без необходимости менять ядро. исходный код. По сути, мы можем загружать программы в ядро, чтобы расширить его функциональность и добавить новые возможности. Это также вызвало массовую волну инноваций. Гиперскейлеры, такие как Facebook, Google и Netflix, используют это самостоятельно, напрямую, со своими собственными командами ядра. 

Что Cilium привносит в таблицу, так это то, что он использует эту низкоуровневую технологию eBPF, чтобы по существу обеспечить новую волну программной инфраструктуры, особенно для облачной волны. Думайте об этом как о программно-определяемой сети и о том, что Nicira, ставшая VMware NSX, сделала для индустрии виртуализации. Мы делаем то же самое для собственного облака, где это сочетание облачной инфраструктуры или общедоступной облачной инфраструктуры, а также локальной инфраструктуры. И мы решаем варианты использования сети, безопасности и наблюдения с помощью этого на уровне инфраструктуры.

И только что выпущенная Cilium Service Mesh — это эволюция этих возможностей?

В настоящее время, примерно год назад, происходит столкновение двух пространств. То, что Cilium делала до сих пор, было сосредоточено на сетях, виртуализированных сетях, а затем на облачных сетях, но по-прежнему на сетях. Но затем, идя сверху вниз, команды приложений в Twitter и Google занимались сервисная сетка вещи — сначала в приложении, а затем модель на основе sidecar, модель на основе прокси, что нравится проектам Istio доставлять. И теперь эти два слоя сближаются, потому что традиционные предприятия приходят в облачный мир, и у них есть требования к корпоративной сети, но их командам разработчиков также нужна сервисная сетка. 

Gartner называет этот новый уровень «сервисным соединением» — посмотрим, приживется ли этот термин, — но, по сути, это уровень, который включает в себя часть корпоративной сети и часть сервисной сетки, которая исходит от групп приложений. И поскольку этого требуют клиенты, мы добавили возможности в сам Cilium. Так что, по сути, Cilium идет вверх со стороны корпоративной сети, а сервисные сетки идут вниз, в большую часть сети.

Почему так много внимания уделяется сетевому уровню и сервисной сетке стека Kubernetes?

Поскольку при желании работать в нескольких облаках и разбивать приложения на контейнеры уровень подключения стал центральным. То, что раньше было, возможно, межпроцессным взаимодействием и промежуточным программным обеспечением, теперь стало сетью, поэтому сеть становится абсолютно необходимой для того, чтобы приложения могли общаться друг с другом и для передачи данных. 

И в облаке, в частности, мультиоблако становится абсолютно необходимым. Все облачные провайдеры имеют свои собственные сетевые уровни, но, конечно же, адаптированные к своим облакам. У них есть локальные предложения, но они не являются мультиоблачными. Cilium и eBPF обеспечивают этот многооблачный независимый слой. В локальной среде он ведет себя точно так же, как и в общедоступном облаке. Несколько поставщиков общедоступных облаков используют Cilium для своих управляемых предложений Kubernetes, а телекоммуникационные компании используют его для локальной инфраструктуры 5G. Речь идет о том, чтобы говорить на обоих языках и соединять эти миры вместе.

Вот почему этому уделяется так много внимания: потому что один из самых простых способов для облачных провайдеров заблокировать клиентов — это владеть этим уровнем подключения. Я думаю, что с точки зрения стратегической инфраструктуры, точно так же, как уровень виртуализации был ключевым, теперь уровень подключения и сети является абсолютно ключевым.

Источником [будущих] инноваций будет открытый исходный код, а клиентами и пользователями, формирующими спрос, будут компании на один уровень ниже гиперскейлеров — уже крупные компании, которые по-прежнему очень революционны.

На данный момент Kubernetes довольно широко принят и принят, но в некоторых кругах все еще говорят, что это излишество. Как вы думаете, для кого предназначен Kubernetes и облачная экосистема в целом?

Это для современных групп приложений. Я думаю, пришло осознание того, что если вы хотите привлечь современные команды приложений и иметь возможность быстро выйти на рынок, вам необходимо предоставить им облачную инфраструктуру. Мы часто видим прототипирование — начальное, до MVP, даже проверку концепции или внутреннюю продажу — на бессерверных платформах, что-то вроде Lambda. А затем в Kubernetes, потому что команды приложений могут напрямую владеть инфраструктурой. А затем, когда он переходит в производство, они переходят к корпоративным, локальным дистрибутивам Kubernetes. Но на самом деле это относительно небольшая часть всей инфраструктуры, может быть однозначный или двузначный процент. 

Тем не менее, это явно будет новый стандарт. Точно так же, как внедрение виртуализации изначально было очень медленным, и люди говорили, что это излишество — но со временем, конечно, оно начало заменять большинство вещей — мы увидим то же самое здесь. Или так же, как с современными языками. Люди говорили, что Java — это излишество, и, вероятно, это все еще так для многих приложений, но было время, когда было очень трудно заниматься разработкой каких-либо приложений за пределами Java, потому что это то, на чем могло писать большинство разработчиков приложений. Это верно для современных команд разработчиков приложений: они будут ожидать, что Kubernetes будет рядом, чтобы разрабатывать более гибко и быстро выводить продукт на рынок.

С точки зрения инфраструктуры это может быть излишним, но если альтернативой является переписывание приложения с бессерверного на локальное, это серьезная задача. Так что Kubernetes — это золотая середина, что очень привлекательно. 

Как насчет идеи о том, что Kubernetes все еще нуждается в лучшем опыте разработчиков?

Если мы посмотрим на исходный OpenShift до того, как он был перебазирован на Kubernetes, он был таким. Это было еще ближе к команде приложений и было еще лучше для разработчиков приложений. Вы можете нажать на Git, и он автоматически развернется. Heroku тоже пробовал это, но на основе SaaS. 

Kubernetes сделал шаг назад и сказал: «Нам нужно сохранить в нем некоторые операционные аспекты и сделать его немного ближе к тому, что ожидает системный администратор. Мы не можем быть адаптированы только к приложениям». Это золотая середина: оно должно быть достаточно привлекательным для команд разработчиков, но при этом должна быть возможность запускать это приложение вне определенной среды и чтобы им управляли люди, не являющиеся разработчиками приложений.

Я бы сказал, что самым большим шагом между Docker и Kubernetes было то, что Docker был полностью ориентирован на опыт разработчиков. Он решил эту часть, но не решил часть экосистемы общедоступного облака.

Как мы дошли до этого момента? Было ли это естественной эволюцией от платформы как услуги (PaaS) и контейнеров приложений?

Это были образы Docker и аспект упаковки Docker. Старая школа заключалась в том, как развертывать виртуальные машины, и вокруг этого были все виды автоматизации. А еще было то, что Facebook делал с Tupperware — очень индивидуально и для действительно больших масштабов. А затем появился Docker и, по сути, предоставил этот образ контейнера, и каждый мог обращаться с ним как с миниатюрной виртуальной машиной. Теперь я могу распространять свое приложение, и вместо виртуального образа размером 600 МБ это контейнер размером 10 МБ. Но вы можете относиться к нему так же, в нем есть все, что нужно. 

Это открыло возможность использовать оркестратор, такой как Kubernetes, который по-прежнему позволяет вам обрабатывать приложения как мини-виртуальные машины, а затем делать еще один шаг и фактически рассматривать их как микросервисы. Это позволяет вам делать и то, и другое.

Я бы сказал, что самым большим шагом между Docker и Kubernetes было то, что Docker был полностью ориентирован на опыт разработчиков. Он решил эту часть, но не решил часть экосистемы общедоступного облака. У него не было тесной интеграции с облачными провайдерами, или она обязательно хотела этого. Kubernetes решил эту проблему. 

Кто, по вашему мнению, использует Kubernetes внутри компаний? Это отдельные прикладные группы?

С облачными технологиями произошел интересный сдвиг, который заключается в росте «платформенной команды», как я это назову. Они не прикладные инженеры. У них есть немного знаний о сетевых операциях и довольно много знаний о безопасности. У них есть знания SRE, и они знают, как делать облачную автоматизацию. Они предоставляют платформу для групп приложений и относятся к этим группам приложений как к своим клиентам.

Платформенные команды — это те, кто покупает Kubernetes и связанные с ним технологии, которые они используют, потому что перед ними стоит задача предоставить инфраструктуру следующего поколения, чтобы сделать современные команды приложений счастливыми.

Я думаю, что определенно есть место для бессерверных технологий, особенно для очень быстрой разработки приложений. Но на предприятиях мы видим облачные технологии как новый уровень поверх виртуализации.

Это новый покупатель или новая команда? Или команды платформы похожи на то, что существует внутри таких мест, как Google или Facebook, и теперь становится мейнстримом?

В основном это новая команда. Я думаю, что они в какой-то степени похожи на команды SRE в Google и Facebook. Тем не менее, команды приложений, вероятно, владеют большей частью развертывания приложений на предприятиях, потому что у предприятий нет такого четкого различия между инженерами-программистами и SRE, как в Google и Facebook. Я бы сказал, что эта эволюция очень похожа на то, как у вас были группы виртуализации, а затем многие сетевые операции мигрировали — или развивались или развивались — из-за сети. аппаратные средства быть о сети виртуализации. И эти команды, например, начали эксплуатировать VMware NSX. То же самое происходит и здесь. 

Хотя, это не обязательно новый бюджет. Мы видим, например, что бюджеты переходят от безопасности и сетей к этой платформенной команде, поскольку расходы на облачные технологии увеличиваются, а на сетевое оборудование тратится меньше. Они часто работают с командой безопасности и с командой сетевых операций, чтобы получить поддержку, но на самом деле они владеют довольно значительным бюджетом.

Каким ты видишь Фонд облачных вычислений развивается, и всегда ли Kubernetes будет в центре этого — или движения в облаке в целом?

Kubernetes — это то, что зажгло CNCF, и в первые пару лет все было связано с Kubernetes и общедоступным облаком. Примерно год назад мы увидели, что теперь речь идет не только о Kubernetes, но и о нативном облаке. Принципы. На самом деле это означает, что это уже не обязательно облако, даже частное облако. Часто это даже традиционная корпоративная сеть, скучная локальная инфраструктура, серверы без ПО и все такое, но со встроенными облачными принципами. 

Новая норма теперь является гибридной и включает несколько поставщиков общедоступных облаков, а также локальную инфраструктуру. Компании хотят обеспечить такую ​​же гибкость разработчика приложений, или обеспечить наблюдаемость с помощью современных облачных собственных инструментов, или обеспечить безопасность с помощью современных облачных собственных инструментов — например, аутентификацию, а не просто сегментацию или принудительное применение на основе удостоверений — все эти новые облачные концепции на существующая инфраструктура. 

Мы наблюдаем очень высокий спрос на то, чтобы по-прежнему подключаться к старому миру и использовать MPLS, VLAN, sFlow и NetFlow — весь существующий набор корпоративных требований. Никто из них не ушел.

По прошествии примерно десяти лет облачное пространство не кажется чем-то причудливым. Насколько у него есть возможности для дальнейшего развития?

Определенно было время, когда люди думали: «О, Kubernetes, вероятно, недолговечен, а бессерверные технологии станут следующим уровнем». Или: «Kubernetes похож на OpenStack. Или: «Он исчезнет и станет частью реализации». Но этого не произошло. 

Я думаю, что определенно есть место для бессерверных технологий, особенно для очень быстрой разработки приложений. Но на предприятиях мы рассматриваем облачные технологии как новый уровень поверх виртуализации, и мы считаем, что у них такой же срок годности, как и у виртуализации. Это означает, что мы находимся в самом начале миграции в облако.

Какие большие проблемы еще предстоит решить на уровне инфраструктуры?

Мы видим предприятия в ситуации, когда внезапно, хотят они того или нет, им нужна мультиоблачная стратегия. Поскольку у них также есть локальная инфраструктура, теперь им нужна стратегия гибридного облака. И им нужно выяснить, как выполнять функции безопасности и другие функции повсеместно в этой инфраструктуре, не привязываясь к конкретному общедоступному облаку. 

Итак, это следующая большая проблема: кто будет тем независимым уровнем для мультиоблачных и облачных технологий, как то, чем стала VMware? Кто станет VMware для облачных технологий?

Я думаю, пришло осознание того, что если вы хотите привлечь современные команды приложений и иметь возможность быстро выйти на рынок, вам необходимо предоставить им облачную инфраструктуру.

И хотя внедрение облачных технологий могло быть относительно легким для современных веб-компаний, которые были первыми пользователями, проблема, с вашей точки зрения, заключается в создании новых технологий, которые устранят разрыв между современным миром и существующими корпоративными инструментами и системами?

Сложность заключается в том, что современные команды разработчиков приложений привыкли к тому, что уровень инфраструктуры развивается так же быстро, как и они. И это вынуждало уровень инфраструктуры быть еще более программируемым, более регулируемым. Вот почему мы на самом деле видим сетевой уровень и уровень безопасности поверх уровня облачной сети. Но теперь к нам приходят предприятия, и мы видим очень высокий спрос на то, чтобы по-прежнему подключаться к старому миру и говорить о MPLS, VLAN, sFlow и NetFlow — весь существующий набор корпоративных требований. Ни один из них никуда не делся, все правила соблюдения остались прежними. А также даже некоторые из современных SaaS-компаний теперь сталкиваются с этими проблемами по мере того, как они становятся больше и заботятся о соблюдении нормативных требований. и так далее. 

С технологической точки зрения речь идет о том, как связать этот новый облачный мир с существующими корпоративными требованиями. Потому что многие из этих проблем были скрыты поставщиками общедоступных облаков. Поставщики общедоступных облаков решили проблемы соответствия, но они не открыли исходный код и не опубликовали ничего из этого; они решили это самостоятельно. Это часть ценности облака. Теперь предприятиям необходимо перестроить и купить это, если они не хотят ограничивать себя предложениями общедоступного облака.

Откуда, по вашему мнению, придет следующая волна облачных инноваций? Это все еще исходит от такой компании, как Google, или есть новый тип компании, возглавляющей зарядку?

Это очень интересно. Я бы сказал, что это, вероятно, не исходит от Google и Facebook. Источником инноваций будет открытый исходный код, а клиентами и пользователями, формирующими спрос, будут компании на один уровень ниже гиперскейлеров — уже крупные компании, которые по-прежнему очень разрушительны, такие как Adobe, Shopify или GitHub. Но также и компании, которые рискуют быть разрушенными технологиями, такие как финансовые услуги, страховые компании и телекоммуникационные компании. Все эти компании заинтересованы в стандартизации инфраструктуры с повторяемыми моделями разработки и инфраструктуры.

Опубликовано: 26 июля, 2022