Русский
Русский
English
Статистика
Реклама

Kubernetes

Docker уже умер или все, что вы хотели узнать про Devops, но боялись спросить

25.10.2020 14:05:47 | Автор: admin

Недавно в наших соцсетях выступал Александр Чистяков, DevOps с 7-летним опытом и сооснователь Санкт-Петербургского сообщества DevOps-инженеров.

Саша один из топовых докладчиков в этой сфере, он выступал на главных сценах на Highload++, РИТ++, PiterPy, Стачка, всего сделав не менее 100 докладов. В прошлый понедельник он ответил на вопросы зрителей и рассказал про свой опыт.

Делимся записью эфира и расшифровкой.



Меня зовут Александр Чистяков, я много лет работаю DevOps-инженером. Я давно консультирую различные компании на тему внедрения DevOps-практик, использования современного DevOps-инструментария и организации инфраструктур таким образом, чтобы все мы могли спокойно спать по ночам, и люди продолжали получить деньги за свои товары и услуги.

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

Мы поговорим о том, как люди используют Kubernetes в повседневной практике, зачем это нужно, почему этого не стоит бояться, на что стоит обратить внимание и что будет дальше.
Думаю, что системным администраторам, DevOps-инженерам, IT-директорам, другим специалистам, которые занимаются управлением инфраструктурами (и сочувствующим) это будет полезно.

Как развивался этот ландшафт? Я помню компьютеры, на которых был установлен ROM Basic, и можно было писать программы без установленной ОС. С тех пор много воды утекло. Сначала ОС не было как таковых (точнее, они были написаны на ассемблере). Потом появился язык C и ситуация принципиально улучшилась. Конечно, теперь мы все знакомы с понятием ОС: это платформа, которая позволяет запускать пользовательские приложения и управлять ресурсами, которые у нас есть на этом компьютере. Или на других, если она распределенная. Уже тогда можно было собрать высокопроизводительный вычислительный кластер из своего ноутбука и десктопа так делали студенты в общежитии Санкт-Петербургского политеха году в 97-м.

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

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

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

Раньше было принято спрашивать разработчика, на чем он пишет. Были специалисты по C++ (наверно, и сейчас есть где-то), сейчас много специалистов по PHP (они и сами над собой смеются, бывает) и очень много разработчиков на JavaScript. Сейчас набирает популярность Typescript, язык GoLang, в который переключились люди со знанием PHP. Был язык Perl (наверно, и сейчас остался, но сильно потеряв в популярности), язык Ruby. Вообще, приложение может быть написано на чем угодно. Если вы живете в реальном мире, вы, наверно, сталкивались с тем, что они пишутся на чем угодно: на Javascript, на Rust, на C; придумайте название на этом что-то было написано.

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

Несмотря на то, что человечество движется по некому эволюционному процессу, этот процесс имеет сходимость. В нашей индустрии так получается, что кто-то все еще пишет код на языке Perl (под mod_perl Apache), а кто-то уже на GoLang пишет микросервисную архитектуру. Оказалось, что очень важен контракт с платформой, очень важно наполнение платформы, и очень важно, чтобы платформа помогала человеку. Делать вручную операции для того, чтобы завернуть и запустить сервис, становится очень дорого. Мне приходилось сталкиваться с проектами, где было 20 сервисов и это был не слишком большой проект; я слышал и о ребятах, у которых тысяча разных сервисов. 20 это нормальной количество; и каждый набор сервисов разрабатывает своя команда на своем языке, они связаны только протоколом обмена.

Касаемо того, как устроен контракт для приложения. Есть манифест о 12-факторном приложении 12 правил того, как приложение должно быть устроено, чтобы его было удобно эксплуатировать. Мне он не нравится. В частности, там написано, что надо доставлять конфигурации через переменные окружения; и я уже не раз сталкивался с тем, что в Amazon, например, количество переменных окружения, которые можно передать в Elastic Beanstalk, составляет одну страницу ядра Linux 4 килобайта. И они очень быстро переполняются; когда у тебя 80 различных переменных, 81-ю уже сложно воткнуть. Более того, это плоское конфигурационное пространство когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит. Я еще не придумал, как с этим быть, и мне не с кем это обсудить нет группы энтузиастов, которые были бы против подобного подхода. Если это вдруг кого-то тоже не устраивает напишите мне (demeliorator в Telegram), буду знать, что я не одинок. Мне это категорически не нравится. Этим трудно управлять, трудно передавать иерархические данные; получается, что работа современного инженера состоит в том, чтобы знать, где какие переменные, что они значат, правильно ли они заведены, насколько легко их изменять. Мне кажется, что старые добрые конфигурационные правила были лучше.

Возвращаясь к контракту. Получается, что нужен Docker Image: понадобится непосредственно сам Docker (несмотря на то, что он сам убогий я надеюсь, что их какая-нибудь Microsoft купит и либо похоронит, либо разовьет нормально). Если вас не устраивает Docker, можно попробовать Stack от Red Hat; про него я не могу ничего сказать, хотя мне и кажется, что это должно быть лучше, чем просто ванильный Kubernetes. Ребята из Red Hat уделяют гораздо больше внимания вопросам безопасности, умеют делать даже multi-turned инсталляции, многопользовательские, многоклиентские, с нормальным разделением прав в общем, следят за тем, чтобы управление правами было.

Остановимся на вопросах безопасности. С ней плохо везде, не только на Kubernetes. Если говорить о вопросах безопасности и оркестрирования контейнеров, я большие надежды возлагаю на web assembly, которую делают server side, и для web assembly-приложений можно будет ограничения потребления ресурсов, системных вызовов прикрутить в специальных контейнерах, на Rust. Это будет хороший ответ на вопрос безопасности. А в Kubernetes безопасности нет.

Допустим, у нас есть приложение. Оно представляет из себя Docker-образ, оно 12-факторное то есть, оно умеет забирать вашу конфигурацию из переменных окружения, из файла, который вы смонтируете внутри контейнера. Его можно запустить внутри оно самодостаточно, его можно попытаться связать с другими приложениями через конфигурации, автоматически. И оно должно писать логи в стандартный вывод что, наверно, является наименьшим злом; когда логи контейнер пишет в файлах, оттуда не очень легко собирать. Даже Nginx запатчили так, чтобы можно было собирать логи со стандартного вывода контейнера, это приемлемо (в отличие от передачи конфигурации через параметр). По сути дела, раньше у нас было несколько оркестраторов: Rancher, Marathon Mesos, Nomad; но, как гласит принцип Анны Карениной применительно к техническим системам, сложные технические системы устроены одинаково.

С Kubernetes у нас ситуация, как у авиакомпаний с Boeing 737 MAX он не летает, потому что в нем ошибка, но ничего другого нет, потому что конструкция очень сложная. Я не могу сказать, что он нравится мне как и язык GoLang, и управление через формат YAML, когда у вас есть некий синтаксис, и поверх него ничего нет никаких проверок того, что вы пишете, никаких типов данных. Все проверки, которые вы делаете перед тем, как сделать apply конфигурации в Kubernetes это рудименты. Вы можете попытаться сделать apply неправильной конфигурации, и она применится без вопросов, и получится неизвестно что. Очень легко написать неправильный конфигурационный файл. Это большая проблема, и люди уже начали потихоньку решать её, используя DSL-и Kubernetes на языках Kotlin, даже Typescript. Есть такой проект Pulumi, есть Amazon-овский проект EKS хотя он больше ориентирован на Amazon; Pulumi это такой Terraform, только на Typescript. Я жалею, что до сих пор не попробовал Pulumi, потому что считаю, что в нем будущее. Конфигурация должна быть описана на языке программирования со строгой статической типизацией, чтобы перед применением, которое может потенциально уничтожить кластер, вам хотя бы сказали бы на этапе компиляции, что так нельзя.

Таким образом, на данный момент оркестратор только один. Я знаю, что где-то остались пользователи на MATA, я жму им руку; надеюсь, что Docker Swarm больше никто не использует мой опыт с ним был достаточно негативным. Я верю, что может быть иначе, но не знаю, зачем; никакого дальнейшего развития Docker Swarm я не предвижу, и не думаю, что люди, выпускающие его, что-то сейчас собираются с ним делать. Капитализм; если вы не зарабатываете деньги, то на разработку тратить нечего а их компания последние два года находится в долине смерти стартапов: денег им никто не хочет давать. Можно делать ставки, кто купит их. Microsoft не заинтересовался. Может быть, какой-нибудь Microfocus это сделает, если Docker доживет.
Раз остался один Kubernetes, давайте поговорим про него. Есть прекрасная картинка с пентаграммой из пяти его бинарей; написано, что Kubernetes это очень просто, всего пять бинарников. Но я далек от того, чтобы сложности системы измерять в количестве бинарников, в которые она скомпилирована, и в количестве сервисов, которые составляют ядро системы. Неважно, сколько там бинарников важно, что Kubernetes умеет выполнять, и как он устроен внутри.

Что он умеет выполнять? Вот представьте себе, что вам надо объяснить пятилетнему ребенку, что вы делали на работе. И вот папа, который пытался на Ansible написать playbooks и роли, которые позволят ему сделать blue-green deployment на базе Nginx на хосте и набора контейнеров, которые не регистрируются ничем, кроме tv-ansible, говорит: Знаешь, сынок, я пытался все это время сделать свой собственный Kubernetes. Он плохо работает, он плохо протестирован, я плохо его понимаю, я не знаю всех граничных условий, работает в пределах одной машины, но зато он мой! Я неоправданно много раз такое видел 2 или 3 раза только смотрел, и 2 раза участвовал в написании подобного. Рано или поздно человек, который в таком участвует, понимает, что 4-го раза быть не должно. Это как у моих друзей-автолюбителей, которые однажды восстановили ВАЗ-2101 поставили электростеклоподъемники, флоком салон заделали, покрасили в металлик. Создание своего собственного оркестратора это примерно так. Можно попробовать один раз, чтобы убедиться, что вы умеете, но рекомендовать это всем а не только энтузиастам я не готов. Поэтому управление жизненным циклом, управление состояниями контейнеров это задача Kubernetes.

Он может убедиться в том, что контейнер запущен на том узле, где есть ресурсы, может перезапустить умерший контейнер, может убедиться в том, что, если контейнер не запускается, то на него трафик не пойдет, если будет новый deployment. Кроме того, мы начали со слов о том, что Kubernetes это ОС; где ОС, там должен быть пакетный менеджер. Когда Kubernetes начинался, описания объектов в нем были императивны; stateful сет и описание кода это такие описания, которые работают напрямую, и сверху надо добавить что-то, чтобы было более понятно состояние вашего [??? 18:52 глюк записи]. Собственно, радикальное отличие от Ansible и других подобных конфигурационных систем управления заключается в том, что в Kubernetes вы описываете то, что должно получиться, а не то, как это должно получиться. Вы натурально описываете, какие у вас объекты есть и какие у них есть свойства. Объекты это service, deployment, daemonset, statefulset. Интересно, что, кроме тех объектов, которые можно создавать стандартно, есть и кастомные объекты, которые в Kubernetes можно описывать и создавать. Это очень полезно; это еще и сильно проредит ряды сисадминов и devops-инженеров.

Когда умрет Kubernetes?


Хороший вопрос. Зависит от того, что понимать под словом умрет. Вот Docker мы год назад собирались на конференции в Петербурге, был круглый стол, и мы совместно решили (ну, поскольку мы и есть индустрия, я думаю, там было квалифицированное большинство, и мы вполне могли себе позволить говорить за всех), что Docker уже умер. Почему? Потому что на конференции не было докладов про Docker, хотя ему не так много лет. Про него никто ничего не рассказывал. Рассказывали про Kubernetes, про следующие шаги Kube Flow, например, про использование операторов, про то, как размещать базы Kubernetes. Про что угодно, но не про Docker. Это смерть когда вы насколько плохи, что вы как бы живы, но к вам никто не приходит.

Docker уже умер. Когда умрет Kubernetes давайте подождем лет 5. Он не умрет, он будет у каждого он будет внутри Tesla, внутри вашего телефона, везде, и никому не будет интересно о нем говорить. Я думаю, что это и есть смерть. Может быть, даже не через 5 лет, а через 3. Другой вопрос что придет ему на смену: какая-то громкая новая технология, про которую все будут говорить, возможно, не из DevOps-мира вообще. Сейчас про Kubernetes говорят даже просто для того, чтобы поддержать разговор, и это нормально это модно.

Что не так с Docker?


Все. Это единый бинарь для управления всем, это сервис, который должен быть запущен в системе, это штука, которая управляется через сокет в том числе. Это такой продукт, в котором много кода, который не сильно кто ревьюил, как я думаю. Это продукт, за которым нет, по большому счету, энтерпрайзных денег. В компании Red Hat работают очень умные люди, я их очень уважаю, и, если вы обычный инженер, то вам следует смотреть на то, что они делают, потому что это может определить ландшафт на следующие 5 лет. Так вот, Red Hat выкинули Docker вообще. Они движутся к тому, чтобы его не было. Пока они не могут сделать этого до конца, но они близки, и рано ли поздно они дожмут Docker. У него, кроме всего, что я перечислил, громадная площадь атаки. Безопасность там никакая. Было поднято не так много CVE по нему, но, если посмотреть на них понятно, что, как и в любом другом проекте, где безопасность не во главе угла, ею занимаются по остаточному принципу. Это закон. Безопасность это долго, дорого, муторно, ограничивает разработчика, сильно усложняет жизнь. Правильно сделать безопасность это тяжелый труд, за который надо заплатить. Если поговорить с любым специалистом по безопасности, неважно, какой квалификации вы наслушаетесь страшилок про Docker и историй про то, как все плохо. Они частично связаны с самим Docker, частично с людьми, которые его эксплуатируют, но сам Docker мог бы и помогать людям и некоторые security checks внутри себя проводить; например, не стартовать процесс в контейнере от рута, если не сказано сделать это явно.

Как хранить состояния? Допустимо ли базу данных разместить в Kubernetes?


Если вы спросите DBA, или человека, который за инфраструктуру этой БД отвечал до того, как вы решили ее поместить в Kubernetes, этот человек скажет нет. Я думаю, на многих круглых столах люди скажут, что никаких БД в Kubernetes не должно быть: это сложно, ненадежно, непонятно, как этим управлять.

Я считаю, что БД в Kubernetes могут быть представлены. Насколько это надежно? Ну, смотрите: мы имеем дело с распределенной системой. Когда вы будете ставить БД в кластер, вы должны понимать, что у вас есть требование по отказоустойчивости. Если у вас есть такое требование, скорее всего, то, что вы поставите к себе в Kubernetes внутрь это кластер БД. Много ли людей в современном мире умеют делать нормально кластер базы данных? Много ли БД предоставляют возможность кластеризации? Здесь начинается разделение БД на традиционные реляционные, и на нереляционные. Их отличие не в том, что вторые не поддерживают SQL в том или ином виде. Отличие в том, что нереляционные БД гораздо лучше подходят для работы в кластерах, потому что их изначально писали для того, чтобы БД была распределенной. Поэтому, если для какой-нибудь MongoDB или Cassandra хотите сделать размещение в Kubernetes, я не могу вас отговаривать, но вы должны очень хорошо представлять, что будет дальше. Вы должны очень хорошо понимать, где лежат ваши данные, что будет в случае отказа и восстановления, как идут бэкапы, где находится точка восстановления и за какое время вы восстановитесь. Эти вопросы не имеют отношения к Kubernetes; они имеют отношение к тому, как вы в принципе эксплуатируете кластерное решение на базе обычных баз данных. С NoSQL-решениями проще, они сразу cloud-ready.
Но все-таки возникает вопрос а зачем БД помещать в Kubernetes? Вы можете взять предоставляемую вашим провайдером услугу, managed-решение; вы можете в Amazon взять RDS, в Google тоже managed-базу. И даже географически распределенный кластер этой базы, в случае с Amazon это Aurora, можете установить и использовать. Но, если вы будете ставить географически распределенный кластер базы, прочитайте внимательно документацию; мне доводилось встречать кластера Aurora, состоявшие из одного узла они даже не были распределены на два региона. Более того, второй регион вообще не был нужен. У людей вообще очень странные вещи в головах: они считают, что главное выбрать продукт, а дальше он сам себя обеспечит и заработает, как надо. Нет. Реляционные БД вообще не были готовы к тому, чтобы работать даже в обычном кластере, не говоря уже про геораспределенные. Поэтому, если вы делаете что-то сложное на их базе, ознакомьтесь с документацией.

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

Если у вас среднее или небольшое решение среднее решение для России примерно соответствует большому новостному агентству типа Ленты то большого количества сложных запросов к базе не должно быть. Если база не справляется, то, наверно, вы что-то делаете не так, и вам нужно об этом подумать. Не пытайтесь бездумно масштабироваться. Перевод некластерного решения в кластер несет свои плюсы, но также и большое количество минусов особенно, если вы возьмете postgres-кластера на базе Patroni или Stallone. Там много граничных условий; я с ними не сталкивался, но коллеги из Data Egret вам с удовольствием расскажут про то, как бывает. Есть доклад Алексея Лесовского прекрасный о том, что будет, если вы попытаетесь вашу базу перевести в кластер, не думая.

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

В принципе, если посмотреть на то, что из себя представляет Kubernetes как ОС и платформа, то это конструктор сделай сам. Там есть все, чтобы вы построили микросервисную архитектуру, в том числе с возможностью хранения стейтов на дисках, организации телеметрии, мониторинга, алертинга. Это делается средством Helm это пакетный менеджер Kubernetes. В интернете огромное количество опенсорсных, публично доступных Helm Charts. Самый просто способ поднять инфраструктуру проекта это взять Helm Chart, который ставит ваше приложение, ваш сервис, если этот сервис это база данных Redis, PostgreSQL, Patroni что угодно; начать его конфигурировать, и применить эту конфигурацию. Она полностью декларативна; все, что можно предусмотреть, авторы Helm Charts обычно предусматривают. Ваше приложение тоже лучше всего релизить при помощи Helm. Третий Helm не содержит сервисов на стороне кластеров; второй содержал, у него был постоянно работающий от администратора кластера сервис, необходимый, чтобы раскладывать по namespace релизы, но третий Helm эту дыру в безопасности закрыл.
Helm это такой шаблонизатор на базе синтаксиса шаблонов GoLang. Он берет список переменных, которые представляют собой неплоскую структуру (она, слава богу, иерархическая записывается в YAML); эти переменные с помощью Helm расставляются по нужным местам в Helm Templates, дальше применяете это все в какой-то namespace, там запускаются ваши коды, сервисы, ваши роли создаются. Есть генератор скаффолдинга, который позволяет Helm Chart написать, не приходя в сознание. Единственное, что мне не нравится это необходимость знать синтаксис шаблонизатора GoLang и условных ветвлений в самом Helm; они сделаны по lispовому принципу, с префиксной нотацией. Хорошо, что это еще нравится кому-то, но это заставляет каждый раз голову переключать. Ну, переживем это.

Теперь немного о том, что будет дальше. Я уже напоминал операторы; это такие сервисы, которые живут внутри кластера Kubernetes и управляют жизненным циклом другого, большего приложения. Достаточно сложно. Можно считать, что оператор это такой ваш кремниевый домашний site reliability engineer; наверняка в дальнейшем люди будут писать все больше операторов, потому что никому не хочется держать смену людей 1-го уровня поддержки, которые бы следили за графиком Nagios, замечали бы outages и предпринимали действия вручную. Оператор понимает, какие состояния системы возможны; это конечный автомат. Теперь концентрирование знаний человечества, написанное на языке GoLang или подобном, компилируется, ставится в кластер и делает большое количество работы за вас: добавляет или удаляет узлы, реконфигурирует, следит за тем, чтобы упавшее поднималось, чтобы данные пристыковывались к нужным кодам с того места, где они находятся. В общем, управляет жизненным циклом того, что под ним установлено. Операторы сейчас есть буквально для всего. Я вот развлекался тем, что при помощи оператора Rook ставил sev прямо в кластер Kubernetes. Я посмотрел на то, как это происходит, и я очень доволен, и думаю, что операторов нужно больше, и все мы должны участвовать в их тестировании. Время, которые вы затрачиваете на исправление чужого оператора это подарок человечеству. Вам больше не нужно будет делать одну и ту же работу много раз. Вы сможете эту работу в отчуждаемом виде положить в репозиторий, и дальше умная программа будет делать ее за вас это ли не счастье.

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

Кто поддерживает Swarm? Кроме Docker Inc?


Никто. А Docker Inc. уже раздербанили на две половины, и одну половину куда-то продали. Я не слежу за тем, что у них происходит; одно время они называли продукт Mobi, но это была open source-версия, то есть, была не открытая версия. И что-то продали с правами, а что-то не продали. Для меня это выглядит как больной перед смертью потел люди пытаются хоть как-то извлечь вложенные деньги. В общем, никто не поддерживает.

Master/Slave


Это работает. Если в реляционной БД перестанет работать master/slave, то на этом мир закончится. Kubernetes никак не мешает работе БД; единственное, что он привносит это разные health checks, которые можно при желании отключить, и, в принципе, управление состоянием. Желательно не отключать ваш оператор, который управляет БД, должен видеть ее состояние.

Как называется книга Red Hat?


Kubernetes Operators, так и называется. Там уточка нарисована. Книга OReilly, сейчас сделали редизайн обложек; довольно много книг в сотрудничестве с Red Hat выпустили. У Red Hat есть еще 3 или 4 книги по Kubernetes, которые можно скачать бесплатно: например, Kubernetes Patterns, gRPC. Протокол gRPC, хотя и не имеет прямого отношения к Kubernetes, применяется многими для обмена данных между микросервисами. Кроме того, он в балансировщиках следующего поколения применяется, например, в Envoy.

Что такое SRA?


Это такой человек, который понимает временные рамки изменений, происходящих в распределенной системе. Грубо говоря, он понимает, сколько уже вы в этом месяце полежали, сколько еще можно, можно ли давать разрешение на релиз. Заведует ключами от бэкапов, рекавери-планами, вопросами восстановление после сбоя, вопросами обслуживания инфраструктуры промышленного приложения, которое должно работать 24/7. У него есть метрики по состоянию и бизнес-состоянию приложения в части application metrics сколько latency, где и сколько запросов; те самые 4 золотых сигнала. Дальше SRA на основании этих метрик может предпринимать шаги по приведению системы в боеготовое состояние обратно, у него есть план того, как это сделать. От классического DevOps почему-то это не требуется, он просто помогает разработчику довести приложение до релиза, вообще куда-то выкатить. А SRA еще и противостоит потоку запросов с разных сторон.

Я обещал поговорить про безопасность. Вы знаете, это достаточно молодая тема в Kubernetes. Я знаю только самые основы: например, то, что не следует запускать приложение в сервисе от рута, потому что, как только это происходит, у него есть доступ ко всему в namespace, права суперпользователя, и можно попытаться проломить ядро хостовой системы, что, наверно, получится (и всякие другие операции выполнять от рута). Не надо давать хакерам подобную подсказку; по возможности, давайте пользователям как можно меньше прав и хорошо обрабатывайте пользовательский инпут. Мне кажется, что, если говорить о безопасности Kubernetes, его надо выносить куда-то в закрытые контура, которые сейчас есть. Или, если действительно хотите заняться вопросами безопасности, следует обратить внимание на проект Cilium. Он умеет использовать сетевые фильтры, разграничение прав сетевого трафика на базе BPF это работает лучше, чем iptables. Это будущее. Мне кажется, что за пределами Калифорнии его особо никто не использует, но можно уже начинать. Может быть, будет какой-то еще проект, но я в это сомневаюсь. У человечества вообще мало рабочих рук.

Поэтому про безопасность мне особо нечего сказать. Есть различные варианты mounted tenancy в Kubernetes, но там надо сидеть с карандашиком и разбираться в том, что люди сделали, какую уязвимость закрыли, имело ли это смысл, применимо ли это к вашей модели угроз. Кстати, я рекомендую начинать с поиска описания того, как строится модель угроз, и построения ее для себя. Есть более-менее формальные методики. Нарисуйте, посмотрите на нее, и, может быть, произойдет озарение, и вы поймете, что вам нужно, а что не нужно в текущей ситуации. Может быть, будет достаточно загнать весь Kubernetes в закрытый контур. Это, кстати, правильное решение; я с таким сталкивался, и это непробиваемо. Если получить доступ к системе можно, только предъявив пропуск на вахте, и внутри никакого интернета нет, а обмен идет через какой-нибудь специальный gateway, находящийся в DMZ, и его сложно сломать, потому что он необычно написан тогда это хорошо защищенная система. Как это делать техническими средствами ну, надо мониторить текущий рынок решений. Он сильно меняется, безопасность горячая тема. Игроков пытается быть много, но кто из них врет, а кто нет я не берусь говорить. Хотя Red Hat, скорее всего, не врет, но он и не впереди всех. Надо просто сделать research (и мне тоже), потому что пока непонятно.

Поговорим о том, что еще в кластере Kubernetes должно быть. Раз уж у нас есть возможность ставить туда приложения бесплатно, и мы не боимся хранить там БД. Кстати, если у вас Managed Kubernetes, то нет вопросов о том, где хранить БД: у вас есть отказоустойчивое хранилище, в том или ином виде (часто в виде блочных устройств) подводимое из облака, в котором размещен Managed Kubernetes. Можно спокойно диски с этого хранилища размещать у себя по кластеру и с помощью snapshots забирать консистентные бэкапы. Только не забывайте, что snapshot это не бэкап, нужно еще отснапшоченное куда-то скопировать. Это очевидно, но очевидные вещи хорошо повторять, чтобы не забывались.

Очень важно, когда у вас есть платформа с микросервисной архитектурой, сделать так, чтобы она прослеживалась, чтобы было observability, чтобы вы могли понять, где находятся запросы и где они теряют время, и так далее. Построение такой платформы это большой труд. Вам понадобится Prometheus. Он понадобится потому, что является проектом Cloud Native Computing Foundation; он специально предназначен для того, чтобы мониторить Kubernetes. Содержит огромное количество экспортеров, сборщиков метрик; некоторые приложения нативно содержат все его dashboard. Если ваше приложение их не содержит, то приделать к долгоживущему приложению dashboard Prometheus это дело 20 минут. Хотя почему-то никто не приделывает. По моему опыту это происходит из-за того, что люди держат свои продукты в облаках. Там есть Amazon CloudWatch, Google StackDriver, и туда можно точно так же отправлять метрики хотя это будет стоить денег. То есть, если люди все равно платят за инфраструктуру, то они платят и за средства мониторинга, прилагаемые к ней. Тем не менее, Prometheus бывает очень удобен, если у вас есть несколько разных мест, откуда вы забираете метрики, если облако не в одном месте, если оно гибридное, если у вас есть машины on-premise и нужна централизованная инфраструктура. Тогда Prometheus ваш выбор.

Что вам еще понадобится? Понятно, что там, где Prometheus, там и Alert Manager нужен. И еще понадобится какой-то вариант распределенной трассировки ваших запросов. Как это сделать в Kubernetes ну, взять какой-нибудь продукт типа jaeger, или zipkin, или что там сейчас на топе; также Cassandra, чтобы хранить ваши трейсы, также Grafana, чтобы их визуализировать. Насколько я понимаю, в Grafana эта функция появилась недавно, но это не повод не внедрять. То есть, вы можете вручную собрать среду, в которой приложения будут [глюки 49:14] (иметь?) к этому времени выполнения и счетчики, и еще метрики, пригодные к выстраиванию, визуализации ваших трейсов, распределенных: где приложение сколько времени проводит?

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

Мне кажется, я рассказал все, что хотел рассказать. Повторю еще раз основные положения.

Первое: Kubernetes избавляет вас от необходимости писать механизм отказоустойчивой замены одного контейнера другим самому на Ansible Engine X.

Второе: Kubernetes никуда не исчезнет. Он может умереть, но перестать им пользоваться уже невозможно, он захватил большую часть рынка. На вопрос когда умрет Kubernetes: я хочу спросить а когда умрет WordPress? А ему еще жить и жить Давайте очередность установим: сначала WP, потом Kubernetes.

Итак, Kubernetes с нами. Интересен скорее не он сам, а интересны те сервисы, которые накручиваются поверх это операторы и Custom Resource Definition. Возможность взять и написать свой ресурс, который будет называться PostgreSQL cluster, описать его одной YAML-портянкой и забросить в кластер.

Что еще будет? Еще будет возможность управления всем этим, статически типизированные языки программирования такие, как GoLang и TypeScript. И в Котлин я очень верю на нем уже написано очень много классных DSL. И еще будет написано.

Еще появятся платные Helm Chart, платные приложения, которые можно запускать on-premise, какие-то лицензионные, по подписке. Будет интеграция разных сервисов собственно, она уже есть, например, DataDog уже интегрируется с Kubernetes. И новые ребята, которые будут появляться на рынке мониторинга-алертинга, тоже будут интегрироваться с Kubernetes, по понятным причинам. Любой облачный продукт не пройдет мимо Kubernetes, так или иначе. Это та платформа, в которую каждый будет целиться.

Но все это не значит, что Kubernetes хороший, и ничего нельзя придумать лучше. Я сравниваю его с тем, что было раньше с решениями Amazon: ECS, Elastic Beanstalk. Кто сталкивался с ними знает, что в моей давней аналогии что одно, что другое было бы не просто 737 MAX, а 737 MAX, сделанным из изоленты и пластилина. Поэтому основные игроки Amazon, Microsoft Azure, Google все уже в Kubernetes.Наверно, Яндекс и Mail.ru тоже, но я за ними не слежу. Это такое общее будущее. Такое плохое, но достаточно хорошее общее будущее, на которое пока все согласны. Во что это все мутирует дальше, надо спрашивать у Red Hat они умнее меня.

Как себя Java чувствует в Kubernetes?


Нормально.

Какую ОС используете на своем ПК?


На обоих MacOS.

Берут ли сейчас активно DevOps-специалистов на удаленку?


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



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
  16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
  17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
  18. Как Data Science продает вам рекламу? Интервью с инженером Unity
  19. Как я переехал в Лондон c Revolut
  20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
  21. Как организовать IT-конференцию и не сойти с ума




Подробнее..

Зонтичная система мониторинга и ресурсно-сервисные модели в обновленном DX Operations Intelligence от Broadcom (ex. CA)

19.10.2020 08:13:18 | Автор: admin
В этом сентябре Broadcom (бывшая CA) выпустила новую версию 20.2 своего решения DX Operations Intelligence (DX OI). На рынке этот продукт позиционируется как зонтичная система мониторинга. Система сособна получать и объединять данные от систем мониторинга различных доменов (сеть, инфраструктура, приложения, базы данных) как CA так и сторонних производителей, в том числе, open source решений (Zabbix, Prometheus и других).



Основная функция DX OI создание полноценной ресурсно-сервисной модели (РСМ) на базе конфигурационных единиц (КЕ), наполняющих инвентарную базу при интеграции со сторонними системами. В DX OI реализованы функции Machine Learning и Artificial Intelligence (ML и AI) над поступающими в платформу данными, что позволяет оценить/спрогнозировать вероятность отказа конкрентной КЕ и степень влияния отказа на бизнес-сервис, в основе которого лежит конкретная КЕ. Кроме того, DX OI является единой точкой сбора событий мониторинга и, соответственно, интеграции с системой Service Desk, что является неоспоримым преимуществом использования системы в единых центрах мониторинга дежурными сменами организаций. В этой статье мы расскажем подробнее о функционале системы и покажем интерфейсы пользователя и администратора.

Архитектура решения DX OI


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

  • Мониторинг мобильных приложений в DX App Experience Analytics;
  • Мониторинг производительности приложений в DX APM;
  • Мониторинг инфраструктуры в DX Infrastructure Manager;
  • Мониторинг сетевых устройств в DX NetOps Manager.



Компоненты DX работают под управление кластера Kubernetes и масштабируются простым запуском новых POD. Ниже верхнеуровневая схема решения.



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

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



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



Ресурсно-сервисные модели и мониторинг бизнес-сервисов


DX OI имеет встроенные механизмы для создания сервисов и разработки классических РСМ с заданием логики влияния и весов между компонентами сервиса. Также имеются механизмы экспорта РСМ из внешней CMDB. На рисунке ниже встроенный редактор РСМ (обратите внимание на веса связей).



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



Рассмотрим подробности на примере сервиса Digital Banking. По клику по названию сервиса переходим в детальную РСМ сервиса. Видим, что статус сервиса Digital Banking зависит от состояния инфраструктурных и транзакционных подсервисов с различными весами. Работа с весами и их отображение занятное преимущество DX OI.



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

DX OI Topology Viewer это сервис, который использует в работе топологические данные, поступающие от доменных систем мониторинга, осуществляющих сбор данных непосредственно с объектов мониторинга. Инструмент предназначен для поиска в нескольких слоях хранилищ топологии и отображения карты отношений, зависящую от контекста. Для расследования проблем можно перейти в проблемный подсервис Backend Banking и увидеть топологию и проблемные компоненты. Также по каждому компоненту можно анализировать аварийные сообщения и метрики производительности.



При анализе транзакционных компонентов Payments (пользовательских транзакций) можем отслеживать значения бизнес-KPI, которые также учитываются при расчете статуса доступности и здоровья сервиса. Пример бизнес-KPI приведен ниже:





Событийная аналитика (Alarm Analytics)


Алгоритмическое шумоподавление за счет кластеризации аварий


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



Таким образом, кластеризация позволяет пользователям объединять и группировать огромное количество событий и анализировать только те, которые имеют общий контекст. Например, набор событий, представляющих инцидент, влияющий на работу приложений или центра обработки данных. Ситуации создаются с использованием алгоритмов кластеризации на основе машинного обучения, использующих для анализа временную корреляцию, топологическую взаимосвязь и обработку естественного языка (native language). На рисунках ниже приведены примеры визуализации кластерных групп сообщений, так называемые Situations Alarms, и Evidence Timeline, отображающие основные параметры группировки и процесс уменьшения количества шумовых событий.





Анализ корневых проблем и корреляция аварий


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

Разберем пример, когда в систему поступают многочисленные аварийные сообщения по разным объектам (КЕ), лежащим в основе одного сервиса. В случае воздействия на доступность и работоспособность сервиса система сгенерирует сервисную аварию (Service Alarm), укажет и обозначит вероятную корневую причину (проблемный КЕ и аварийное сообщение по КЕ), которое способствовало снижению производительности или отказу сервиса. На рисунке ниже приведена визуализация аварийной ситуации для сервиса Webex.



DX OI позволяет работать с событиями посредством интуитивно понятных действий в web-интерфейсе системы. Пользователи могут вручную назначать события на ответственного сотрудника для устранения неполадок, сбрасывать/подтверждать оповещения, создавать заявки или отправлять уведомления по электронной почте, запускать автоматизированные сценарии для устранения аварийной ситуации (Remediation Workflow, об этом чуть позже). Таким образом, DX OI позволяет операторам дежурных смен сосредоточиться на корневом аварийном сообщении, а также помочь упростить процесс сортировки сообщений на кластерные массивы.

Машинные алгоритмы обработки метрик и анализ данных по производительности


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

  • Обнаружение узких мест и аномалий производительности;
  • Сравнение несколько показателей для одних и тех же устройств, интерфейсов или сетей;
  • Сравнение одинаковых показателей на нескольких объектах;
  • Сравнение различных показателей по одному и нескольким объектам;
  • Сравнение многомерных метрик по нескольким объектам.

Для анализа поступающих в систему метрик DX OI использует функции машинной аналитики с применением математических алгоритмов что способствует сокращению времени при настройке статических порогов и генерации предупреждений при возникновении аномалий.



Результатом применения математических алгоритмов является построение так называемых вероятностных распределений значения метрики (Rare, Probable, Center, Mean, Actual). На рисунках выше и ниже представлены вероятностные распределения.



На двух графиках выше отображены следующие данные:

  • Фактические данные (Actual). Фактические данные отображаются на графике в виде сплошной черной линии (нет сигналов тревоги) или цветной сплошной линии (состояние тревоги). Линия рассчитывается на основе фактических данных для метрики. Сравнивая фактические данные и медианное значение, вы можете быстро увидеть вариации метрики. Когда возникает событие, черная линия меняется на цветную сплошную линию, которая соответствует критичности события и отображает значки с соответствующей критичностью над графиком. Например, красный цвет для критической аномалии, оранжевый для значительной аномалии и желтый для незначительной аномалии.
  • Среднее значение показателя (Mean value). Среднее значение или среднее значение для показателя показано на диаграмме серой линией. Среднее значение отображается, когда не хватает исторических данных.
  • Медианное значение показателя (Center value). Медианная линия является серединой диапазона и показана зеленой пунктирной линией. Зоны, ближайшие этой линии, наиболее близки к типичным значениям показателя.
  • Общие данные (Common Value). Данные общей зоны отслеживают ближайшую к центральной линии или норму для вашего показателя и отображаются в виде темно-зеленой полосы. Аналитические расчеты помещают общую зону на один процентиль выше или ниже нормы.
  • Вероятностные данные. Данные вероятностной зоны показаны на графике зеленой полосой. Система помещает вероятностную зону на два процентиля выше или ниже нормы.
  • Редкие данные. Данные о редких зонах показаны на графике в виде светло-зеленой полосы. Система помещает зону с редкими значениями метрики на три процентиля выше или ниже нормы и сигнализирует о поведении показателя за пределами нормального диапазона при этом система генерирует так называемый Anomaly Alert.

Аномалия это измерение или событие, несовместимое с нормальными показателями метрики. Обнаружение аномалий для выявления проблем и понимания тенденций в инфраструктуре и приложениях ключевая особенность DX OI. Обнаружение аномалий позволяет как распознавать необычное поведение (например, сервер, который отвечает медленнее, чем обычно, или необычную сетевую активность, вызванную взломом), так и соответствующим образом реагировать (заведение инцидента, запуск автоматического сценария Remediation).

Функция обнаружения аномалий DX OI предоставляет следующие преимущества:

  • Не нужно устанавливать пороговые значения. DX OI самостоятельно сопоставит данные и выявит аномалии.
  • DX OI включает более десяти алгоритмов искусственного интеллекта и машинного обучения, в том числе EWMA (Exponentially-WeightedMoving-Average) и KDE (Kernel Density Estimation). Эти алгоритмы позволяют выполнять быстрый анализ первопричин и прогнозировать будущие значения метрик.

Предиктивная аналитика и оповещение о возможных отказах


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



А это визуализация предиктивных предупреждений для конкретной метрики.



Прогнозирование загрузки вычислительных мощностей с функцией задания сценариев нагрузки


Функция планирования мощностей Capacity Analytics помогает управлять ИТ-ресурсами, обеспечивая правильный размер ресурсов для удовлетворения текущих и будущих потребностей бизнеса. Вы сможете оптимизировать производительность и эффективность имеющихся ресурсов, спланировать и оправдать любые финансовые вложения.

Функция Capacity Analytics в DX OI дает следующие преимущества:

  • Прогнозирование мощностей в пиковые сезоны;
  • Определение момента, когда потребуются дополнительные ресурсы для обеспечения качественного функционирования сервиса;
  • Закупка дополнительных ресурсов только при необходимости;
  • Эффективное управление инфраструктурой и сетями;
  • Устранение излишних затрат на электроэнергию за счет выявления недоиспользуемых ресурсов;
  • Выполнение оценки нагрузки на ресурсы в случае запланированного увеличения потребностей в сервисе или ресурсе.

На странице Capacity Analytics DX OI (рисунок ниже) есть следующие виджеты:

  • Состояние емкости ресурса (Resource Capacity Status);
  • Контролируемые группы/службы (Monitored Groups/Services);
  • Крупные потребители ресурсов (Top Capacity Consumers).



Основная страница Capacity Analytics показывает компоненты ресурсов, которые избыточно загружены и у которых заканчивается емкость. Эта страница помогает администраторам платформы находить чрезмерно используемые ресурсы и помогает им изменять размер и оптимизировать ресурсы. Состояние ресурсов можно проанализировать на основе цветовых кодов и их соответствующих значений. Ресурсы классифицируются в зависимости от степени их перегруженности на странице состояния емкости ресурсов. Можно щелкнуть на каждый из цветов, чтобы просмотреть список компонентов, входящих в выбранную категорию. Далее отобразится тепловая карта со всеми объектами и прогнозами на 12 месяцев, что позволяет выявить ресурсы, которые вот-вот будут исчерпаны.



Для каждой из метрик в Capacity Analytics можно указать фильтры, которые DX Operational Intelligence использует для составления прогнозов (рисунок ниже).



Доступны следующие фильтры:

  • Metric. Метрика, которая будет использоваться для прогноза.
  • Base on. Выбор объема исторических данных, которые будут использованы для построения прогнозов на будущее. Это поле используется для сравнения и анализа тенденций за последний месяц, тенденций за последние 3 месяца, тенденций за год и т. д.
  • Growth. Ожидаемая скорость роста рабочей нагрузки, которую хотите использовать для моделирования прогноза мощности. Эти данные можно использовать для прогнозирования роста сверх прогнозов. Например, ожидается, что использование ресурса вырастет еще на 40 процентов из-за открытия нового офиса.

Анализ логов


Функция анализа логов DX OI обеспечивает:

  • Сбор, агрегацию логов из разных источников (в том числе полученных агентским и безагентским способами);
  • Парсинг и нормализацию данных;
  • Анализ на соответствие поставленным условиям и генерацию событий;
  • Корреляцию событий на основе логов, в том числе с событиями, полученными в результате мониторинга ИТ-инфраструктуры;
  • Визуализацию данных на основе анализа в DX Dashboards;
  • Выводы о доступности сервисов на основе анализа данных из логов.



Сбор логов безагентным методом выполняется системой для Windows Event logs и Syslog. Агентным способом собираются текстовые логи.

Функция автоматизированного разрешения аварийных ситуаций (Remediation)


Автоматизированные действия по исправлению аварийной ситуации (Remediation Workflow) позволяют решить проблемы, вызвавшие генерацию события в DX OI. Например, проблема загрузки ЦП генерирует аварийное сообщение, процесс исправления (Remediation Workflow) решает проблему путем перезапуска сервера, на котором возникла проблема. Интеграция между DX OI и системой автоматизации позволяет запускать процессы исправления из консоли событий в DX Operational Intelligence и отслеживать их в консоли системы автоматизации.

После интеграции c системой автоматизации можно запускать автоматические действия по исправлению любой аварийной ситуации в консоли DX OI из контекста аварийного сообщения. Вы можете просмотреть рекомендованные действия вместе с информацией о процентах достоверности (вероятности устранения ситуации путем выполнения действия).





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



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



Рекомендуемые корректирующие действия для конкретной тревоги основаны на комбинации обратной связи, которая определяет, является ли действие приемлемым. DX OI поставляется с готовой интеграцией с системой автоматизации Automic Automation.

Интеграция DX OI со сторонними системами


Останавливаться подробно на интеграции данных из нативных продуктов мониторинга Broadcom (DX NetOps, DX Infrastructure Management, DX Application Performance Management) мы не будем. Вместо этого рассмотрим как интегрируются данные из сторонних 3rd-party систем и разберем пример интеграции с одной из наиболее популярных систем Zabbix.

Для интеграции со сторонними системами используется компонент DX Gateway. DX Gateway состоит из 3 компонентов On-Prem Gateway, RESTmon и Log Collector (Logstash). Вы можете установить все 3 компонента или только тот, который нужен, изменив общий файл конфигурации при установке DX Gateway. На рисунке ниже архитектура DX Gateway.



Рассмотрим назначение компонентов DX Gateway отдельно.

On-Prem Gateway. Это интерфейс, который собирает аварийные сигналы от платформы DX и отправляет события об авариях в сторонние системы. On-Prem Gateway действует как поллер, который периодически собирает данные о событиях из DX OI, используя API запросов по протоколу HTTPS, затем отправляет предупреждения на сторонний сервер, который интегрирован с платформой DX, используя вебхуки.



DX Log Collector принимает syslog от сетевых устройств или серверов и загружает их в OI. DX Log Collector позволяет разделить программное обеспечение, которое генерирует сообщения, систему, которая их хранит, и программное обеспечение, которое сообщает и анализирует их. Каждое сообщение помечается кодом объекта, указывающим тип программного обеспечения, генерирующего сообщение, и ему назначается уровень критичности. В DX Dashboards это всё потом можно посмотреть.

DX RESTmon интегрируется со сторонними продуктами/услугами через REST API и передает данные в OI. На рисунке ниже представлена схема функционирования DX RESTmon на примере интеграции с системами мониторинга Solarwinds и SCOM.



