Cloud native

Не только на мировом, но и на российском рынке можно заметить волну интереса к технологиям сервисных сеток, или service mesh. Ниже под катом мы разберемся, какие задачи эта технология решает, как она развивалась, а также с какими вопросами сталкиваются корпорации при адаптации Istio у себя в ИТ-инфраструктуре.




Мое знакомство с service mesh было во многом случайным, когда в 2017 году мне на глаза попался анонс о сотрудничестве Google и IBM по созданию нового open source проекта. Не сказать, что партнерства крупнейших технологических компаний редки, но именно этот случай вызвал у меня большой интерес. Во-первых, примеров взаимодействия именно компаний Google и IBM все же не так много: пожалуй, наиболее известными фактами будут работа вокруг открытой аппаратной архитектуры OpenPOWER, а также наличие сервисов IBM в Google Cloud. Во-вторых, несмотря на наличие примеров, когда и Google, и IBM развивают один и тот же open source проект (Kubernetes или TensorFlow), случаев, чтобы обе эти компании стали именно основателями проекта, очень мало, и они достаточно уникальны. И, в-третьих, наличие среди основателей проекта IBM и Google компании Lyft конкурента Uber как сервиса вызова такси, вызывало вопросы и неподдельный интерес. Тот анонс в 2017 году рассказывал о выпуске технологии Istio, предназначенной для управления взаимодействием различных сервисов. Поначалу не совсем очевидно, в чем заключается проблема и зачем создавать такой проект, так как подходов по управлению взаимодействием между сервисами было известно довольно много. Чтобы понять проблематику, стоит взглянуть на ситуацию шире и посмотреть на изменения в ИТ-архитектуре на тот момент времени.

Что такое service mesh

Причины появления и столь стремительно нарастающей популярности service mesh неразрывно связаны с изменениями в ИТ архитектуре. Представить появление service mesh без микросервисной архитектуры достаточно сложно давайте посмотрим почему. Можно долго спорить, что такое микросервисная архитектура, так как единого и устоявшегося определения нет (и вообще эта тема заслуживает отдельной статьи), но для упрощения остановимся на следующих ключевых характеристиках: это небольшие автономные части бизнес-логики, реализованные как сервисы, каждый из которых имеет свой цикл сборки и поддержки. В таком случае логично задуматься о том, как эти небольшие сервисы будут взаимодействовать друг с другом и как контролировать этот процесс. Здесь и появляется service mesh. В реальной жизни эту технологию можно сравнить с дорожным навигатором. На дорогах могут случаться различные ситуации: аварии, заторы, выход из строя светофоров, а система позволяет вам добраться из пункта А в пункт Б наиболее оптимальным способом, зная обо всех произошедших событиях.

Ключевыми задачами, которые берет на себя service mesh, являются:

• управление трафиком
• балансировка нагрузки
• обеспечение безопасности при взаимодействии сервисов
• сбор метрик и мониторинг

Другим аналогом service mesh из реальной жизни может быть служба почтовой доставки: она решает, что делать с посылкой, если вас нет дома или вы переехали, следит за безопасностью транспортировки, обеспечивает приватность передачи посылки и отслеживает статусы.

Эволюция развития service mesh

В настоящее время service mesh стал отдельным слоем и во многом стандартом де-факто современной ИТ-архитектуры на уровне инфраструктуры. Можно ли строить современные решения без service mesh и реализовывать этот функционал как-то по-другому? Конечно, да, только вопрос в удобстве, гибкости, времени реализации и дальнейшей поддержке решения. Безусловно, задачи, связанные с управлением трафика или балансировкой, можно решить самому на уровне кода для каждого из сервисов. Но так как микросервисная архитектура подразумевает существование десятков, сотен или даже тысяч различных сервисов, то реализовывать один и тот же функционал при разработке каждого из них совсем не удобно. Зачем разрабатывать один и тот же функционал десятки или сотни раз, если можно вынести его отдельно?
Первые реализации service mesh были сделаны на прикладном уровне. Самый известный пример фреймворк (или набор библиотек) Netflix OSS, доступный для использования с 2012 года. В него вошли компоненты, реализующие функционал, присущий service mesh: с помощью Eureka производится обнаружение сервисов (service discovery), с помощью Hystrix ряд паттернов обнаружений ошибок (circuit breaker), Zuul решает задачи динамической маршрутизации (dynamic routing).

На необходимость изменения этого подхода оказали сильное влияние следующие факторы:

• поддержка нескольких языков программирования и отсутствие зависимости от них
• удобство разделения прикладных и инфраструктурных задач для DevOps: возможность вносить изменения в прикладной код без влияния на инфраструктуру
• развитие контейнерных технологий

Как ни крути, Netflix OSS куда больше был интегрирован в прикладную логику сервиса, требовал использование стека технологий Netflix, имел зависимость библиотек от языка разработки и не был заточен для использования в контейнерах.
Istio как пример следующей волны эволюции технологии использует sidecar (Envoy от Lyft), то есть прокси, который располагается рядом с каждым сервисом и берет на себя функционал по управлению политиками безопасности, трафиком, сбор телеметрии и пр. Это позволяет быть нейтральным к выбору языка программирования, иметь хорошую интеграцию с Kubernetes как стандарта де-факто по оркестрации контейнерных сред и не иметь никаких зависимостей от прикладной логики сервисов. По факту именно на этом шаге эволюции технологии service mesh произошло ее окончательное выделение в отдельный инфраструктурный слой как самостоятельный уровень современной ИТ-архитектуры.

Адаптация технологии в корпоративном мире

Все большая популярность микросервисной архитектуры и контейнерных технологий и те преимущества, которые они дают, не оставили в стороне большие российские корпорации, которые начали задумываться об использовании этих подходов у себя. Вместе с этим возникает ряд вопросов по использованию service mesh и, в частности, Istio. Многие сомневаются в том, что технология достаточно зрелая для использования в корпоративном мире, что обладает достаточным функционалом и способна выдерживать большие нагрузки. Ниже будут даны ответы на пять наиболее популярных вопросов, которые нам задавали ИТ сотрудники корпораций про использование Istio, чтобы помочь убедиться в ее готовности к внедрению.

Вопрос 1: Достигла ли технология Istio достаточной зрелости для внедрения в корпорациях?

Так как мы говорим о крупных организациях, то для них вопрос зрелости той или иной технологии является одним из самых первых. Что подразумевается под зрелостью? Параметрами зрелости могут быть функциональность, стабильность работы, количество промышленных внедрений, максимальная нагрузка, а также соответствие ряду нефункциональных требований, например, по отказоустойчивости или масштабированию. Важно понимать, что для каждой компании количественные значения каждого из параметров будут своими в зависимости от ее масштабов и сценариев использования.
Что можно сказать про Istio? С точки зрения стабильности работы в мире open source немаловажным является выпуск версии 1.0, которая сообществом контрибьюторов Istio была представлена еще летом 2018 года. Примерами по использованию технологии являются уже десятки компаний, наиболее известными среди которых являются Ebay, Yahoo и банк ING. Интересными примером является история использования Istio при эксплуатации истребителя F16. Отдельно стоит выделить факт, что ведущие облачные провайдеры IBM и Google предоставляют сервисы на базе Istio для своих клиентов. Более того, Istio используется даже как часть новых open source фреймворков. Пример: Kabanero, направленный на более быструю разработку приложений поверх контейнерной инфраструктуры.

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

