Хабрахабр

[Перевод] KubeCon EU 2019: 10 ключевых выводов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть