Мы с ребятами из Datawire недавно вернулись с потрясающих конференций KubeCon и CloudNativeCon ^[1] в Барселоне. Мы участвовали в 6 выступлениях на KubeCon, раздали на своем стенде кучу классных (без ложной скромности) футболок, пообщались с десятками людей и посетили крутые выступления. На KubeCon EU было столько всего интересного, что я решил написать пост с ключевыми итогами.

И вот какие выводы я сделал (не в порядке важности):

1. Многоплатформенность и гибридное облако (все еще) популярны.
2. Объединение технологий набирает обороты.
3. Анонс Service Mesh Interface (SMI): следите за новостями.
4. (Туманное?) будущее Istio.
5. Политика как код поднимается по стеку.
6. Облачный DevEx по-прежнему не обходится без проблем.
7. Компании (все еще) на начальных этапах внедрения технологий.
8. Локальный Kubernetes реален (но заковырист).
9. Считайте кластеры стадом.
10. Успех Kubernetes по-прежнему зависит от сообществ.

Многоплатформенность и гибридное облако (все еще) популярны

На конференции было несколько выступлений ^[2] о мультиоблаках (и соответствующих вопросах: сеть ^[3] и безопасность ^[4]), но я заметил, что на многих вводных слайдах на докладах для конечных пользователей изображалась инфраструктура или архитектура, где было не меньше двух облачных поставщиков. На стенде Datawire мы говорили о тенденциях перехода на мультиоблака чаще, чем на предыдущих конференциях.

Успех Kubernetes значительно упростил мультиоблачную стратегию, предоставив отличную абстракцию для поставок и оркестрации. В последние два года функционал и API Kubernetes стали гораздо стабильнее, и многие поставщики используют эту платформу. Улучшились возможности управления хранением и сетевые подключения, и в этой области достаточно годных коммерческих продуктов и решений с открытым кодом. В своем докладе «Развенчание мифа: в Kubernetes сложно организовать хранение» ^[5] Саад Али (Saad Ali), senior-разработчик Google, интересно рассказал о хранилищах, а Эран Янай (Eran Yanay) из Twistlock представил хороший обзор подключений на лекции «Подключения в Kubernetes: как написать плагин CNI с нуля» ^[6].

Особенно мне понравились разные разговоры о сочетании Azure с имеющимися локальными инфраструктурами. Недавно я написал в InfoQ статью о том, как многоплатформенная архитектура связана с работой по модернизации приложений ^[7]. Я говорил о трех подходах: расширение облака до датацентра, как в Azure Stack ^[8], AWS Outposts ^[9] и GCP Anthos ^[10]; обеспечение однородности структуры поставок (оркестрации) среди несколько поставщиков или облаков с помощью такой платформы, как Kubernetes; обеспечение однородности структуры сервисов (сети) с помощью API-шлюза и service mesh, вроде Ambassador и Consul ^[11].

Мы в Datawire вовсю работаем над API-шлюзами и, очевидно, склоняемся к гибкому третьему подходу. Это позволяет постепенно и безопасно мигрировать из традиционного стека ближе к облаку. Мы с Ником Джексоном (Nic Jackson) из HashiCorp вместе выступали на KubeCon с лекцией «Обеспечение облачного взаимодействия от конечного пользователя до сервиса» ^[12].

Объединение технологий набирает обороты

Многие поставщики предлагают пакеты с инструментами Kubernetes и дополнительными технологиями. Я обратил внимание на анонс Rio MicroPaaS ^[13] от Rancher Labs — в последнее время они выпускают интересные штуки. Я написал в InfoQ обзор о Submariner ^[14], который соединяет несколько кластеров, и облегченном дистрибутиве Kubernetes — k3s ^[15]. И мне не терпится изучить Kubernetes Toolkit от Supergiant ^[16]. Это «набор утилит для автоматизации поставок и управления кластерами Kubernetes в облаке».

В корпоративной среде пакеты направлены на хранение. Хороший пример — VMware Velero 1.0 ^[17] (на основе наработок, купленных у Heptio ^[18]), с которым разработчики могут резервировать и переносить ресурсы и постоянные тома Kubernetes.