Вопрос 2: Service mesh для новых сред с контейнерами, а что делать с традиционным ландшафтом на виртуальных машинах?

Service mesh принадлежит типу технологий, относящихся к cloud native, которые создавались в эру развития контейнеров. Но, вспоминая реальность ИТ ландшафта корпораций, можно заметить, что промышленных систем, работающих поверх контейнеров не так много, и корпорации стоят лишь в начале пути по их массовому использованию. Многие бизнес-критичные задачи по-прежнему работают на виртуальных машинах и здесь возникает вопрос: неужели для них нельзя использовать Istio?
Краткий ответ конечно, можно. Istio позволяет создавать разные конфигурации с использованием как контейнерной инфраструктуры, так и виртуальных машин или даже bare metal. Для связи виртуальных машин и service mesh необходимо выполнить ряд действий, например обеспечить видимость IP-адресов кластера с Istio и пр. Более подробное описание и примеры можно найти здесь.

Вопрос 3: Какую модель развертывания выбрать?

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

• один или несколько кластеров (мультикластер)
• один или несколько сетевых сегментов
• одна или несколько контрольных точек управления (control panel)
• одна или несколько сеток (mesh)

На текущий момент времени можно сказать, что опция мультикластерного развертывания является наиболее востребованной в корпорациях среди прочих не случайно этому аспекту уделяется большая часть работы сообщества вокруг проекта Istio. Каковы причины выбора именно этой опции? Это наличие большого количества команд разработки отдельных продуктов и систем, это необходимость развертывания в нескольких ЦОД, это разделение на зоны разработки, тестирования и промышленной эксплуатации. Из-за всех этих требований опция развертывания одного кластера даже с несколькими сервисными сетками внутри него не позволяет обеспечить необходимый уровень изоляции ресурсов.
Безусловно, внутри мультикластерного развертывания могут быть также варианты размещения контрольных панелей: не обязательно размещать одну контрольную панель на один кластер, несколько кластеров могут использовать одну контрольную панель.
На практике на определение опции развертывания уходит не одна неделя проектирования, так как архитекторам необходимо прийти к компромиссу между хорошим уровнем изоляции ресурсов и накладными расходами на взаимодействие между кластерами.

Вопрос 4: А какую нагрузку выдержит?

Так как речь идет о корпорациях, то, как правило, они обслуживают большое число клиентов и, соответственно, имеют на своих системах большие нагрузки. Поэтому вопрос абсолютно не праздный и на практике не редки случаи, когда та или иная новая технология не давала нужную производительность и не могла обеспечить предоставление сервисов компании по запросу клиентов.
Конечно, самый грамотный ответ на этот вопрос: зависит от множества факторов. То, как развернута система, какие требования по отказоустойчивости или изоляции, какая версия технологии используется все эти факторы оказывают прямое воздействие на производительность. Но вряд ли этот ответ способен дать хоть какие-то оценки, поэтому посмотрим на уже имеющийся опыт других компаний. К сожалению, в открытых источниках сложно найти детальную информацию от компаний по их опыту использования Istio, но на различных встречах, митапах или конференциях уже в начале 2019 года одной из компаний в области информационной безопасности были представлены цифры в десятки тысяч транзакций в секунду (TPS) системы, использующей Istio. Многие корпорации провели пилотные проекты и получили результаты в несколько сотен транзакций в секунду. Много это или мало? Для примера, только несколько крупных банков России имеют нагрузки в несколько тысяч TPS на своих ИТ системах, поэтому оценка даже в несколько сотен TPS с лихвой покроет подавляющее большинство задач любой корпорации.

Вопрос 5: Когда будут нужные нам фичи?

Во время внедрения Istio технические специалисты организаций часто обращаются в IBM как к компании-основателю проекта с вопросами о сроках реализации конкретных новых фич технологии.

На этом вопросе можно хорошо показать разницу между проприетарным программным обеспечением от какого-либо вендора и миром open source. Многие корпорации с точки зрения своих ожиданий одинаково относятся и к тем, и другим технологиям, хотя в ряде моментов различия достаточно большие и ждать такой же ответственности от участников open source проекта, как от компании-производителя коммерческого ПО, странно. Безусловно, за большинством успешных open source проектов стоит одна или несколько компаний, которая, как правило, и является основателем. Но в отличие от коммерческого ПО, компания-основатель не может просто так взять и добавить фичу в проект без обратной связи от других контрибьюторов. Здесь есть и свои плюсы, и минусы. Бывали случаи, когда один из контрибьюторов брался за реализацию конкретной фичи, в которой были заинтересованы многие участники проекта, но срывал сроки из-за занятости и болезни, отодвигая релиз на несколько месяцев вперед. Поэтому в случае open source проекта гарантировать выход конкретной фичи в конкретный срок намного тяжелее, чем в случае с коммерческим ПО. С другой стороны, нет такой прямой зависимости от решения одной компании, так как реализацию может взять на себя другой участник проекта.

Поэтому четкого ответа на этот вопрос не существует, но есть ряд рекомендаций, которые позволят держать руку на пульсе происходящего в open source проекте. На примере Istio cписок рабочих групп проекта известен, их встречи и протоколы обсуждений открыты, доступна возможность задавать вопросы и описывать проблемы во всех этих, а также многих других вещах представители корпораций могут участвовать. В текущий момент времени корпорации крайне осторожно принимают участие в жизни сообщества, и очень хочется надеяться, что в ближайшее время этот тренд изменится.

Вместо заключения

Что можно сказать в итоге? Несмотря на то, что Istio достаточно молодая технология, ее текущий уровень зрелости и существующий функционал полностью отвечают требованиям корпораций. Видно, что среди крупных российских компаний интерес к Istio за последний год существенно вырос и все больше и больше ИТ команд начинают свои первые проекты, а ряд из них уже использует технологию в промышленной среде.
Для тех, кто хочет видеть Istio не только в своих ИТ системах, но и на полке или столе, мой коллега создал модель парусника как копию логотипа Istio для распечатки на 3D-принтере, которую можно скачать здесь.

Хабр, привет! Меня зовут Николай Бутенко, я руководитель Private Cloud в Mail.ru Cloud Solutions, и сегодня хочу обсудить с вами одно из самых больших заблуждений, с которыми я встречаюсь каждый день. Если вы когда-либо работали с облачными сервисами, то наверняка знаете о распространенном мнении, что перенос приложения в облако является панацеей от всех возможных с ним проблем. Я регулярно сталкиваюсь с такой позицией на встречах с самыми разнообразными заказчиками.

К сожалению, это мнение ошибочно. Часть ответственности лежит и на самом клиенте. Необходимо придерживаться определенных принципов в построении Cloud Native-приложений, чтобы обеспечить их отказоустойчивость, причем как на уровне программного кода, так и на уровне нижележащей инфраструктуры. При этом следует понимать, что даже соблюдение этих принципов не гарантирует полной защиты от всех рисков.

Поэтому если перед вами стоит задача построить на 100% отказоустойчивую и высокодоступную (High Availability, HA) систему, я рекомендую придерживаться подхода Multicloud Native Service, сочетающего лучшее в подходах Multicloud и Cloud Native. Такой подход не сводится только к использованию контейнеров: чтобы приложение могло пережить любой отказ, нужно подумать и об инфраструктуре, в частности использовать не одну, а минимум две независимые площадки, например провайдера публичного облака и частную инфраструктуру.

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

Принципы построения Cloud Native-приложений

Прежде чем рассматривать варианты построения Cloud Native-архитектур, необходимо, чтобы ваши приложения были готовы к переносу в облако. По мнению фонда Cloud Native Computing Foundation (CNCF), ставшего своего рода амбассадором в области развития облачных технологий, существует пять базовых принципов, которые выделяют Cloud Native-приложения из числа прочих.

1. Динамичность

Это возможность быстрого развертывания и конфигурирования вашей системы на любой новой площадке, что становится особенно актуальным при неожиданной смене облачного провайдера. К средствам достижения динамичности можно отнести CI/CD и подход Infrastructure As Code (IaC). Остановимся подробнее на втором.

Вся ваша инфраструктура должна быть декларативно описана в виде кода. Описание может включать перечень необходимых сервису виртуальных машин, требования к их конфигурации, топологию сети, DNS-имена и так далее. Стандартом де-факто для решения этой задачи в последнее время стал Terraform, однако существуют и альтернативы: Ansible, Salt, Cloudify, Foreman, Pulumi, AWS Cloud Formation.

Задача этих инструментов возможность быстрого развертывания, настройки инфраструктуры и контроль сохранения ее состояния, в том числе при смене провайдера. Если при небольшом количестве виртуальных машин их ручная настройка вполне возможна, то в том случае, когда это количество измеряется сотнями и дополняется сложной сетевой топологией, процесс переноса инфраструктуры может занять в лучшем случае несколько недель, а то и месяцев. Цель подхода IaC сократить это время. При наличии декларативных описаний все, что обычно требуется при переходе, это использовать другой Terraform-провайдер, изменить Environment-переменные и немного отформатировать код.

Хорошей практикой считается сочетание инструментов для декларативного описания с Post Install-скриптами, которые после запуска инфраструктуры конфигурируют информационную систему нужным образом, например устанавливают последние обновления используемого ПО и так далее. Для этой цели предназначены Ansible Playbooks, Puppet, Chef и другие инструменты, либо можно использовать cloud-unit.

2. Возможность эксплуатации

Это возможность управления жизненным циклом ваших систем в автоматизированном режиме. Это свойство тесно связано с динамичностью и включает в первую очередь применение пайплайнов CI/CD для автоматического развертывания приложений. У вас должна быть возможность оперативно выпускать новые сборки, отслеживать статус их выполнения на различных средах и выполнять откат в случае сбоев. Если вы строите приложение на основе микросервисов, для каждого сервиса рекомендуется настраивать независимый жизненный цикл (отдельную сборку). Обязательно учитывайте возможность отката обновлений или обновление только части ваших информационных систем (Rolling Update), это поможет избежать ошибок на уровне выкатки, которые могут привести к недоступности всего сервиса.

Современный IT-рынок предлагает множество решений для построения CI/CD: GitLab CI/CD, Jenkins, GoCD и другие.

3. Возможность наблюдения

Это мониторинг инфраструктуры и разнообразных бизнес-метрик ваших систем. Необходимость мониторинга для любого приложения, будь то Startup- или Enterprise-решение, сложно переоценить. Однако я регулярно сталкиваюсь с проектами, где мониторинг отсутствует, что в большинстве случаев приводит к серьезным проблемам. При переходе в облако мониторинг как минимум поможет проверять заявленный SLA провайдера и получать ретроспективу производительности при разборе спорных ситуаций, как максимум находить узкие места в архитектуре и исправлять их до того, как они станут влиять на пользователей.

В большинстве случаев облачные провайдеры поддерживают все стандартные инструменты мониторинга, такие как Prometheus, Grafana, Fluentd, OpenTracing, Jaeger, Zabbix и другие, а также могут предлагать собственный встроенный мониторинг.

4. Эластичность

Это возможность масштабирования ваших приложений в зависимости от изменяющейся нагрузки. Когда речь заходит об автоматическом масштабировании, первым из доступных инструментов на ум приходит, конечно же, Kubernetes, ставший своего рода стандартом оркестрации контейнерных приложений. И действительно, он поддерживает все необходимые уровни масштабирования, а у некоторых провайдеров в том числе даже автомасштабирование на уровне кластера из коробки. Однако отмечу, что его использование отнюдь не является обязательным: можно построить эластичное приложение на основе чистого IaaS (Infrastructure as a Service), используя мониторинг и преднастроенные хуки для обработки изменений нагрузки. Да, Kubernetes значительно упрощает этот процесс, но не стоит забывать, что он является всего лишь инструментом.

Чтобы соответствовать подходу Cloud Native, крайне важно планировать свою архитектуру так, чтобы в ней не было узлов, масштабируемых только вертикально (путем увеличения/уменьшения выделенных ресурсов), так как в конечном итоге вы будете ограничены мощностями нижележащего оборудования или гипервизоров в облаке. Постарайтесь обеспечить каждому узлу возможность горизонтального масштабирования за счет изменения числа экземпляров самого приложения.

Отдавайте предпочтение горизонтальному масштабированию

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

5. Отказоустойчивость

Это возможность быстрого автоматического восстановления приложений в случае сбоев с минимальным влиянием на пользователей. Несмотря на определенные гарантии от облачных провайдеров (SLA), нужно обязательно обеспечивать отказоустойчивость на уровне самих приложений и инфраструктуры.

Приведу несколько основных рекомендаций:

1. Составьте план учений DRP (Disaster Recovery Plan) и регулярно проводите согласно нему стресс-тесты для выявления единых точек отказа в системе (Single Point Of Failure, SPOF). Очень важно учитывать все возможные домены отказа, в том числе проверяя поведение системы в боевом режиме при выходе из строя отдельных узлов или целого плеча системы. Конечно, обеспечивая возможность их быстрого включения обратно.
2. Используйте георепликацию для обеспечения высокой доступности ваших данных. Георепликация гарантирует хранение копий данных в нескольких дата-центрах. Но учитывайте, что геораспределенное хранилище имеет более высокие задержки отклика и не подходит для решений, требующих низкого Latency, например высоконагруженных баз данных.
3. Используйте балансировку нагрузки на всех уровнях вашего приложения: перед web-серверами, серверами приложений и серверами баз данных. Все сетевые вызовы должны направляться не на прямые адреса виртуальных машин, а на адреса балансировщиков во избежание создания дополнительных точек отказа. Большинство облачных провайдеров предлагает балансировку нагрузки как сервис (Load Balancer as a Service, LBaaS). Учитывайте возможность выхода из строя части узлов, чтобы перераспределенная нагрузка не убила оставшиеся экземпляры сервиса. Используйте также надежные GSLB для балансировки между разными провайдерами.
4. Используйте резервное копирование. Хотя я в своей практике сталкивался с примерами сервисов и информационных систем, где была построена правильная Cloud Native-архитектура и вовсе отказались от ведения бэкапов: они стали не актуальны. Так что ведение бэкапов желательно, но вовсе не обязательно но только если вы грамотно используете Multicloud Native-подход. Если вы сомневаетесь, всегда делайте бэкапы!
5. Проведите аудиты безопасности, например Penetration Test, на предмет уязвимостей и устойчивости к разным типам атак.

С другими рекомендациями по созданию отказоустойчивых приложений от Mail.ru Cloud Solutions можно ознакомиться по ссылке.

Виды рисков при работе с облаком

Предположим, ваш сервис или информационная система полностью соответствует описанным выше принципам Cloud Native-приложений. Вы выбрали подходящего провайдера и осуществили переход в облако с учетом всех рекомендаций. Означает ли это, что теперь вашим сервисам ничего не угрожает и возможность их недоступности полностью исключена? К сожалению, нет. Даже после переноса приложения в облако остаются определенные риски, которые условно можно разделить на три группы.

1. Географические риски

Любой, даже самый надежный облачный провайдер не застрахован от чрезвычайных ситуаций, будь то стихийные бедствия или аварии техногенного характера. Пожары, наводнения и даже банальная поломка кабеля это лишь неполный перечень того, что может надолго вывести ЦОДы из строя, а в худшем случае полностью их уничтожить.

Думаю, многие помнят пожар в московском дата-центре OST провайдера DataLine в июне 2019-го. Но тогда удалось обойтись малыми жертвами все клиенты были оперативно переведены на резервные площадки, да и урона машинному залу фактически нанесено не было: пострадали лишь кровля и система кондиционирования. К гораздо большим потерям привел недавний пожар в дата-центре SBG2 провайдера OVH в Страсбурге, обернувшийся падением множества сервисов по всему миру, полным уничтожением одного ЦОДа (SBG2) и вынужденной потерей второго ЦОДа, расположенного рядом и частично пострадавшего от пожара (SBG1). В этом как раз и состоит суть географических рисков: когда ЦОДы провайдера территориально расположены близко друг к другу, в случае катастрофы они не страхуют друг друга, а все оказываются под угрозой.

Поэтому при выборе провайдера обязательно обращайте внимание на два пункта:

1. У провайдера несколько ЦОДов.
2. ЦОДы расположены на достаточном расстоянии друг от друга, по возможности используют разные каналы связи, интернет-провайдеров и питаются от различных электростанций.

На что обратить внимание при выборе облачного провайдера для минимизации географических рисков

2. Government-риски

Сюда входят различные политические и законодательные решения, которые могут неожиданно потребовать смены провайдера. В качестве наиболее яркого примера последних лет можно назвать бан социальной сети Parler в январе 2021 года, когда Amazon отказал этой платформе в дальнейшем хранении данных и приложение фактически стало недоступным. В России можно вспомнить 152-ФЗ, запрещающий хранить персональные данные пользователей за пределами РФ, что автоматически ограничивает выбор провайдеров для определенных организаций (банковский сектор, медицинские организации и так далее).

Особенность Government-рисков в том, что выход законопроектов и иных политических решений, как правило, требует очень быстрой реакции, поэтому крайне важно всегда быть готовым к незапланированной смене провайдера.

3. Риски сбоев на стороне провайдера

Это технические сбои на уровне провайдера в целом, чаще всего связанные с человеческим фактором, например выходом неверных обновлений, ошибками в прогнозировании потребляемых ресурсов и так далее. Даже у таких общепризнанных облачных лидеров, как Amazon и Google, регулярно фиксируются сбои в сервисах. Например, в Google Cloud за последний год произошло свыше 100 инцидентов, в AWS сбои происходят минимум раз в год. В качестве примера можно вспомнить крупный сбой на стороне AWS в ноябре 2020 года, в результате которого возникли неполадки в работе множества сайтов и приложений, включая iRobot, Flickr, Roku и Adobe Spark.

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

Таким образом, мы рассмотрели три вида рисков, с которыми вы можете столкнуться после перевода своих приложений в облако. Но если первая группа рисков легко устраняется за счет выбора провайдера с географически разнесенными ЦОДами, то риски из второй и третьей групп, по моему мнению, можно исключить, только применив Multicloud Native Service-подход.

Для устранения всех возможных рисков при работе в облаке рекомендуется подход Multicloud Native Service

Multicloud Native Service и Multicloud: в чем разница?

В первую очередь следует различать подходы Multicloud и Multicloud Native Service.

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

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

Вариант применения подхода Multicloud: использование данных приложения, запущенного в одном облаке, для анализа в другом облаке

Вариант применения подхода Multicloud: хранение данных в нескольких облаках

Подход Multicloud Native Service подразумевает, что вы разрабатываете свой продукт таким образом, что он соответствует принципам Cloud Native и полностью абстрагируется от конкретного облачного провайдера. В первую очередь это достигается за счет отказа от проприетарных сервисов, о которых мы еще подробно поговорим. Такой подход позволяет одновременно развертывать ваши приложения в нескольких выбранных вами облаках и легко переносить их из одного облака в другое без простоев.

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

Подход Multicloud Native Service: развертывание и использование приложения в нескольких облаках одновременно

Таким образом, если Multicloud это про количество облачных провайдеров, то Multicloud Native Service это больше про сами приложения, их соответствие всем принципам Cloud Native и возможность развертывания на нескольких независимых площадках. Чаще всего Multicloud Native Service строится на основе Multicloud, но так происходит не всегда, так как в качестве площадок в этом случае могут выступать не только публичные облака или гибридные инфраструктуры, но и варианты с собственными ЦОДами компании.

В дальнейшем я буду говорить именно про подход Multicloud Native Service.

Варианты построения архитектур Multicloud Native Service

Существует два основных способа построения архитектур по подходу Multicloud Native Service:

1. Использование нескольких публичных провайдеров

В этом случае одно плечо инфраструктуры строится на стороне одного публичного провайдера, а второе на стороне другого провайдера. Например, можно комбинировать локального провайдера, действующего на территории РФ (Mail.ru, Яндекс, МТС, Ростелеком и другие), и глобального, действующего во всем мире (AWS, Google Cloud, Alibaba, Azure и другие), либо использовать двух локальных провайдеров одновременно.

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

2. Сочетание частной инфраструктуры и публичного провайдера

Это более распространенный вариант в российских реалиях, когда клиент продолжает использовать традиционную инфраструктуру на своей стороне (это может быть голое железо, виртуализированная среда или даже приватное облако) плюс добавляет к ней публичного облачного провайдера. Чаще всего получившуюся архитектуру называют гибридным облаком (Hybrid), но если ПО и инфраструктура в этом случае реализуют все принципы Cloud Native-приложений, то систему в целом можно называть Multicloud Native Service.

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

