Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет!
Мы подготовили перевод выступления Келси Хайтауэра на тему «Создание облачных приложений с помощью Kubernetes и Istio» (конференция O’Reilly). Автор рассуждает о преимуществах совместного использования Kubernetes и Istio, рассказывает, что такое sidecar, bar и foo, показывает как отразить матрицу в дашборде и как начать «разговаривать» с инфраструктурой. На примерах он демонстрирует процесс работы с Istio.
Келси Хайтауэр и Istio
Дадим немного вводных.
Келси Хайтауэр – это американский инженер-программист и спикер, известный своей работой с Kubernetes, программным обеспечением с открытым исходным кодом и облачными вычислениями. Активно продвигает и популяризирует работу с Kubernetes с помощью своих презентаций, семинаров и учебных материалов. Он выступал с докладами на различных отраслевых конференциях, включая KubeCon, PuppetConf, GopherCon, и был автором ряда статей и учебных пособий по Kubernetes и смежным темам.
Istio – это открытая платформа управления трафиком и сервисными сетевыми службами, разработанная для облегчения работы с микросервисной архитектурой в контейнерных средах, таких как Kubernetes. Предоставляет инструменты для управления и контроля сетевого трафика между микросервисами, обеспечивая такие функции, как балансировка нагрузки, контроль маршрутизации, обнаружение ошибок и управление безопасностью.
Начнем
Сегодня поговорим об Istio.
Вы уже знаете все о политиках, обслуживании, безопасности, и надежности. Но, на самом деле, у большинства людей нет возможности делать подобное, потому что, это не так-то просто, как говорят. Я хочу, чтобы вы задумались о том, почему мы думаем обо всех этих вещах и об инструменте Istio. Почему это важно для нас?
С одним утверждением, которое пришло из отрасли, нам придется согласиться: «Большинство людей управляющие инфраструктурой, просто хотят иметь платформу как услугу (PaaS). Единственное требование: она должна быть создана ими».
Никто не любит работать с готовыми продуктами. Популярные слова большинства людей, работающих в области технологий: «Я создам свой собственный продукт». И как только вы это делаете, вы уже настраиваете себя на проблемы.
Docker
Многие люди начали думать о создании своих собственных путей. И за последние несколько лет технологии, о которых вы слышали, стали внедряться в производство, например Docker. Чем так хорош Docker? Почему эта технология становится основой большинства новых платформ?
Настоящая причина, по которой Docker важен для большинства, заключается в том, что впервые они могут отделить свое приложение от машины. Весь хайп вокруг Docker – это его реальные преимущества, как технологии и идеи, где уже на первом этапе у вас может быть автономное приложение и возможность перенести его на другие устройства. Как только вы начинаете работать с Docker, вам становится легче решать, где вы бы хотели запустить свое приложение. Но это не решение всех ваших проблем.
Kubernetes
Как только вы начинаете работать с Docker, вы задумываетесь о своем следующем шаге. Именно здесь большинство людей начинают изучать такие инструменты кластерного управления, как Kubernetes или Apache Mesos.
- Kubernetes (K8s) – это открытая платформа для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Она предоставляет средства для упрощения оркестрации контейнеров в распределенных средах, таких как облачные кластеры или локальные серверы. Позволяет разработчикам определять, как и где должны работать их приложения.
- Apache Mesos (обычно называемый просто Mesos) – это открытая система управления кластерами, разработанная для распределения вычислительных ресурсов и управления работой приложений на крупномасштабных вычислительных кластерах. Mesos предоставляет абстракцию над ресурсами кластера, объединяя физические или виртуальные машины и предоставляя единый пул вычислительных ресурсов, таких как процессорное время, память и хранилище.
Суть здесь в том, что, когда вы внедряете одну из этих платформ, они в свою очередь отделяют вас от чего-то. В этот раз это инфраструктура.
Как только ваше приложение отделяется от машины, последний этап этого процесса — это отделение «себя» от базовой инфраструктуры, будь то виртуальные машины, облачный провайдер или ваш ноутбук. И Kubernetes дает вам новый набор абстракций, которые позволяют запускать приложение и масштабировать его везде, где вам хочется.
Люди уже пару лет используют Kubernetes в производстве, так что это уже не какое-то ноу-хау, с которым никто не знает, как работать. И затем со временем эти же люди поняли, что Kubernetes тоже имеет свои недостатки. Но это все еще лучшая отправная точка для создания распределенных систем или вашей собственной платформы, например все API. Но что же упускается?
Что упускается?
Когда вы начинаете задавать вопросы, что мне нужно сделать, чтобы запускать свои приложения, будь то микросервисы или монолиты, есть то, что вам придется сделать. Об этом мы уже говорили ранее. Рекомендуют такие проекты, как NGINX, который будет заниматься управлением приложениями и отслеживать то, как вы получаете трафик для него. Также у вас есть такие проекты, как OpenTracing. Он дает вам представление о том, как все работает друг с другом и какой у вас уровень задержки интернет-трафика. А также есть VAULT для управления секретами.
У всех этих вещей есть API. И Prometheus предоставляет хороший адаптер, чтобы иметь возможность собирать метрики из каждого уникального приложения в вашем стеке. И последнее, с чем знакомо большинство – это проект под названием SPIFFE.
SPIFFE решает настоящую проблему. Мы все так или иначе отправляем свои личные данные в наши приложения. Мы подключаемся к базе данных, и к другим платформам. Но правда в том, что у нас нет идентичности для любого из этих приложений. На самом деле, мы понятия не имеем, куда мы отправляем наши личные данные. Поэтому такие вещи, как SPIFFE, попытались дать идентичность нашим приложениям независимо от того, на какой платформе они работают.
Istio Integration
Итак, что у нас есть по итогу из всего вышесказанного? Вы спрашиваете, как Istio вписывается во все это.
Как в случае с Docker и Kubernetes, цель состоит в том, что Istio не заменяет эти проекты, а интегрируется с ними, избавляя нас от необходимости делать все самостоятельно.
Eсли вы подумаете обо всех этих инструментах, я думаю, что мы все придем к тому, что мы уже услышали достаточно, прочитали достаточно, и знаем, что у нас есть все возможности. Но насколько легко это сделать, на самом деле?
Насколько это просто?
Большинство людей испытывает проблемы даже при работе с одним языком программирования, который используется для реализации всего этого. А потом в организации появляется кто-то новый и говорит вам что-то типа: «Эй, мы теперь работаем через Haskell!». А ты такой: «но… почему?!» На этот вопрос почти никогда нет хорошего ответа. Но если вы окажетесь в такой ситуации, вам теперь нужно будет найти библиотеки, которые реализуют всю трассировку безопасности. Здесь и возникает проблема. Обычно это невозможно сделать для всех стеков. Поэтому Istio пытается использовать другой подход.
Istio подход
Istio:
- управление потоком трафика между сервисами;
- агрегирование телеметрических данных;
- обеспечение соблюдения политик доступа.
Как только вы встанете посреди потока данных, вы сможете начать агрегировать такие вещи, как телеметрические данные. А затем вы сможете обеспечить соблюдение этих политик. И я здесь не просто говорю о правилах брандмауэра (Firewall) в группах безопасности.
Этот проект очень просто устроен. У него нет представления о том, что приложение пытается сделать. Он просто включен или выключен. Но нам понадобится здесь немного больше информации.
Реализация
Мир Istio:
- панель управления Istio: плоскость управления (Pilot), компонент телеметрии Mixer, auth;
- адаптеры для серверной инфраструктуры (backend infrastructure);
- envoy (управление трафиком) sidecar-прокси.
Так, Docker дает нам способ описать, как наше приложение должно быть построено, как оно работает на низкоуровневой части ядра. Kubernetes дает нам тот же тип политики для всей инфраструктуры. Это все находится под приложением. Но что же насчет всего, что находится над приложением и вокруг него?
Это то, что и делает Istio. Здесь применяется та же модель, но на уровне приложения между сетью.
Есть еще одна вещь, называемая серверной инфраструктурой. Когда вы думаете о логах и метриках, это и есть серверная инфраструктура приложений. Кто-то должен управлять этим, и поэтому все вещи управляются в мире Istio через Mixer с помощью адаптеров.
Мы никогда не сможем абстрагироваться от всех способов трассировки или всех способов ведения логов. Но что мы можем сделать, так это отобразить события, происходящие в наших системах, и отобразить их таким образом, чтобы эти адаптеры могли просто взять на себя всю тяжелую работу и размещать данные в нужном месте.
И, наконец, последний фрагмент: как убедиться в том, что эти политики всегда соблюдаются? Мы добиваемся этого с помощью sidecar. Многое из этого на самом деле построено для создания конфигурации, которую мы будем проталкивать на каждый узел.
Теперь, когда у нас есть конфигурация на месте, единственный способ действительно узнать, как выглядит Istio, — это увидеть его работу в действии. Мы собираемся сделать это сейчас. Мы посмотрим, как эта штука на самом деле работает.
Наша цель здесь состоит в том, чтобы на примере реального приложения, показать вам его работу. Для этого я написал свой собственный маленький сетап микросервиса, а затем развернул его с нуля и посмотрел, как мы внедряем Istio в этот процесс.
Кластер Kubernetes и развертывание приложения
Итак, первое, мы рассмотрим здесь мой kubernetes, где есть множество узлов.
Снова весь смысл работы с kubernetes, заключается в том, что неважно, где я его запускаю – это может быть мой ноутбук, это может быть облачный провайдер в моем центре обработки данных, но мы ограничиваем его.
Затем нам нужно развернуть наше приложение. Первое, что мы сделаем, это развернем простой стек нашего приложения.
- Fluent $ kubectl apply -f kubernetes/deployments/bar-v1.yaml
- Fluent $ kubectl apply -f kubernetes/deployments/foo-v1.yaml
- Fluent $ kubectl apply -f kubernetes/deployments/frontend-v1.yaml
Это то, что большинство делает, работая с Kubernetes. Он позволяет очень легко сказать: «Эй, я хочу, чтобы мой стек был развернут вот так!».
И как только он будет развернут, мы сможем получить немного информации о том, что тут происходит. Я просто получаю список всех приложений, которые запускаются в v1.
- Fluent $ kubectl get pods -l version=v1
Отлично, все работает.
Проверка запущенного приложения
Так, в этот момент я должен быть в процессе запуска. Как видите, это все действительно просто. Теперь я должен пропинговать приложение.
Итак приложение работает. Теперь проблема в том, что большинство людей доходят до этого этапа, а потом останавливаются. Вы переходите в дашборд и вы ничего не видите. Да, Матрицей тут не пахнет.
Вы покупаете оборудование по «лучшей цене», все эти мониторы с плоскими экранами и развешиваете их по всему офису. Люди приходят к вам, а у вас на экранах это!
– Вы, ребята, абсолютно ничего не делаете!
Вы попросту летаете вслепую. Это ситуация, с которой сталкивается большинство людей, и они полагаются на поистине древние методы отладки процессов. Типа: Нет-нет-нет, вы должны зайти на ЭТОТ сервер, СПЕЦИАЛЬНЫЙ сервер. А человек, который может дать мне доступ к этому серверу сейчас в отпуске, и поэтому мне придется подождать. И нам надо выбраться из этой ситуации.
Итак, нам нужно, чтобы отображалось то, что происходит. Мы могли бы попросить всех разработчиков настроить свой код таким образом, чтобы мы получали метрики в систему. Каковы шансы того, что это случится? (люди смеются) Они близки к нулю. Поэтому нам нужен способ лучше.
Sidecar
Способ, которым мы могли бы выполнить нашу задачу, это подумать о паттерне SIDECAR. Мы можем войти и прикрепить желаемую функциональность к системе. Давайте сейчас попробуем сделать это.
Мы пишем то же самое тело кода, но теперь еще внедряем SIDECAR. Вы скоро сможете сделать это на стороне сервера, но я просто собираюсь показать, как это работает сейчас.
- Fluent $ kubectl apply -f >(istioctl kube-inject -f kubernetes/deployments/frontend-v1.yaml)
Так, мы займемся frontend, а также поработаем с зависимостями.
- Fluent $ kubectl apply -f >(istioctl kube-inject -f kubernetes/deployments/bar-v1.yaml)
- Fluent $ kubectl apply -f >(istioctl kube-inject -f kubernetes/deployments/foo-v1.yaml)
На скриншоте в 5 строке допущена ошибка. К.Хайтауэр исправляет ее в 8 строке.
Теперь все работает. Давайте посмотрим, каково состояние мира сейчас.
На данный момент версия равна v1.
Вы заметили, что здесь написано 2/2, а не 1/1? Вместо 1/1 у нас SIDECAR теперь работает бок о бок с приложением. В этот момент я собираюсь добавить его в цикл просмотра, чтобы мы могли видеть, что здесь происходит.
Взаимодействие с Sidecar
Давайте просто добавим его в цикл, и мы начнем видеть, что мы зависим от одной из наших подзависимостей, это V1 BAR.
Теперь, когда у нас все работает, давайте проверим, что мы получаем.
Так, вместо разработчика SIDECAR сидит в потоке данных и может просматривать и получать все эти показатели для нашего приложения. Оно не только собирает метрики о том, сколько происходит запросов в секунду, оно понимает такие вещи, как HTTP, HTTP2, GRPC, и даже определенные подключения с базой данных. Он может обрабатывать такие вещи как логика повторных попыток и экспоненциальная выдержка. Все, что вам нужно сделать, чтобы ваше приложение было готово к работе, SIDECAR сделает за вас автоматически. Это не только даст нам метрики, но также такие вещи, как трассировку (tracing).
Когда все эти запросы приходят, как они проходят через систему? Мы заходим в Zipkin (система трассировки) и видим некоторые следы.
Итак, мы видим, что наш frontend общается с BAR, а затем с FOO. Мы можем видеть, что это происходит последовательно, и, возможно даже параллельно. Но что касается видимости, здесь вы просто теряетесь в догадках.
Теперь мы действительно можем видеть, что у нас происходит. Все обрабатывается через SIDECAR и теперь обновляет данные в нашем приложении.
Развертывание sidecar
Следующее, что можно сделать – вы можете представить себе мир, в котором вы делаете все, что связано с DevOps, а ваша команда разработчиков занимается развертываниями, так как им этого хочется, и при этом они всегда работают ответственно, верно? Так что нам не о чем беспокоиться. Ха-ха, дурачок!
Теперь мы собираемся развернуть новую версию, просто чтобы смоделировать то, что я говорю. Мы разворачиваем v2.
- Fluent $ kubectl apply -f >(istioctl kube-inject -f kubernetes/deployments/bar-v1.yaml)
Обычно, при развертывании kubernetes, когда вы делаете это бок о бок, учитывая, как настроен мой сервис, трафик будет идти в v1 и v2. Теперь, когда вы вводите SIDECARS, у вас есть определенная политика.
Команды разработчиков такие: «Эй, я не вижу V1». Что ж, хорошая новость в том, что теперь я полностью контролирую ситуацию, независимо от того, что делают эти люди. Они не видят, что у меня есть этот контроль. Если я хочу показать вам, что на самом деле здесь происходит, я могу удалить одно из правил маршрутизации, которые у меня есть.
- Fluent $ istioctl delete -f istio/route-rules/bar.yaml
Это не то, что я хочу, поэтому я верну правило на место. Когда вы смотрите на него, оно очень похоже на то, как мы описываем нашу инфраструктуру для Kubernetes.
- Fluent $ cat istio/route-rules/bar.yaml
Мы можем просто сказать: «Эй, все, что предназначено для BAR в определенном пространстве имен, это то, как я хочу, чтобы этот трафик обрабатывался».
Автоматизация
Теперь я вернусь назад.
- Fluent $ istioctl create -f istio/route-rules/bar.yaml
Теперь идеальное время, чтобы поговорить. Мы собираемся кое-что попробовать. Istio API действительно надежный, так что вы можете переосмыслить то, как мы взаимодействуем с нашей инфраструктурой. Поэтому почему бы не попробовать что-то новое?
Мы можем начать «говорить» с нашей инфраструктурой. Однажды в будущем это будет похоже на «Звездный путь». Вы будете говорить со своей инфраструктурой, я обещаю вам это. Давайте попробуем.
Келси: Окей гугл, поговори с Istio.
Google: Конечно, давайте получим тестовую версию Istio API.
Istio: Привет Келси.
Келси: Привет.
Istio: У тебя тут довольно много народу, надеюсь, ты знаешь, как работать с командами Istio. Я заметила, что вы используете Wi-Fi конференции. Демо-боги будут не слишком довольны.
Келси: Получи frontend топологию.
Istio: Служба frontend зависит от сервиса FOO и сервиса BAR. Это не то, что я бы назвала веб-масштабом, это больше выглядит как «милота».
Зависимости
Так, как она может получить эту информацию? Что в этом стеке хорошо – у нас есть API, который сообщит нам обо всех наших зависимостях на основе данных, которые проходят через систему.
Тут у нас необработанные данные, которые я использую через свой API, но у меня также есть возможность посмотреть на схему.
Как видите, согласно этой схеме я фактически составляю список своих зависимостей на основе трафика, проходящего через все SIDECARS. Нам не нужно никого просить допиливать что-либо вручную. Мы просто получаем это бесплатно.
Другое дело, что тут вы можете использовать свою силу. Например другие разработчики не хотят вас слушать.
Келси: Запрети доступ к сервису BAR
Istio: Доступ к сервису BAR запрещен из сервиса FRONTEND
Теперь мы ждем появления скачка на 400-500 пунктов. Надо дать им знать, кто тут главный. «Келси, наш сайт перестал работать». Я знаю, это сделал я. Но, вы, конечно, проявите ответственность и включите его снова.
Келси: Разреши доступ к сервису BAR.
Istio: Доступ к сервису BAR разрешен из frontend сервиса.
Теперь мы должны увидеть падение на 400-500 пунктов.
Паттерны
Оказывается, нам действительно нужно приложение v2. Но дело в том, что некоторые паттерны просто не имеют смысла для всех типов приложений. Когда вы имеете дело с новым стеком, как этот, вы имеете дело не только с браузерами. Иногда вы имеете дело с мобильными устройствами или даже автомобилями, и некоторые из обновлений должны быть стратегически развернуты в шаблоне CANARY. Так что в идеале мы можем сказать: «Эй, покажи новое приложение только на мобильном устройстве».
Итак, мы собираемся посмотреть, сможем ли мы сделать это хирургическим путем, что действительно сложно сформулировать в Kubernetes. Нет никакого способа выразить это, потому что это не его забота. Он имеет дело с базовой инфраструктурой. Нам нужно что-то на прикладном уровне, что могло бы немного улучшить работу. Так что давайте вернемся к нашей командной строке, и мы увидим, что у нас есть наше первое приложение в цикле.
Мы собираемся указать curl, чтобы он установил строку пользователя агента в значение mobile.
На данный момент у нас есть два приложения – одно имитирует мобильное устройство, а другое имитирует браузер. И они оба видят v1.
Теперь мы хотим разрешить трафик только на мобильные устройства.
Келси: Направь мобильный трафик на BAR v2.
Istiso: Чтение обновления завершено. Трафик с мобильных клиентов будет направляться на версию BAR v2.
Спасибо, это был Istio.
Полезные материалы
Переводы лекций:
- PuppetConf 2016. Kubernetes для сисадминов. Часть 1
- PuppetConf 2016. Kubernetes для сисадминов. Часть 2
- PuppetConf 2016. Kubernetes для сисадминов. Часть 3
- Hightower, Kelsey; Burns, Brendan; Beda, Joe (2017). Kubernetes: Up and Running
- https://github.com/kelseyhightower
- Как Келси Хайтауэр стала одной из самых уважаемых людей в сфере облачных вычислений (английский)
Совсем немного рекламы: в Serverspace вы можете развернуть Kubernetes-кластер для оркестрации своих приложений и попробовать поработать с Istio.