На конференции было представлено много других операторов для хранения и управления данными в Kubernetes, например CockroachDB ^[19], ElasticCloud ^[20] и StorageOS ^[21]. Роб Шумски (Rob Szumski) из Red Hat в своем выступлении говорил об эволюции Operator SDK и сообщества ^[22] и представил Operator Hub ^[23]. Судя по всему, поддержка операторов — одно из главных преимуществ корпоративного пакета OpenShift от Red Hat ^[24].

Анонс Service Mesh Interface (SMI): следите за новостями

Анонс Service Mesh Interface (SMI) ^[25] в докладе Гейба Монроя (Gabe Monroy) из Microsoft ^[26] определенно наделал много шума ^[27]. Никто не станет отрицать, что service mesh в последнее время очень популярна, и SMI объединит главные фичи в стандартный интерфейс и предоставит «набор распространенных переносимых API, которые обеспечат взаимную совместимость разных технологий service mesh, включая Istio, Linkerd и Consul Connect».

В демонстрации ^[28] Гейб показывает основные возможности: политика трафика для применения таких политик, как удостоверения и транзитное шифрование между сервисами (на примере Consul ^[29] и Intention); мониторинг трафика — сбор главных метрик, например число ошибок и задержки при обмене данными между сервисами (на примере Linkerd ^[30] и сервера метрик SMI); и управление трафиком — измерение и перенос трафика между разными сервисами (на примере Istio ^[31] с Weaveworks Flagger ^[32]).

Было бы интересно определить интерфейс в этой среде с высокой конкуренцией, но я зашел на веб-сайт SMI ^[33], почитал спецификации ^[34] и подозреваю, что эта абстракция может сводиться к минимальному набору общих функций (этого всегда сложно избежать в таких решениях, как я знаю по своему опыту работы над Java Community Process). Потенциальная опасность в том, что хотя все будут применять эту спецификацию, поставщики будут предоставлять самые интересные функции через кастомные расширения.

Я поговорил об этом с ребятами из Datawire и думаю, что service mesh существует на рынке, который работает по принципу «победитель получает все», поэтому в итоге SMI отвлечет на себя какое-то внимание, а другая технология просто появится и соберет все плоды (примерно так поступил Kubernetes по отношению к Mesos, Docker Swarm и т. д.). Следите за новостями, посмотрим, что получится.

(Туманное?) будущее Istio

Хотя о service mesh говорилось много, тема Istio — пожалуй, самой известной service mesh — вызывала смешанные чувства. Кто-то считает, что Istio и service mesh — синонимы (как Docker и контейнеры) и видит только решение, а не проблемы; кому-то нравятся функции Istio; а кто-то не особо доволен этой технологией.

Недавно было много дискуссий о бенчмаркинге Istio ^[35], и в выпуске 1.1 намеренно решаются ^[36] некоторые проблемы с компонентом Mixer ^[37]. Что интересно, я говорил с разными людьми, которые несколько месяцев оценивали Istio (одна команда потратила на это почти год), и они утверждают, что Istio по-прежнему очень сложный и ресурсоемкий. Кто-то говорит, что выпуск размещенного Istio через GKE ^[38] решил много проблем, но не все могут использовать GCP.

У представителя Google спросили, что будет с Istio, не станет ли он проектом CNCF. Ответ был очень гладким, но туманным: сейчас у Istio открытый код, люди могут работать над ним, а насчет CNCF, поживем — увидим. Пока только Linkerd ^[30] является официальным проектом по service mesh в CNCF, хотя Envoy Proxy ^[39] тоже проект CNCF (и на нем основаны Istio, API-шлюз Ambassador и много других технологий). На нашем стенде многие спрашивали об интеграции Linkerd 2 и Ambassador ^[40] (спасибо Оливеру Гоулду (Oliver Gould), техдиректору Buoyant, который упомянул Ambassador в своем подробном обзоре Linkerd ^[41]), и участникам нравится простота использования Linkerd.

Кстати, я обрадовался, когда ребята из Knative в своем выступлении «Расширение Knative для веселья и прибыли» ^[42] показали, что заменили Istio на Ambassador в Knative, потому что Ambassador проще использовать (обратите внимание на их футболки на фото и почитайте соответствующую задачу на GitHub: «Удаление Istio как зависимости» ^[43]):

Политика как код поднимается по стеку

