Проведение Контейнеров: Как Работает Комбинация Kubernetes И Istio

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

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

Подробности под катом.

Проведение контейнеров: как работает комбинация Kubernetes и Istio

Крейг Бокс — эксперт и бизнес-лидер 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 утверждает, что 54% компаний из списка Fortune 100 используют Kubernetes, что составляет 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. Кроме того, мы создали фантастический набор API-интерфейсов в Kubernetes, которые позволяют вам управлять всеми видами приложений, от веб-сервисов с отслеживанием состояния до пакетных рабочих нагрузок для больших данных и моделей машинного обучения на графических процессорах.

Мы также потратили много времени на создание расширяемых функций в Kubernetes, которые позволяют определять типы объектов, о которых мы даже не думали.

Мы рассматриваем Kubernetes как ядро экосистемы, которое можно расширить.

— Насколько сложно поддерживать существующие решения по оркестрации? Можно ли быстро въехать, запустить их и забыть о них? Или будут постоянные настройки, поломки кластера и прочие проблемы? Крейг Бокс: У каждого пользователя будут свои причины для использования кластеров.

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

Другие захотят включать их только тогда, когда они им нужны, и предоставить различным бизнес-подразделениям собственные кластеры.

Люди, работающие с фиксированным количеством компьютеров, имеют другой взгляд на их использование, чем люди, работающие в облаке, где они могут автоматически добавлять машины по мере необходимости.

Мы разработали Kubernetes так, чтобы он хорошо работал во всех ситуациях, а наш продукт Google Container Engine позволяет развернуть кластер менее чем за три минуты.

— Какие проблемы невозможно или сложно решить с помощью существующих систем оркестрации? Куда движется их развитие? Крейг Бокс: Системы оркестровки контейнеров хорошо подходят для общих динамических рабочих нагрузок в масштабируемых системах.

Если вы хотите запустить одну коммерческую базу данных на одном компьютере и она использует все ресурсы этого компьютера, мы рекомендуем вам ничего не менять.

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

Аналогично, если у вас есть управляемый сервис, такой как Google BigQuery, вам не нужно запускать хранилище данных в своем кластере.

Istio знает, что не все приложения будут работать в Kubernetes. В версии 0.2 вы можете добавлять сервисы, работающие как на виртуальных, так и на реальных машинах.

Oracle опубликовала сценарии, которые позволяют размещать базу данных Oracle в контейнере, а Microsoft пошла еще дальше и выпустила образы SQL Server в Docker Hub. Если вы хотите перенести такие рабочие нагрузки, это более чем возможно! — А как насчет сервисов с отслеживанием состояния? Стоит ли ожидать появления универсального механизма? Крейг Бокс: В Kubernetes MVP размещались веб-сервисы без сохранения состояния, но мы всегда думали о том, что нам нужно сделать, чтобы иметь возможность запускать рабочие нагрузки с сохранением состояния.

Мы работали над концепцией StatefulSet, которая дает каждому члену порядковый (нумерованный) идентификатор и отдельное хранилище.

Кроме того, вы можете создавать «операторы» для приложений, которые знают, что должно произойти, чтобы присоединить или удалить элемент из кластера.

Сообщество Kubernetes разработало ряд шаблонов для распространенных приложений с открытым исходным кодом, таких как Cassandra и MongoDB, и, как я уже упоминал, многие компании переносят традиционные корпоративные приложения в контейнеры.

Мы надеемся, что со временем все сообщества будут использовать Kubernetes в качестве основной поддерживаемой платформы развертывания.

Если для вас актуальны вопросы управления микросервисами, приглашаем вас послушать доклад Крейга Бокса.

Управление микросервисами с помощью Kubernetes и Istio на ДевОупс 2017 .

Вероятно, вас также заинтересуют другие доклады на конференции, в том числе: