Мы с ребятами из Datawire недавно вернулись с потрясающих конференций KubeCon и CloudNativeCon в Барселоне. Мы участвовали в 6 выступлениях на KubeCon, раздали на своем стенде кучу классных (без ложной скромности) футболок, пообщались с десятками людей и посетили крутые выступления. На KubeCon EU было столько всего интересного, что я решил написать пост с ключевыми итогами.
И вот какие выводы я сделал (не в порядке важности):
- Многоплатформенность и гибридное облако (все еще) популярны.
- Объединение технологий набирает обороты.
- Анонс Service Mesh Interface (SMI): следите за новостями.
- (Туманное?) будущее Istio.
- Политика как код поднимается по стеку.
- Облачный DevEx по-прежнему не обходится без проблем.
- Компании (все еще) на начальных этапах внедрения технологий.
- Локальный Kubernetes реален (но заковырист).
- Считайте кластеры стадом.
- Успех Kubernetes по-прежнему зависит от сообществ.
Многоплатформенность и гибридное облако (все еще) популярны
На конференции было несколько выступлений о мультиоблаках (и соответствующих вопросах: сеть и безопасность), но я заметил, что на многих вводных слайдах на докладах для конечных пользователей изображалась инфраструктура или архитектура, где было не меньше двух облачных поставщиков. На стенде Datawire мы говорили о тенденциях перехода на мультиоблака чаще, чем на предыдущих конференциях.
Успех Kubernetes значительно упростил мультиоблачную стратегию, предоставив отличную абстракцию для поставок и оркестрации. В последние два года функционал и API Kubernetes стали гораздо стабильнее, и многие поставщики используют эту платформу. Улучшились возможности управления хранением и сетевые подключения, и в этой области достаточно годных коммерческих продуктов и решений с открытым кодом. В своем докладе «Развенчание мифа: в Kubernetes сложно организовать хранение» Саад Али (Saad Ali), senior-разработчик Google, интересно рассказал о хранилищах, а Эран Янай (Eran Yanay) из Twistlock представил хороший обзор подключений на лекции «Подключения в Kubernetes: как написать плагин CNI с нуля».
Особенно мне понравились разные разговоры о сочетании Azure с имеющимися локальными инфраструктурами. Недавно я написал в InfoQ статью о том, как многоплатформенная архитектура связана с работой по модернизации приложений. Я говорил о трех подходах: расширение облака до датацентра, как в Azure Stack, AWS Outposts и GCP Anthos; обеспечение однородности структуры поставок (оркестрации) среди несколько поставщиков или облаков с помощью такой платформы, как Kubernetes; обеспечение однородности структуры сервисов (сети) с помощью API-шлюза и service mesh, вроде Ambassador и Consul.
Мы в Datawire вовсю работаем над API-шлюзами и, очевидно, склоняемся к гибкому третьему подходу. Это позволяет постепенно и безопасно мигрировать из традиционного стека ближе к облаку. Мы с Ником Джексоном (Nic Jackson) из HashiCorp вместе выступали на KubeCon с лекцией «Обеспечение облачного взаимодействия от конечного пользователя до сервиса».
Объединение технологий набирает обороты
Многие поставщики предлагают пакеты с инструментами Kubernetes и дополнительными технологиями. Я обратил внимание на анонс Rio MicroPaaS от Rancher Labs — в последнее время они выпускают интересные штуки. Я написал в InfoQ обзор о Submariner, который соединяет несколько кластеров, и облегченном дистрибутиве Kubernetes — k3s. И мне не терпится изучить Kubernetes Toolkit от Supergiant. Это «набор утилит для автоматизации поставок и управления кластерами Kubernetes в облаке».
В корпоративной среде пакеты направлены на хранение. Хороший пример — VMware Velero 1.0 (на основе наработок, купленных у Heptio), с которым разработчики могут резервировать и переносить ресурсы и постоянные тома Kubernetes.
На конференции было представлено много других операторов для хранения и управления данными в Kubernetes, например CockroachDB, ElasticCloud и StorageOS. Роб Шумски (Rob Szumski) из Red Hat в своем выступлении говорил об эволюции Operator SDK и сообщества и представил Operator Hub. Судя по всему, поддержка операторов — одно из главных преимуществ корпоративного пакета OpenShift от Red Hat.
Анонс Service Mesh Interface (SMI): следите за новостями
Анонс Service Mesh Interface (SMI) в докладе Гейба Монроя (Gabe Monroy) из Microsoft определенно наделал много шума. Никто не станет отрицать, что service mesh в последнее время очень популярна, и SMI объединит главные фичи в стандартный интерфейс и предоставит «набор распространенных переносимых API, которые обеспечат взаимную совместимость разных технологий service mesh, включая Istio, Linkerd и Consul Connect».
В демонстрации Гейб показывает основные возможности: политика трафика для применения таких политик, как удостоверения и транзитное шифрование между сервисами (на примере Consul и Intention); мониторинг трафика — сбор главных метрик, например число ошибок и задержки при обмене данными между сервисами (на примере Linkerd и сервера метрик SMI); и управление трафиком — измерение и перенос трафика между разными сервисами (на примере Istio с Weaveworks Flagger).
Было бы интересно определить интерфейс в этой среде с высокой конкуренцией, но я зашел на веб-сайт SMI, почитал спецификации и подозреваю, что эта абстракция может сводиться к минимальному набору общих функций (этого всегда сложно избежать в таких решениях, как я знаю по своему опыту работы над Java Community Process). Потенциальная опасность в том, что хотя все будут применять эту спецификацию, поставщики будут предоставлять самые интересные функции через кастомные расширения.
Я поговорил об этом с ребятами из Datawire и думаю, что service mesh существует на рынке, который работает по принципу «победитель получает все», поэтому в итоге SMI отвлечет на себя какое-то внимание, а другая технология просто появится и соберет все плоды (примерно так поступил Kubernetes по отношению к Mesos, Docker Swarm и т. д.). Следите за новостями, посмотрим, что получится.
(Туманное?) будущее Istio
Хотя о service mesh говорилось много, тема Istio — пожалуй, самой известной service mesh — вызывала смешанные чувства. Кто-то считает, что Istio и service mesh — синонимы (как Docker и контейнеры) и видит только решение, а не проблемы; кому-то нравятся функции Istio; а кто-то не особо доволен этой технологией.
Недавно было много дискуссий о бенчмаркинге Istio, и в выпуске 1.1 намеренно решаются некоторые проблемы с компонентом Mixer. Что интересно, я говорил с разными людьми, которые несколько месяцев оценивали Istio (одна команда потратила на это почти год), и они утверждают, что Istio по-прежнему очень сложный и ресурсоемкий. Кто-то говорит, что выпуск размещенного Istio через GKE решил много проблем, но не все могут использовать GCP.
У представителя Google спросили, что будет с Istio, не станет ли он проектом CNCF. Ответ был очень гладким, но туманным: сейчас у Istio открытый код, люди могут работать над ним, а насчет CNCF, поживем — увидим. Пока только Linkerd является официальным проектом по service mesh в CNCF, хотя Envoy Proxy тоже проект CNCF (и на нем основаны Istio, API-шлюз Ambassador и много других технологий). На нашем стенде многие спрашивали об интеграции Linkerd 2 и Ambassador (спасибо Оливеру Гоулду (Oliver Gould), техдиректору Buoyant, который упомянул Ambassador в своем подробном обзоре Linkerd), и участникам нравится простота использования Linkerd.
Кстати, я обрадовался, когда ребята из Knative в своем выступлении «Расширение Knative для веселья и прибыли» показали, что заменили Istio на Ambassador в Knative, потому что Ambassador проще использовать (обратите внимание на их футболки на фото и почитайте соответствующую задачу на GitHub: «Удаление Istio как зависимости»):
Политика как код поднимается по стеку
В нашей отрасли все уже привыкли представлять политику как код в связи с системой управления идентификацией и доступом (IAM), настройкой iptable, списками ACL и группами безопасности, но пока это осуществляется на низком уровне, близко к инфраструктуре. Когда я услышал, как ребята из Netflix рассказывали об использовании Open Policy Agent (OPA) на KubeCon в Остине в 2017 году, мне стало интересно, как с помощью этого проекта определить политику как код.
На этом KubeCon я видел, что политика как код поднимается по уровням, и все больше людей обсуждают использование OPA, например во время доклада Риты Чжан (Rita Zhang) и Макса Смайта (Max Smythe), и подробнее — на докладе «Модульное тестирование конфигураций Kubernetes с помощью Open Policy Agent» Гарета Рашгроува (Gareth Rushgrove) (у него чутье на проекты с большим потенциалом).
Я уже давно слежу, как Sentinel от HashiCorp определяет политику на уровне инфраструктуры, а теперь использование Intention в Consul service mesh поднимает эту технологию еще выше по стеку. С помощью Intention политику можно определить на уровне сервисов. Например, сервис A может общаться с сервисом B, но не с сервисом C. Когда мы с командой Datawire начали сотрудничать с HashiCorp для интеграции Ambassador и Consul, мы быстро поняли, какие преимущества дает сочетание Intention с mTLS (для идентификации сервисов) и списками ACL (чтобы предотвратить спуфинг и для многоуровневой защиты).
Облачный DevEx по-прежнему не обходится без проблем
Во время заключительного слова — «Не переставайте верить» — Брайан Лайлз (Bryan Liles), senior-разработчик в VMware, говорил о важности рабочего процесса разработчика (developer experience, DevEx), и эта тема поднималась на нескольких выступлениях. Kubernetes и его экосистема неплохо развиваются, но внутренний цикл разработки и интеграция пайплайнов поставки с Kubernetes определенно нуждаются в доработке.
Об этом говорил Кристиан Роджиа (Christian Roggia) в своем докладе «Воспроизводимые разработки и поставки с Bazel и Telepresence». Он рассказал, как Engel and Volkers используют инструмент Telepresence в CNCF во внутреннем цикле разработки, чтобы не приходилось собирать и отправлять контейнер после каждого изменения.
Там было интересное групповое обсуждение с ребятами из Weaveworks и Cloudbees, «GitOps и лучшие практики для CI/CD в облаке», где подробно рассматривалась непрерывная поставка. GitOps довольно успешно развивается, так что при работе в Datawire и на конференциях я часто встречаю команды, которые используют этот подход к настройке и поставке. Например, Джонатан и Родриго упомянули об этом в своем увлекательном докладе «Масштабирование граничных операций в Onefootball с помощью Ambassador: от 0 до 6000 запросов в секунду»:
Компании (все еще) на начальных этапах внедрения технологий
Это первый KubeCon, где на стенде Datawire я много общался с разработчиками из крупных компаний, которые только начинают изучать облачную технологию. Почти все слышали о Kubernetes или экспериментировали с ним, но многие еще только думают, как вписать свою старую технологию в новый мир.
Шерил Хан (Cheryl Hung), директор по экосистеме в CNCF, провела несколько обсуждений, включая «Трансформация компании с помощью облачных технологий», и было интересно послушать таких первооткрывателей, как Intuit. Лора Рехорст (Laura Rehorst) в своем докладе «От COBOL до Kubernetes: путешествие в облако для банка с 250-летней историей» рассказала, как банк ABN AMRO применял планирование и стратегические ресурсы.
Мы разместили API-шлюз Ambassador в самом центре стенда, поэтому чаще всего нам задавали вопросы о том, чем современный шлюз для Kubernetes отличается от существующих решений по управлению полным жизненным циклом API. Сейчас мы работаем над следующим коммерческим продуктом в этой области — Ambassador Code, и было интересно обсуждать с разработчиками требования и ожидания в связи с новыми облачными парадигмами.
Локальный Kubernetes реален (но заковырист)
Было несколько анонсов по локальной установке Kubernetes, в частности, в корпоративной среде, например Интеграция Kublr VMware и VMware и kubeadm. Red Hat участвовали во всех обсуждениях OpenShift, и я не раз слышал, как людям нравятся абстракции OpenShift, и потенциальная зависимость компенсируется улучшенным рабочим процессом и соглашениями SLA, которые идут в комплекте.
Но все повторяли одно и тоже: не нужно устанавливать и обслуживать Kubernetes самостоятельно, если в этом нет крайней необходимости. И даже если вы считаете, что ваша компания особенная, не торопитесь: почти любая компания, которая может использовать общедоступное облако, может применять и Kubernetes как услугу.
Считайте кластеры стадом
В своем интересном докладе «Как Spotify нечаянно удалили все кластеры Kube, а пользователи ничего не заметили», разработчик Spotify Дэвид Ся (David Xia) рассказал, чему они научились, когда удалили несколько (!) рабочих кластеров. Я не буду описывать всю ситуацию (посмотрите видео), но главным посылом Дэвида было относиться к кластерам Kubernetes, как к стаду. Думаю, многие из нас слышали эту фразу: «Относитесь к серверам, как к стаду, а не любимым питомцам». Но Дэвид считает, что по мере развития вычислительной абстракции (когда мы воспринимаем «Датацентр как компьютер»), мы должны применять тот же принцип и не слишком привязываться к нашей инфраструктуре.
В своем докладе Совместное развитие Kubernetes и сетей GCP Пурви Десай (Purvi Desai) и Тим Хокин (Tim Hockin) предлагают организациям постоянно уничтожать, воссоздавать и переносить кластеры Kubernetes, чтобы не сродниться с ними. Главный аргумент: если вы постоянно не проверяете возможность восстановить кластеры и перенести данные, возможно, вам это не удастся, когда возникнет проблема. Представьте себе, что это хаос-инжиниринг для кластеров.
Успех Kubernetes по-прежнему зависит от сообществ.
В докладах, за обедом и повсюду одной из ключевых тем была важность сообщества и разнообразия. В четверг утром Лукас Кэльдстрём (Lucas Käldström) и Никита Рагунат (Nikhita Raghunath) в своем докладе «Первые шаги в сообществе Kubernetes» не только рассказали две удивительные истории, но и разбили все оправдания тех, кто не участвует в опенсорс-проектах и проектах CNCF.
Шерил Хан (Cheryl Hung) в своем докладе «2,66 миллиона» поблагодарила за огромный вклад в проект и привела веский аргумент в пользу разнообразия и сильного лидерства. Я удивился, когда узнал, что на пожертвования от разных организаций в составе CNCF было учреждено более 300 стипендий, поддерживающих разнообразие.
Заключение о KubeCon EU
Еще раз спасибо всем, с кем мы пообщались в Барселоне. Если вам не удалось побывать на наших презентациях, привожу полный список:
- Создание панели управления на границе с использованием Kubernetes и Envoy: Флинн из Datawire рассказывает об эволюции API-шлюза Ambassador и его архитектуре.
- Обеспечение облачного взаимодействия от конечного пользователя до сервиса: Ник Джексон (Nic Jackson) из HashiCorp и Дэниел Брайант (Daniel Bryant) из Datawire обсуждают интеграцию API-шлюза Ambassador с Consul service mesh.
- Масштабирование граничных операций в Onefootball с помощью Ambassador: от 0 до 6000 запросов в секунду: SRE-инженеры Onefootball рассказывают, как использовали Ambassador в продакшене.
- Расширение Knative для веселья и прибыли: команда Google Knative рассказывает о платформе Knative и показывает, как они использовали Ambassador.
- Telepresence: быстрая разработка рабочих процессов для Kubernetes: обсуждение прошлого, настоящего и будущего Telepresence.
- Воспроизводимые разработки и поставки с Bazel и Telepresence: Кристиан Роджиа (Christian Roggia) рассказывает, какой подход Engel & Volkers используют для разработки микросервисов с Telepresence.
Мы в Datawire отслеживаем эти тенденции, чтобы Ambassador и дальше развивался и соответствовал изменчивым потребностям облачных разработчиков. Если вы не использовали Ambassador в последнее время, попробуйте наш последний выпуск — Ambassador 0.70 со встроенной поддержкой Consul service mesh, поддержкой пользовательского определения ресурсов и многими другими фичами.
Если возникли проблемы с обновлением, создайте задачу или найдите нас в Slack. Если нужна готовая установка Ambassador с интегрированной аутентификацией, ограничением скорости и поддержкой, попробуйте наш коммерческий продукт Ambassador Pro.
А если вам нравится работать с Ambassador, расскажите нам об этом. Оставьте комментарий под статьей или напишите @getambassadorio в Twitter.
Автор: nAbdullin