Упрощенная схема Multicloud Native Service-архитектуры: два плеча, в роли которых могут выступать два облачных провайдера либо один провайдер и частная инфраструктура

Возможные проблемы при переходе на Multicloud Native Service и как их избежать

Разумеется, у подхода Multicloud Native Service есть свои подводные камни. Ниже приведен перечень наиболее часто встречающихся проблем и описаны способы их решения:

1. Сетевые задержки

Если для вашей системы приоритетны низкие задержки, например требуются синхронные реплики БД, то, скорее всего, вам не подойдет вариант сочетания локального и глобального провайдеров в силу их территориальной удаленности. Следует выбирать провайдеров, которые смогут обеспечить минимальный Latency, например через выделенный канал Direct Connect. Это могут быть два локальных провайдера на территории РФ либо сочетание локального облачного провайдера и частной инфраструктуры. Также Direct Connect позволяют делать некоторые глобальные провайдеры.

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

2. Разница в производительности вычислительных ресурсов

Сочетание различных провайдеров чревато тем, что мощность используемого в них оборудования будет сильно отличаться. Поэтому при выборе провайдера и последующей настройке конфигураций ВМ важно не допускать сильных расхождений в производительности ресурсов, используемых в разных плечах. Тип и частота процессоров, объем, пропускная способность и величина задержек на дисках, размер оперативной памяти все эти и другие параметры должны быть примерно одинаковы. В противном случае обработка данных в двух плечах получится крайне неравномерной.

3. Vendor lock-in

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

Пояснить проблему Vendor lock-in проще всего на примере референсных архитектур (Architecture Reference), предлагаемых большинством ведущих облачных провайдеров. Эти архитектуры описывают готовые решения (комбинации компонентов, их взаимосвязи и так далее) для типовых архитектурных задач, которые могут возникнуть при переходе в облако. Например, референсные архитектуры от Google и AWS.

На рисунке ниже приведен пример референсной архитектуры от AWS для обработки логов, которые впоследствии используются для построения мониторинга. Из рисунка очевидно, что для решения архитектурной задачи провайдер предлагает сразу несколько своих проприетарных сервисов: AWS Lambda, Amazon Kinesis Data Streams и так далее.

Пример референсной архитектуры от AWS. Источник

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

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

Какому провайдеру отдать предпочтение

В предыдущих разделах мы определились, что для построения отказоустойчивых приложений лучше всего использовать пару различных облачных провайдеров. Но как сделать правильный выбор из множества доступных на современном IT-рынке вариантов, какие возможности предлагает идеальный провайдер? А также на какие сервисы стоит ориентироваться, чтобы не попасть в ловушку Vendor lock-in?

По моему мнению, джентльменский набор современного облачного провайдера должен выглядеть примерно так:

1. Реализация подхода IaC (Infrastructure as Code). В большинстве случаев это подразумевает поддержку Terraform, но не обязательно. В Mail.ru Cloud Solutions работает стандартный Terraform-провайдер, также можно использовать для управления инфраструктурой наш собственный Terraform-провайдер, доработанный под нашу платформу. Также сюда обязательно входит управление жизненным циклом виртуальных машин (Virtual Machine Lifecycle Management).
2. Наличие хорошо документированных CLI и API. Необходимо для быстрого и удобного управления облачными ресурсами.
3. Возможность подключения DC (Direct Connect). Это установка выделенного сетевого соединения между облаком и своим собственным ЦОДом или офисом с целью изолированного сетевого соединения, а также увеличения пропускной способности и обеспечения более устойчивой работы, чем через подключение по интернету. При этом уровень, на котором настраивается соединение, не принципиален (L2, L3).
4. Поддержка CDN (Content Delivery Network). Использование географически распределенной сетевой инфраструктуры, лежащей в основе CDN, позволяет быстро раздавать контент по всему миру с задержкой в считаные миллисекунды даже во время пиковых нагрузок.
5. Наличие DNS и балансировщиков сетевой нагрузки. Это важная часть настройки любых виртуальных сетей.
6. Соответствие местному законодательству и наличие прочих сертификатов. Например PCI DSS, ISO 27*, GPDR для Европы, ФСТЭК для России и так далее. Это поможет избежать дополнительной головной боли при локализации.
7. Технологическое соответствие между провайдерами. Если, например, ваша исходная инфраструктуру использует VMWare, логично выбрать провайдера предоставляющего гипервизор ESXi, желательно той же версии. Это сильно упростит миграцию. Тоже справедливо и для других платформ и гипервизоров. Требование не является обязательным, можно разместиться и на разных платформах.
8. Поддержка основного пула сервисов:
   
   • контейнеризация/оркестрация (общепризнанный стандарт K8s или OpenShift);
   • базы данных как сервис;
   • S3 объектное хранилище для хранения больших объемов данных и статического контента;
   • очереди сообщений (Simple Queue Service, SQS);
   • Big Data с этим сервисом стоит быть аккуратным, чтобы не получить Vendor lock-in, так как некоторые провайдеры реализуют его по-своему;
   • мониторинг инфраструктуры и бизнес-метрик, в идеале сервис мониторинга должен быть независимым;
   • бессерверные вычисления (Function as a Service, FaaS). Незаменимы для обработки непрогнозируемой нагрузки без сохранения состояния (чат-боты, социальные сети и так далее);
   • аудит как сервис;
   • стандартные функции вида биллинга, сервисов ИБ (такие как WAF, AntiDDOS, возможность проведения аудитов ИБ), возможности использовать idP, RBAC;
   • выбирайте надежный Global Server Load Balancer, не надейтесь только на балансировку на уровне облачного провайдера, так как она подвержена тем же рискам.

Выводы

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

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

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

Также важно понимать, что подходы Cloud Native и построенный на его основе Multicloud Native Service это в большей степени не про используемые вами программные инструменты. Например, они не требуют от вас жесткого использования контейнеров и Kubernetes, как принято считать. Применение этих подходов в первую очередь означает, что вы полностью продумали инфраструктуру и проверили все возможные домены отказа. И в случае сбоев вы не возлагаете всю ответственность на своего провайдера, осознавая, что успешная работа приложений в облаке во многом определяется и вашими действиями тоже.

Любите облака, и они ответят вам взаимностью.

Что еще почитать:

1. VMware и OpenStack: сравниваем две платформы для развертывания инфраструктуры.
2. Как правильно посчитать TCO инфраструктуры.
3. Наш канал в Телеграм о цифровой трансформации и IT-бизнесе.

Привет, Хабр!

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



Приятного чтения!

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

Контейнеры зародились как специальная конструкция для изоляции процессов в Linux; в состав контейнеров с 2007 входят cgroups, а с 2002 пространства имен. Контейнеры оформились еще лучше к 2008 году, когда стала доступна LXC, а в Google разработали свой внутрикорпоративный механизм под названием Borg, где вся работа ведется в контейнерах. Отсюда перенесемся в 2013, когда состоялся первый релиз Docker, и контейнеры окончательно перешли в разряд популярных массовых решений. На тот момент основным инструментом для оркестрации контейнеров был Mesos, хотя, бешеной популярностью он не пользовался. Первый релиз Kubernetes состоялся 2015 году, после чего этот инструмент де-факто стал стандартом в области оркестрации контейнеров.

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

