Меня зовут Максим Набоких, и я один их тех, кто участвовал в разработке Structured Authentication Config. Это крупнейшее изменение в системе аутентификации в Kubernetes за последние годы, которое появилось в версии 1.29. В статье я расскажу о предпосылках появления нового аутентификатора и покажу сценарии, в которых он полезен.

У Prometheus есть серьёзный недостаток — чрезмерное потребление ресурсов. Проблема может заключаться в недостаточном понимании инструмента и его неверном использовании. А Prometheus требует грамотного управления метриками и лейблами.

В своем докладе технический директор Deckhouse Observability Platform Владимир Гурьянов выяснил, кто виноват в этом и что делать.

Всем привет! На связи Максим Набоких, архитектор и технический руководитель Deckhouse Kubernetes Platform. Deckhouse работает в компаниях из разных отраслей: нефтегазовые предприятия, финтех, государственные организации, банки, облачные провайдеры и так далее. И больше чем в половине этих организаций во внутренней инфраструктуре нет интернета — он просто запрещён. Поэтому нам надо было придумать процесс установки своей платформы в закрытый контур.

О том, как устанавливать Kubernetes (Deckhouse использует ванильный K8s), где «не ступал» ни один пакет из публичной сети, я рассказал на HighLoad++ 2023. Эта статья — текстовая версия моего доклада. Мы разберём целевую схему закрытого контура, нюансы работы инструментов для создания безопасной среды, посмотрим, как готовить дистрибутив Kubernetes-платформы к установке и осуществлять доставку приложений в закрытых окружениях.

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

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

Проблемы роста — обычное дело, и базы данных в этом смысле не исключение. Полтора года назад команда Loki задумалась о том, как на порядок повысить кардинальность (cardinality), производительность запросов (query throughput) и надежность (reliability). Работа над новым индексным слоем почти закончена — время остановиться и посмотреть: что же мы делаем, чтобы оставаться на пике прогресса.

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

В этой статье рассмотрен новый экспериментальный режим работы werf — Open Source-утилиты для сборки приложений и их деплоя в Kubernetes, — в котором не требуется наличие Docker-сервера. Мы покажем, как убедиться, что это режим будет работать на вашей машине, соберем первый образ и научимся использовать Kubernetes executor для автоматизации сборки в GitLab CI/CD.

Рады представить новую версию онлайн-самоучителя по werf, нашей CI/CD-утилите с открытым кодом!

Общая идея самоучителя — познакомить разработчиков с Kubernetes, показав на простых приложениях (готовы примеры для Ruby on Rails, Node.js и Laravel), как можно развертывать приложения в K8s с помощью werf. Это отличная возможность быстро освоить практические основы K8s без погружения в его объемную теоретическую базу. Если вы еще не решили, как провести новогодние каникулы с пользой, — вот вам идея.

Наш клиент cybersport.ru — один из самых популярных информационно-новостных порталов про киберспорт в СНГ. По данным Similarweb, в октябре 2021 года у сайта было 16,5 млн посещений.

Обычно нагрузка на cybersport.ru даже во время значимых событий не превышает 400 RPS (requests per second). Так было до недавнего времени, точнее — до The International 10. Турнир вернулся после годичного перерыва из-за пандемии, что подогрело интерес к нему. Ажиотажа добавило и успешное выступление российских команд. В итоге во время турнира нагрузка достигала небывалых для сайта 2300 RPS.

Статья посвящена так называемым review-окружениям, реализуемым в рамках кластеров Kubernetes. Ранее эта тема затрагивалась, например, в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab», но не была там основной темой, поэтому раскрывалась не во всех деталях. Попробую восполнить этот пробел, рассказав, для чего нужны и/или обычно используют review-окружения, как сделать pipeline c review-окружением в GitLab CI/CD, какие могут быть потенциальные проблемы и способы их решения.

Этой ночью, 5 августа, состоится новый релиз Kubernetes — 1.22. Рассказываем о наиболее значимых изменениях в новой версии.

Сегодня состоялся долгожданный публичный Open Source-релиз нашей платформы для автоматизации обслуживания кластеров Kubernetes — Deckhouse. Этому предшествовало три с половиной года внутренней разработки и эксплуатации платформы на многочисленных и весьма разнообразных проектах. Сейчас с помощью Deckhouse мы обслуживаем в production более 170 кластеров (3500+ узлов), в которых развернуто около 3000 приложений. Deckhouse — это квинтэссенция нашего опыта в эксплуатации Kubernetes-кластеров и кульминация всей связанной с этим производственной деятельности последних лет.

Мы начали выдавать ранний доступ к платформе и демонстрировать её возможности ещё в мае, на конференции HighLoad++. Уже более 300 человек смогли самостоятельно попробовать Deckhouse. Пришло время поделиться нашим опытом автоматизации Kubernetes с более широким сообществом!