Ключевые функции DX RESTmon:

  • Подключение к любому стороннему источнику данных для приема данных:
    • PULL: подключение и извлечение данных из общедоступных REST API;
    • PUSH: поток данных в RESTmon через REST.
  • Поддержка форматов JSON и XML;
  • Прием метрик, предупреждений, групп, топологии, инвентаризации и журналов;
  • Готовые коннекторы для различных инструментов/технологий, также возможно разработать коннектор к любому источнику с открытым API (список коробочных коннекторов на рисунке ниже);
  • Поддержка базовой аутентификации (по умолчанию) при доступе к интерфейсу Swagger и API;
  • Поддержка HTTPS (по умолчанию) для всех входящих и исходящих сообщений;
  • Поддержка входящих и исходящих прокси;
  • Мощные возможности синтаксического анализа текста для журналов, полученных через REST;
  • Настраиваемый синтаксический анализ с помощью RESTmon, обеспечивающий эффективный анализ и визуализацию журналов;
  • Поддержка извлечения информации о группах устройств из приложений мониторинга и загрузки в OI для анализа и визуализации;
  • Поддержка возможности сопоставления с регулярными выражениями. Это может использоваться для синтаксического анализа и сопоставления сообщений логов, полученных через REST, а также для генерации или закрытия событий на основе определенных условий регулярного выражения.



Теперь рассмотрим процесс настройки интеграции DX OI с Zabbix через DX RESTmon. Коробочная интеграция забирает из Zabbix следующие данные:

  • Инвентарные данные;
  • Топология;
  • Проблемы;
  • Метрики.

Поскольку коннектор для Zabbix доступен из коробки, всё, что нужно сделать для настройки интеграции это обновить профайл, указав IP адрес API сервера Zabbix и учетную запись, а затем загрузить профайл через web-интерфейс Swagger. Пример на двух следующих рисунках.





После настройки интеграции, для поступающих из Zabbix данных будут доступны аналитические функции DX OI, описанные выше, а именно: Alarm Analytics, Performance Analytics, Predictive Insights, Service Analytics и Remediation. На рисунке ниже приведен пример анализа метрик производительности по объектам, интегрированным из Zabbix.



Заключение


DX OI современный инструмент аналитики, который обеспечит значительную операционную эффективность IT-подразделений, позволит принимать более быстрые и правильные решения для повышения качества ИТ-услуг и бизнес-сервисов за счет междоменного контекстного анализа. Для владельцев приложений и бизнес-подразделений DX OI рассчитает показатель доступности и качество сервисов не только в контексте технологических IT-показателей, но и бизнес-KPI, извлекаемых из транзакционной статистики по конечным пользователям.

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

Из песочницы Turing Pi кластерная плата для self-hosted приложений и сервисов

16.10.2020 18:23:47 | Автор: admin
image

Turing Pi это решение для self-hosted приложений построенное по принципу rack стоек в дата центре, только на компактной материнской плате. Решение ориентировано на построение локальной инфраструктуры для локальной разработки и хостинга приложений и сервисов. Вообщем это как AWS EC2 только для edge.

Мы небольшая команда разработчиков решили создать решение для построения bare-metal кластеров в edge и назвали проект Turing Pi. Продукт начался на коленке, однако сейчас для проверок своих концепций его заказали отделы разработок в Red Hat, Rancher (SUSE), Toyota Connected, Sony, Electrolux, Facebook, и набирается аудитория разработчиков под 10К.

Но все началось с открытия.

Открытие продукта


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

В течении последнего десятилетия я наблюдал как набирает обороты любительское движение homelab (ресурс subreddit), self-hosted (ресурсы subreddit и awesome-selfhosted), одноплатные компьютеры, как растет интерес к запуску контейнеров на одноплатных компьютерах типа Raspberry Pi, растет движение собирающее кластеры из одноплатных компьютеров. Постепенно туда тянется и идея Kubernetes. Уже появилась его легкая версия k3s ориентированная на Edge/IoT. Большая сеть ресторанов быстрого питания Chick-fil-A одни из первых в мире разместили кластеры Kubernetes на своих кухнях kubectl make me a sandwich.

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

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

Строительные блоки (Building Blocks)


Итак, что же из себя представляет решение, в чем суть. Суть в том чтобы дать конструктор, строительные блоки (Building Blocks) из которых можно собрать edge инфраструктуру дешевле чем на классических серверах, мобильную без громоздких металлических ящиков, не требовательную к особым условия эксплуатации типа серверных, энергоэффективную, стандартизированную в плане модулей и с возможностью быстрого масштабирования на десятки и сотни вычислительных узлов (процессоры).
Кластерная плата (Clusterboard)

Mini ITX плата объединяет несколько вычислительных модулей с помощью сети на плате, дает периферийные интерфейсы и контроль над модулями
Вычислительный модуль (Compute Module)

Плата в SO-DIMM форм-факторе содержащая процессор и оперативную память, опционально флеш-память для хранения операционной системы
image
Одна из проектируемых конфигураций версии Turing V2
image
Комбинируя кластерную плату и вычислительные модули легко создать инфраструктуру к примеру на 20+ процессоров (примеры ниже), бесшумную и с низким энергопотреблением. Сама кластерная плата увеличивает эффективность используемого объема. Примеры кластеров для сравнения
SBC based*
image
24 CPUs
Автор Afkham Azeez
Turing Pi based
image
21 CPUs
Автор th3st0rmtr00p3r
* SBC Single Board Computer

Со-основателя Rancher Labs и автора k3s такой подход не оставил равнодушным

image

Далее подробнее про строительные блоки.

Вычислительный Модуль (Compute Module)


Для проверки концепции мы выбрали Raspberry Pi Compute Module это идеальная конфигурация для старта. Коммьюнити RPi активно, нет проблем с софтом, сам модуль в формате SO-DIMM (6 x 3 см), доступен по цене, содержит на борту 4-core CPU, 1 GB RAM и опционально флеш-память 8, 16 или 32 GB для ОС и других системных нужд. Подобный форм-фактор часто используют в индустриальных IoT решениях.

Raspberry Pi 1/3/3+ Compute Module

image

Но у модели CM3 есть и серьезные ограничения max. 1 GB RAM и Ethernet через USB HUB с максимальной скоростью до 100 Mbps. Поэтому вторая версия Turing будет поддерживать Raspberry Pi 4 и до 8 GB оперативной памяти на модуль. Ниже пример Nvidia Jetson модулей для Accelerated Computing задач. Возможно, будет их поддержка во второй версии, если мы решим некоторые технические задачи, тогда можно миксовать модули.

Nvidia Jetson Compute Modules

image

В модулях кроется самая главная возможность, которая на первый взгляд не очевидна. Возможность создания других модулей в подобном форм-факторе с разным набором CPU, RAM и eMMC, под разные типы задач от general-computing до machine learning интенсивных вычислений. Это очень похоже на инстансы AWS EC2, но только для edge. При этом кластерная плата остается неизменной или с минорными изменениями.

Кластерная плата (Clusterboard)


Еще ее можно назвать материнской платой или базовой платой, достаточно новое направление и производителей подобных решений сегодня не много и все еще довольно на начальном уровне, среди них Pine64, MiniNodes, Clover Pi, Bitscope Blade, PicoCluster (SBC кластеры). Кластерная плата объединяет модули сетью, обеспечивает питанием и дает шину управления кластером (Cluster Management Bus), по крайней мере мы эту шину решили добавить и она вроде прижилась.
Front
image
Back
image
Backplane Bandwidth 12 Gbps SD слоты для модулей без eMMC, например, можно держать пару модулей с SD для быстрого доступа к данным ноды
В основе кластерной платы лежит микросхема switch для обеспечения сетевого соединения модулей и выхода во внешнюю сеть. В текущей версии мы используем unmanaged switch т.к. не было времени проводить полноценный R&D, но ко второй версии мы выбрали неплохой managed switch. Возможна конфигурация в режиме мастер нода как роутер для раздачи сети на плату, это если требуется более высокий уровень безопасности и изоляции воркеров от доступа извне, в таком случае на мастер ноде необходимо также держать DHCP сервер.

Применение


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

Чтобы начать мы рекомендуем серию от замечательного Джеффа Гирлинга, который прочитал о нас на Y Combinator, он автор бестселлера Ansible for DevOps. Он так вдохновился что сделал 6-ти серийный обзор начиная от идеи кластеризации в целом до практических примеров работы с платой, изучения Kubernetes и какой софт можно устанавливать

Серия про установку k3s на кластер


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

image

Что дальше?


Во-первых, я очень надеюсь что было интересно. Это абсолютно авторский контент, попытка заглянуть за горизонт. Во-вторых, планирую написать вторую часть про проектирование Turing V2. Как происходил поиск продукта, логические суждения, поиск основных свойств которые важны. Статья будет содержать эскизы продукта от самых ранних до финальных. Вторая статья будет особенно интересна продуктологам, кто отвечает за продукты и их развитие в компаниях.

И скорее всего там будет реально long read.
Подробнее..

Мини ITX кластер Turing Pi 2 c 32 GB RAM

21.10.2020 12:13:27 | Автор: admin
image

Приветствую сообщество Хабра! Недавно я писал про нашу кластерную плату первой версии [V1]. И сегодня хочу рассказать как мы работали над версией Turing V2 с 32 GB оперативной памяти.

Мы увлекаемся мини серверами которые можно использовать как для локальной разработки так и для хостинга локально. В отличии от настольных компьютеров или лэптопов наши сервера созданы для работы 24/7 их быстро можно соединять в федерацию, например было 4 процессора в кластере, а через 5 минут стало 16 процессоров (без дополнительного сетевого оборудования) и все это в компактном форм-факторе, безшумно и энергоэффективно.

В основе архитектуры наших серверов кластерный принцип построения т.е. мы делаем кластерные платы которые с помощью ethernet сети на плате соединяют несколько вычислительных модулей (процессоров). Для упрощения мы пока не делаем свои вычислительные модули, а используем Raspberry Pi Compute Modules и мы очень надеялись на новый модуль CM4. Но, все пошло вразрез планам с их новым форм-фактором и думаю многие разочарованы.

Под катом как мы шли от V1 к V2 и как нам пришлось выкручиваться с новым форм-фактором Raspberry Pi CM4.

Итак, после создания кластера на 7 нод, вопросы что дальше? Как увеличить ценность продукта? 8, 10 или 16 нод? Какие производители модулей? Думая над продуктом в комплексе мы поняли что основное здесь не количество нод или кто производитель, а сама суть кластеров как строительного блока. Надо искать минимальный строительный блок, которые

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

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

Третье, минимальные кластерные блоки должны быть достаточно компактны, мобильны, энергоэффективны, cost-effective и не требовательны к условиям эксплуатации. Это одно из ключевых отличий от server racks и всего что с ними связано.

Мы начали с определения количества нод.

Количество нод


Простыми логическими суждениями мы поняли что 4 ноды лучший вариант для минимального кластерного блока. 1 нода это не кластер, 2 ноды мало (1 мастер 1 воркер, нет возможности масштабирования в рамках блока, особенно для гетерогенных вариантов), 3 ноды выглядит ок, но не кратно степеням 2 и лимитировано масштабирование в рамках блока, 6 нод выходит по цене почти как 7 нод (из нашего опыта это уже большая себестоимость), 8 много, не умещается в mini ITX форм факторе и еще более дорогое решение для PoC.

Четыре ноды на блок считаем золотой серединой:

  • меньше материалов на кластерную плату, следовательно дешевле производство
  • кратно 4, всего 4 блока дают 16 физических процессоров
  • стабильная схема 1 мастер и 3 воркера
  • больше гетерогенных вариаций, general-compute + accelerated-compute модули
  • мини ITX форм-фактор с SSD дисками и платами расширения

Вычислительные модули


Вторая версия базируется на CM4 мы думали что ее выпустят в SODIMM форм-факторе. Но
Мы приняли решение сделать дочернюю плату SODIMM и собирать CM4 сразу в модули чтобы пользователи не думали о CM4.

image
Turing Pi Compute Module с поддержкой Raspberry Pi CM4

Вообще в поисках модулей был открыт целый рынок вычислительных модулей от небольших модулей на 128 MB RAM до 8 GB RAM. Впереди модули на 16 GB RAM и более. Для edge хостинга приложений базирующихся на cloud native технологиях 1 GB RAM уже мало, а недавнее появление модулей на 2, 4 и даже 8 GB RAM дает хорошее пространство для роста. Даже рассматривали и варианты с FPGA модулями для приложений машинного обучения, но их поддержка отложена потому что не развита софтверная экосистема. Во время изучения рынка модулей пришли к идеи создания универсального интерфейса для модулей и в V2 начинаем унификацию интерфейса вычислительных модулей. Это позволит владельцам версии V2 подключать модули других производителей и смешивать их под конкретные задачи.

V2 поддерживает всю линейку Raspberry Pi 4 Compute Module (CM4), включая Lite версии и модули на 8 GB RAM

image

Периферия


После определения вендора модулей и количества нод мы подошли к PCI шине, на которой находится периферия. PCI шина является стандартом для периферийных устройств и она есть почти во всех вычислительных модулях. У нас несколько нод и в идеале чтобы каждая нода могла шерить PCI устройства в режиме конкурентных запросов. Например, если это диск подключенный к шине, то он доступен всем нодам. Мы начали искать PCI свичи с возможностью поддержки мультихост и обнаружили что ни один из них не подходит под наши требования. Все эти решения в основном ограничивались 1 хостом или мульти хостами, но без режима конкурентных запросов к endpoints. Вторая проблема высокая стоимость от $50 и более за чип. В V2 мы решили отложить эксперименты с PCI свичами (мы вернемся к ним позже по мере развития) и пошли по пути назначения роли для каждой ноды: первые две ноды exposed mini PCI express port per node, третья нода exposed 2-ports 6 Gbps SATA контроллер. Для получения доступа к дискам с других нод можно использовать сетевую файловую систему в рамках кластера. Why not?

Sneakpeek


Мы решили поделиться некоторыми эскизами как эволюционировал минимальный кластерный блок с течением времени в процессе обсуждения и обдумывания

imageimageimage

В результате мы пришли к кластерному блоку с 4-мя нодами 260-pin, 2-мя mini PCIe (Gen 2) портами, 2-мя SATA (Gen 3) портами. На плате установлен Layer-2 Managed Switch с поддержкой VLAN. С первой ноды выведен mini PCIe порт, в который можно установить сетевую карту и получить еще один Ethernet порт или 5G модем и сделать из первой ноды роутер для сети на кластере и Ethernet портов.

image

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

Применение


Edge infrastructure for self-hosted applications & services


Мы проектировали V2 с целью использовать ее как минимальный строительный блок для consumer/commercial-grade edge инфраструктуры. С V2 дешево начать проверку концепции и масштабироваться по мере роста, постепенно перенося приложения, которые экономически и практически целесообразнее хостить в edge. Кластерные блоки можно соединять вместе, строя кластеры большего размера. Это можно делать постепенно без особых рисков для устоявшихся
процессов. Уже сегодня имеется огромное количество приложений для бизнеса, которые можно хостить локально.

ARM Workstation


С оперативной памятью до 32 GB RAM на кластер, первую ноду можно использовать для desktop версии OS (например Ubuntu Desktop 20.04 LTS) и оставшиеся 3 ноды для задач компиляции, тестирования и отладки, разработки cloud native решений для ARM кластеров. Как узел для CI/CD на ARM периферийную инфраструктуру в проде.

Turing V2 кластер с CM4 модулями архитектурно почти идентичен (разница в минорных версиях ARMv8) кластеру на базе инстансов AWS Graviton. В процессоре CM4 модулей используется архитектура ARMv8 вы можете собирать образы и приложения для AWS инстансов Graviton 1 и 2, которые как известно намного дешевле инстансов x86.
Подробнее..

Перевод Автоскейлинг приложений Kubernetes при помощи Prometheus и KEDA

28.09.2020 18:04:45 | Автор: admin
Balloon Man by Cimuanos

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

Kubernetes позволяет автоматически масштабировать приложения (то есть Pod в развертывании или ReplicaSet) декларативным образом с использованием спецификации Horizontal Pod Autoscaler. По умолчанию критерий для автоматического масштабирования метрики использования CPU (метрики ресурсов), но можно интегрировать пользовательские метрики и метрики, предоставляемые извне.

Команда Kubernetes aaS от Mail.ru перевела статью о том, как использовать внешние метрики для автоматического масштабирования приложения Kubernetes. Чтобы показать, как все работает, автор использует метрики запросов HTTP-доступа, они собираются с помощью Prometheus.

Вместо горизонтального автомасштабирования подов, применяется Kubernetes Event Driven Autoscaling (KEDA) оператор Kubernetes с открытым исходным кодом. Он изначально интегрируется с Horizontal Pod Autoscaler, чтобы обеспечить плавное автомасштабирование (в том числе до/от нуля) для управляемых событиями рабочих нагрузок. Код доступен на GitHub.

Краткий обзор работы системы




На схеме краткое описание того, как все работает:

  1. Приложение предоставляет метрики количества обращений к HTTP в формате Prometheus.
  2. Prometheus настроен на сбор этих показателей.
  3. Скейлер Prometheus в KEDA настроен на автоматическое масштабирование приложения на основе количества обращений к HTTP.

Теперь подробно расскажу о каждом элементе.

KEDA и Prometheus


Prometheus набор инструментов для мониторинга и оповещения систем с открытым исходным кодом, часть Cloud Native Computing Foundation. Собирает метрики из разных источников и сохраняет в виде данных временных рядов. Для визуализации данных можно использовать Grafana или другие инструменты визуализации, работающие с API Kubernetes.

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

Скейлеры поддерживают нескольких источников данных, например, Kafka, Redis, Prometheus. То есть KEDA можно применять для автоматического масштабирования развертываний Kubernetes, используя в качестве критериев метрики Prometheus.

Тестовое приложение


Тестовое Golang-приложение предоставляет доступ по HTTP и выполняет две важные функции:

  1. Использует клиентскую библиотеку Prometheus Go для инструментирования приложения и предоставления метрики http_requests, которая содержит счетчик обращений. Конечная точка, по которой доступны метрики Prometheus, расположена по URI /metrics.

    var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{       Name: "http_requests",       Help: "number of http requests",   })
    
  2. В ответ на запрос GET приложение увеличивает значение ключа (access_count) в Redis. Это простой способ выполнить работу как часть обработчика HTTP, а также проверить метрики Prometheus. Значение метрики должно быть таким же, как значение access_count в Redis.

    func main() {       http.Handle("/metrics", promhttp.Handler())       http.HandleFunc("/test", func(w http.ResponseWriter, r *http.Request) {           defer httpRequestsCounter.Inc()           count, err := client.Incr(redisCounterName).Result()           if err != nil {               fmt.Println("Unable to increment redis counter", err)               os.Exit(1)           }           resp := "Accessed on " + time.Now().String() + "\nAccess count " + strconv.Itoa(int(count))           w.Write([]byte(resp))       })       http.ListenAndServe(":8080", nil)   }
    

Приложение развертывается в Kubernetes через Deployment. Также создается служба ClusterIP, она позволяет серверу Prometheus получать метрики приложения.

Вот манифест развертывания для приложения.

Сервер Prometheus


Манифест развертывания Prometheus состоит из:

  • ConfigMap для передачи конфига Prometheus;
  • Deployment для развертывания Prometheus в Kubernetes-кластере;
  • ClusterIP сервис для доступа к UI Prometheus;
  • ClusterRole, ClusterRoleBinding и ServiceAccount для работы автоопределения сервисов в Kubernetes (Auto-discovery).

Вот манифест для запуска Prometheus.

KEDA Prometheus ScaledObject


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

ScaledObject содержит информацию о масштабировании развертывания, метаданные об источнике события (например, секреты для подключения, имя очереди), интервал опроса, период восстановления и другие данные. Он приводит к соответствующему ресурсу автомасштабирования (определение HPA) для масштабирования развертывания.

Когда объект ScaledObject удаляется, соответствующее ему определение HPA очищается.

Вот определение ScaledObject для нашего примера, в нем используется скейлер Prometheus:

apiVersion: keda.k8s.io/v1alpha1kind: ScaledObjectmetadata: name: prometheus-scaledobject namespace: default labels:   deploymentName: go-prom-appspec: scaleTargetRef:   deploymentName: go-prom-app pollingInterval: 15 cooldownPeriod:  30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: prometheus   metadata:     serverAddress: http://prometheus-service.default.svc.cluster.local:9090     metricName: access_frequency     threshold: '3'     query: sum(rate(http_requests[2m]))

Учтите следующие моменты:

  1. Он указывает на Deployment с именем go-prom-app.
  2. Тип триггера Prometheus. Адрес сервера Prometheus упоминается вместе с именем метрики, пороговым значением и запросом PromQL, который будет использоваться. Запрос PromQL sum(rate(http_requests[2m])).
  3. Согласно pollingInterval, KEDA запрашивает цель у Prometheus каждые пятнадцать секунд. Поддерживается минимум один под (minReplicaCount), а максимальное количество подов не превышает maxReplicaCount (в данном примере десять).

Можно установить minReplicaCount равным нулю. В этом случае KEDA активирует развертывание с нуля до единицы, а затем предоставляет HPA для дальнейшего автоматического масштабирования. Возможен и обратный порядок, то есть масштабирование от единицы до нуля. В примере мы не выбрали ноль, поскольку это HTTP-сервис, а не система по запросу.

Магия внутри автомасштабирования


Пороговое значение используют в качестве триггера для масштабирования развертывания. В нашем примере запрос PromQL sum(rate (http_requests [2m])) возвращает агрегированное значение скорости HTTP-запросов (количество запросов в секунду), ее измеряют за последние две минуты.

Поскольку пороговое значение равно трем, значит, будет один под, пока значение sum(rate (http_requests [2m])) меньше трех. Если же значение возрастает, добавляется дополнительный под каждый раз, когда sum(rate (http_requests [2m])) увеличивается на три. Например, если значение от 12 до 14, то количество подов четыре.

Теперь давайте попробуем настроить!

Предварительная настройка


Всё, что вам нужно кластер Kubernetes и настроенная утилита kubectl. В этом примере используется кластер minikube, но вы можете взять любой другой. Для установки кластера есть руководство.

Установить последнюю версию на Mac:

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \&& chmod +x minikubesudo mkdir -p /usr/local/bin/sudo install minikube /usr/local/bin/

Установите kubectl, чтобы получить доступ к кластеру Kubernetes.

Поставить последнюю версию на Mac:

curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -shttps://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"chmod +x ./kubectlsudo mv ./kubectl /usr/local/bin/kubectlkubectl version

Установка KEDA


Вы можете развернуть KEDA несколькими способами, они перечислены в документации. Я использую монолитный YAML:

kubectl apply -fhttps://raw.githubusercontent.com/kedacore/keda/master/deploy/KedaScaleController.yaml

KEDA и ее компоненты устанавливаются в пространство имен keda. Команда для проверки:

kubectl get pods -n keda

Дождитесь, когда под KEDA Operator стартует перейдет в Running State. И после этого продолжайте.

Установка Redis при помощи Helm


Если у вас не установлен Helm, воспользуйтесь этим руководством. Команда для установки на Mac:

brew install kubernetes-helmhelm init --history-max 200

helm init инициализирует локальный интерфейс командной строки, а также устанавливает Tiller в кластер Kubernetes.

kubectl get pods -n kube-system | grep tiller

Дождитесь перехода пода Tiller в состояние Running.

Примечание переводчика: Автор использует Helm@2, который требует установки серверного компонента Tiller. Сейчас актуален Helm@3, для него серверная часть не нужна.

После установки Helm для запуска Redis достаточно одной команды:

helm install --name redis-server --set cluster.enabled=false --set usePassword=false stable/redis

Убедиться, что Redis успешно запустился:

kubectl get pods/redis-server-master-0

Дождитесь, когда под Redis перейдет в состояние Running.

Развертывание приложения


Команда для развертывания:

kubectl apply -f go-app.yaml//outputdeployment.apps/go-prom-app createdservice/go-prom-app-service created

Проверить, что все запустилось:

kubectl get pods -l=app=go-prom-app

Дождитесь перехода Redis в состояние Running.

Развертывание сервера Prometheus


Манифест Prometheus использует Kubernetes Service Discovery для Prometheus. Он позволяет динамически обнаруживать поды приложения на основе метки службы.

kubernetes_sd_configs:   - role: service   relabel_configs:   - source_labels: [__meta_kubernetes_service_label_run]     regex: go-prom-app-service     action: keep

Для развертывания:

kubectl apply -f prometheus.yaml//outputclusterrole.rbac.authorization.k8s.io/prometheus createdserviceaccount/default configuredclusterrolebinding.rbac.authorization.k8s.io/prometheus createdconfigmap/prom-conf createddeployment.extensions/prometheus-deployment createdservice/prometheus-service created

Проверить, что все запустилось:

kubectl get pods -l=app=prometheus-server

Дождитесь, пока под Prometheus перейдет в состояние Running.

Используйте kubectl port-forward для доступа к пользовательскому интерфейсу Prometheus (или серверу API) по адресу http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

Развертывание конфигурации автомасштабирования KEDA


Команда для создания ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

Проверьте логи оператора KEDA:

KEDA_POD_NAME=$(kubectl get pods -n keda -o=jsonpath='{.items[0].metadata.name}')kubectl logs $KEDA_POD_NAME -n keda

Результат выглядит примерно так:

time="2019-10-15T09:38:28Z" level=info msg="Watching ScaledObject:default/prometheus-scaledobject"time="2019-10-15T09:38:28Z" level=info msg="Created HPA with namespace default and name keda-hpa-go-prom-app"

Проверьте под приложения. Должен быть запущен один экземпляр, поскольку minReplicaCount равно 1:

kubectl get pods -l=app=go-prom-app

Проверьте, что ресурс HPA успешно создан:

kubectl get hpa

Вы должны увидеть что-то вроде:

NAME                   REFERENCE                TARGETS     MINPODS   MAXPODS   REPLICAS   AGEkeda-hpa-go-prom-app   Deployment/go-prom-app   0/3 (avg)   1         10        1          45s

Проверка работоспособности: доступ к приложению


Чтобы получить доступ к конечной точке REST нашего приложения, запустите:

kubectl port-forward service/go-prom-app-service 8080

Теперь вы можете получить доступ к приложению Go, используя адрес http://localhost:8080. Для этого выполните команду:

curl http://localhost:8080/test

Результат выглядит примерно так:

Accessed on 2019-10-21 11:29:10.560385986 +0000 UTC m=+406004.817901246Access count 1

На этом этапе также проверьте Redis. Вы увидите, что ключ access_count увеличен до 1:

kubectl exec -it redis-server-master-0 -- redis-cli get access_count//output"1"

Убедитесь, что значение метрики http_requests такое же:

curl http://localhost:8080/metrics | grep http_requests//output# HELP http_requests number of http requests# TYPE http_requests counterhttp_requests 1

Создание нагрузки


Мы будем использовать hey утилиту для генерации нагрузки:

curl -o hey https://storage.googleapis.com/hey-release/hey_darwin_amd64 && chmod a+x hey

Вы можете также скачать утилиту для Linux или Windows.

Запустите ее:

./hey http://localhost:8080/test

По умолчанию утилита отправляет 200 запросов. Вы можете убедиться в этом, используя метрики Prometheus, а также Redis.

curl http://localhost:8080/metrics | grep http_requests//output# HELP http_requests number of http requests# TYPE http_requests counterhttp_requests 201kubectl exec -it redis-server-master-0 -- redis-cli get access_count//output201

Подтвердите значение фактической метрики (возвращенной запросом PromQL):

curl -g 'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'//output{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1571734214.228,"1.686057971014493"]}]}}

В этом случае фактический результат равен 1,686057971014493 и отображается в поле value. Этого недостаточно для масштабирования, поскольку установленный нами порог равен 3.

Больше нагрузки!


В новом терминале следите за количеством подов приложения:

kubectl get pods -l=app=go-prom-app -w

Давайте увеличим нагрузку с помощью команды:

./hey -n 2000 http://localhost:8080/test

Через некоторое время вы увидите, что HPA масштабирует развертывание и запускает новые поды. Проверьте HPA, чтобы в этом убедиться:

kubectl get hpaNAME                   REFERENCE                TARGETS         MINPODS   MAXPODS   REPLICAS   AGEkeda-hpa-go-prom-app   Deployment/go-prom-app   1830m/3 (avg)   1         10        6          4m22s

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

curl -g 'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'

Очистка


//Delete KEDAkubectl delete namespace keda//Delete the app, Prometheus server and KEDA scaled objectkubectl delete -f .//Delete Redishelm del --purge redis-server

Заключение


KEDA позволяет автоматически масштабировать ваши развертывания Kubernetes (до/от нуля) на основе данных из внешних метрик. Например, на основе метрик Prometheus, длины очереди в Redis, задержки потребителя в теме Kafka.

KEDA выполняет интеграцию с внешним источником, а также предоставляет его метрики через Metrics Server для Horizontal Pod Autoscaler.

Успехов!

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

  1. Лучшие практики и рекомендации для запуска контейнеров и Kubernetes в производственных средах.
  2. 90+ полезных инструментов для Kubernetes: развертывание, управление, мониторинг, безопасность и не только.
  3. Наш канал Вокруг Kubernetes в Телеграме.
Подробнее..

АйТиБорода Контейнеризация понятным языком. Интервью с System Engineers из Southbridge

02.10.2020 16:05:32 | Автор: admin

Сегодня вас ожидает путешествие в мир системных инженеров aka DevOps-инженеров: выпуск про виртуализацию, контейнеризацию, оркестрацию с помощью kubernetes, и настройку конфигоd через. Docker, kubernetes, ansible, рулбуки, кублеты, хельм, докерсворм, kubectl, чарты, поды -мощная теория для чёткой практики.


В гостях System Engineers из учебного центра Слёрм и одновременно компании Southbridge Николай Месропян и Марсель Ибраев. Так что, заваривайте чаинский/кофеинский и приготовьтесь к погружению



ДОПОЛНИТЕЛЬНО:




НАВИГАЦИЯ:


0:00 Вступление
1:00 Коля о себе
5:02 Марсель о себе
11:54 О виртуализации
13:50 Отличие контейнеризации от виртуализации
17:54 Почему контейнеры работают быстро
19:05 Аналоги контейнеризации
20:35 Почему Docker захватил рынок
21:30 Про дебаг и логи в контейнера
23:18 Контейнеризация в винде
25:37 Почему нет нативного докера для винды
27:20 WSL
27:58 Про оркестрацию
30:30 Типичные примеры применения оркестратора
32:18 Кубернетис это только про контейнеры?
33:43 Конкуренты Docker
34:45 Как работает kubernetes
47:35 Опять про дебаг и кублеты
50:08 Для каких архитектурных мощностей хорош кубик
50:34 Про поды
51:51 Что с базами данных
1:00:45 Helm & чарты
1:05:11 Statefull-приложения и их разворачивание
1:07:30 Безопасность кубика
1:15:35 Навыки для работы с кубиком
1:16:32 Когда кубик использовать не стоит
1:18:02 Разница между ансиблом и кубиком
1:19:26 Что такое ansible и зачем это нужно
1:22:38 Как работает ансибл
1:26:15 Из чего состоит ансибл
1:33:20 Тесты конфигов
1:37:04 Нужно ли программирование, что бы работать с ансиблом
1:39:20 Навыки для работы с ансиблом
1:42:51 Про Слёрм и ламповый формат образования
1:53:48 Онлайн и корона сказался на качестве получения знаний?
1:57:35 Кто клиент Слёрма и какой порог входа на курсы
1:59:53 КОНКУРС


May the Kubernetes be with you!

Подробнее..

Проблема умной очистки образов контейнеров и её решение в werf

06.10.2020 10:05:04 | Автор: admin


В статье рассмотрена проблематика очистки образов, которые накапливаются в реестрах контейнеров (Docker Registry и его аналогах) в реалиях современных CI/CD-пайплайнов для cloud native-приложений, доставляемых в Kubernetes. Приведены основные критерии актуальности образов и вытекающие из них сложности при автоматизации очистки, сохранения места и удовлетворения потребностям команд. Наконец, на примере конкретного Open Source-проекта мы расскажем, как эти сложности можно преодолеть.

Введение


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

  1. использовать фиксированное количество тегов для образов;
  2. каким-либо образом очищать образы.

Первое ограничение иногда допустимо для небольших команд. Если разработчикам хватает постоянных тегов (latest, main, test, boris и т.п.), реестр не будет раздуваться в размерах и долгое время можно вообще не думать об очистке. Ведь все неактуальные образы перетираются, а для очистки просто не остаётся работы (всё делается штатным сборщиком мусора).

Тем не менее, такой подход сильно ограничивает разработку и редко применим к CI/CD современных проектов. Неотъемлемой частью разработки стала автоматизация, которая позволяет гораздо быстрее тестировать, развертывать и доставлять новый функционал пользователям. Например, у нас во всех проектах при каждом коммите автоматически создается CI-пайплайн. В нём собирается образ, тестируется, выкатывается в различные Kubernetes-контуры для отладки и оставшихся проверок, а если всё хорошо изменения доходят до конечного пользователя. И это давно не rocket science, а обыденность для многих скорее всего и для вас, раз вы читаете данную статью.

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

Но как вообще определить, актуален ли образ?

Критерии актуальности образа


В подавляющем большинстве случаев основные критерии будут таковы:

1. Первый (самый очевидный и самый критичный из всех) это образы, которые в настоящий момент используются в Kubernetes. Удаление этих образов может привести к серьезным издержкам в связи с простоем production (например, образы могут потребоваться при репликации) или свести на нет усилия команды, которая занимается отладкой на каком-либо из контуров. (По этой причине мы даже сделали специальный Prometheus exporter, отслеживающий отсутствие таких образов в любом Kubernetes-кластере.)

2. Второй (менее очевиден, но тоже очень важен и снова относится к эксплуатации) образы, которые требуются для отката в случае выявления серьёзных проблем в текущей версии. Например, в случае с Helm это образы, которые используются в сохраненных версиях релиза. (К слову, по умолчанию в Helm лимит в 256 ревизий, но вряд ли у кого-то реально есть потребность в сохранении такого большого количества версий?..) Ведь мы, в частности, для того и храним версии, чтобы можно было их потом использовать, т.е. откатываться на них в случае необходимости.

3. Третий потребности разработчиков: все образы, которые связаны с их текущими работами. К примеру, если мы рассматриваем PR, то имеет смысл оставлять образ, соответствующий последнему коммиту и, скажем, предыдущему коммиту: так разработчик сможет оперативно возвращаться к любой задаче и работать с последними изменениями.

4. Четвертый образы, которые соответствуют версиям нашего приложения, т.е. являются конечным продуктом: v1.0.0, 20.04.01, sierra и т.д.

NB: Определенные здесь критерии были сформулированы на основе опыта взаимодействия с десятками команд разработчиков из разных компаний. Однако, конечно, в зависимости от особенностей в процессах разработки и используемой инфраструктуры (например, не используется Kubernetes), эти критерии могут отличаться.

Соответствие критериям и существующие решения


Популярные сервисы с container registry, как правило, предлагают свои политики очистки образов: в них вы можете определять условия, при которых тег удаляется из registry. Однако возможности этих условий ограничиваются такими параметрами, как имена, время создания и количество тегов*.

* Зависит от конкретных реализаций container registry. Мы рассматривали возможности следующих решений: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io по состоянию на сентябрь'2020.

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

Например, третий критерий связанный с потребностями разработчиков может решаться за счет организации процессов внутри команд: специфичного именования образов, ведения специальных allow lists и внутренних договоренностей. Но в конечном счете его всё равно необходимо автоматизировать. А если возможностей готовых решений не хватает, приходится делать что-то своё.

Аналогична и ситуация с двумя первыми критериями: их невозможно удовлетворить без получения данных от внешней системы той самой, где происходит развёртывание приложений (в нашем случае это Kubernetes).

Иллюстрация workflow в Git


Предположим, вы работаете примерно по такой схеме в Git:



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

Что произойдёт, если политики очистки позволяют оставлять (не удалять) образы только по заданным названиям тегов?



Очевидно, такой сценарий никого не обрадует.

Что изменится, если политики позволяют не удалять образы по заданному временному интервалу / числу последних коммитов?



Результат стал значительно лучше, однако всё ещё далёк от идеала. Ведь у нас по-прежнему есть разработчики, которым нужны образы в реестре (или даже развёрнутые в K8s) для отладки багов

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

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

Наш путь к универсальной очистке образов


Откуда такая потребность? Дело в том, что мы не отдельно взятая группа разработчиков, а команда, которая обслуживает сразу множество таковых, помогая комплексно решать вопросы CI/CD. И главный технический инструмент для этого Open Source-утилита werf. Её особенность в том, что она не выполняет единственную функцию, а сопровождает процессы непрерывной доставки на всех этапах: от сборки до деплоя.

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

* Хоть сами реестры могут быть различными (Docker Registry, GitLab Container Registry, Harbor и т.д.), их пользователи сталкиваются с одними и теми же проблемами. Универсальное решение в нашем случае не зависит от реализации реестра, т.к. выполняется вне самих реестров и предлагает одинаковое поведение для всех.

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

Итак, мы занялись внешней реализацией механизма для очистки образов вместо тех возможностей, что уже встроены в реестры для контейнеров. Первым шагом стало использование Docker Registry API для создания всё тех же примитивных политик по количеству тегов и времени их создания (упомянутых выше). К ним был добавлен allow list на основе образов, используемых в развёрнутой инфраструктуре, т.е. Kubernetes. Для последнего было достаточно через Kubernetes API перебирать все задеплоенные ресурсы и получать список из значений image.

Такое тривиальное решение закрыло самую критичную проблему (критерий 1), но стало только началом нашего пути по улучшению механизма очистки. Следующим и куда более интересным шагом стало решение связать публикуемые образы с историей Git.

Схемы тегирования


Для начала мы выбрали подход, при котором конечный образ должен хранить необходимую информацию для очистки, и выстроили процесс на схемах тегирования. При публикации образа пользователь выбирал определённую опцию тегирования (git-branch, git-commit или git-tag) и использовал соответствующее значение. В CI-системах установка этих значений выполнялась автоматически на основании переменных окружения. По сути конечный образ связывался с определённым Git-примитивом, храня необходимые данные для очистки в лейблах.

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

  • При удалении ветки/тега в Git автоматически удалялись и связанные образы в registry.
  • Количество образов, связанное с Git-тегами и коммитами, можно было регулировать количеством тегов, использованных в выбранной схеме, и временем создания связанного коммита.

В целом, получившаяся реализация удовлетворяла нашим потребностям, но вскоре нас ожидал новый вызов. Дело в том, что за время использования схем тегирования по Git-примитивам мы столкнулись с рядом недостатков. (Поскольку их описание выходит за рамки темы этой статьи, все желающие могут ознакомиться с подробностями здесь.) Поэтому, приняв решение о переходе на более эффективный подход к тегированию (content-based tagging), нам пришлось пересмотреть и реализацию очистки образов.

Новый алгоритм


Почему? При тегировании в рамках content-based каждый тег может удовлетворять множеству коммитов в Git. При очистке образов больше нельзя исходить только из коммита, на котором новый тег был добавлен в реестр.

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

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

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

Итоговая конфигурация и общий алгоритм


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

  • множеством references, т.е. Git-тегами или Git-ветками, которые используются при сканировании;
  • илимитом искомых образов для каждого reference из множества.

Для иллюстрации вот как стала выглядеть конфигурация политик по умолчанию:

cleanup:  keepPolicies:  - references:      tag: /.*/      limit:        last: 10  - references:      branch: /.*/      limit:        last: 10        in: 168h        operator: And    imagesPerReference:      last: 2      in: 168h      operator: And  - references:        branch: /^(main|staging|production)$/    imagesPerReference:      last: 10

Такая конфигурация содержит три политики, которые соответствуют следующим правилам:

  1. Сохранять образ для 10 последних Git-тегов (по дате создания тега).
  2. Сохранять по не более 2 образов, опубликованных за последнюю неделю, для не более 10 веток с активностью за последнюю неделю.
  3. Сохранять по 10 образов для веток main, staging и production.

Итоговый же алгоритм сводится к следующим шагам:

  • Получение манифестов из container registry.
  • Исключение образов, используемых в Kubernetes, т.к. их мы уже предварительно отобрали, опросив K8s API.
  • Сканирование Git-истории и исключение образов по заданным политикам.
  • Удаление оставшихся образов.

Возвращаясь к нашей иллюстрации, вот что получается с werf:



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

Заключение


  • Рано или поздно с проблемой переполнения registry сталкивается большинство команд.
  • При поиске решений в первую очередь необходимо определить критерии актуальности образа.
  • Инструменты, предлагаемые популярными сервисами container registry, позволяют организовать очень простую очистку, которая не учитывает внешний мир: образы, используемые в Kubernetes, и особенности рабочих процессов в команде.
  • Гибкий и эффективный алгоритм должен иметь представление о CI/CD-процессах, оперировать не только данными Docker-образов.

P.S.


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

Подробнее..

Мёртвые оркестраторы оказывается не такие уж мёртвые

08.10.2020 08:19:04 | Автор: admin


На прошлой неделе Слёрм провел опрос об оркестраторах среди тех, кто прошел курсы или вечернюю школу по Kubernetes.
Результат, мягко говоря, удивил: 49 человек из 316 ответивших используют Docker Swarm, на котором мы поставили крест ещё два года назад! И это среди тех, кто как минимум знаком с Kubernetes.
Возможно, это аномалия. Возможно, Docker Swarm не так мертв, как нам казалось. Расскажите, пожалуйста, пользуетесь ли вы Свормом и почему?


В мобильной версии хабра не видно опросов. На этот случай гуглоформа с опросами: https://forms.gle/veaYBFirHVJoPtvm8

Подробнее..

Проект Kyma как разрабатывать приложения для SAP с использованием технологии Kubernetes

09.10.2020 10:12:07 | Автор: admin

Привет, Хабр! Давай сегодня поговорим о том, зачем SAP придумал Kyma и что это такое.

Kyma/kee-ma/в переводе с греческого - волна.

Это проект с открытым исходным кодом, построенный на основе Kubernetes. Основное назначение Kyma упрощение создания serverless и микросервисных cloud-native приложений для расширения функциональности SAP бизнес-решений. То есть с помощью нее можно создавать необходимую компании функциональность, но которая по тем или иным причинам не доступна в стандартных SAP решениях (например, SAP Ariba, SAP Business Suite, S/4HANA и др.).

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

Наверно возникает вопрос зачем требуется использовать Kyma вместо стандартного кластера Kubernetes? Несмотря на то, что Kubernetes (k8s) является платформой полного набора компонентов для управления жизненным циклом распределенных приложений, она оставляет за нами выбор решений для множества задач. Это может быть хранилище данных, резервное копирование, мониторинг шины обмена сообщениями, оркестровка сервисов и т.п. Для всех этих задач open source сообщество разработала большое количество проектов, решений и сервисов (например, Istio, Jaeger, Linkerd, и др.). Выбирая наиболее подходящий, можно гибко конфигурировать целевые системы. Но, с другой стороны, потребуется решение многих технических вопросов. Например, как установить то или иное решение/сервис, интегрировать его с другими выбранными сервисами, настроить сквозной мониторинг и др. Поэтому на реализацию оптимальной целевой архитектуры на кластере k8s может уйти много времени, экспертных знаний и дополнительных инженеров. Вот как раз для этого и можно использоваться Kyma.

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

Kyma состоит из нескольких компонентов, основные из которых:

- Application connector используется для подключения любого приложения к кластеру Kubernetes и предоставления его API и событий (events) через Kubernetes Service Catalog.

- Serverless позволяет создавать расширения для приложения через механизм функций (код Node.js). Код функции может запускаться вызовами API, а также событиями, поступающими из внешней системы.

- Service Catalog предоставляет простой доступ к сервисам, которыми управляют сервисные брокеры, и использует их в приложениях. Например, можно легко применять сервисы сторонних облачных платформ, таких как Azure, AWS или GCP.

Кроме этого в Kyma интегрированы одни из самых оптимальных и функциональных сервисов, использующихся в разработке cloud-native приложений:

- Мониторинг и оповещение основаны на PrometheusиGrafana.

- Для логирования используется Loki.

- Обработка событий происходит в NATS.

- Как средство управления и хранения данных/объектов используется Rafter и MinIO.

- Оркестровка сервисов ведется через Istio.

- Трассировка распределенных микросервисов осуществляется в Jaeger.

- Аутентификация поддерживается Dex и др.

Давайте разберемся с использованием Kyma на примере расширения SAP Service Cloud и SAP Field Service Management для работы с клиентскими отзывами.

1. Потребитель пишет комментарий на Facebook с номером своего заказа.

2. Аналитический микросервис (-сервис) делает его сентиментный анализ.

3. И если комментарий отрицательный, создает заявку в SAP Field Service Management (FSM); администратор FSM назначает ее техническому специалисту.

4. Далее при завершении работы над заявкой запускается lambda-функция.

5. Lambda-функция создает ответ клиенту на основе результатов работы над заявкой и отправляет его.

Для установки доступны две версии: полная (Kyma) и облегченная (Kyma Lite). Облегченная версия используется для локальной разработки и не устанавливает такие компоненты, как ведение журнала, мониторинг и т.д. Полный список всех компонентов, установленных для полной и облегченной версии, можно найти тут. Можно кастомизировать набор устанавливаемых компонентов через установочный yaml-файл.

Сейчас вендор также запустил SAP Cloud Platform Extension Factory, Kyma runtime. Благодаря этому теперь можно получить Kubernetes кластер в составе SAP Cloud Platform вместе с другими сервисами платформы для разработки приложений. Extension Factory, Kyma runtime работает на кластере Kubernetes который разворачивается через Gardener (еще один open source проект SAP, платформа для управления кластерами Kubernetes) в выбранном пользователем облачном провайдере и в необходимом регионе. В дальнейшем Extension Factory, Kyma runtime будет доступна в триальном режиме в SAP Cloud Platform.

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

Если вдруг вам захочется еще прочитать про Kyma, то вот дополнительные материалы:

Kyma Open Source website

SAP Help Portal

SAP Cloud Platform Discovery Center

Blog post: SAP Cloud Platform Extension Factory, Kyma runtime: How to get started

Kyma runtime onboarding mission

Автор Георгий Шутов, эксперт по платформенным решениямSAP CIS

Подробнее..

14 октября стартует продвинутый курс по Kubernetes последний в этом году

12.10.2020 12:10:07 | Автор: admin
14 октября начинается Kubernetes Мега онлайн-интенсив для опытных пользователей Kubernetes. Последний в 2020 году.



В программе: работа с Kubeadm, тестирование и траблшутинг кластера, авторизация через LDAP и OIDC, сетевые политики, политики безопасности, управление секретами, бэкапы и восстановление, ротация сертификатов, темплэйтирование и деплой, Service Mesh. Курс сложный, подойдет опытным пользователям Kubernetes.

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

Примеры занятий с базового курса:
Лекция: траблшутинг кластера

Лекция: продвинутые абстракции Kubernetes

Практика: поды, лимиты, деплой


Обучение идёт 3 дня, с 10:00 до 19.00. Включает 12 блоков и 12 практических занятий на выделенных стендах. Лекции через Zoom. Ответы на вопросы голосом, через Telegram. Рекомендуем освободить полностью эти 3 дня, совмещать интенсив с работой практически невозможно.

Лекторы:
  • Павел Селиванов, Senior DevOps-инженер в Mail.ru.
  • Сергей Бондарев, архитектор Southbridge и разработчик kubespray с правами на принятие pull request.
  • Марсель Ибраев, CTO Слёрм.


Стоимость интенсива: 50 000 рублей. Есть рассрочка, возможна оплата по договору.

Участие в Kubernetes Мега предполагает, что студент знает основные абстракции и компоненты Kubernetes, а также поработал с Kubernetes на практике. Пройти тест на готовность и сразу получить результат можно на сайте.

Узнать подробности и зарегистрироваться
Подробнее..

Оператор в Kubernetes для управления кластерами БД. Владислав Клименко (Altinity, 2019)

14.10.2020 10:20:11 | Автор: admin


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


В первой части доклада рассмотрим:


  • что такое оператор в Kubernetes и зачем он нужен;
  • как именно оператор упрощает управление сложными системами;
  • что оператор может, а что оператор не может.

Далее, перейдём к обсуждению внутреннего устройства оператора. Рассмотрим архитектуру и функционирование оператора по шагам. Подробно разберём:


  • взаимодействие между оператором и Kubernetes;
  • какие функции оператор берет на себя, а что делегирует в Kubernetes.

Рассмотрим управление шардами и репликами БД в Kubernetes.
Далее, обсудим вопросы хранения данных:


  • как работать с Persistent Storage с точки зрения оператора;
  • подводные камни использования Local Storage.

В заключительной части доклада рассмотрим практические примеры применения clickhouse-operator с Amazon или Google Cloud Service. Доклад строится на примере разработки и опыта эксплуатации оператора для ClickHouse.


Видео:



Меня зовут Владислав Клименко. Я хотел сегодня рассказать о нашем опыте разработки и эксплуатации оператора, причем это специализированный оператор для управления кластерами баз данных. На примере ClickHouse-operator для управления кластером ClickHouse.



Почему мы имеем возможность рассказывать об операторе и ClickHouse?


  • Мы занимаемся поддержкой и развитием ClickHouse.
  • На текущий момент мы стараемся потихоньку вносить свой посильный вклад в разработку ClickHouse. И являемся вторыми после Яндекса по объему сделанных изменений в ClickHouse.
  • Стараемся делать дополнительные проекты для экосистемы ClickHouse.

Об одном из таких проектов я хотел бы рассказать. Это про ClickHouse-operator для Kubernetes.


В своем докладе я хотел бы затронуть две темы:


  • Первая тема это как работает наш оператор по управлению базами данных ClickHouse в Kubernetes.
  • Вторая тема это как работает любой оператор, т. е. как он взаимодействует с Kubernetes.

При этом эти два вопроса будут пересекаться на протяжении всего моего доклада.



Кому будет интересно послушать то, что я пытаюсь рассказать?


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


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



Что такое ClickHouse? Это колоночная база данных со спецификой в онлайн-обработку аналитических запросов. И она полностью open source.


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



Зачем он там нужен? Почему мы не можем продолжать его эксплуатировать самостоятельно? И ответы частично технические, а частично организационные.


  • На практике мы все чаще и чаще встречаем такую ситуацию, когда в крупных компаниях уже практически все компоненты и так уже в Kubernetes. Остаются базы данных за пределами.
  • И все чаще задается вопрос: Можно ли это внутрь поместить?. Поэтому крупные компании стараются производить максимальную унификацию управления для того, чтобы быстро иметь возможность управлять своими хранилищами данных.
  • И особенно это помогает, если нужна максимальная возможность повторить тоже самое на новом месте, т. е. максимальная переносимость.


Насколько это просто или сложно? Это, конечно, можно делать руками. Но это не так, чтобы просто, потому что у нас складываются по сумме сложность управления самим Kubernetes, но при этом накладывается специфика ClickHouse. И получается такая агрегация.


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



У ClickHouse при динамической конфигурации есть достаточно большое количество вопросов, которые создают постоянную нагрузку на DevOps:


  • Когда мы хотим поменять что-то в ClickHouse, например, добавить реплику, шард, то нам надо провести управление конфигурацией.
  • Потом поменять схему данных, потому что у ClickHouse специфичный способ шардирования. Там надо раскладывать схему данных, раскладывать конфигурации.
  • Надо настроить мониторинг.
  • Сбор логов для новых шардов, для новых реплик.
  • Озаботиться восстановлением.
  • И перезапуском.

Это такие рутинные работы, которые очень бы хотелось облегчить в эксплуатации.



Сам Kubernetes хорошо помогает в эксплуатации, но на базовых системных вещах.


Kubernetes хорошо облегчает и производит автоматизацию таких вещей, как:


  • Восстановление.
  • Перезапуск.
  • Управление системой хранения.

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


Хочется большего, хочется, чтобы у нас работала вся база данных в Kubernetes.



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


И мы постарались сделать такое решение, которое помогло бы облегчить работу. Это ClickHouse-operator для Kubernetes от компании Altinity.



Оператор это программа, основная задача которой управлять другими программами, т. е. это управленец.


И он содержит шаблоны поведения. Можно это назвать кодифицированными знаниями о предметной области.


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


И как раз оператор это робот помощник, который борется с микрозадачами и помогает DevOps.



Зачем нужен оператор? Он особенно хорошо себя показывает в двух вопросах:


  • Когда у специалиста, который занимается ClickHouse, недостаточно опыта, но эксплуатировать ClickHouse уже надо, оператор облегчает эксплуатацию и позволяет эксплуатировать кластер ClickHouse с достаточно сложной конфигурацией, при этом не очень вдаваясь в подробности о том, как это все работает внутри. Просто ему даешь высокоуровневые задачи, и это работает.
  • И вторая задача, в которой он себя наиболее хорошо проявляет, это когда надо автоматизировать большое количество типовых задач. Снимает микрозадачи с сисадминов.


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



В чем же отличие подхода, основанного на операторах, от других систем? Есть же Helm. Он же тоже помогает поставить ClickHouse, можно нарисовать helm charts, которые даже поставят целый кластер ClickHouse. В чем тогда отличие между оператором и от того же, например, Helm?


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



Это была вступительная часть, давайте пойдем дальше.


Как мы строим свой оператор? Мы пытаемся подойти к вопросу, чтобы управлять кластером ClickHouse как одним ресурсом.


Вот у нас в левой части картины есть входные данные. Это YAML со спецификацией кластера, который классическим образом через kubectl передается в Kubernetes. Там у нас оператор это подхватывает, делает свою магию. И на выходе у нас получается вот такая схема. Это имплементация ClickHouse в Kubernetes.


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



Давайте исходить из практики. Наш проект это полностью open source, поэтому можно посмотреть на GitHub, как он работает. И можно исходить из соображений, если хочется просто запустить, то с Quick Start Guide можно начинать.


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



Давайте начнем с практической задачи. Первая задача, с чего мы все хотим начать, это запустить первый пример хоть как-нибудь. Как при помощи оператора запустить ClickHouse, даже не очень зная, как он работает? Пишем манифест, т.к. все общение с k8s это общение через манифесты.



Вот такой сложный манифест. То, что у нас выделено красным, это то, на чем надо акцентироваться. Мы оператора просим создать кластер по имени demo.


Пока что это базовые примеры. Storage еще не описывается, но мы к storage вернемся чуть позже. Пока что в динамике будем наблюдать за развитием кластера.


Создали мы этот манифест. Скармливаем его нашему оператору. Он поработал, сделал магию.



Смотрим в консоль. Интерес вызывают три компонента это Pod, два Service-a, StatefulSet.


Оператор отработал, и мы можем посмотреть, что именно он создал.



Создает он примерно такую схему. У нас есть StatefulSet, Pod, ConfigMap для каждой реплики, ConfigMap для всего кластера. Обязательно сервисы как точки входа в кластер.


Сервисы это центральный Load Balancer Service и можно еще для каждой реплики, для каждого шарда.


Вот у нас базовый кластер выглядит примерно таким образом. Он из одной единственной ноды.



Пойдем дальше, будем усложнять. Надо кластер шардировать.



У нас задачи растут, начинается динамика. Мы хотим добавить шард. Следим за развитием. Меняем нашу спецификацию. Указываем, что мы хотим два шарда.


Это тот же самый файл, который у нас динамически развивается с ростом системы. Storage нет, storage будет дальше рассмотрен, это отдельная тема.


Скармливаем YAML-оператор и смотрим, что получается.



Оператор подумал и сделал следующие сущности. У нас уже два Pod, три Service-a и, внезапно, 2 StatefulSet-а. Почему 2 StatefulSet-а?



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



Стало вот так. Пока что все просто, оно продублировалось.



И почему же StatefulSet стало два? Тут надо отвлечься и обсудить вопрос, как в Kubernetes происходит управление Podами.


Есть такой объект под названием StatefulSet, который позволяет делать набор Podов из шаблона. Тут ключевой фактор это Template. И можно в одном StatefulSet запускать по одному шаблону много Podов. И ключевой фразой тут является по одному шаблону много Podов.


И был большой соблазн сделать весь кластер, упаковав в один StatefulSet. Это будет работать, в этом нет никаких проблем. Но есть один нюанс. Если мы хотим собрать гетерогенный кластер, т. е. из нескольких версий ClickHouse, то тут у нас начинаются вопросы. Да, StatefulSet может сделать rolling update, да там можно накатывать новую версию, объяснять, что нужно попробовать не больше столько-то нодов одновременно.


Но если экстраполировать задачу и сказать, что мы хотим сделать полностью гетерогенный кластер и хотим не со старой версии поменять на новую при помощи rolling update, а просто хотим создать кластер гетерогенный как в части разных версий ClickHouse, так в части разного storage. Мы хотим, например, какие-то реплики сделать на отдельных дисках, на медленных, в общем, полностью построить гетерогенный кластер. И из-за того, что StatefulSet делает из одного шаблона стандартизованное решение, поэтому нет возможности это сделать.


После некоторого раздумья было принято решение, что мы делаем вот так. У нас каждая реплика в своем StatefulSet. Есть некоторые недостатки у этого решения, но на практике это все полностью в себе инкапсулирует оператор. И есть куча достоинств. Мы можем строить полностью такой кластер, какой хотим, например абсолютно гетерогенный. Поэтому в кластере, в котором у нас два шарда по одной реплике, у нас будет 2 StatefulSetа и 2 Podа именно потому, что мы избрали такой подход из-за вышеозвученным причинам для возможности построить гетерогенный кластер.



Вернемся к практическим задачам. В нашем кластере надо настраивать пользователей, т.е. надо производить какое-то конфигурирование ClickHouse в Kubernetes. Оператор для этого предоставляет все возможности.



Можно прямо в YAML писать то, что мы хотим. Все конфигурационные опции прямиком мапятся из этого YAML в конфиги ClickHouse, которые потом раскладываются по всему кластеру.


Можно и вот так писать. Это для примера. Пароль можно шифрованный сделать. Поддерживаются абсолютно все конфигурационные опции ClickHouse. Здесь только пример.


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



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



Что нам нужно для репликации?


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


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



И схема взаимодействия всей системы получается вот такая. У нас есть Kubernetes как платформа. На нем исполняется оператор ClickHouse. ZooKeeper я изобразил вот здесь. И оператор взаимодействует как с ClickHouse, так и с ZooKeeper. Т. е. получается взаимодействие.


И все это надо для того, чтобы ClickHouse удачно реплицировал данные в k8s.



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


Мы к нашему манифесту добавляем две секции. Первая это где брать ZooKeeper, который может быть как внутри Kubernetes, так и внешний. Это просто описание. И заказываем реплики. Т.е. мы хотим две реплики. Итого на выходе у нас должно быть 4 podа. Про storage мы помним, он вернется чуть дальше. Storage это отдельная песня.



Было вот так.



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



И настало время добавлять следующую задачу. Будем добавлять Persistent Storage.


По Persistent Storage у нас есть различные варианты исполнения.


В случае, если мы исполняемся в cloud-провайдере, например, используя Amazon, Google, то есть большой соблазн воспользоваться облачным storage. Это очень удобно, это хорошо.


И есть второй вариант. Это для local storage, когда у нас диски локальные на каждой ноде. Этот вариант намного сложнее в исполнении, но при этом он более производительный.



Давайте посмотрим, что у нас относительно cloud storage.


Есть достоинства. Это очень просто конфигурировать. Мы просто заказываем у облачного провайдера, что дай нам, пожалуйста, storage такой-то емкости, такого-то класса. Классы расписаны провайдерами самостоятельно.


И есть недостаток. Для кого-то это некритичный недостаток. Конечно, там будут какие-то накладки по производительности. Это очень удобно в работе, надежно, но есть некие потенциальные просадки по производительности.



А т.к. ClickHouse акцентируется именно на производительности, можно даже сказать, что выжимает все, что можно, поэтому очень многие клиенты стараются выжать максимум производительности.



А чтобы выжать максимум, нам нужен local storage.


Kubernetes предоставляет три абстракции для использования local storage в Kubernetes. Это:


  • EmptyDir
  • HostPath.
  • Local

Рассмотрим, чем они различаются, чем они похожи.


Во-первых, во всех трех подходах у нас storage это локальные диски, которые находятся на том же самой физической k8s ноде. Но у них есть некоторые различия.



Начнем с самого простого, т. е. с emptyDir. Что это на практике такое? Это мы у своей спецификации просим систему контейнеризации (чаще всего это докер) предоставить нам доступ в папку к локальному диску.


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


Как это будет работать по производительности? Это будет работать со скоростью локального диска, т.е. это полностью доступ к своему винту.


Но у этого дела есть свой недостаток. Persistent в этом деле достаточно сомнительный. При первом же движении докера с контейнерами Persistent теряется. Если Kubernetes захочется по какой-то причине перенести этот Pod на другой диск, то данные потеряются.


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



Поэтому есть второй подход. Это hostPath. Если посмотреть предыдущий слайд и этот, то можно увидеть одно только различие. У нас папка выехала из докера прямо на Kubernetes ноду. Тут немного попроще. Мы прямо прописываем путь по локальной файловой системе, где мы бы хотели хранить свои данные.


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


Есть и недостатки. Это сложность управления. Наш Kubernetes может захотеть Pod передвинуть на другую физическую ноду. И тут уже вступает в дело DevOps. Он должен правильно объяснить всей системе, что передвигать эти podы можно только лишь на такие ноды, на которых у тебя по этим путям что-то смонтировано, и не больше одной ноды за раз. Это достаточно сложно.


Специально для этих целей, мы у себя в операторе сделали шаблоны для того, чтобы всю эту сложность спрятать. И можно было бы просто сказать: Я хочу, чтобы был у меня один instance ClickHouse на каждую физическую ноду и по такому-то пути.



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


Он называется local. Разницы от предыдущего слайда практически никакой. Только раньше надо было руками проводить, что у нас нельзя эти podы переносить с ноды на ноду, потому что они должны быть прицеплены по такому-то пути к локальному физическому диску, а теперь все эти знания инкапсулируется в сам Kubernetes. И получается намного проще конфигурировать.



Вернемся к нашей практической задаче. Вернемся к YAML template. Тут у нас появился настоящий storage. Мы вернулись к этому. Мы задаем классический VolumeClaim template как в k8s. И описываем, какой storage мы хотим.


После этого k8s запросит storage. Выделит нам его в StatefulSet. И в итоге это получится в распоряжении ClickHouse.



Была у нас вот такая схема. Наш Persistent Storage был красным, что как бы намекало на то, что его надо бы сделать.



И он становится зеленым. Теперь схема кластера ClickHouse on k8s полностью финализирована. У нас есть шарды, реплики, ZooKeeper, есть настоящий Persistent, который реализован тем или иным способом. Схема уже полностью работоспособная.



Мы продолжаем жить дальше. У нас кластер развивается. И Алексей старается, и выпускает новую версию ClickHouse.


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


Что мы можем сказать по этому поводу?



Тут у нас есть как раз и такая возможность. Это шаблоны podов. Можно расписать, наш оператор полностью позволяет построить кластер гетерогенный. Т.е. конфигурировать, начиная от всех реплик кучей, заканчивая каждой персональной репликой тем, какой версии мы хотим ClickHouse, какой версии мы хотим storage. Мы можем полностью сконфигурировать кластер такой конфигурации, как нам надо.



Немножко будем уже углубляться внутрь. До этого мы говорили, как работает ClickHouse-operator применительно к специфике ClickHouse.


Теперь я хотел бы сказать пару слов о том, как работает вообще любой оператор, а также о том, как взаимодействует с K8s.



Рассмотрим взаимодействие с K8s для начала. Что происходит, когда мы делаем kubectl apply? У нас через API в etcd появляются наши объекты.



К примеру базовые объекты Kubernetes: pod, StatefulSet, service и так далее по списку.


При этом ничего физического еще не происходит. Эти объекты надо материализовать в кластере.



Для этого появляется контроллер. Контроллер это специальный компонент k8s, который умеет материализовывать эти описания. Он знает, как и что надо делать физически. Он знает, как запускать контейнеры, что там надо настроить для того, чтобы заработал сервер.



И он материализует наши объекты в K8s.


Но мы хотим оперировать не только pod-ами, StatefulSet-ами, мы хотим создать ClickHouseInstallation, т. е. объект типа ClickHouse, чтобы оперировать им как единым целом. Пока что такой возможности нет.



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



И что для этого надо сделать? Во-первых, на сцену выходит Custom Resource Definition. Что это такое? Это описание для K8s, что у тебя будет еще один тип данных, что мы к pod, StatefulSet хотим добавить кастомный ресурс, который будет сложным внутри. Это описание структуры данных.



Мы его тоже через kubectl apply туда отправляем. Kubernetes его радостно забрал.


И теперь у нас в хранилище, у объекта в etcd появляется возможность записать кастомный ресурс под названием ClickHouseInstallation.


Но пока что ничего дальше не произойдет. Т. е. если мы сейчас создадим YAML-файл, который мы рассматривали с описанием шард, реплик и скажем kubectl apply, то Kubernetes его примет, положит в etcd и скажет: Отлично, но что с ним делать, не знаю. Как обслуживать ClickHouseInstallation я не знаю.



Соответственно, нам нужен кто-то, кто поможет Kubernetes обслуживать новый тип данных. Слева у нас есть штатный контроллер Kubernetes, который работает со штатными типами данных. А справа у нас должен появиться кастомный контроллер, который умеет работать с кастомными типами данных.


И по-другому он называется оператор. Я его здесь специально вынес за Kubernetes, потому что он может исполняться и снаружи K8s. Чаще всего, конечно, все операторы исполняются в Kubernetes, но ничего не мешает ему стоять снаружи, поэтому тут он специально вынесен наружу.



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



Как работает оператор? Давайте заглянем в правую часть, чтобы узнать, как он это делает. Узнаем, как оператор все это материализует и как дальше происходит взаимодействие с K8s.



Оператор это программа. Она событийно ориентированная. Оператор при помощи Kubernetes API подписывается на события. В Kubernetes API есть точки входа, в которых можно подписаться на события. И если что-то в K8s меняется, то Kubernetes посылает события всем желающим, т.е. кто на эту точку API подписался, тот и будет получать уведомления.


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



События генерируются некими апдейтами. Приходит наш YAML-файл с описанием ClickHouseInstallation. Он через kubectl apply пошел в etcd. Там сработал event, в итоге этот event пришел в ClickHouse-operator. Оператор получил это описание. И он что-то должен делать. Если пришел апдейт на объект ClickHouseInstallation, то надо апдейтить кластер. И задача оператора это апдейтить кластер.



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



Он начинает согласно этому плану варить эту структуру внутри, чтобы материализовать podы, сервисы, т.е. делать то, что его основной задачей и является. Это как строить кластер ClickHouse в Kubernetes.



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


Kubernetes отвечает за системные вещи, т.е. за базовый набор объектов, который можно интерпретировать как system-scope. Kubernetes знает, как запускать podы, как рестартить контейнеры, как делать mount volumes, как работать с ConfigMap, т.е. все, что можно назвать системой.


Операторы оперируют в предметных областях. Каждый оператор делается для своей предметной области. Мы сделали для ClickHouse.


И оператор взаимодействует именно в терминах предметной области таких, как добавить реплику, сделать схему, настроить мониторинг. Получается такое разделение.



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


В оператор приходит задача добавить реплику. Что оператор делает? Оператор рассчитает, что надо новый сделать StatefulSet, в котором надо описать такие-то шаблоны, volume claim.



Он это все подготовил и передает дальше в K8s. Говорит, что ему надо ConfigMap, StatefulSet, Volume. Kubernetes отрабатывает. Он материализует базовые единицы, которыми он оперирует.



И дальше в дело вступает снова ClickHouse-operator. У него уже есть физический pod, на котором можно уже что-то делать. И ClickHouse-operator снова работает в терминах предметной области. Т.е. конкретно ClickHouse для того, чтобы включить реплику в кластер надо, во-первых, настроить схему данных, которая в этом кластере есть. А, во-вторых, эту реплику надо включить в мониторинг, чтобы она хорошо прослеживалась. Уже оператор это настраивает.



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