В нашей отрасли все уже привыкли представлять политику как код в связи с системой управления идентификацией и доступом (IAM), настройкой iptable, списками ACL и группами безопасности, но пока это осуществляется на низком уровне, близко к инфраструктуре. Когда я услышал, как ребята из Netflix рассказывали об использовании Open Policy Agent (OPA) на KubeCon в Остине в 2017 году ^[44], мне стало интересно, как с помощью этого проекта определить политику как код.

На этом KubeCon я видел, что политика как код поднимается по уровням, и все больше людей обсуждают использование OPA, например во время доклада Риты Чжан (Rita Zhang) и Макса Смайта (Max Smythe) ^[45], и подробнее — на докладе «Модульное тестирование конфигураций Kubernetes с помощью Open Policy Agent» ^[46] Гарета Рашгроува (Gareth Rushgrove) (у него чутье на проекты с большим потенциалом).

Я уже давно слежу, как Sentinel от HashiCorp ^[47] определяет политику на уровне инфраструктуры, а теперь использование Intention в Consul service mesh ^[48] поднимает эту технологию еще выше по стеку. С помощью Intention политику можно определить на уровне сервисов. Например, сервис A может общаться с сервисом B, но не с сервисом C. Когда мы с командой Datawire начали сотрудничать с HashiCorp для интеграции Ambassador и Consul, мы быстро поняли, какие преимущества дает сочетание Intention с mTLS (для идентификации сервисов) и списками ACL (чтобы предотвратить спуфинг и для многоуровневой защиты).

Облачный DevEx по-прежнему не обходится без проблем

Во время заключительного слова — «Не переставайте верить» ^[49] — Брайан Лайлз (Bryan Liles), senior-разработчик в VMware, говорил о важности рабочего процесса разработчика (developer experience, DevEx), и эта тема поднималась на нескольких выступлениях. Kubernetes и его экосистема неплохо развиваются, но внутренний цикл разработки ^[50] и интеграция пайплайнов поставки с Kubernetes определенно нуждаются в доработке.

Об этом говорил Кристиан Роджиа (Christian Roggia) в своем докладе «Воспроизводимые разработки и поставки с Bazel и Telepresence» ^[51]. Он рассказал, как Engel and Volkers используют инструмент Telepresence в CNCF во внутреннем цикле разработки, чтобы не приходилось собирать и отправлять контейнер после каждого изменения.

^[52]

Там было интересное групповое обсуждение с ребятами из Weaveworks и Cloudbees, «GitOps и лучшие практики для CI/CD в облаке» ^[53], где подробно рассматривалась непрерывная поставка. GitOps довольно успешно развивается, так что при работе в Datawire и на конференциях я часто встречаю команды, которые используют этот подход к настройке и поставке. Например, Джонатан и Родриго упомянули об этом в своем увлекательном докладе «Масштабирование граничных операций в Onefootball с помощью Ambassador: от 0 до 6000 запросов в секунду» ^[54]:

Компании (все еще) на начальных этапах внедрения технологий

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

Шерил Хан (Cheryl Hung), директор по экосистеме в CNCF, провела несколько обсуждений, включая «Трансформация компании с помощью облачных технологий» ^[55], и было интересно послушать таких первооткрывателей, как Intuit. Лора Рехорст (Laura Rehorst) в своем докладе «От COBOL до Kubernetes: путешествие в облако для банка с 250-летней историей» ^[56] рассказала, как банк ABN AMRO применял планирование и стратегические ресурсы.

Мы разместили API-шлюз Ambassador в самом центре стенда, поэтому чаще всего нам задавали вопросы о том, чем современный шлюз для Kubernetes отличается от существующих решений по управлению полным жизненным циклом API. Сейчас мы работаем над следующим коммерческим продуктом в этой области — Ambassador Code ^[57], и было интересно обсуждать с разработчиками требования и ожидания в связи с новыми облачными парадигмами.

Локальный Kubernetes реален (но заковырист)

Было несколько анонсов по локальной установке Kubernetes, в частности, в корпоративной среде, например Интеграция Kublr VMware ^[58] и VMware и kubeadm ^[59]. Red Hat участвовали во всех обсуждениях OpenShift, и я не раз слышал, как людям нравятся абстракции OpenShift, и потенциальная зависимость компенсируется улучшенным рабочим процессом и соглашениями SLA, которые идут в комплекте.

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

Считайте кластеры стадом