Инфраструктура как YAML

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

apiVersion: v1kind: Podmetadata:  name: site  labels:    app: webspec:  containers:    - name: front-end      image: nginx      ports:        - containerPort: 80

С таким представлением специалистам по DevOps или SRE удобнее полностью выражать свои рабочие нагрузки, без необходимости писать программный код на таких языках как Python или Javascript.

Другие достоинства организации инфраструктуры как данных, в частности, таковы:

• GitOps или контроль версий Git Operations Version. Такой подход позволяет держать все YAML-файлы Kubernetes в репозиториях git, благодаря чему вы в точности можете отследить, когда было внесено изменение, кто его внес, и что именно изменилось. Благодаря этому повышается прозрачность операций в пределах всей организации, повышается эффективность работы в силу устранения неоднозначности, в частности, в том, где сотрудники должны искать нужные им ресурсы. В то же время, становится проще автоматически вносить изменения в ресурсы Kubernetes путем обычного слияния pull-запроса.
• Масштабируемость. Когда ресурсы определены в виде YAML, операторам кластера становится чрезвычайно просто изменить одно или два числа в ресурсе Kubernetes, изменив тем самым принципы его масштабирования. В Kubernetes предусмотрен механизм для горизонтального автомасштабирования подов, при помощи которого удобно определять, каково минимальное и максимальное количество подов, которое требуется в конкретной развернутой конфигурацией, чтобы справляться с низким и высоким уровнем трафика. Например, если вы развернули конфигурацию, для которой требуются дополнительные мощности из-за резкого всплеска трафика, то показатель maxReplicas можно изменить с 10 на 20:

apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata:  name: myapp  namespace: defaultspec:  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: myapp-deployment  minReplicas: 1  maxReplicas: 20  metrics:  - type: Resource    resource:      name: cpu      target:        type: Utilization        averageUtilization: 50

• Безопасность и управление. YAML отлично подходит для оценки того, как те или иные вещи развертываются в Kubernetes. Например, серьезная проблема, связанная с обеспечением безопасности, касается того, запускаются ли ваши рабочие нагрузки из-под пользователя, не обладающего правами администратора. В данном случае нам могут пригодиться такие инструменты как conftest, валидатор YAML/JSON, плюс Open Policy Agent, валидатор политик, позволяющий убедиться, что контекст SecurityContext ваших рабочих нагрузок не позволяет контейнеру работать с привилегиями администратора. Если требуется это обеспечить, пользователи могут применить простую политику rego, вот так:

package maindeny[msg] {  input.kind = "Deployment"  not input.spec.template.spec.securityContext.runAsNonRoot = true  msg = "Containers must not run as root"}

• Варианты интеграции с облачным провайдером. Одна из наиболее заметных тенденций в современных высоких технологиях запускать рабочие нагрузки на мощностях общедоступных облачных провайдеров. При помощи компонента cloud-provider Kubernetes позволяет любому кластеру интегрироваться с тем облачным провайдером, на котором он работает. Например, если пользователь запустил приложение в Kubernetes на AWS и хочет открыть доступ к этому приложению через сервис, облачный провайдер помогает автоматически создать сервис LoadBalancer, который автоматически предоставит балансировщик нагрузки Amazon Elastic Load Balancer, чтобы перенаправить трафик в поды приложений.

Расширяемость

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

Например, если мы хотим определить ресурс CronTab, то могли бы сделать нечто подобное:

apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata:  name: crontabs.my.orgspec:  group: my.org  versions:    - name: v1      served: true      storage: true      Schema:        openAPIV3Schema:          type: object          properties:            spec:              type: object              properties:                cronSpec:                  type: string                  pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'                replicas:                  type: integer                  minimum: 1                  maximum: 10  scope: Namespaced  names:    plural: crontabs    singular: crontab    kind: CronTab    shortNames:    - ct

Позже мы можем создать ресурс CronTab приблизительно таким образом:

apiVersion: "my.org/v1"kind: CronTabmetadata:  name: my-cron-objectspec:  cronSpec: "* * * * */5"  image: my-cron-image  replicas: 5

Еще один вариант расширяемости в Kubernetes заключается в том, что разработчик может писать собственные операторы. Оператор это особый процесс в кластере Kubernetes, работающий по паттерну контур управления. При помощи оператора пользователь может автоматизировать управление CRD (собственными определениями ресурсов), обмениваясь информацией с Kubernetes API.

В сообществе есть несколько инструментов, при помощи которых разработчикам удобно создавать собственные операторы. Среди них Operator Framework и его Operator SDK. Этот SDK предоставляет основу, отталкиваясь от которой, разработчик может очень быстро приступить к созданию оператора. Скажем, можно начать с командной строки примерно таким образом:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

Так создается весь стереотипный код для вашего оператора, в том числе, файлы YAML и код на Golang:

.|____cmd| |____manager| | |____main.go|____go.mod|____deploy| |____role.yaml| |____role_binding.yaml| |____service_account.yaml| |____operator.yaml|____tools.go|____go.sum|____.gitignore|____version| |____version.go|____build| |____bin| | |____user_setup| | |____entrypoint| |____Dockerfile|____pkg| |____apis| | |____apis.go| |____controller| | |____controller.go

Затем можно добавлять нужные API и контроллер, вот так:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

После чего, наконец, собрать оператор и отправить его в реестр вашего контейнера:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Если разработчику требуется еще более полный контроль, то можно изменить стереотипный код в файлах на Go. Например, чтобы видоизменить специфику контроллера, можно внести изменения в файл controller.go.

Другой проект, KUDO, позволяет создавать операторы, пользуясь одними лишь декларативными YAML-файлами. Например, оператор для Apache Kafka будет определяться примерно так. С его помощью можно всего лишь парой команд установить кластер Kafka поверх Kubernetes:

$ kubectl kudo install zookeeper$ kubectl kudo install kafka

А затем настроить его при помощи еще одной команды:

$ kubectl kudo install kafka --instance=my-kafka-name \            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 \            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m \            -p BROKER_COUNT=5 -p BROKER_MEM=4096m \            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 \            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

Инновации

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

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

Сообщество

Еще один серьезный аспект популярности Kubernetes заключается в силе его сообщества. В 2015 году, по достижении версии 1.0, Kubernetes спонсировался Cloud Native Computing Foundation.

Также существуют разнообразные сообщества SIG (специальные группы по интересам), нацеленные на проработку различных областей Kubernetes по мере того, как этот проект развивается. Эти группы постоянно добавляют все новые возможности, благодаря чему работать с Kubernetes становится удобнее и удобнее.