Получается цепочка выполнения и разделения ответственности при добавлении реплики достаточно длинной.



Продолжаем наши практические задачи. Если кластер уже есть, то можно осуществить миграцию конфигурации.



Мы сделали так, что в существующий xml, которую ClickHouse понимает, можно прокидывать насквозь.



Можно сделать тонкую настройку ClickHouse. Как раз zoned deployment это то, о чем я рассказывал при объяснении hostPath, local storage. Это как правильно сделать zoned deployment.



Следующая практическая задача это мониторинг.



Если у нас кластер меняется, то надо периодически настраивать мониторинг.


Давайте рассмотрим схему. Мы зеленые стрелки тут уже рассмотрели. Теперь давайте рассмотрим красные стрелки. Это то, как мы хотим мониторить наш кластер. Как метрики из кластера ClickHouse попадают в Prometheus, а потом в Grafana.



А в чем сложность с мониторингом? Почему это выносится как какое-то достижение? Сложность именно в динамике. Когда у нас кластер один и он статический, то можно единожды настроить мониторинг и больше не заморачиваться.


Но если у нас кластеров много, или постоянно что-то меняется, то процесс динамический. И постоянно заниматься перенастройкой мониторинга это трата ресурсов и времени, т.е. даже просто лень. Это надо автоматизировать. Сложность именно в динамике процесса. И оператор это очень хорошо автоматизирует.



Как у нас развивался кластер? В начале он был такой.



Потом он был такой.



В итоге он стал вот таким.


А мониторинг автоматически делается оператором. Единая точка входа.



И мы всего лишь на выходе смотрим в Grafana dashboard, как там внутри кипит жизнь нашего кластера.


Кстати, Grafana dashboard тоже распространяется с нашим оператором прямо в исходниках. Можно подключать и пользоваться. Вот этот скриншот мне наши DevOps дали.



Куда бы мы хотели двигаться дальше? Это:


  • Развивать автоматизацию тестирования. Основная задача это автоматизированное тестирование новых версий.
  • Также мы очень хотим автоматизировать интеграцию с ZooKeeper. И в планах интегрироваться с ZooKeeper-operator. Т.е. для ZooKeeper написан оператор и логично, чтобы два оператора начали интегрироваться для построения более удобного решения.
  • Мы хотим сделать более сложные проверки жизнедеятельности.
  • Зеленым я выделил то, что у нас на подходе наследование Templates DONE, т. е. со следующим релизом оператора у нас уже будет наследование шаблонов. Это мощный инструмент, который позволяет строить сложные конфигурации из кусочков.
  • И мы хотим автоматизацию сложных задач. Основная из которых это Re-sharding.


Давайте проведем промежуточные итоги.



Что мы получаем на выходе? И стоит ли этим заниматься или не стоит? Надо ли вообще пытаться затащить базу данных в Kubernetes и применять оператор в целом и Alitnity-оператор в частности.


На выходе мы получаем:


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


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


Ответ все нормально! Я не буду подробно расписывать, это тема отдельного доклада.



Но есть такой проект, как TSBS. Какая его основная задача? Это тест баз данных на производительность. Это попытка сравнивать теплое с теплым, мягкое с мягким.


Как он работает? Генерируется один набор данных. Потом этот набор данных на одинаковом наборе тестов прогоняется на разных базах данных. И каждая база данных решает одну задачу так, как она умеет. И потом можно результаты сравнивать.


Он уже поддерживает большую кучу баз данных. Я выделил три основных. Это:


  • TimescaleDB.
  • InfluxDB.
  • ClickHouse.


Также было проведено сравнение с другим решением похожим. Сравнение с RedShift. Сравнение было произведено на Amazon. ClickHouse тоже хорошо всех обгоняет в данном вопросе.



Какие можно сделать выводы из того, что я рассказал?


  • DB в Kubernetes можно. Наверное, можно любые, но в целом выглядит, что можно. ClickHouse в Kubernetes точно можно силами нашего оператора.
  • Оператор помогает автоматизировать процессы и реально упрощает жизнь.
  • Производительность нормальная.
  • И, нам кажется, что это можно и нужно использовать.

Open source присоединяйтесь!


Как я уже говорил, оператор это полностью open source продукт, поэтому было бы очень хорошо, если бы максимальное количество людей его использовало. Присоединяйтесь! Мы ждем вас всех!


Всем спасибо!


Вопросы



Спасибо за доклад! Меня зовут Антон. Я из компании SEMrush. Мне интересно, что с логированием. Про мониторинг слышно, а про логирование ничего, если говорить о кластере целиком. У нас, например, поднят кластер на железе. И мы используем централизованное логирование, стандартными средствами собираем в общую кучу. И потом оттуда достаем интересные нам данные.


Хороший вопрос, т. е. логирование в списке todo. Оператор наш пока что это не автоматизирует. Он еще развивается, проект еще достаточно молодой. Мы понимаем необходимость логирования. Это тоже очень важная тема. И она, наверное, не менее важная, чем мониторинг. Но первым в списке на реализацию был мониторинг. Логирование будет. Мы, естественно, стараемся проавтоматизировать все стороны жизнедеятельности кластера. Поэтому ответ на текущий момент оператор, к сожалению, этого не умеет, но это есть в планах, мы это будем делать. Если есть желание присоединиться, то pull request, пожалуйста.


Здравствуйте! Спасибо за доклад! У меня стандартный вопрос, связанные с Persistent Volumes. Когда мы создаем данным оператором конфигурацию, как оператор определяет на какой ноде у нас примоутен какой-то диск, либо папка? Мы должны ему предварительно объяснить, что, пожалуйста, размести наш ClickHouse именно на этих нодах, на которых есть диск?


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


Вкратце это выглядит так. Нам, естественно, надо сделать provisioning этих volumes. На текущей момент в local storage динамического provision нет, поэтому DevOps должны сами нарезать диски, вот эти volumes. И должны объяснить Kubernetes provisioning, что у тебя будут Persistent volumes такого-то класса, который находится на таких-то нодах. Потом надо будет объяснить Kubernetes, что podы, которые требуют такой-то класс local storage, надо по labels шедулить только на такие-то ноды. Для этих целей в операторе есть возможность назначить каким-то label и one per host instance. И получится, что podы будут смаршрутизированы Kubernetesом для запуска только на ноды, удовлетворяющим требованиям, labels, говоря простым языком. Администраторы назначают labels, делают provisioning дисков руками. И тогда оно масштабируется.


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


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


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


Теперь практический вопрос. Что делать, если у вас потерялась нода, на которой диск был? Тут уже задача решается на более высоком уровне. В случае с ClickHouse у нас есть реплики, которые работают на уровне выше, т.е. на уровне ClickHouse.


Какая получается диспозиция? За то, чтобы не потерялись данные отвечает DevOps. Он должен правильно настроить репликацию и должен следить, чтобы репликация исполнялась. В реплике на уровне ClickHouse должны быть данные продублированы. Это не та задача, которую решает оператор. И не та задача, которую решает сам Kubernetes. Это на уровне ClickHouse.


Что делать, если у вас железная нода отвалилась? И получается, что надо будет поставить вторую, правильно на ней спровижинить диск, нанести labels. И после этого она станет удовлетворять требованиям, что Kubernetes на ней может запустить instance podа. Kubernetes его запустит. У вас же количество podов не хватает до заданного. Она пройдет по циклу, который я показывал. И на самом верхнем уровне ClickHouse поймет, что у нас вошла реплика, она еще пустая и на нее надо начинать переливать данные. Т.е. этот процесс еще плохо автоматизированный.


Спасибо за доклад! Когда происходят всякие гадости, падает оператор и перезапускается, а в этот момент поступают события, вы как-то обрабатываете это?


Что произойдет, если оператор упал и перезапустился, да?


Да. И в этот момент поступили события.


Задача, что делать в этом случае частично разделяется между оператором и Kubernetes. Kubernetes имеет возможность перепроиграть произошедшее событие. Он перепроигрывает. А уже задача оператора сделать так, чтобы, когда на него был сделал replay лога событий, чтобы эти события были идемпотентными. И чтобы повторное вхождение того же события не ломало нам нашу систему. И наш оператор с этой задачей справляется.


Здравствуйте! Спасибо за доклад! Дмитрий Завьялов, компания Смедова. Планируется ли добавление в оператор возможности настройки с haproxy? Интересен какой-нибудь другой балансировщик помимо стандартного, чтобы он умным был и понимал, что там реально ClickHouse.


Вы говорите про Ingress?


Да, Ingress заменить на haproxy. В haproxy можно указать топологию кластера, где у него реплики.


Пока что мы над этим не думали. Если вам это надо и сможете объяснить, зачем это надо, то можно будет реализовать, особенно, если вы захотите поучаствовать. Мы с удовольствием рассмотрим вариант. Краткий ответ нет, у нас на текущий момент такой функциональности нет. Спасибо за наводку, мы на это дело посмотрим. А если вы еще объясните use case и зачем это надо на практике, например, issues на GitHub создадите, то прекрасно будет.


Уже есть.


Хорошо. Мы открыты к любым предложениям. И haproxy ставится в список todo. Список todo растет, а не убавляется пока. Но это хорошо, это значит, что продукт востребован.

Подробнее..

Прости, OpenShift, мы недостаточно ценили тебя и принимали как должное

15.10.2020 12:13:13 | Автор: admin
Этот пост написан поскольку у наших сотрудников было довольно много разговоров с клиентами о разработке приложений на Kubernetes и о специфике такой разработки на OpenShift.



Начинаем мы обычно с тезиса, что Kubernetes это просто Kubernetes, а OpenShift это уже Kubernetes-платформа, как Microsoft AKS или Amazon EKS. У каждой из этих платформ есть свои плюсы, ориентированные на ту или иную целевую аудиторию. И после этого разговор уже перетекает в сравнение сильных и слабых сторон конкретных платформ.

В общем, мы думали написать этот пост с выводом типа Слушайте, да без разницы, где запускать код, на OpenShift или на AKS, на EKS, на каком-то кастомном Kubernetes, да на каком-угодно-Kubernetes (для краткости назовем его КУК) это реально просто, и там, и там.

Затем мы планировали взять простейший Hello World и на его примере показать, что общего и в чем различия между КУК и Red Hat OpenShift Container Platform (далее, OCP или просто OpenShift).

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

В общем, пришла пора деятельного раскаяния, и сейчас мы пошагово сравним ввод в строй своего Hello World на КУК и на OpenShift, и сделаем это максимально объективно (ну разве что выказывая иногда личное отношение к предмету). Если вам интересно сугубо субъективное мнение по этому вопросу, то его можно прочитать здесь (EN). А в этом посте мы будем придерживаться фактов и только фактов.

Кластеры


Итак, для нашего Hello World нужны кластеры. Сразу скажем нет всяким публичным облакам, чтобы не платить за сервера, реестры, сети, передачу данных и т.д. Соответственно, мы выбираем простой одноузловой кластер на Minikube (для КУК) и Code Ready Containers (для кластера OpenShift). Оба этих варианта реально просты в установке, но потребуют довольно много ресурсов на вашем ноуте.



Сборка на КУК-е


Итак, поехали.

Шаг 1 собираем наш контейнерный образ


Начнем я с того, что развернем наш Hello World на minikube. Для этого потребуется:

  1. 1. Установленный Docker.
  2. 2. Установленный Git.
  3. 3. Установленный Maven (вообще-то в этом проекте используется mvnw-бинарник, так что можно обойтись и без этого).
  4. 4. Собственно, сам исходник, т.е. клон репозитория github.com/gcolman/quarkus-hello-world.git

Первым делом надо создать проект Quarkus. Не пугайтесь, если никогда не работали с сайтом Quarkus.io это легко. Просто выбираете компоненты, которые хотите использовать в проекте (RestEasy, Hibernate, Amazon SQS, Camel и т.д.), а дальше Quarkus уже сам, без какого-либо вашего участия, настраивает архетип maven и выкладывает всё на github. То есть буквально один клик мышью и готово. За это мы и любим Quarkus.



Самый простой способ собрать наш Hello World в контейнерный образ использовать расширения quarkus-maven для Dockerа, которые и проделают всю необходимую работу. С появлением Quarkus это стало действительно легко и просто: добавляете расширение container-image-docker и можете создавать образы командами maven.

./mvnw quarkus:add-extension -Dextensions=container-image-docker

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



./mvnw -X clean package -Dquarkus.container-image.build=true

Вот, собственно, и всё, теперь можно запускать контейнер командой docker run, подмапив наш сервис на порт 8080, чтобы к нему можно было обращаться.

docker run -i  rm -p 8080:8080 gcolman/quarkus-hello-world




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



Итак, всё работает, и это было действительно легко и просто.

Шаг 2 отправляем наш контейнер в репозиторий контейнерных образов


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

Это тоже очень просто, и нужен здесь только аккаунт на dockerhub.

Итак, ставим dockerhub и отправляем туда наш образ.



Шаг 3 запускаем Kubernetes


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

Для начала запускаем кластер minikube:

minikube start

Шаг 4 развертываем наш контейнерный образ


Теперь надо преобразовать наш код и контейнерный образ в конфигурации kubernetes. Иначе говоря, нам нужен pod и deployment definition с указанием на наш контейнерный образ на dockerhub. Один из самых простых способов это сделать запустить команду create deployment, указав на наш образ:



kubectl create deployment hello-quarkus  image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

Этой командной мы сказали нашей КУК создать deployment configuration, которая должна содержать спецификацию podа для нашего контейнерного образа. Эта команда также применит эту конфигурацию к нашему кластеру minikube, и создаст deployment, который скачает наш контейнерный образ и запустит pod в кластере.

Шаг 5 открываем доступ к нашему сервису


Теперь, когда у нас есть развернутый контейнерный образ, пора подумать, как сконфигурировать внешний доступ к этому Restful-сервису, который, собственно, и запрограммирован в нашем коде.

Тут есть много способов. Например, можно использовать команду expose, чтобы автоматически создавать соответствующие Kubernetes-компоненты, такие как services и endpoints. Собственно, так мы и сделаем, выполнив команду expose для нашего deployment-объекта:

kubectl expose deployment hello-quarkus  type=NodePort  port=8080

Давайте на минутку остановимся на опции type команды expose.

Когда мы делаем expose и создаем компоненты, необходимые для запуска нашего сервиса, нам, среди прочего, надо, чтобы снаружи можно было подключиться к службе hello-quarkus, которая сидит внутри нашей программно-определяемой сети. И параметр type позволяет нам создать и подключить такие вещи, как балансировщики нагрузки, чтобы маршрутизировать трафик в эту сеть.

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

В нашем примере type=NodePort, то есть обращение к нашему сервису идет по IP-адресу узла и номеру порта. Такой вариант позволяет не использовать никакие публичные облака, но требует ряд дополнительных шагов. Во-первых, нужен свой балансировщик нагрузки, поэтому мы развернем в своем кластере балансирощик нагрузки NGINX.

Шаг 6 ставим балансировщик нагрузки


У minikube есть ряд платформенных функций, облегчающих создание необходимых для доступа извне компонентов, вроде ingress-контроллеров. Minikube идет в комплекте с ingress-контроллером Nginx, и нам остается только включить его и настроить.

minikube addons enable ingress

Теперь мы всего одной командой создам ingress-контроллер Nginx, который будет работать внутри нашего кластера minikube:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

Шаг 7 Настраиваем ingress


Теперь нам надо настроить ingress-контроллер Nginx, чтобы он воспринимал запросы hello-quarkus.





И, наконец, нам надо применить эту конфигурацию.



kubectl apply -f ingress.yml




Поскольку мы делаем все это на своем компе, то просто добавляем IP-адрес своей ноды в файл /etc/ hosts, чтобы направлять http-запросы к нашему minikube на балансировщик нагрузки NGINX.

192.168.99.100 hello-quarkus.info

Всё, теперь наш сервис minikube доступен снаружи через ingress-контроллер Nginx.



Ну что, это же было легко, да? Или не очень?





Запуск на OpenShift (Code Ready Containers)


А теперь посмотрим, как это все делается на Red Hat OpenShift Container Platform (OCP).

Как в случае с minikube, мы выбираем схему с одноузловым кластером OpenShift в форме Code Ready Containers (CRC). Раньше это называлось minishift и базировалось на проекте OpenShift Origin, а теперь это CRC и построено на Red Hatовской OpenShift Container Platform.

Здесь мы, извините, не можем сдержаться и не сказать: OpenShift прекрасен!

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

Давайте пробежимся по процессу и посмотрим, что нам потребуется сделать.

Итак, в примере с minikube мы начинали с Docker Стоп, нам больше не надо, чтобы на машине был установлен Docker.

И локальный git нам не нужен.
И Maven не нужен.
И не надо руками создавать контейнерный образ.
И не надо искать какой-нибудь репозиторий контейнерных образов.
И не надо устанавливать ingress-контроллер.
И конфигурировать ingress тоже не надо.


Вы поняли, да? Чтобы развернуть и запустить наше приложение на OpenShift, не нужно ничего из вышеперечисленного. А сам процесс выглядит следующим образом.

Шаг 1 Запускаем свой кластер OpenShift


Мы используем Code Ready Containers от Red Hat, который по сути есть тот же Minikube, но только с полноценным одноузловым кластером Openshift.

crc start

Шаг 2 Выполняем сборку и развертывание приложения в кластере OpenShift


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

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

Мы будем использовать OpenShift'овский процесс Source 2 Image (S2I), у которого есть несколько различных способов для того, чтобы взять наш исходник (код или двоичные файлы) и превратить его в контейнерный образ, запускаемый в кластере OpenShift.

Для этого нам понадобятся две вещи:

  • Наш исходный код в репозитории git
  • Builder-образ, на основании которого будет выполняться сборка.

Существует множество таких образов, сопровождаемых как силами Red Hat, так и на уровне сообщества, и мы воспользуемся образом OpenJDK, ну поскольку я же собираю Java-приложение.

Запустить S2I-сборку можно, как и из графической консоли OpenShift Developer, так и из командной строки. Мы воспользуемся командой new-app, указав ей, где брать builder-образ и наш исходный код.



oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

Всё, наше приложение создано. При этом процесс S2I выполнил следующие вещи:

  • Создал служебный build-pod для всяких вещей, связанных со сборкой приложения.
  • Создал конфиг OpenShift Build.
  • Скачал builder-образ во внутренний docker-реестр OpenShift.
  • Клонировал Hello World в локальный репозиторий.
  • Увидел, что там есть maven pom, и поэтому скомпилировал приложение с помощью maven.
  • Создал новый контейнерный образ, содержащий скомпилированное Java-приложение, и положил этот образ во внутренний реестр контейнеров.
  • Создал Kubernetes Deployment со спецификациями podа, сервиса и т.д.
  • Запустил deploy контейнерного образа.
  • Удалил служебный build-pod.

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

Если визуально отслеживать запуск S2I в консоли, то можно видно, как при выполнении сборки запускается build pod.



А теперь взглянем логи builder podа: во-первых, там видно, как maven делает свою работу и скачивает зависимости для сборки нашего java-приложения.



После того, как закончена maven-сборка, запускается сборка контейнерного образа, и затем этот собранный образ отправляется во внутренний репозиторий.



Всё, процесс сборки завершен. Теперь убедимся, что в кластере запустились podы и сервисы нашего приложения.

oc get service




Вот и всё. И всего одна команда. Нам остается только сделать expose этого сервиса для доступа извне.

Шаг 3 делаем expose сервиса для доступа извне


Как и в случае КУК, на платформе OpenShift нашему Hello World тоже нужен роутер, чтобы направлять внешний трафик на сервис внутри кластера. В OpenShift это делает очень просто. Во-первых, в кластере по умолчанию установлен компонент маршрутизации HAProxy (его можно поменять на тот же NGINX). Во-вторых, здесь есть специальные и допускающие широкие возможности настройки ресурсы, которые называются Routes и напоминают Ingress-объекты в старом добром Kubernetes (на самом деле OpenShiftовкие Routes сильно повлияли на дизайн Ingress-объектов, которые теперь можно использовать и в OpenShift), но для нашего Hello World, да и почти во всех остальных случаях, нам хватит стандартного Route без дополнительной настройки.

Чтобы создать для Hello World маршрутизируемый FQDN (да, в OpenShiift есть свой DNS для маршрутизации по именам сервисов), мы просто выполним expose для нашего сервиса:



oc expose service quarkus-hello-world

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

oc get route




И наконец, обращаемся к нашему сервису из браузера:



А вот теперь это было действительно легко!


Мы любим Kubernetes и всё, что позволяет делать эта технология, а также мы любим простоту и легкость. Kubernetes создавался, чтобы невероятно упростить эксплуатацию распределенных масштабируемых контейнеров, но вот для ввода в строй приложений его простоты сегодня уже недостаточно. И здесь в игру вступает OpenShift, который идет в ногу со временем и предлагает Kubernetes, ориентированный в первую очередь на разработчика. Была вложена масса усилий, чтобы заточить платформу OpenShift именно под разработчика, включая создание таких инструментов, как S2I, ODI, Developer Portal, OpenShift Operator Framework, интеграция с IDE, Developer Catalogues, интеграция с Helm, мониторинг и многие другие.

Надеемся, что эта статься была для вас интересной и полезной. А найти дополнительные ресурсы, материалы и другие полезные для разработки на платформе OpenShift вещи можно на портале Red Hat Developers.

Перевод, источник: itnext.io/im-sorry-openshift-i-ve-taken-you-for-granted-the-evidence-dd7a7d471fa1
Подробнее..

Перевод Доступен NGINX Service Mesh

16.10.2020 12:13:24 | Автор: admin


Мы рады представить предварительную версию NGINX Service Mesh (NSM), связанную легковесную service mesh, использующую data plane на основе NGINX Plus для управления трафиком контейнеров в окружениях Kubernetes.


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


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


NSM решает эти проблемы, предоставляя вам в первую очередь:


  • Безопасность, которая сейчас важнее чем когда-либо. Утечка данных может стоить компании миллионы долларов ежегодно в виде потерь доходов и репутации. NSM обеспечивает шифрование всех соединений с помощью mTLS так что чувствительных данных, которые могут украсть взломщики по сети, просто нет. Контроль доступа позволяет вам задать политики, как сервисы будут общаться с другими сервисами.
  • Управление трафиком. При поставке новой версии приложения вы возможно захотите для начала ограничить ему входящий трафик на случай ошибки. С помощью интеллектуального управления трафиком контейнеров от NSM вы можете задать политику ограничения трафика новым сервисам, которая будет наращивать трафик с течением времени. Другие функции, например ограничение скорости и circuit breakers, дают вам полный доступ к управлению прохождения трафика всем вашим сервисам.
  • Визуализация. Управление тысячами сервисов может быть кошмаром отладки и визуализации. NSM помогает справиться с такой ситуацией с помощью встроенной панели управления Grafana, на которой отображаются все характеристики, доступные в NGINX Plus. А также внедренная Open Tracing позволяет детально следить за транзакциями.
  • Гибридные поставки, если ваша компания, как и большинство других, не использует инфраструктуру, полностью запущенную на Kubernetes. NSM гарантирует, что старые приложения не останутся без присмотра. С помощью внедренного NGINX Kubernetes Ingress Controller старые сервисы смогут связаться с mesh сервисами, и наоборот.

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


