Помните, Apple представила открытые проекты container и containerization для нативной контейнеризации на macOS? Написано на Swift, оптимизировано для Apple Silicon и вызывает больше вопросов, чем восторга.
При чуть более внимательном рассмотрении, оказалось, что Apple снова выбрали свой путь. У них не неймспейсы и общий кернел, а мини-микро-нано-виртуалка под каждый контейнер. И, внимание, нет адекватной сетевой связности между контейнерами, а вдобавок к этому ещё и сложности при работе с оперативной памятью.
Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации.
Оба проекта находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов.
Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container.
Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.
При чуть более внимательном рассмотрении, оказалось, что Apple снова выбрали свой путь. У них не неймспейсы и общий кернел, а мини-микро-нано-виртуалка под каждый контейнер. И, внимание, нет адекватной сетевой связности между контейнерами, а вдобавок к этому ещё и сложности при работе с оперативной памятью.
Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации.
Оба проекта находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов.
Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container.
Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.
🤔13🤣11👍2❤1
DevOps Deflope теперь и на Spotify.
А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave.
Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!
А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave.
Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!
👍18❤5👎1🤡1
Книги от Google по SRE весьма полезны, но не у всех есть время прочесывать 1000+ страниц принципов и философии. Автор с Medium, Magsther, решил эту проблему — он прочитал всю трилогию и превратил массив теории в 100 практических уроков.
Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”.
Нет регистрации, рекламы или paywall. Ну круто же :)
Тем не менее, делимся и книгами, по которым и сделаны 100 уроков:
• Site Reliability Engineering (2016),
• The Site Reliability Workbook (2018),
• Building Secure & Reliable Systems (2020)
Мнение редакции: это не замена книгам, скорее, качественный конспект. Поможет освежить какую-то тему, посмотреть быструю справку и т.д. Он поможет сослаться на SRE by Google без рысканья по книге. Но для обучения этого не хватит, нужно подкреплять практикой и другой теорией.
Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”.
Нет регистрации, рекламы или paywall. Ну круто же :)
Тем не менее, делимся и книгами, по которым и сделаны 100 уроков:
• Site Reliability Engineering (2016),
• The Site Reliability Workbook (2018),
• Building Secure & Reliable Systems (2020)
Мнение редакции: это не замена книгам, скорее, качественный конспект. Поможет освежить какую-то тему, посмотреть быструю справку и т.д. Он поможет сослаться на SRE by Google без рысканья по книге. Но для обучения этого не хватит, нужно подкреплять практикой и другой теорией.
sre.in100.dev
SRE in 100 Lessons - Learn Site Reliability Engineering
Master Site Reliability Engineering with 100 practical lessons. Learn real-world SRE skills, best practices, and techniques used by top tech companies.
👍26🔥15👏3❤2👌1🐳1😐1
«Хилы, танки и дамагеры DevOps» — каждый понимает DevOps по-своему. В новом выпуске DevOps Deflope узнаете:
• Почему DevOps-инженеры сравнивают себя с героями WoW?
• Как пайплайны помогают печь круассаны?
• Зачем DevOps’у лезть в архитектуру приложений?
• Чему учат в магистратуре по DevOps и можно ли его считать методологией?
Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps.
Слушайте:
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
• Почему DevOps-инженеры сравнивают себя с героями WoW?
• Как пайплайны помогают печь круассаны?
• Зачем DevOps’у лезть в архитектуру приложений?
• Чему учат в магистратуре по DevOps и можно ли его считать методологией?
Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps.
Слушайте:
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
🤡28👍7🔥4💊1
Новый выпуск — и он про безопасность!
В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:
• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.
Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:
• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.
Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте
🔥10❤5👍1
Наткнулись на kubesec-diagram — интерактивную карту угроз Kubernetes, созданную внутри Telenor Norway. И знаете что? Она реально хорошая :)
Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе.
Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”.
Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет?
Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое.
Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции.
Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco.
Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io
Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе.
Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”.
Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет?
Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое.
Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции.
Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco.
Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io
kubesec-diagram.github.io
Interactive annotated security focused kubernetes diagram.
👍14🔥4❤1👎1
Быстро потестировать etcd или поковырять containerd без поднятия локального кластера? Собрали браузерные песочницы, где можно экспериментировать с инфраструктурным софтом без танцев вокруг Docker Desktop и minikube.
1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes
Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод.
2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes
Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании.
3. Nerdctl Playground — containerd с человеческим лицом
Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма.
4. KodeKloud Playgrounds — готовые среды под задачу
Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания.
5. LabEx — тренажёр с дорожной картой
Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud.
6. Helm Playground — песочница для Helm-чартов
Позволяет экспериментировать с шаблонами, values и структурой чарта, сразу видя итоговые YAML-манифесты. Удобно для быстрой проверки идей и отладки шаблонов.
Эти площадки не заменят продакшен-кластеры со всеми их перформанс-проблемами, конечно же. Но будут весьма полезны для обучения.
Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)
1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes
Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод.
2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes
Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании.
3. Nerdctl Playground — containerd с человеческим лицом
Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма.
4. KodeKloud Playgrounds — готовые среды под задачу
Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания.
5. LabEx — тренажёр с дорожной картой
Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud.
6. Helm Playground — песочница для Helm-чартов
Позволяет экспериментировать с шаблонами, values и структурой чарта, сразу видя итоговые YAML-манифесты. Удобно для быстрой проверки идей и отладки шаблонов.
Эти площадки не заменят продакшен-кластеры со всеми их перформанс-проблемами, конечно же. Но будут весьма полезны для обучения.
Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)
🔥28👍10❤1👎1👾1
4 декабря в Москве пройдёт Kuber Conf от Ассоциации облачно-ориентированных технологий.
Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками.
На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество.
Ну и, конечно, нас ждут доклады от практиков. Не про то, что мы уже много раз слышали на других конфах, а про свежие кейсы и реальные проблемы.
Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт.
Кстати, про билеты. Коллеги постарались сделали их максимально доступными с доступом ко всем докладам, материалами конференции, обедом, нетворкингом и афтерпати. Важно, чтобы прийти мог каждый, кому интересна тема. Вся информация про билеты и регистрация здесь.
Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе.
До встречи 4 декабря!
Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками.
На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество.
Ну и, конечно, нас ждут доклады от практиков. Не про то, что мы уже много раз слышали на других конфах, а про свежие кейсы и реальные проблемы.
Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт.
Кстати, про билеты. Коллеги постарались сделали их максимально доступными с доступом ко всем докладам, материалами конференции, обедом, нетворкингом и афтерпати. Важно, чтобы прийти мог каждый, кому интересна тема. Вся информация про билеты и регистрация здесь.
Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе.
До встречи 4 декабря!
🔥15❤3👎3👍1
ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.
Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.
ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.
Продукт уже работает для пользователей Kubernetes, Helm и GitOps.
Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.
Источник — пост Alexis Richardson на LinkedIn.
Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.
ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.
Продукт уже работает для пользователей Kubernetes, Helm и GitOps.
Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.
Источник — пост Alexis Richardson на LinkedIn.
Linkedin
ConfigHub is now available!
Our doors are ‘open’ and if you want to try ConfigHub then please go to www.confighub.
👍20🔥10😁3
Нельзя так просто взять и спарсить 150 тысяч вакансий… Или можно?
Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России.
Проблема того же TIOBE в том, что он считает поисковые запросы в Google. Люди могут искать что угодно из любопытства, для учёбы, для решения legacy-проблем. Но это не показывает, что реально нужно работодателям прямо сейчас.
TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях.
Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается.
Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик.
Зачем это всё? Если ты джун, рейтинг помогает увидеть, какие технологии дают больше всего «входных билетов» в профессию и где спрос не ограничивается одиночными вакансиями. Если ты мидл или сеньор — это удобный способ понять, в какой стек имеет смысл вкладываться, чтобы оставаться востребованным на российском рынке.
Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.
Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России.
Проблема того же TIOBE в том, что он считает поисковые запросы в Google. Люди могут искать что угодно из любопытства, для учёбы, для решения legacy-проблем. Но это не показывает, что реально нужно работодателям прямо сейчас.
TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях.
Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается.
Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик.
Зачем это всё? Если ты джун, рейтинг помогает увидеть, какие технологии дают больше всего «входных билетов» в профессию и где спрос не ограничивается одиночными вакансиями. Если ты мидл или сеньор — это удобный способ понять, в какой стек имеет смысл вкладываться, чтобы оставаться востребованным на российском рынке.
Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.
TrueIndex
TrueIndex - Объективный рейтинг технологий разработки
Рейтинг и аналитика технологий разработки на основе GitHub активности, Stack Overflow, вакансий и других метрик. Объективная оценка языков программирования, фреймворков и инструментов.
👍15❤8🤔3🤡1
Kuber Conf уже завтра, но вы успеваете запрыгнуть.
Смотрите, программа там реально насыщенная. Мы пробежались по докладам и выбрали то, что зашло:
• Как мы строили платформу деплоя в Т.
Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами.
• Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях.
• Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации.
Ещё два доклада будут от нас:
• А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA.
• Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят.
Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет.
Смотрите, программа там реально насыщенная. Мы пробежались по докладам и выбрали то, что зашло:
• Как мы строили платформу деплоя в Т.
Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами.
• Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях.
• Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации.
Ещё два доклада будут от нас:
• А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA.
• Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят.
Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет.
👍8❤🔥3🔥2🏆2❤1