Фонд Cloud Native Foundation также проводит CloudNativeCon/KubeCon, которая, на момент написания этого текста, является крупнейшей опенсорсной конференцией в мире. Как правило, она проводится три раза в год и собирает тысячи профессионалов, желающих улучшить Kubernetes и его экосистему, а также освоить новые возможности, появляющиеся каждые три месяца.

Более того, в Cloud Native Foundation есть Комитет по техническому надзору, который, совместно с SIGs рассматривает новые и имеющиеся проекты фонда, ориентированные на облачную экосистему. Большинство из этих проектов помогают улучшить сильные стороны Kubernetes.

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

Будущее

Один из основных вызовов, с которыми разработчикам придется иметь дело в будущем, является умение сосредотачиваться на деталях самого кода, а не на той инфраструктуре, в которой он работает. Именно этим тенденциям отвечает бессерверная архитектурная парадигма, являющаяся сегодня одной из ведущих. Уже существуют продвинутые фреймворки, например, Knative и OpenFaas, которые используют Kubernetes для абстрагирования инфраструктуры от разработчика.

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

Прим. перев.: это перевод статьи, подготовленной по мотивам недавнего выступления Richard Hartmann заметного представителя команды разработчиков Prometheus, директора по сообществам из Grafana Labs, основателя проекта OpenMetrics и председателя группы SIG Observability в CNCF. Автор подводит итоги последнего года в жизни Open Source-проекта (и сообщества) Prometheus, а также рассказывает об основных трудностях и ближайших перспективах.



Во время PromCon Online 2020 я выступил с докладом под названием Будущее Prometheus и его экосистемы. И хочу поделиться с вами его ключевыми моментами.

Резюме

Со времени прошлой конференции PromCon 2019 в Prometheus произошло множество изменений.

2.14

В версии 2.14 появился новый интерфейс на React. Хотя по функциональности он пока отстает от старого, мы над ним работаем и продолжаем улучшать.

2.15

Версия 2.15 прошла под знаком API метаданных. Формат экспозиции Prometheus уже давно поддерживает специальные выражения HELP, TYPE и т.п., однако сам Prometheus раньше просто отбрасывал эти данные. Теперь, когда они остаются, можно открыть внешний доступ к ним через API. Например, Grafana уже пользуется этой возможностью и предоставляет пользователям дополнительную информацию о временных рядах, с которыми те работают:

2.16

В версии 2.16 основное внимание было уделено различным улучшениям и стабильности. Например, пользователи еще с 2016 года просили о возможности выбора локального времени в UI, а также о реализации журнала запросов было приятно закрыть эти проблемы.

2.17

К слову о затянувшихся запросах на фичи: версия 2.17, наконец, дала долгожданную I в ACID для БД: изолированность.

2.18

В 2.18 были улучшены трассировка и поддержка экземпляров в формате экспозиции. Экземпляры это первый заметный для пользователя эффект от внедрения OpenMetrics в Prometheus. Объединив их с Grafana, можно достичь удобной детализации, позволяющей переходить от:



к:

2.19

В 2.19 сократили потребление памяти на целых 50%! Даже несмотря на то, что Prometheus уже весьма эффективна, остается значительный потенциал для оптимизации это одновременно и воодушевляет, и пугает.

Такой график прекрасная тому иллюстрация:

2.20

Версия 2.20 может похвастаться самым длинным списком изменений с момента выхода v2.6(!). Главным, вероятно, является родная поддержка обнаружения сервисов для Docker Swarm и DigitalOcean.

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

node_exporter

Подводя итог, хочу заметить, что node_exporter достиг версии 1.0 и теперь включает в себя ЭКСПЕРИМЕНТАЛЬНУЮ поддержку TLS. Фонд Cloud Native Computing Foundation проспонсировал аудит node_exporter'а компанией Cure53 (он охватывал как экспортер в целом, так и нашу реализацию TLS в частности). И он того стоил вдвойне: мы не только проверили TLS перед тем, как копировать его в другие экспортеры, но и использовали node_exporter как подопытного кролика, с которого копируются и иные паттерны.

Будущее

Иногда у меня возникает ощущение, что мы как проект почиваем на лаврах. Некоторое время назад я запустил мозговой штурм внутри Grafana под девизом Prometheus'у не хватает функций и призвал Red Hat поступить так же. Попутно мы создали доступный для всей команды Prometheus документ сразу обо ВСЕМ. Он служит основой для рассмотрения конкретных тем, разбитых на пункты для обсуждения во время dev-саммитов (по мере готовности этих пунктов).

Саммиты разработчиков

В прошлом году у нас было два dev-саммита: один после KubeCon EU, второй после PromCon. Планировалось то же самое сделать в 2020 году, но помешал COVID. В этом году пока саммитов не было, но я полагаю, что мы нашли выход: более короткие, частые и виртуальные встречи. Мы проводим блоки по 4 часа вместо того, чтобы собираться сразу на 1-2 дня. Первый такой dev-саммит прошел 10 июля, а следующий, вероятно, состоится 7 августа. Мы продолжим проводить их, пока не разберем все накопившиеся вопросы (хотя их число постоянно растет по мере того, как добавляются все новые пункты из вышеупомянутого документа).

Сейчас я хочу сделать две вещи:

1. Ознакомить вас с тем, о чем нам удалось договориться. Не думаю, что будет полезно или справедливо рассказывать о том, над чем мы пока еще активно думаем. При этом я буду поднимать темы в таком же порядке, в котором мы их обсуждали. Этот порядок определяется общим голосованием темы, набравшие наибольшее число голосов, обсуждаются в первую очередь.
2. Немного рассказать о том, как именно проходят эти встречи и о некоторых соображениях, лежащих в их основе. Хотя я, вероятно, скоро еще напишу пару заметок о ведении этих рабочих сессий.

Метаданные

Метаданные начинают приносить реальную пользу в Prometheus (см. 2.15 выше). Нам нужно реализовать больше возможностей для работы с метаданными (например, распространять их через удаленное чтение/запись). Консенсус ниже не охватывает такие интересные вопросы, как Что делать, если метаданные изменились/пропали? или Что делать, если они станут вектором атаки?.

КОНСЕНСУС: Мы хотим лучше поддерживать метаданные. Работа будет вестись в специальном документе.

КОНСЕНСУС: PR 6815 пойдет в качестве ЭКСПЕРИМЕНТАЛЬНОГО временного решения. Скорее всего, оно будет другим в версиях 3.х.

Изменения в рабочем процессе и s/master/main/

Тема разгребания мусора, скопившегося в рабочих процессах, не требует особого пояснения, однако следует сказать несколько слов об устранении словоблудия (единстве терминологии). Мы серьезно настроены на очистку терминологии: это не самое важное, но то, чем мы можем заняться уже сейчас. Пока мы ждем соответствующего инструментария от GitHub. Как только он появится, попробуем привлечь к этой работе платного стажера через Community Bridge.

Я веду переговоры с Linux Foundation и CNCF о том, чтобы потенциально реализовать это во всех проектах. Отличная возможность для того, кто интересуется данной тематикой: возможность изучить множество проектов, поработать с различными инструментами, познакомиться со многими людьми. Свяжитесь со мной в Twitter (@TwitchiH) или по почте (richih на сервере grafana.com), если вам это интересно.