Как устроен NGINX Service Mesh?


NSM состоит из объединенного data plane для горизонтального (сервис-к-сервису) трафика и внедренного NGINX Plus Ingress Controller для вертикального, управляемые единым control plane.


Control plane специально разработана и оптимизирована для NGINX Plus data plane, определяет правила управления трафиком, распределенные по NGINX Plus sidecars.


В NSM sidecars proxy устанавливаются для каждого сервиса в mesh. Они взаимодействуют с следующими решениями с открытым исходным кодом:


  • Grafana, визуализация параметров Prometheus, встроенная панель NSM помогает вам при работе;
  • Kubernetes Ingress Controllers, для управления входящим и исходящим трафиком в mesh;
  • SPIRE, CA для управления, распределения и обновления сертификатов в mesh;
  • NATS, масштабируемая система отправки сообщений, например обновления маршрутов, с control plane к sidecars;
  • Open Tracing, распределенная отладка (поддерживаются Zipkin и Jaeger);
  • Prometheus, сбор и хранение характеристик от NGINX Plus sidecars, например число запросов, соединений и SSL handshakes.

Функции и компоненты


NGINX Plus в качестве data plane охватывает sidecar proxy (горизонтальный трафик) и Ingress controller (вертикальный), перехватывая и управляя трафиком контейнеров между сервисами.


Функции включают:


  • Взаимную аутентификацию TLS (mTLS);
  • Балансировку нагрузки;
  • Отказоустойчивость;
  • Ограничение скорости;
  • Circuit breaking;
  • Сине-зеленые и канареечные развертывания;
  • Контроль доступа.

Запуск NGINX Service Mesh


Для запуска NSM нужно:


  • доступ к окружению Kubernetes. NGINX Service Mesh поддерживается на многих платформах Kubernetes, включая Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), VMware vSphere и обычные кластера Kubernetes, развернутые на "железных" серверах;
  • Инструмент kubectl, установленный на машине, откуда будет устанавливаться NSM;
  • Доступ к пакетам выпусков NGINX Service Mesh. В пакете есть образы NSM, нужные для выгрузки в закрытую registry для контейнеров, доступную в кластере Kubernetes. Пакет также содержит nginx-meshctl, нужную для разворачивания NSM.

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


$ DOCKER_REGISTRY=your-Docker-registry ; MESH_VER=0.6.0 ; \ ./nginx-meshctl deploy  \  --nginx-mesh-api-image "${DOCKER_REGISTRY}/nginx-mesh-api:${MESH_VER}" \  --nginx-mesh-sidecar-image "${DOCKER_REGISTRY}/nginx-mesh-sidecar:${MESH_VER}" \  --nginx-mesh-init-image "${DOCKER_REGISTRY}/nginx-mesh-init:${MESH_VER}" \  --nginx-mesh-metrics-image "${DOCKER_REGISTRY}/nginx-mesh-metrics:${MESH_VER}"Created namespace "nginx-mesh".Created SpiffeID CRD.Waiting for Spire pods to be running...done.Deployed Spire.Deployed NATS server.Created traffic policy CRDs.Deployed Mesh API.Deployed Metrics API Server.Deployed Prometheus Server nginx-mesh/prometheus-server.Deployed Grafana nginx-mesh/grafana.Deployed tracing server nginx-mesh/zipkin.All resources created. Testing the connection to the Service Mesh API Server...Connected to the NGINX Service Mesh API successfully.NGINX Service Mesh is running.

Для получения дополнительных параметров, включая расширенные настройки, запустите эту команду:


$ nginx-meshctl deploy h

Проверить, что control plane работает корректно в пространстве имен nginx-mesh, можно так:


$ kubectl get pods n nginx-meshNAME                                 READY   STATUS    RESTARTS   AGEgrafana-6cc6958cd9-dccj6             1/1     Running   0          2d19hmesh-api-6b95576c46-8npkb            1/1     Running   0          2d19hnats-server-6d5c57f894-225qn         1/1     Running   0          2d19hprometheus-server-65c95b788b-zkt95   1/1     Running   0          2d19hsmi-metrics-5986dfb8d5-q6gfj         1/1     Running   0          2d19hspire-agent-5cf87                    1/1     Running   0          2d19hspire-agent-rr2tt                    1/1     Running   0          2d19hspire-agent-vwjbv                    1/1     Running   0          2d19hspire-server-0                       2/2     Running   0          2d19hzipkin-6f7cbf5467-ns6wc              1/1     Running   0          2d19h

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


Например если мы развернем приложение sleep в пространстве имен default, а затем проверим Pod увидим два запущенных контейнера, приложение sleep и связанный с ним sidecar:


$ kubectl apply f sleep.yaml$ kubectl get pods n defaultNAME                     READY   STATUS    RESTARTS   AGEsleep-674f75ff4d-gxjf2   2/2     Running   0          5h23m

Также мы можем следить за приложением sleep в панели NGINX Plus, запуская эту команду для получения доступа к sidecar с вашей локальной машины:


$ kubectl port-forward sleep-674f75ff4d-gxjf2 8080:8886

Затем просто заходим сюда в браузере. Вы также можете соединиться с Prometheus чтобы следить за приложением sleep.


Вы можете использовать отдельные ресурсы Kubernetes для настройки политик трафика, например контроля доступа, ограничения скорости и circuit breaking, для этого смотрите документацию


Заключение


NGINX Service Mesh бесплатно доступна для загрузки на портале F5. Попробуйте ее в работе на ваших dev и test окружениях и напишите нам о результатах.


Чтобы попробовать NGINX Plus Ingress Controller, активируйте бесплатный испытательный период на 30 дней, или свяжитесь с нами для обсуждения ваших вариантов использования.


Перевод в авторстве Павла Демковича, инженера компании Southbridge. Системное администрирование за 15 000 в месяц. И как отдельное подразделение обучающий центр Слёрм, практика и ничего, кроме практики.

Подробнее..

Перевод 12 инструментов, делающих Kubernetes легче

16.10.2020 20:06:22 | Автор: admin


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


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


N.B. Надеюсь, неведомая летучемышиная зараза, которая укусила собаку, которая укусила панголина, который укусил китайца по странному стечению обстоятельств в Ухане, где расположена биологическая лаборатория BSL-4 уровня, к февралю поутихнет и об 2019-nCoV мы будем только вспоминать, применяя обсценную лексику. И мы сможем провести уже в офлайне Kubernetes База 810 февраля 2021, а Kubernetes Мега для продвинутых пользователей K8s 1214 февраля. Честно, лично я, как редактор, соскучился по драйву, кофебрейкам, спорам и каверзным вопросам спикерам. Ну, или вымрем всей планетой в стиле самых жестоких и трешовых романов Стёпы нашего Королёва, если всевышние силы устали от наших стрёмных шуток вроде Кончиты Вурст, часов патриарха Кирилла и желания Папы Римского поправить слова молитвы Отче наш.

Но вернёмся к главному.


Goldpinger: Визуализация кластеров Kubernetes


Люди предпочитают смотреть. Графики и диаграммы делают более легким понимание огромной картины. И если учитывать масштабы и сложноть кластера Kubernetes, мы можем использовать на всю катушку эту особенность.


Проект с забавным названием (вероятно тут что-то про агента 007, прим. переводчика) Goldpinger, имеющий открытый исходный код и выпущенный техническим подразделением Bloomberg, представляет собой простой инструмент, работающий внутри кластера Kubernetes и отображающий интерактивную карту отношений между узлами. Нормально функционирующие узлы показываются зеленым цветом, неработоспособные красным. Достаточно щелкнуть по узлу, чтобы узнать подробности. Также можно настроить API с помощью Swagger, чтобы добавить дополнительные отчеты, характеристики и другие вещи.


K9s: Полноэкранный консольный интерфейс к Kubernetes


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


Kops: Консольный ops для кластеров Kubernetes


Эта разработка от команды Kubernetes поможет вам управлять кластерами Kubernetes из командной строки. Он поддерживает кластера, запущенные на AWS и GKE, также работает с VMware vSphere и другими окружениями. В дополнение к автоматизации процессов установки и удаления, Kops может помочь справиться и с другими типами автоматизации. В частности он может создать настройки для Terraform, которыми можно переналить кластер с помощью Terraform.


Kubebox: Терминальная оболочка для Kubernetes


Продвинутая терминальная оболочка для Kubernetes, Kubebox, дает больше, чем старая добрая оболочка к Kubernetes и его API. Кроме прочего умеет в режиме реального времени показывать использование процессорного времени и оперативной памяти, список pods, содержимое журналов, а также запускать редактор настроек. Что еще понравилось, так то, что она доступна в виде отдельного приложения для Linux, Windows и MacOS.


Kube-applier


Kube-applier устанавливается как сервис Kubernetes, получает декларативные настройки кластера Kubernetes из git-репозитория, а затем применяет их к pods в кластере. Каждый раз, когда изменения были внесены, они берутся из репозитория и применяются к запрошенным pods. Это чем-то напоминает Scaffold от Google, но работает для управления целым кластером, вместо одного приложения.


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


Kube-ps1: Умная подсказка командной строки для Kubernetes


Нет, Kube-ps1 это не эмулятор Sony PlayStation для Kubernetes, хотя это было бы изящно. Это простое расширение командной строки Bash, отображающее текущий контекст Kubernetes и пространство имен в подсказке. Kube-shell включает ее в многими другими функциями, но если вам достаточно тольно умной подсказки Kube-ps1 предоставит вам ее с минимальными затратами.


Kube-prompt


Еще одной минимальной, но весьма приятной в использовании модификацией Kubernetes CLI является Kube-prompt, с помощью которой вы можете войти в интерактивный сеанс с клиентом Kubernetes. Kube-prompt избавляет вас от необходимости вводить kubectl перед каждой командой, а также предоставляет автодополнение с контекстной информацией для каждой команды.


Kubespy: Мониторинг ресурсов Kubernetes в реальном времени


Kubespy от Pulumi это инструмент диагностики, помогающий отлаживать изменения ресурса кластера в реальном времени, предоставляя для этого что-то вроде текстовой панели для управления происходящим. Например, вы хотите посмотреть изменения состояния pod c момента запуска: определение pod пишется в etcd, pod планируется к запуску на узле, kubelet на узле создает pod, и, наконец, pod помечается как запущенный. Kubespy может запускаться как отдельной программой, так и в виде расширения к kubectl.


Kubeval: Проверка настроек Kubernetes


YAML файлы настроек Kubernetes могут быть человекочитаемыми, но это не всегда значит, что они могут быть так же проверены. Легко пропустить запятую или имя, и не найти это до того, как уже станет поздно. Лучше использовать Kubeval, установленный локально или подключенный в конвейере CI\CD. Kubeval берет YAML определение настроек Kubernetes и выдает обратно информацию о корректности. Он также умеет выводить данные в JSON или TAP, а также анализировать исходные шаблоны, на которые ссылаются настройки чарта Helm, не выполняя при этом дополнительные запросы.


Kube-ops-view: панель для нескольких кластеров Kubernetes


У Kubernetes уже есть весьма годная панель для мониторинга общего назначения, но сообщество Kubernetes экспериментирует с другими способами отображения данных, пригодных сисадминам Kubernetes. Kube-ops-view как раз и есть такой эксперимент, он предоставляет возможность обзора нескольких кластеров, можно увидеть потребление процессорного вреемни и оперативной памяти, состояние модулей кластера. Обратите внимание, что нельзя вызывать команды, инструмент только для визуализации. Но предоставляемые отображения четкие и ровные, прямо просятся на на настенный экран в вашем центре поддержки.


Rio: Поставка приложений для Kubernetes


Rio, проект от Rancher Labs, реализует общие методики поставки приложений в Kubernetes, например CD из Git, A\B или сине-зеленые поставки. Он также может выкатывать новую версию вашего приложения как только вы зафиксировали изменения, помогая управлять сложностями с, например, DNS, HTTPS, Service Mesh.


Stern и Kubetail: просмотр журналов в Kubernetes


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


Kubetail сходным способом соединяет журналы из разных pods в один поток, помечая цветом разные pods и контейнеры. Но Kubetail это скрипт на Bash. так что для его работы не требуется чего-либо еще, кроме оболочки.

Подробнее..

Конфигурация проекта внутри и вне Kubernetes

17.10.2020 20:10:41 | Автор: admin

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



Предыстория вопроса такова: жил-был один проект, сначала он был маленьким монолитом с утилитами и скриптами, но со временем рос, делился на сервисы, которые в свою очередь стали делиться на микросервисы, а потом ещё и скейлиться. Поначалу это всё выполнялось на голых VPS, процессы настройки и разворачивания кода на которых были автоматизированны с помощью Ansible, и каждому сервису составлялся YAML-конфиг с нужными настройками и ключами, и аналогичный конфиг-файл использовался для локальных запусков, что было очень удобно, т.к этот конфиг грузится в глобальный объект, доступный из любого места в проекте.


Однако рост числа микросервисов, их связей, а также потребность в централизованном логировании и мониторинге, предвещали переезд в Кубер, который до сих пор ещё в процессе. Вместе с помощью в решении упомянутых задач, Kubernetes предлагает свои подходы к управлению инфраструктурой, в том числе т.н Секреты и способы работы с ними. Механизм стандартный и надёжный, поэтому в буквальном смысле грех им не воспользоваться! Но при этом хотелось бы сохранить свой текущий формат работы с конфигом: во-первых, единообразно использовать его в разных микросервисах проекта, а во-вторых, иметь возможность запускать код на локальной машине используя один простой конфиг-файл.


В связи с этим, механизм построения объекта-конфигурации был доработан так, чтобы уметь работать как с нашим классическим конфиг-файлом, так и с секретами из Кубера. Также была задана более жёсткая структура конфига, говоря языком третьего Питона, такая:


Dict[str, Dict[str, Union[str, int, float]]]

То есть, итоговый когфиг это словарь с именованными секциями, каждая из которых является словарём со значениями из простых типов. А секции описывают конфигурацию и доступы до ресурсов определённого вида. Пример куска нашего конфига:


adminka:  django_secret: "ExtraLongAndHardCode"db_main:  engine: mysql  host: 256.128.64.32  user: cool_user  password: "SuperHardPassword"redis:  host: 256.128.64.32  pw: "SuperHardPassword"  port: 26379smtp:  server: smtp.gmail.com  port: 465  email: info@test.com  pw: "SuperHardPassword"

При этом, поле engine баз данных можно установить на SQLite, а redis настроить на mock, указав ещё имя файла для сохранения, эти параметры корректно распознаются и обрабатываются, что позволяет легко запускать код локально для отладки, юнит-тестирования и любых других нужд. Нам это особенно актуально потому, что этих других нужд много часть нашего кода предназначена для разнообразных аналитических расчётов, запускается не только на серверах с оркестрацией, но и разными скриптами, и на компьютерах аналитиков, которым нужно прорабатывать и отлаживать сложные конвейеры обработки данных не парясь бэкэндерскими вопросами. Кстати, не лишним будет поделиться тем, что наши основные инструменты, включая код компоновки конфига, устанавливаются через setup.py вместе это объединяет наш код в единую экосистему, не зависящую от платформы и способа использования.


Описание пода в Kubernetes выглядит так:


containers:  - name : enter-api    image: enter-api:latest    ports:      - containerPort: 80    volumeMounts:      - name: db-main-secret-volume        mountPath: /etc/secrets/db-mainvolumes:  - name: db-main-secret-volume    secret:      secretName: db-main-secret

То есть, в каждом секрете описана одна секция. Сами секреты создаются так:


apiVersion: v1kind: Secretmetadata:  name: db-main-secrettype: OpaquestringData:  db_main.yaml: |    engine: sqlite    filename: main.sqlite3

Вместе это приводит к созданию YAML-файлов по пути /etc/secrets/db-main/section_name.yaml


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


config.py
__author__ = 'AivanF'__copyright__ = 'Copyright 2020, AivanF'import osimport yaml__all__ = ['config']PROJECT_DIR = os.path.abspath(__file__ + 3 * '/..')SECRETS_DIR = '/etc/secrets'KEY_LOG = '_config_log'KEY_DBG = 'debug'def is_yes(value):    if isinstance(value, str):        value = value.lower()        if value in ('1', 'on', 'yes', 'true'):            return True    else:        if value in (1, True):            return True    return Falsedef update_config_part(config, key, data):    if key not in config:        config[key] = data    else:        config[key].update(data)def parse_big_config(config, filename):    '''    Parse YAML config with multiple section    '''    if not os.path.isfile(filename):        return False    with open(filename) as f:        config_new = yaml.safe_load(f.read())        for key, data in config_new.items():            update_config_part(config, key, data)        config[KEY_LOG].append(filename)        return Truedef parse_tiny_config(config, key, filename):    '''    Parse YAML config with a single section    '''    with open(filename) as f:        config_tiny = yaml.safe_load(f.read())        update_config_part(config, key, config_tiny)        config[KEY_LOG].append(filename)def combine_config():    config = {        # To debug config load code        KEY_LOG: [],        # To debug other code        KEY_DBG: is_yes(os.environ.get('DEBUG')),    }    # For simple local runs    CONFIG_SIMPLE = os.path.join(PROJECT_DIR, 'config.yaml')    parse_big_config(config, CONFIG_SIMPLE)    # For container's tests    CONFIG_ENVVAR = os.environ.get('CONFIG')    if CONFIG_ENVVAR is not None:        if not parse_big_config(config, CONFIG_ENVVAR):            raise ValueError(                f'No config file from EnvVar:\n'                f'{CONFIG_ENVVAR}'            )    # For K8s secrets    for path, dirs, files in os.walk(SECRETS_DIR):        depth = path[len(SECRETS_DIR):].count(os.sep)        if depth > 1:            continue        for file in files:            if file.endswith('.yaml'):                filename = os.path.join(path, file)                key = file.rsplit('.', 1)[0]                parse_tiny_config(config, key, filename)    return configdef build_config():    config = combine_config()    # Preprocess    for key, data in config.items():        if key.startswith('db_'):            if data['engine'] == 'sqlite':                data['filename'] = os.path.join(PROJECT_DIR, data['filename'])    # To verify correctness    if config[KEY_DBG]:        print(f'** Loaded config:\n{yaml.dump(config)}')    else:        print(f'** Loaded config from: {config[KEY_LOG]}')    return configconfig = build_config()

Логика здесь довольно простая: объединяем крупные конфиги из директории проекта и пути по переменной окружения, и небольшие конфиги-секции из секретов Кубера, а затем немного их предобрабатываем. Плюс некоторые переменные. Замечу, что при поиске файлов из секретов используется ограничение глубины, т.к K8s в каждом секрете создаёт ещё скрытую папку, где сами секреты и хранится, а уровнем выше находится просто ссылка.


Надеюсь, описанное окажется кому-нибудь полезным :) Принимаются любые комментарии и рекомендации касательно безопасности или других моментов на улучшение. Также интересно мнение сообщества, возможно стоит добавить поддержку ConfigMaps (в нашем проекте они пока не используется) и оформить код на ГитХабе / PyPI? Лично я думаю, что такие вещи слишком индивидуальные для проектов, чтобы быть универсальными, и достаточно небольшого подглядывания на чужие реализации, вроде приведённой здесь, да обсуждения нюансов, советов и best practices, которое я надеюсь увидеть в комментариях ;)

Подробнее..

Перевод Доступна бесплатная версия cloud-native хранилища для Kubernetes от robin.io

21.10.2020 14:12:03 | Автор: admin


Jacky Parker Photography / Getty Images


Компания Robin, автор одноименного cloud-native решения для управления данными и приложениями корпоративных клиентов, например USAA, Sabre, SAP, Palo Alto Networks и Rakuten Mobile, сегодня рассказала о запуске новой бесплатной версии своего сервиса, в дополнение к крупному обновлению основного инструментария.


Robin.io обещает возможность cloud-native управления данными для контейнеризированных приложений с поддержкой типовых операций, например, резервное копирование и восстановление, снимки, возможность откатов и многое другое. Компания обеспечивает работоспособность на уровне железа, а также поддерживает основных поставщиков облачных услуг. Сервис не зависит от используемой базы данных, поддерживает PostgreSQL, MySQL, MongoDB, Redis, MariaDB, Cassandra, Elasticsearch и прочие.



Robin Cloud Native Storage работает с любыми нагрузками на любых платформах, основанных на Kubernetes, а также в любом облаке. Наша платформа с возможностями хранения, создания снимков, клонирования, миграции и обеспечения безопасности данных все они работают с простейшими командами предлагает командам разработчиков и DevOps-командам суперпростой, но высокопроизводительный инструмент для быстрого развертывания и управления вашими корпоративными нагрузками в Kubernetes.
Основатель и генеральный директор Robin, Partha Seetala.

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


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


Среди новых функций основного сервиса хранения Robin поддержка управления данными для Helm Charts, возможность указания точного местоположения данных (в основном это нужно для того, чтобы они находились как можно ближе к вычислительным ресурсам) и политики связывания, подразумевающей доступность для stateful приложений, зависящих от распределенных баз данных и платформ данных.

Подробнее..

Перевод Как использовать HashiCorp Waypoint для совместной работы с GitLab CICD

22.10.2020 06:11:39 | Автор: admin


HashiCorp показала новый проект Waypoint на HashiCorp Digital. Он использует файл на основе HCL для описания сборки, поставки и выпуска приложений для различных облачных платформ, начиная от Kubernetes и заканчивая AWS и Google Cloud Run. Можно представить, что Waypoint это сложенные вместе Terraform и Vagrant для описания процесса сборки, поставки и выпуска ваших приложений.


Не изменяя себе, HashiCorp выпустила Waypoint с открытым исходным кодом, также к нему прилагается множество примеров. Уровень оркестратора остается за вами, Waypoint поставляется в виде исполняемого файла, который вы можете запустить прямиком на вашем ноутбуке или из выбранного вами инструмента оркестрации CI/CD. Цель для развертывания приложений также выбирается вами, поскольку Waypoint поддерживает Kubernetes, Docker, Google Cloud Run, AWS ECS и другие.


