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

воскресенье, 25 октября 2020 г.

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

Недавно в наших соцсетях выступал Александр Чистяков, 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, так и называется. Там уточка нарисована. Книга O’Reilly, сейчас сделали редизайн обложек; довольно много книг в сотрудничестве с 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-специалистов на удаленку?

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

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

Let's block ads! (Why?)

Парсер Хабра

...

воскресенье, 25 октября 2020 г.