КОНСЕНСУС: Установить Требовать прохождения проверок статусов перед merge'ем во всех репозиториях prometheus/ Не допускать прямые push'и в main branch? Не допускать force push'и в main branch?

КОНСЕНСУС: Отключить force push'и во все main branches.

КОНСЕНСУС: Поведение по умолчанию разрешает push'и в main branch, однако его следует отключить для некоторых важных репозиториев, например, prometheus/prometheus (на усмотрение maintainer'а).

Заполнение данными (backfilling)

Это один из самых давнишних запросов на фичи и хороший пример того, как следует подходить к консенсусу. В команде Prometheus циркулирует множество разных мнений по этому поводу, и сложно прийти к общему знаменателю. Поэтому я написал ограниченное и весьма конкретное консенсус-предложение с тремя критериями: Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным блоком.

После продолжительных обсуждений и попыток прийти к консенсусу стало ясно, что сделать это так просто не получится. Поэтому я переформулировал предложение следующим образом: Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с head block.

Только заставив каждого высказать свое определенное мнение по этому поводу, мы смогли прийти к окончательному варианту: Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с head block при условии надлежащей реализации. Каждое слово здесь подобрано, чтобы отражать точную степень и границы консенсуса.

КОНСЕНСУС: Мы хотим поддерживать текстовый формат экспозиции Prometheus и OpenMetrics, и один четко определенный CSV-формат для импорта данных.

КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным.

НЕ КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с головным блоком.

КОНСЕНСУС: Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с головным блоком при условии надлежащей реализации.

Вендоринг

Еще одна из задач, связанных с наведением порядка. Здесь я хочу покритиковать Go: он был разработан в мире, в котором единый монореп это норма. Google хранит весь (или основную часть) своего общего кода в единственном репозитории. Этот подход имеет много преимуществ, но плохо переносится на реальные условия. Go медленно, но верно уходит от этого наследия.

Занимательный факт: я написал консенсус-предложение практически в самом начале обсуждения. Было понятно, что мы как минимум его попробуем. Было понятно, что Ben Kochie вызовется сделать это. И было понятно, что жертвой станет node_exporter. Как правило, мы стремимся совершенствовать рабочий процесс, и волонтером всегда выступает Ben, а node_exporter является тем тестовым стендом, с которого мы потом копируем результаты в другие экспортеры. И да, было важно, чтобы обсуждение продолжалось некоторое время и чтобы люди сами пришли к этому, вместо того, чтобы ставить их перед фактом.

КОНСЕНСУС: Удалить его в node_exporter и посмотреть, довольны ли мы будем результатом.

Списки рассылки и IRC

Google заблокирован в Китае, однако наши списки рассылки работают на нем. Мы решили попробовать сделать так, чтобы можно было подписываться по электронной почте. Я проверил: prometheus-users+subscribe@googlegroups.com работает. Также можно почитать архивы (https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html), если есть такое желание.

Кроме того, мы позаботились о том, чтобы все желающие могли использовать IRC через Matrix, поскольку для некоторых xkcd 1782 весьма актуален.

КОНСЕНСУС:

Посмотреть, возможно ли подписываться на наши списки рассылок без учетки Google и подключить этот функционал; для публикации по-прежнему требуется подписка.

Добавить ссылку на общедоступный архив списков рассылок в разделе docs/community и рассказать, как можно подписаться на рассылки без учетной записи Google.

Отключить требования идентификации в каналах IRC, чтобы упростить использование Matrix; вернуть все назад, если будут атаки.

Документация

Позвольте повторить слова, сказанные на саммите: Самое первое, что мне не понравилось в Prometheus в 2015, году это документация; в 2020-м я ее просто ненавижу. Она сложна в использовании и почти бесполезна, подходит только тем, кто уже знает, что делает, или по крайней мере хорошо представляет себе концепции. Короче говоря, мы будем работать в этом направлении:

КОНСЕНСУС:

Мы разделим документацию на три части:

* Руководство пользователя (user manual) как простой для понимания вариант по умолчанию.
* Справка (reference) по аналогии с той, что у нас сейчас есть с примерами на PromQL для ввода/вывода.
* Гайды (guides), желательно на модульной основе.

Мы попросим Diana Payton разработать единый стиль оформления, общую концепцию и т.п. для всей документации.

Мы постараемся не ломать ссылки понапрасну.

Если вам это интересно, в настоящее время мы ищем технического писателя в Grafana Cloud, который будет работать над официальной upstream-документацией для Prometheus. В конце концов, мы серьезно относимся к своим обязательствам перед сообществом.

Как обычно, записи по итогам dev-саммита будут опубликованы. Также можно почитать итоги саммита 2020-1 и саммитов прошлых лет.

P.S. от переводчика

Читайте также в нашем блоге:

• Мониторинг и Kubernetes (обзор и видео доклада);
• Устройство и механизм работы Prometheus Operator в Kubernetes;
• Представляем k8s-image-availability-exporter для обнаружения пропавших образов в Kubernetes.

Сообщества пользователей Сeph переполнены историями, как всё сломалось, не завелось, отвалилось. Значит ли это, что технология плохая? Совсем нет. Это означает, что идёт развитие. Пользователи натыкаются на узкие места технологии, находят рецепты и решения, отправляют в апстрим патчи. Чем больше опыта с технологией, чем больше пользователей делают на неё ставку, тем больше будет описанных проблем и решений. То же самое совсем недавно было с Kubernetes.

Сeph прошёл долгий путь от проекта Сейджа Уэйла в 2007 году в его докторской диссертации до поглощения фирмы Уэйла Inktank корпорацией Red Hat в 2014 году. И сейчас многие узкие места Сeph уже известны, многие кейсы от практиков можно изучить и взять на заметку.

Хватит читать истории о граблях и фейлах, хватит заочно разочаровываться в технологии 1 сентября стартует бета-тест нашего практического видеокурса по Ceph. Научим работать с технологией стабильно, эффективно и с удовольствием.

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

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

Вы можете посмотреть итоговую программу и скидку для бета-тестеров на странице курса.

В самом начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph.

К 1 сентября будут готовы темы:

Что такое Ceph и чем он не является?
Обзор архитектуры;
Интеграция Ceph с распространенными Cloud Native решениями.

К 1 октября вы получите:

Установка Ceph;
Мониторинг Ceph;
Производительность Ceph. Математика производительности.

К 15 октября:

Все остальное.

Спикер курса:

Виталий Филиппов. Разработчик-эксперт в компании CUSTIS, линуксоид, "цефер". Занимается разработкой на React, Node.js, PHP, Go, Python, Perl, Java, C++, причастен к инфраструктурным задачам. Тестировал и исследовал код Ceph, отправлял в апстрим патчи. Имеет глубокие знания по производительности Ceph, автор Wiki-статьи Производительность Ceph.

Также появятся другие спикеры-практики по мере развития курса.

К 15 октября участники получат курс по Ceph, практически настроенный под их пожелания, боли и вопросы.

Присоединяйтесь!