Почитав улетную документацию и шикарнейшие примеры приложений, предоставленные HashiCorp, мы решили взглянуть поближе на оркестровку Waypoint с помощью GitLab CI/CD. Чтобы это сделать, мы возьмем простое приложение Node.js, запускаемое на AWS ECS, из репозитория примеров.


После клонирования репозитория посмотрим структуру приложения, отображающего одну страницу:



Как вы могли заметить, в этом проекте нет Dockerfile. Они не добавлены в примере, поскольку они в принципе и не нужны нам, ведь Waypoint позаботится о них за нас. Давайте рассмотрим детальнее файл waypoint.hcl, чтобы понять, что он будет делать:


project = "example-nodejs"app "example-nodejs" {  labels = {    "service" = "example-nodejs",    "env" = "dev"  }  build {    use "pack" {}    registry {    use "aws-ecr" {        region = "us-east-1"        repository = "waypoint-gitlab"        tag = "latest"    }    }  }  deploy {    use "aws-ecs" {    region = "us-east-1"    memory = "512"    }  }}

На этапе сборки Waypoint использует Cloud Native Buildpacks (CNB), чтобы определить язык программирования проекта и создать образ для Docker без использования Dockerfile. В принципе, это та же самая технология, которая используется GitLab в части Auto DevOps на шаге Auto Build. Приятно видеть, что CNB от CNCF получает все большее распространение у пользователей из отрасли.


Как только образ собран, Waypoint автоматически выгрузит его в нашу AWS ECR registry, чтобы он был готов к поставке. По окончанию сборки шаг поставки использует дополнение AWS ECS для развертывания нашего приложения в нашу учетную запись AWS.


С моего ноутбука все просто. Я ставлю Waypoint, который уже аутентифицирован в моей учетной записи AWS, и оно просто работает. Но что будет, если я захочу выйти за пределы моего ноутбука? Или вдруг я хочу автоматизировать это развертывание в виде части моего общего конвейера CI/CD, где запускаются мои текущие интеграционные тесты, тесты безопасности и прочие? Это та часть рассказа, где появляется GitLab CI/CD!


N.B. Если вы еще только планируете внедрение CI/CD или хотите начать применять лучшие практики построения пайплайнов, обратите внимание на новый курс Слёрма CI/CD на примере Gitlab CI. Сейчас он доступен по цене предзаказа.

Waypoint в GitLab CI/CD


Для оркестровки всего этого в GitLab CI/CD давайте посмотри, что нам понадобится в нашем файле .gitlab-ci.yml:


  • В первую очередь, нужен базовый образ для запуска внутри него. Waypoint работает на любом дистрибутиве Linux, ему нужен только Docker, так что мы может запускаться с generic образа Docker.
  • Далее надо установить Waypoint в этот образ. В будущем мы можем собрать образ meta build и контейнеризировать этот процесс для себя.
  • Наконец мы запустим команды Waypoint

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


Для аутентификации GitLab CI\CD в AWS есть несколько вариантов. Первый вариант использование встроенного HashiCorp Vault. Он подойдет, если ваша команда уже пользуется Vault для управления учетными данными. Еще один способ, который подходит, если ваша команда управляет авторизацией с помощью AWS IAM проверьте, что задачи поставки запускаются через GitLab Runner, авторизованный для запуска развертывания через IAM. Но если вы просто хотите ознакомиться с Waypoint и хотите это сделать побыстрее, есть последний вариант добавить ваши ключи AWS API и Secret в переменные окружения GitLab CI/CD AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.


Собираем все вместе


Как только мы разобрались с аутентификацией, можно начинать! Наш окончательный .gitlab-ci.yml выглядит так:


waypoint:  image: docker:latest  stage: build  services:    - docker:dind  # Define environment variables, e.g. `WAYPOINT_VERSION: '0.1.1'`  variables:    WAYPOINT_VERSION: ''    WAYPOINT_SERVER_ADDR: ''    WAYPOINT_SERVER_TOKEN: ''    WAYPOINT_SERVER_TLS: '1'    WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1'  script:    - wget -q -O /tmp/waypoint.zip https://releases.hashicorp.com/waypoint/${WAYPOINT_VERSION}/waypoint_${WAYPOINT_VERSION}_linux_amd64.zip    - unzip -d /usr/local/bin /tmp/waypoint.zip    - rm -rf /tmp/waypoint*    - waypoint init    - waypoint build    - waypoint deploy    - waypoint release

Вы видите, что мы начинаем с образа docker:latest и устанавливаем несколько переменных окружения, требуемых для Waypoint. В разделе script мы скачиваем последнюю версию исполняемого файла Waypoint и ставим его в /usr/local/bin. Поскольку наш runner уже авторизован в AWS, далее мы просто запускаем waypoint init, build, deploy и release.


Вывод задачи по сборке покажет нам endpoint, куда мы раскатили приложение:



Waypoint одно из многочисленных решений HashiCorp, отлично работающих с GitLab. Например, в дополнение к поставке приложения мы можем оркестрировать нижележащую инфраструктуру с помощью Terraform в GitLab. Для стандартизации безопасности SDLC, мы можем также внедрить GitLab с Vault для управления секретами и токенами в конвейерах CI/CD, предоставляя целостное решение для разработчиков и администраторов, полагающихся на управление секретами при разработке, тестировании, а также промышленном использовании.


Совместные решения, разработанные HashiCorp и GitLab, помогают компаниям найти лучший способ разработки приложений, обеспечивая согласованное управление потоками поставки и инфраструктурой. Waypoint сделали еще один шаг в верном направлении, и мы с нетерпением ожидаем дальнейшего развития проекта. Вы можете узнать больше о Waypoint здесь, также стоит изучить документацию и план развития проекта. Мы добавили полученные нами знания в документацию GitLab CI\CD. Если вы хотите попробовать все в работе самостоятельно, можете взять полный работоспособный пример в этом репозитории.


Понять принципы CI/CD, освоить все тонкости работы с Gitlab CI и начать применять лучшие практики можно, пройдя видеокурс CI/CD на примере Gitlab CI. Присоединяйтесь!

Подробнее..

Перевод Наш путь к нулевым простоям при непрерывном обновлении с помощью Ambassador

24.10.2020 08:05:17 | Автор: admin


Мы в Lifion строим распределенную платформу и портфель продуктов для клиентов по всему миру. С учетом этого важно, чтобы мы могли выпускать обновления нашей платформы непрерывно прямо во время ее работы, прозрачно для наших пользователей, которым важна доступность системы, при этом они находятся в разных регионах и часовых поясах. В этой статье мы поделимся с вами путем, которым мы шли, чтобы получить нулевые простои при непрерывном обновлении с помощью Kubernetes. Мы запускаем наши нагрузки с помощью управляемого сервиса Kubernetes AWS EKS. В качестве шлюза API мы применяем Ambassador, сборку Envoy с открытым исходным кодом, специально разработанную для Kubernetes. Наша платформа состоит из более чем 150 микросервисов, большинство из них написаны на Node.js, запускаются в многих подах поверх многочисленных рабочих узлов.


Состояние проблемы


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


Главная причина (Нет обработки SIGTERM)


Среда запуска контейнеров в некоторой части жизненного цикла пода Kubernetes отправляет сигнал SIGTERM в старый под во время обновления, к примеру, когда новый под уже запущен и может принимать запросы для обслуживания. Проведя исследование, мы поняли, что часть наших команд инженеров запускали сервисы на Node.js в подах под PID1, так что SIGTERM явно не обрабатывался на уровне кода, несмотря на рекомендации:


Node.js не разработан для запуска под PID1, это может привести к неопределенному поведению при запуске внутри контейнера Docker. Например, процесс Node.js, запущенный под PID1 не будет отвечать на SIGINT (CTRL-C) и другие подобные сигналы.

Это значит, что во время обновления, когда поды получают сигнал SIGTERM, они ждут 30 секунд (промежуток времени для мягкого завершения), а затем им присылается SIGKILL, так что процессы с PID1 резко выключаются с кодом возврата 137. Это приводит к сбору существующих обрабатываемых в этот момент запросов к поду, на которые не будет дан ответ.



Решение (первая попытка)


В нашу библиотеку Node.js, поверх которой строятся наши микросервисы, мы добавили типовую обработку сигнала SIGTERM, который останавливает активное обслуживание запросов после некоторой задержки. Это значит, что оставшимся запросам дается некоторое время для завершения, прежде чем они будут закрыты и их соединения TCP с все еще активными keep-alive также будут завершены. Ну и наконец сервис останавливается.


...process.on('SIGINT', () => {    logger.warn('SIGINT received. Shutting down');    process.exit(0);  });  process.on('SIGTERM', () => {    logger.warn('SIGTERM received. Initiating graceful shutdown');    shutdown()      .catch((err) => {        logger.error('Ignoring error during graceful shutdown:', err);      })      .finally(() => {        logger.warn('Graceful shutdown completed.');        process.exit(0);      });?  });....module.exports = Object.assign(exposed, {  _listen: exposed.listen,  config,  listen: start,  listenAsync: startAsync,  reset,  setAfterShutdown: (fn) => {    hooks.afterShutdown = fn;  },  setBeforeShutdown: (fn) => {    hooks.beforeShutdown = fn;  },  start,  startAsync,  stop,  stopAsync: promisify(stop)});

Еще один барьер (получение запросов после SIGTERM)


После подключения обработки SIGTERM в нашей основной библиотеке мы получили еще одну проблему: один из инженеров сказал нам, что по факту его сервис все еще получал некоторые запросы после получения SIGTERM во время обновления. А если верить соглашению жизненного цикла пода в Kubernetes, как только под получил SIGTERM, он удаляется из endpoints сервиса, а значит, и из балансировщика нагрузки. Однако если под удаляется из кластера через API, то он только помечается для удаления на сервере метаданных. Сервер уже в свою очередь отправляет уведомление об удалении пода всем связанным подсистемам, обрабатывающим запрос на удаление:


  • kubelet, запускающий последовательности запуска и остановки пода
  • сервис kube-proxy, удаляющий на всех узлах ip-адрес пода в iptables
  • контроллер endpoints удаляет под из списка корректных endpoints, что приводит к удалению пода из Service

Мы можем воспроизвести эту проблему следующим кусочком кода:


function readyCheck() {    let ready = true;process.on('SIGTERM', () => {      logger.info('SIGTERM received, making service as no longer ready');      ready = false;    });return (req, res) => {      if (ready) {        logger.info('Successful ready check');        res.sendStatus(200);      } else {        res.sendStatus(503);        logger.info('Signaling ready check failure');      }    };  }....router.get('/ready', readyCheck());

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


Envoy старается быть максимально эффективным при поддержке открытых соединений к вышестоящим сервисам. Поскольку фактические endpoints меняются, эти долгоживущие соединения все еще могут быть связаны с старым подом, который будет удален через некоторое короткое время. Проблема в том, что существует некая задержка между Kubernetes, отправляющим SIGTERM для отключения пода, и Ambassador, удаляющим под из списка endpoints. Стоит отметить, что проблема существует и в kube-proxy, если вы с ним работаете в больших масштабах.

Проще говоря, из-за оптимизации Envoy некоторые сервисы будут получать запросы после того, как они получили SIGTERM, что приведет к потере текущих запросов (запрос пришел до DIGTERM, но еще не обработан) во время обновления этого сервиса.


Решение (вторая попытка)


Envoy нужно некоторое время для остановки существующих соединений на время остановки пода до получения подом SIGTERM. Так что в качестве решения мы добавили поддержку preStopHook в Helm Chart для нашего сервиса:


lifecycle:  preStop:    exec:      command:      - sleep      - "10"

Во время обновления процесс остановки старого пода ждет 10 секунд, чтобы дать возможность Envoy отключить все существующие соединения к поду, а также удостовериться, что под убран из endpoints балансировщика нагрузки. Сразу же после этого Kubernetes, как обычно, отправляет сигнал SIGTERM процессу с PID1.


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


lifecycle:  preStop:    exec:      command: [        "sh", "-c",        # Introduce a delay to the shutdown sequence to wait for the        # pod eviction event to propagate. Then, gracefully shutdown        # nginx.        "sleep 5 && /usr/sbin/nginx -s quit",      ]

Выводы


Если сложить все вместе, то эта статья покрывает:


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

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


N.B. Для тех, кому нужна практика построения систем с надежной архитектурой, готовых к перегрузкам, Слёрм проводит онлайн-интенсив по SRE. Интенсив пройдет 1113 декабря 2020, до начала декабря можно купить билет со скидкой.

Подробнее..

Три образовательных сервиса, которые помогут на практике научиться работать в IT на уровне PRO

25.10.2020 16:08:20 | Автор: admin

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

А вот тренажерам для администраторов и DevOps, Data Science и по работе с инструментарием типа Docker, Kubernetes, TensorFlow и Linux удивиться можно. Особенно, если они с хорошей методологической траекторией

О таких мы сегодня и поговорим.

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

Что еще сейчас может удивить?

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

Что еще?

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

KataCoda

https://www.katacoda.com

Их купил в свое время О'Рейли- лучший издатель книг по программированию.

Чтобы объяснить почему такой прелести вы еще не встречали, давайте окунемся на секунду в историю и реальность.

Я продюсер ИТ и инженерных обучающих программ для мидл+. В общем, для сложных. Я всегда стремилась к большей практике на курсе, поэтому мы завели такую штуку, как "Стенды".

Ну что вам объяснять? Наверно все сами знаете: покупаешь сервер или просишь партнера его предоставить. Препод-эксперт разворачивает на нем всю инфраструктуру, далее пишет методичку для студентов, что и как делать.

О'рейли сломали систему.

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

выбор разных треков в Катакодавыбор разных треков в Катакода

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

Слева - методологическое описание, справа - терминалСлева - методологическое описание, справа - терминал

В одном окне методологически ШИКАРНО описано, что нажимать и к чему это приведет.

В ассортименте много интересных курсов, все бесплатные, на некоторые даже не нужно регистрироваться: и CI/CD, и Infrastracture-as-a-Code, и облака с их Serverless.

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

PS в KataCoda есть опция приватных курсов. Я даже с Орейли вела переговоры, очень хотела внедрить сервис для нашего образовательного проекта. Сократить расходы на сервера и не мучить студентов прочтением методичек. Чтобы наши эксперты разработали методичку в терминале катакоды, а студенты наслаждались легкостью практических работ. Но чет дорого

HyperSkill

https://hyperskill.org/projects

Мне очень понравился новый интересный сервис от JetBrains, созданный совместно со Stepik.

Сервис платный. Он на английском. Знаю-знаю, вам такое не нравится. Мне тоже, но что делать?

Во-первых, тут есть Kotlin. Тот самый, что JetBrains придумали. А курсов по нему почти считайте, что и нет. А тут есть.

Во-вторых, очень хорошо выстроена траектория обучения.

В-третьих, тут текстовые супер-маленькие уроки. Не всем подходят видео, которые сейчас повсюду.

Что значит хорошо выстроенная траектория и мини-уроки?

Вам не надо полностью проходить все, что вам ЗАДАЛ какой-то преподаватель исключительно в том порядке, что он для вас разработал и отразил в своей программе.

Вы выбираете уроки в рамках темы и делаете мини-проекты. Например, начали ООП . Тут вам мини-урок по полиморфизму, а потом вам стало скучно и вы перешли на тему "Алгоритмы" на урок, допустим, "Графы". И т.д.

Пример трека в Hyperskill, выделены миниуроки Пример трека в Hyperskill, выделены миниуроки

Суть в том, чтобы обучение было веселым.

Да-да иногда обучение - это не прогрызание гранита сквозь *нальную боль. Иногда это положительные эмоции. НЕ забывайте об этом, друзья!

Solvery

https://solvery.io/

Во времена моего студенчества, репетиторов мы воспринимали, как роскошь, которая необходима школьникам, которые готовятся к ЕГЭ.

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

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

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

Мой муж специалист по Matlab, к нему периодически стучатся ребята из инженерки и аналитики данных, чтобы он их проконсультировал по инструменту. Зачем им курс? У них задача и ограниченное время. Аналогичное придумал сервис Solvery, где вы можете под свою задачу найти консультанта и вместе с ним ее решить.

Такое решение показало свою эффективность, когда вы можете на СВОИХ задачах проходить то же обучение, что и на курсах при помощи репетиторов (специалистов) с разным опытом.

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

Подробнее..

Перевод Что такое Waypoint и какие возможности дает его использование

26.10.2020 16:12:51 | Автор: admin


Пару недель назад я посмотрела демонстрацию Waypoint нового инструмента, который представила 15 октября 2020 года компания Hashicorp. Инструмента, который предназначен для создания легкого, интуитивного и настраиваемого под пользователя рабочего процесса сборки, развертывания и релиза.


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


Чем Waypoint не является


Наверное, будет проще в начале пояснить, чем Waypoint не является.


Waypoint не:


  • автоматическая система сборки программ (как make, npm, maven и т.д.)
  • диспетчер пакетов (как helm, pip и т.д.)
  • система непрерывной интеграции (как Jenkins, GitHub Actions и т.д.)
  • registry артефактов (как Artifactory, Docker Registry и т.д.)
  • среда выполнения (как OCI images, Docker containers, buildpacks, машинный код, архивы и т.д.)
  • кластерный оркестратор или кластерная платформа (как Kubernetes, EC2, EKS и т.д.)

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


Что же такое Waypoint?


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


Разработчику не нужно делать каких-либо правок или писать дополнительную конфигурацию. Как говорится в документации:


Waypoint был построен для простоты использования. Больше не надо писать Dockerfiles, YAML и т.д.У нас есть дополнения для автоматического определения вашего языка, построения образа и развертывания. Да, вам придется немного настроить его, но мы сейчас говорим примерно о пятнадцати сроках текста для одного инструмента в сравнении с сотнями строк в разных инструментах на разных языках программирования.

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


Довольно много слов, и изрядное их количество требует объяснения. Остаток статьи как раз будет посвящен расшифровке того, что все это значит.


Переосмысление схемы работы разработкатестированиеразвертываниевыпуск


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


Разработка: включает в себя сборку исполняемых файлов и библиотек, содержащих изменения кода. Большая часть языков программирования имеют собственный набор системы сборки кода. Большинство вычислительных рабочих окружений имеют собственные поддерживаемые форматы артефактов, как Docker/OCI images, ELF binaries, ZIP archives, платформенно-ориентированные артефакты (как AWS Lambda Layers), и это далеко не полный перечень. Любая схема работы с комплексом инструментальных средств, которая имеет целью обслуживать максимально обширное сообщество разработчиков, вынуждена приспосабливаться к сборке кода и предпочтительного формата артефакта, по возможности используя уже существующие ориентированные на конкретный язык встроенные инструментальные средства.


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


Развертывание: чтобы начать обслуживать новый трафик, новые артефакты должны внедряться в эксплуатационную (или тестовую) среду. Часто для этого артефакты устанавливаются на сервера, где запускаются соответствующие исполняемые файлы. В своей карьере я работала с инструментами развертывания, которые охватывали весь спектр: начиная от простых развертываний на основе git (Heroku), до лабиринтообразных скриптов оболочки, до безагентных инструментов удаленного выполнения на основе ssh, как Fabric/Capistrano/Ansible, до систем, запускающих агентов на узлах, которые следят за новыми развертываниями, до (после 2015) сервисов кластерных оркестраторов, как Nomad или Kubernetes. Новому инструменту нецелесообразно заново изобретать платформу/runtime/механизмы развертывания, уже имеющиеся у поставщика облачных услуг, поскольку поставщики облачных услуг уже предоставляют собственные безапелляционные API специальные инструменты и рабочие процессы для развертывания кода.


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


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


Специалисты, идущие в ногу со временем и использующие продукты Hashicorp так же долго, как и я, возможно, заметят, что Waypoint не первый заход Hashicorp в сферу развертывания или рабочих процессов. Одной из предыдущих попыток был проект Otto, который должен был стать абстракцией высокого уровня для разработки и развертывания приложений. Atlas также был экспериментом для предоставления интегрированных инструментов и общего рабочего пространства как для разработчиков, так и для операторов; от внедрения кода приложения до создания артефакта развертывания, конфигурирования инфраструктуры и в конечном итоге управления жизненным циклом приложения в процессе его работы.


Теперь, по прошествии времени, становится понятно, почему ни один из инструментов не справился и оба были в итоге свернуты или стали частью других предложений. На мой взгляд, и Otto, и Atlas должны были одни махом решить слишком много разношерстных задач. Хотя такой подход мог сработать в случае Consul, который может использоваться в качестве распределенного хранилища данных типа ключ-значение, сервиса распределенных блокировок, сервисной сетки, системы обнаружения сервисов и многого другого (и я за годы работы действительно использовала Consul для многих из этих разнообразных целей), рабочий процесс разработчика или даже рабочий процесс развертывания, требующий использования полного набора инструментов Hashicorp, был не совсем подходящим продуктом для решения такой серьезной проблемы как рабочий процесс, и особенно не в то время (начиная с 2015 года), когда индустрия видела невообразимый всплеск в количестве специализированных инструментов инфраструктуры, систем, платформ, API, парадигм и экосистем. Когда у пользователей есть выбор из множества вариантов, продуктам, нацеленным на объединение разрозненных проблем, пожалуй, труднее найти соответствие продукта и рынка без интеграции с широким спектром доступных решений.


Здесь напрашивается вопрос, чем же третья попытка одолеть эту проблемную задачу отличается от предыдущих?
Начнем с того, что Waypoint намного более узко сфокусирован, чем были Otto и Atlas за все время своего существования. Waypoint призван унифицировать опыт разработчика, не давая предписаний или обязуя пользователей прибегать к другим продуктам Hashicorp, таким как Vagrant, Terraform или Packer.


Во-вторых, складывается ощущение, что Waypoint перенял кое-что у Terraform. Подобно тому как Terraform успешно абстрагировался от различных облачных провайдеров, облачных API, платформ, систем и инструментов с открытым кодом, предоставил пользователям язык (HCL) для определения, настройки, обновления, поддержки и развития исходных конфигураций инфраструктуры и для интеграции, Waypoint стремится предоставить пользователям ориентированную на HCL декларативную спецификацию и простой CLI-интерфейс для управления и развития рабочего процесса сборки и развертывания. Как и проводники в Terraform, так и плагины в Waypoint позволяют проводить интеграцию с внешними и API системами.


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


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


Заключение


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


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


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


Для меня Waypoint шаг в нужном направлении. Все еще рано загадывать, но я с радостью буду следить за развитием проекта в следующие 1218 месяцев.


От редакции: приглашаем на курс Слёрма CI/CD на примере Gitlab CI. Сейчас курс находится в разработке и его можно купить по цене предзаказа. Кроме того, вы сможете стать консультантом-тестером: получить ранний доступ к урокам, задать свои вопросы спикерам и повлиять на итоговую программу курса.

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru