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

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

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

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

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

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

В конце — набор рекомендаций и базовых настроек, которые можно протестировать на своих приложениях.

Казалось бы, права на чтение — что с них взять? Оказывается, в Kubernetes разрешение nodes/proxy GET позволяет выполнять любой код в любых подах кластера. Уязвимость уже нашли в популярных Helm-чартах, включая Prometheus, Datadog и Grafana. И да, команда Kubernetes решила это не исправлять.

Сложно поддерживать CI/CD, когда граф пайплайна в GitLab превращается в бесконечную «простыню», параллельные запуски terraform apply приводят к блокировкам, а для игнорирования некритичных ошибок приходится писать || true. 

Может показаться, что для решения этих проблем нужны «костыли» или переход на enterprise-лицензию. На деле же с ними помогут встроенные возможности GitLab CE. В статье разбираем неочевидные ключевые слова .gitlab-ci.yml, которые сэкономят вам время и нервы.

Тикет летит три дня. А человек, который написал код, сидит в двух метрах. Сдвинули стул и запустили цепную реакцию — в итоге замкнули «круг боли» и превратили рутину в удовольствие.

Купил отреставрированную советскую радиолу — чтобы… наконец-то обзавестись умным домом. Реставраторы встроили туда Алису и «гитарный вход».

Но Алиса молчала, пока радиола выключена, а «гитарный» вход оказался 3,5 мм — под наушники.

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

Автоматизируем создание виртуальных машин в Proxmox с помощью Terraform: от подготовки единого образа и настройки провайдера до управления инфраструктурой как кодом и хранения state в GitLab.

10 лет назад мы запустили проект под названием dapp. Сегодня он известен как werf. За это время — тысячи коммитов, сотни релизов, переход на Go, Helm, CNCF, Nelm…

Собрали всю историю в одной статье — от первого Ruby-скрипта до экосистемы Open Source-инструментов.

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

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

802.1x и двери по картам — это должно быть надёжно. Пентестер зашёл в банк ночью, «обманул» ИК-датчик баллончиком, стал принтером в сети и нашёл заполненные чеки. Это не теория. Это отчёт по реальному тесту на проникновение.

Проник в банк не через вайфай и не через фишинг — а просто пристроился к аудиторам с улицы. Никто не спросил имени. Никто не проверил. А через час уже сидел у них в сети с рабочим пропуском. Как это случилось — и почему «следовать инструкции» не спасло — в новой статье.

Они работали в коллекторской сфере. Привыкли к угрозам, обману и агрессии. Но когда к ним пришли с благодарностью — дали дорогу. Эта статья — про то, как взломать «непробиваемую» компанию через её самого главного человека. И почему технические защиты тут почти не при чём.

В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.

Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.

Сегодня официально выпустили новую версию Kubernetes — 1.35. Собрали обзор со всеми изменениями. Среди главных нововведений — возможность запускать поды с hostNetwork: true и hostUsers: false, групповое планирование подов и перевод контроллера маршрутов на watch-модель.

Команда Deckhouse Storage рассказала о поддерживаемых в наших платформах CSI с использованием реализаций от вендора (для платформ Huawei, HPE, NetApp и Yadro), а также о собственном универсальном CSI-драйвере csi-scsi-generic, который поддерживает интеграцию с любыми системами хранения данных.

В статье — проверенные практики от сообщества Kubernetes: от выбора версии API и работы с YAML до управления подами и лейблами. Плюс несколько советов от команды Deckhouse по работе с ресурсами и автомасштабированием.

Мы избавились от «вечно живущих» EC2‑инстансов, настроили масштабируемые GitLab Runner’ы через Fleeting и Autoscaler и при этом сократили расходы на CI‑инфраструктуру. Делимся рабочими конфигами, подводными камнями и практическим гайдом по настройке.

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

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