Наша конференция по DevOps инструментам и подходам уже послезавтра, а это значит, что пришло время для последнего интервью! В этот раз мы задали несколько вопросов одному из руководителей групп разработчиков в Google про работу связки Kubernetes и Istio, релиз которой намечен на начало следующего года.
Крейг расскажет, почему стоит деплоить в контейнерах даже на одну машину, когда подключать систему оркестрации, какие есть альтернативы у Kubernetes и что нас ждет в будущем. Подробности — под катом.
Крейг Бокс (Craig Box) — эксперт и руководитель одного из подразделений в Google Cloud. В его обязанности входит работа с платформами, сбор отзывов пользователей и взаимодействие с инженерами. Начал с системного администратора, затем переключился на разработку, внедрение, DevOps, консалтинг и управление.
Расскажите, пожалуйста, немного о своем докладе. Та связка, о которой Вы будете говорить, уже используется кем-то в продакшне или это концепт? Насколько lstio — зрелый продукт?
Крейг Бокс: Istio — это сервисная сеть с открытым исходным кодом, которая позволяет отделить рабочие процессы от разработки. Вы можете представить ее как сеть сервисов, а не байтов или пакетов.
Когда люди переносят свои приложения из монолитного процесса в микросервисы, они внедряют сеть, которая не всегда работает надежно, как и многие распределенные конечные точки. Некоторые компании, в частности Netflix, решали сетевые проблемы микросервисов при помощи библиотеки, которая должна быть включена каждым микросервисом. Так как микросервисы позволяют разрабатывать каждый компонент на любом языке, библиотеки необходимо поддерживать на нескольких языках, и вскоре это стало дополнительной проблемой.
Istio позволяет вам управлять существующими и новыми службами на любом языке единым способом. Он помогает управлять, контролировать и защищать микросервисы на любом языке и развернутые в любом месте.
Администратор определяет правила (например, «отправьте 10% бэкенд-трафика на мой сервис» или «убедитесь, что весь трафик между A и B проведен с помощью взаимного шифрования TLS»). Istio внедряет прокси-сервер перед каждой службой, которая запрограммирована для обеспечения соблюдения этих правил. И даже не определяя ничего, вы сразу получаете богатый арсенал по мониторингу трафика и обеспечению распределенной трассировки между вашими конечными точками после установки Istio на кластере Kubernetes.
Прокси-сервер, используемый Istio, называется Envoy. Он был написан командой из Lyft под руководством Мэтта Клейна. Lyft уже давно используют Envoy в своих проектах и за это время проверили его работу в системах разных масштабов.
В сообщество Istio изначально входили компании Google, IBM и Lyft, но после присоединения многих других участников была выпущена версия 0.2. Мы рассматриваем ее как «бета-версию» и планируем ограниченное промышленное использование к версии 0.3 в конце этого года, а выпуск 1.0 запланирован на 2018, она будет поддерживать еще больше окружений.
Первоначально Istio был разработан с учетом Kubernetes, а Kubernetes — это, конечно же, зрелый, готовый к использованию продукт. Исследовательская фирма Redmonk утверждает, что Kubernetes пользуются 54% компаний из списка Fortune 100, что составляет 75% от общего числа компаний, использующих контейнеры.
— В отличие от большинства практик DevOps, необходимость использования систем оркестрации не всегда очевидна, особенно для относительно небольших команд и проектов. Нужны ли они всегда и для всех, или подобные системы появляются и приносят пользу только там, где микросервисы и большое число машин?
Крейг Бокс: Даже если у вас только один сервис на одной машине, все равно есть преимущества в использовании контейнеров: вы можете развернуть свое приложение со всеми его зависимостями в одном атомарном блоке, быть уверенным, что оно не возьмет ресурсов больше, чем дозволено, при этом в любой момент можно легко откатить все изменения.
Даже если у вас только один контейнер, Kubernetes — отличный API для управления жизненным циклом этого контейнера, работающего на любой машине; он обрабатывает абстракции уровнем ниже вашего приложения, например, память и сеть, и предоставляет сервер API, который можно легко настроить при помощи ваших инструментов развертывания.
Теперь у вас есть портируемое приложение, которое вы можете перемещать между средами. Когда ваше приложение настроено, можно перейти к масштабированию.
— По каким признакам можно понять, что вот сейчас уже надо, если проект изначально начинался без подобной системы оркестрации?
Крейг Бокс: Система, подобная Kubernetes, управляется через API от начала и до конца. Вы можете автоматизировать все, начиная с создания кластеров, с помощью службы, такой как Google Container Engine, и заканчивая развертыванием и обновлением приложений на этом кластере.
Одной из наиболее распространенных причин, почему люди этим занимаются, является увеличение скорости изменений. Это происходит примерно так: перемещая в облако контейнеры, оркестрацию и микросервисы, вы уменьшаете риск одного развертывания. Это позволяет вам обеспечить непрерывную работу. Теперь вы уверены в своем процессе, который активируется с помощью шаблонов, таких как канареечное развертывание (где вначале 1% трафика переходит к новой службе, затем 5%, затем 20% и т. д.). Вы также можете вернуться назад, если что-то пойдет не так.
Наши клиенты сказали нам, что они могут перейти от одного развертывания в месяц к десяткам в день. Это означает, что новый код работает быстрее, и в конечном итоге приводит к более гибкому управлению бизнес-процессами.
— Существуют ли серьезные альтернативы Kubernetes? Или его модель настолько хороша и универсальна, что они в принципе не нужны, и в конце концов останется только один?
Крейг Бокс: Kubernetes — это эволюция модели кластеризации, созданной Google. Мы опубликовали документы о нашей работе, которые повлияли на другие системы в этом пространстве, например, на Mesos.
Примерно в то же время, когда возник Kubernetes, появились и другие подобные системы. Многие из них в скором времени перешли на Kubernetes (например, OpenShift, Deis Workflow и недавно Rancher).
Одна из причин, по которой Google решил создать Kubernetes и выпустить его под открытой лицензией, заключается в том, что всем нужен был стандартный API, который можно использовать для всех поставщиков.
Kubernetes называют «Linux для облака». Хотя Linux в некотором роде является де-факто выбором, когда вам нужен Unix, по-прежнему существует экосистема других операционных систем с открытым исходным кодом для разных случаев — не говоря уже о мире с закрытым исходным кодом и Windows.
Аналогичным образом мы создали в Kubernetes фантастический набор API-интерфейсов, позволяющий управлять всеми видами приложений: от stateful веб-сервисов до пакетных рабочих нагрузок для моделей ML с большими данными и GPU. Мы также потратили много времени на создание расширяемых функций в Kubernetes, которые позволяют вам определять типы объектов, о которых мы даже не думали. Мы видим Kubernetes как ядро экосистемы и что-то, что вы можете расширить.
— Насколько сложно поддерживать существующие решения оркестрации? Можно ли быстро въехать, запустить их и забыть? Или предстоит постоянный тюнинг, развалы кластера и другие проблемы?
Крейг Бокс: У каждого пользователя будут свои причины использовать кластеры. Одни будут совместно использовать их для максимальной утилизации мощности и, возможно, захотят, чтобы те долго работали. Другие захотят включить их лишь тогда, когда они им нужны, и дать разным бизнес-единицам свои собственные кластеры. У людей, работающих с фиксированным числом машин, иной взгляд на их использование, чем у людей, работающих в облаке, когда они могут автоматически добавлять машины по мере необходимости.
Мы разработали Kubernetes так, чтобы он хорошо работал во всех ситуациях, а наш продукт, Google Container Engine, позволит вам разворачивать кластер менее чем за три минуты.
— Какие задачи нельзя или сложно решить с помощью существующих систем оркестрации? Куда движется их развитие?
Крейг Бокс: Системы оркестровки контейнеров хорошо подходят для общих динамических рабочих нагрузок в масштабируемых системах. Если вы хотите запустить одну коммерческую базу данных на одной машине и она использует все ресурсы этой машины, мы порекомендовали бы вам ничего не менять. Если этот сервер сломается, усилия и затраты на его перенос могут быть больше, чем усилия и затраты на ремонт. Учитывая это, наша рекомендация заключается в том, чтобы просто подключиться к внешней службе внутри вашего кластера.
Аналогично, когда у вас есть управляемая служба, например, Google BigQuery, вам не нужно запускать хранилище данных в вашем кластере.
Istio знает, что не все приложения будут работать на Kubernetes. В версии 0.2 вы можете добавить сервисы, запущенные как на виртуальных, так и на реальных машинах.
Oracle опубликовали сценарии, позволяющие разместить Oracle Database в контейнере, а Microsoft сделали еще один шаг и выложили образы SQL Server на Docker Hub. Если вы хотите переместить такие рабочие нагрузки, это более чем возможно!
— Что насчет stateful-сервисов? Стоит ожидать появления универсального механизма?
Крейг Бокс: MVP для Kubernetes размещал stateless веб-службы, но мы всегда думали над тем, что нам нужно сделать, чтобы иметь возможность запускать stateful рабочие нагрузки.
Мы работали над концепцией «StatefulSet», которая дает каждому члену порядковый (нумерованный) идентификатор и отдельное хранилище. Кроме того, вы можете создавать «операторы» для приложений, которые знают, что должно произойти, чтобы присоединить или удалить элемент из кластера.
Сообщество Kubernetes разработало ряд шаблонов для обычных приложений с открытым исходным кодом, таких как Cassandra и MongoDB, и, как я уже говорил, многие компании переносят традиционные корпоративные приложения в контейнеры. Мы надеемся, что со временем все сообщества будут использовать Kubernetes как первоклассную поддерживаемую платформу развертывания.
Если для вас актуальны вопросы управления микросервисами, приглашаем послушать доклад Крейга Бокса Managing your microservices with Kubernetes and Istio на DevOops 2017.
Также вам наверняка будут интересны и другие выступления на конференции, среди которых:
- Расширяем k8s (Николай Рыжиков, Health Samurai)
- Troubleshooting & debugging production applications in Kubernetes a.k.a. The Failing Demo Talk (Ray Тsang, Google и Барух Садогурский, JFrog)
- SmartMonitoring — мониторинг бизнес-логики в Одноклассниках (Сергей Шарапов, Одноклассники)
Автор: MaxJoint