Представляем текстовую версию недавнего разговора с коллегами из Data Egret — компании, которая специализируется на поддержке PostgreSQL. Ведущий инженер команды Okmeter Владимир Гурьянов пообщался с Ильей Космодемьянским (CEO Data Egret) и Алексеем Лесовским (senior DBA Data Egret). Обсудили, как мониторить PostgreSQL, какие бывают ошибки при выборе и настройке систем мониторинга, кто такие DBA и какие soft skills для них важны, а также затронули более хардкорные темы. Пост объемный, но он того стоит.

Технический долг — особый вид долга: мы занимаем у самих себя, причем нередко с большими процентами. Несмотря на то, что платить по счетам рано или поздно приходится, устранение техдолга редко относится к насущным бизнес-задачам. Бизнес либо откладывает это «на потом», либо вообще не рассматривает как проблему.

Я думаю, главная причина непонимания — в том как мы, инженеры и разработчики, пытаемся объяснять бизнесу, почему важно избавляться от техдолга. Мы транслируем наше видение из нашего технического мира, забывая, что у бизнеса другие критерии оценки важности проблем. Мой доклад, с которым я выступил на DevOpsConf 2021, как раз о том, как устранить это непонимание и «продать» бизнесу технический долг.

Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

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

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

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

А ещё кофебрейки с единомышленниками, бодрая и драйвовая атмосфера, обмен опытом, самые неожиданные вопросы спикерам. И ответы, и информация, которую не встретишь в мануалах, а только на практике.

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

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

Наверное, Google — для каждого свой. Для каждого наблюдателя — сотрудника, независимого разработчика и админа, конкурента, просто человека интересующегося IT-тематикой, пользователя в сети, вбивающего в адресную строку браузера google.com.

Я познакомился c Евгением Вараввой, разработчиком широкого профиля в Google (Сан-Франциско), на Слёрме SRE — он там вовсю с удовольствием запутывал участников задачками, неожиданными багами и проблемами учебного проекта.

А после, когда начали расставлять столы, усталые участники прощаться друг с другом, сотрудники Слёрма убирали провода, роутеры и сетевые удлинители, я пригласил Евгения поговорить — каким он видит Google. Изнутри. И изменилась ли его ощущение и точка зрения за десяток лет работы в компании.

Что получилось — читайте…

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

Но ты не чувствуешь себя счастливым. У тебя проблемы в семье. Проблемы с алкоголем. Натянутые отношения с персоналом. Акульи улыбки на совещаниях с такими же топ-менеджерами. Бессонница. Резкие перепады настроения и короткие депрессивные эпизоды. Работа надоела давным давно — с утра ты мрачно осознаёшь, что впереди ещё один бессмысленный день. С друзьями общаться не хочется да и незачем. Ты понимаешь, что в плену социальных условностей — ты IT-директор с высокой зарплатой и завидным положением в обществе — но это как камень на шее. И конфликты, конфликты, конфликты. Уже не только на работе, но и в семье.

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

С этого осознания начинается долгий путь к самому себе.

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

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

В беседе он откровенно сравнил два мира — мир государственных корпораций и мир свободного IT-сообщества, где он теперь по-настоящему профессионально свободен и счастлив.

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

Команда Слёрма поздравляет читателей Хабра и участников Слёрмов — от Базового и Мега до DevOps и SRE. Спасибо, что вы были с нами весь этот год. За ваши неожиданные вопросы на интенсивах. За вашу критику — потому что благодаря вам мы становимся лучше.

Спасибо Хабру и его читателям. За ваши комментарии — одобрительные, критические, ироничные.

IT, изучение мозга и космонавтика — это последние фронтиры нашего мира. И там собираются самые свободные, самые ищущие, самые сомневающиеся, самые безрассудные.

Стив Джобс: «Оставайтесь голодными. Оставайтесь безрассудными. Всем большое спасибо».

С Новым годом, друзья!

Введение

Мы в Shopify занялись развертыванием Istio в качестве service mesh. В принципе все устраивает, кроме одной вещи: это дорого.

В опубликованных бенчмарках для Istio говорится:

С Istio 1.1 прокси потребляет примерно 0,6 vCPU (виртуальных ядер) на 1000 запросов в секунду.

Для первого региона в service mesh (по 2 прокси с каждой стороны соединения) у нас будет 1200 ядер только для прокси, из расчета один миллион запросов в секунду. Согласно калькулятору стоимости от Google получается примерно $40/месяц/ядро для конфигурации n1-standard-64, то есть один этот регион будет стоить нам больше 50 тыс. долларов в месяц за 1 млн запросов в секунду.

Айвен Сим (Ivan Sim) наглядно сравнил задержки service mesh в прошлом году и обещал то же самое для памяти и процессора, но не получилось:

Судя по всему, values-istio-test.yaml серьезно увеличит запросы к процессору. Если я все правильно посчитал, нужно примерно 24 процессорных ядра для панели управления и 0,5 ЦП для каждого прокси. У меня столько нету. Я повторю тесты, когда мне выделят больше ресурсов.

Я хотел сам убедиться, насколько показатели Istio схожи с другой service mesh с открытым кодом: Linkerd.