Что KubeCon + CloudNativeCon говорит нам о контейнерах в 2019 году

KubeCon + CloudNativeCon прошел в Сиэтле в прошлом месяце и собрал в два раза больше участников, чем предыдущая конференция, и все они были посвящены совершенно новому видению Kubernetes и проектов в его среде. Они не были разочарованы, и KubeCon + CloudNativeCon Seattle 2018 был направлен на то, чтобы двигаться вперед и просто покончить со старыми способами, такими как попытка запустить Kubernetes самостоятельно. Новое видение заключается в том, чтобы не изобретать велосипед, никогда не переписывать код и иметь кристально ясное представление о том, где вы и ваши инструменты вписываетесь в эту гигантскую штуку, называемую стеком Kubernetes.

Детализация на KubeCon: стек CNCF

Келси Хайтауэр из Google Cloud Platform отметил в своем интервью на KubeCon, что так называемый «стек Kubernetes» — это, по сути, просто Kubernetes в основе, а затем надстройка над ним, и хотя Kubernetes хорош сам по себе, все еще есть много пробелы в стеке. До недавнего времени это были пробелы, которые потребители должны были заполнять самостоятельно с помощью того или иного стула с открытым исходным кодом, но теперь CloudNative Computing Foundation — это место, где можно найти эти пробелы. Он объяснил, как люди гордились созданием своих собственных дистрибутивов Linux до тех пор, пока не поняли, что это пустая трата времени, и вместо этого просто переключились на RedHat или Ubuntu.

Вот где сейчас находится Kubernetes, и вместо того, чтобы создавать собственные стеки Kubernetes с инструментами с открытым исходным кодом, потребители находят большую ценность в использовании всего этого в качестве услуги, чтобы они могли сосредоточиться на текущих задачах. Что касается инструментов в среде, все, что вам нужно или вы планируете построить, вероятно, уже было создано кем-то в какой-то момент, и CNCF — это универсальный магазин, где можно это выяснить. Скорее всего, вы можете прекратить все, что вы делаете, и просто загрузить что-нибудь вместо этого.

Нативные и бессерверные

Бессерверные технологии определенно стали популярным словом на конференции, и несколько поставщиков, включая Red Hat, Google, SAP и IBM, объявили о том, что они объединяются для поддержки проекта Knative с открытым исходным кодом. Тот факт, что IBM делает это, несмотря на свой собственный проект OpenWhisk, является прекрасным примером того, в каком состоянии сегодня находится предприятие, и того, как, казалось бы, конкурирующие инструменты служат для поддержки и даже дополнения друг друга. Бессерверная технология, которую часто называют «Функции как услуга», позволяет организациям выполнять функции, вызываемые триггерами, что устраняет необходимость в предварительной подготовке долговременного постоянного сервера.

Проект Knative — это, по сути, бессерверная платформа с открытым исходным кодом, которая обеспечивает общую основу для всех, кто хочет работать без сервера. Это достигается за счет предоставления разработчикам возможности создавать, обслуживать и управлять бессерверными приложениями на основе контейнеров, которые можно легко перемещать между облачными провайдерами. Однако Knative все еще не завершен и не взаимодействует с функциями Azure или функциями AWS Lambda. Кроме того, все еще необходимы «улучшения», чтобы полностью включить открытую экосистему для бессерверных вычислений. Хотя это может быть не то, что Келси Хайтауэр называет золотым стандартом в бессерверной технологии, также известной как AWS Lambda, несколько основных разработчиков Knative объявили, что они, тем не менее, внедрили его в свои облачные решения.

Мультиоблако

Теперь разработчикам нужен способ создания систем на основе функций, обладающих гибкостью для перемещения между облаками или локальными средами, отсюда и ажиотаж вокруг гибридных или мультиоблачных сред. Основное уникальное торговое предложение Kubernetes заключается в том, что вы можете использовать его где угодно, и главный вопрос, на который нужно ответить, заключается в том, действительно ли Kubernetes поддерживает мультиоблако? Можно ли перенести Kubernetes из Azure в AWS, сохранив при этом те же элементы управления и конфигурации? Ответ заключается в уровнях, и хотя первые несколько уровней, которые включают перемещение контейнеров и их журналов, защиту доступа и балансировку нагрузки, теперь довольно стандартны, такие вещи, как CI/CD, который является следующим уровнем, все еще не являются стандартными. Это связано с тем, что в настоящее время все облака имеют разные решения для управления идентификацией и доступом (IAM) в дополнение к различным функциям безопасности и сети.

Сохранение локальных и облачных сред как можно более похожими может избавить ИТ-команды от мучительного обучения. На конференции было представлено довольно много бессерверных платформ, одной из которых является контейнерная платформа Cisco, которая является локальной, но выглядит идентично тому, что вы найдете в средах Kubernetes в AWS или Google. IBM Multicloud Manager — еще один отличный вариант для пользователей гибридного облака, поскольку он позволяет клиентам управлять своими кластерами Kubernetes и перемещать их между разными облаками и центрами обработки данных с помощью единой панели управления. Кроме того, Arista интегрировала контейнерную версию своей сетевой операционной системы с программным обеспечением Red Hat и Tigera для поддержки контейнеров, работающих в общедоступных, частных и гибридных облаках.

Контейнеры и виртуальные машины

Теперь, хотя сами контейнеры долгое время будут довольно стандартными, то, как мы их воспринимаем и упаковываем, меняется. В 2019 году именно облачные провайдеры найдут ценность в обеспечении оркестрации контейнеров или Kubernetes как услуги, которая включает в себя его запуск, исправление и обновление. Потребители, которые использовали Kubernetes самостоятельно, теперь понимают, что Kubernetes — это только начало и средство для облегчения других частей, таких как инструменты Knative или CI / CD, поэтому находят ценность в использовании его как услуги.

Хотя первоначальной тенденцией контейнеров было создание их на базе Docker, вскоре потребители начали понимать, что существует значительный компромисс в отношении безопасности. Поскольку виртуальные машины уже были известны как безопасные, многие люди использовали их в качестве контейнеров. Теперь иметь виртуальную машину для каждого контейнера может показаться огромной тратой ресурсов, но это были традиционные виртуальные машины, а новые оптимизированы для контейнеров и загружаются за миллисекунды. Одним из них, упомянутых на конференции, был FireCracker, который позволяет запускать легковесные микровиртуальные машины (microVM) и реализует монитор виртуальных машин (VMM), который использует виртуальную машину на основе ядра Linux (KVM).

Легендарный «конец игры»

В 2019 году контейнерная среда становится настолько зрелой, что самой важной задачей является определение того, что вы можете потреблять как услугу, а что вам нужно создать самостоятельно. В аккуратной демонстрации во время своего основного доклада на KubeCon Хайтауэр сначала запустил простую функцию в Kubernetes, а затем извлек двоичные файлы, чтобы запустить их в Lambda, подчеркнув, что переписывать код никогда не нужно. Он также шутит о том, что любой, у кого есть важная задача, должен сначала изучить Docker, а затем Kubernetes, а затем кучу других вещей, прежде чем он сможет что-то сделать, поэтому будущее должно заключаться в том, чтобы надеть капюшон на все это и назвать это. инфраструктура.

Выяснение того, что вы делаете неправильно, и поиск того, кто может сделать это лучше, кажется достаточно простой игрой, но, к сожалению, это не всегда было так просто, поскольку не было такой ясности, как сегодня. Благодаря тому, что CNCF устанавливает стандарты для различных уровней стека, становится намного проще понять, где именно вы подходите. Итог: 2019 год будет посвящен поиску поставщиков и тому, чтобы не тратить время ни на что, кроме завершения игры.