В своем интересном докладе «Как Spotify нечаянно удалили все кластеры Kube, а пользователи ничего не заметили» ^[60], разработчик Spotify Дэвид Ся (David Xia) рассказал, чему они научились, когда удалили несколько (!) рабочих кластеров. Я не буду описывать всю ситуацию (посмотрите видео), но главным посылом Дэвида было относиться к кластерам Kubernetes, как к стаду. Думаю, многие из нас слышали эту фразу: «Относитесь к серверам, как к стаду, а не любимым питомцам». Но Дэвид считает, что по мере развития вычислительной абстракции (когда мы воспринимаем «Датацентр как компьютер» ^[61]), мы должны применять тот же принцип и не слишком привязываться к нашей инфраструктуре.

В своем докладе Совместное развитие Kubernetes и сетей GCP ^[62] Пурви Десай (Purvi Desai) и Тим Хокин (Tim Hockin) предлагают организациям постоянно уничтожать, воссоздавать и переносить кластеры Kubernetes, чтобы не сродниться с ними. Главный аргумент: если вы постоянно не проверяете возможность восстановить кластеры и перенести данные, возможно, вам это не удастся, когда возникнет проблема. Представьте себе, что это хаос-инжиниринг ^[63] для кластеров.

Успех Kubernetes по-прежнему зависит от сообществ.

В докладах, за обедом и повсюду одной из ключевых тем была важность сообщества и разнообразия. В четверг утром Лукас Кэльдстрём (Lucas Käldström) и Никита Рагунат (Nikhita Raghunath) в своем докладе «Первые шаги в сообществе Kubernetes» ^[64] не только рассказали две удивительные истории, но и разбили все оправдания тех, кто не участвует в опенсорс-проектах и проектах CNCF.

Шерил Хан (Cheryl Hung) в своем докладе «2,66 миллиона» ^[65] поблагодарила за огромный вклад в проект и привела веский аргумент в пользу разнообразия и сильного лидерства. Я удивился, когда узнал, что на пожертвования от разных организаций в составе CNCF было учреждено более 300 стипендий, поддерживающих разнообразие.

Заключение о KubeCon EU

Еще раз спасибо всем, с кем мы пообщались в Барселоне. Если вам не удалось побывать на наших презентациях, привожу полный список:

• Создание панели управления на границе с использованием Kubernetes и Envoy ^[66]: Флинн из Datawire рассказывает об эволюции API-шлюза Ambassador и его архитектуре.
• Обеспечение облачного взаимодействия от конечного пользователя до сервиса ^[67]: Ник Джексон (Nic Jackson) из HashiCorp и Дэниел Брайант (Daniel Bryant) из Datawire обсуждают интеграцию API-шлюза Ambassador с Consul service mesh.
• Масштабирование граничных операций в Onefootball с помощью Ambassador: от 0 до 6000 запросов в секунду ^[54]: SRE-инженеры Onefootball рассказывают, как использовали Ambassador в продакшене.
• Расширение Knative для веселья и прибыли ^[68]: команда Google Knative рассказывает о платформе Knative и показывает, как они использовали Ambassador.
• Telepresence: быстрая разработка рабочих процессов для Kubernetes ^[69]: обсуждение прошлого, настоящего и будущего Telepresence.
• Воспроизводимые разработки и поставки с Bazel и Telepresence ^[70]: Кристиан Роджиа (Christian Roggia) рассказывает, какой подход Engel & Volkers используют для разработки микросервисов с Telepresence.

Мы в Datawire отслеживаем эти тенденции, чтобы Ambassador и дальше развивался и соответствовал изменчивым потребностям облачных разработчиков. Если вы не использовали Ambassador в последнее время, попробуйте наш последний выпуск — Ambassador 0.70 ^[71] со встроенной поддержкой Consul service mesh, поддержкой пользовательского определения ресурсов и многими другими фичами.

Если возникли проблемы с обновлением, создайте задачу ^[72] или найдите нас в Slack ^[73]. Если нужна готовая установка Ambassador с интегрированной аутентификацией, ограничением скорости и поддержкой, попробуйте наш коммерческий продукт Ambassador Pro ^[57].

А если вам нравится работать с Ambassador, расскажите нам об этом. Оставьте комментарий под статьей или напишите @getambassadorio ^[74] в Twitter.

Автор: nAbdullin

Источник ^[75]