Советы по работе с Helm Chart

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

В этой статье разберём несколько полезных практик работы с Helm-чартами:
- Правильное использование community charts
- Ревью и анализ SubCharts
- Безопасная работа с образами из публичных регистри
- Поиск всех контейнерных образов, используемых в чарте
- Конвертация чарта в обычные YAML-манифесты для аудита
- Управление несколькими окружениями через аккуратные values-файлы
- Best practices для Chart.yaml
- Тестирование и валидация

Подробный блог-пост:
https://devopscube.com/helm-best-practices-essential-tips-to-know/

👉 DevOps Portal

Совет дня по Linux

Можно использовать команду fc для редактирования команд из истории. Допустим, вам нужно отредактировать команды с номерами 230 по 232 в истории.

fc 230 232

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

👉 DevOps Portal

DNS resolution в Linux и Kubernetes

Автор делится своими знаниями о том, как устроен DNS resolution в Linux и Kubernetes.

В статье можно найти информацию о:
- Общая теория DNS в Kubernetes
- DNS в Linux: resolv.conf и nssswitch.conf
- Что изменится при использовании, например, Alpine?
- DNS в Kubernetes: kube-dns, настройки и модификации, dnsPolicy

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

Читайте здесь

👉 DevOps Portal

Паттерны проброса портов в Kubernetes

Ты находишься внутри dev-кластера, доступ к сети ограничен, и сервис, который ты только что задеплоил, ведёт себя странно.

Нет ни LoadBalancer, ни настроенного ingress-контроллера, и «просто открыть порт» – не вариант, потому что сетевики либо тормозят, либо отвечают отказом.

Вот здесь тебя и выручает kubectl port-forward.

Вот простая инфографика, чтобы было легче понять.

👉 DevOps Portal

Быстрый совет по Linux

Используйте less, чтобы просматривать длинный файл с прокруткой, не открывая редактор:

$ less /var/log/syslog

Нажмите q, чтобы выйти

👉 DevOps Portal

Environment branching – это модель, при которой для каждого окружения существует отдельная ветка.

Код продвигается по пайплайну за счёт мерджей из одной ветки в следующую, обычно по цепочке dev → qa → staging → prod.

Этот подход даёт командам очень явный контроль над тем, что именно деплоится. Разработчики работают в dev, тестировщики подхватывают изменения в qa, staging используется для стабилизации релизов, а в production попадает только то, что было последовательно промоутировано через все этапы.

Такая модель часто встречается в легаси-системах или в конфигурациях без развитых CI/CD-инструментов.

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

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

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

Environment branching даёт контроль, но ценой консистентности. Для большинства современных команд это анти-паттерн, если только ограничения системы не делают его неизбежным.

👉 DevOps Portal

Как создать Kubernetes-оператор с нуля

Операторы упрощают рабочие процессы, сокращают объём ручных операций и помогают в управлении инфраструктурой – это ключевые навыки для всех, кто работает в DevOps.

https://thenewstack.io/how-to-build-a-kubernetes-operator-from-scratch/

👉 DevOps Portal

GoBackup – занятная CLI-утилита для бэкапов баз данных и не только

Всё описывается в YAML-конфиге, после чего можно запускать резервное копирование прямо в системе. Из приятных бонусов – у GoBackup есть простая веб-морда для просмотра и управления бэкапами

- Сайт тут
- Github здесь

👉 DevOps Portal

Запутались, когда использовать Kubernetes Operators, а когда Helm? Это для вас.

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

Kubernetes Operator: обеспечивает расширенное управление за счёт автоматизации, учитывающей жизненный цикл, для сложных приложений

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

👉 DevOps Portal

В этом репозитории вы найдёте роадмап для изучения Kubernetes с нуля (от уровня новичка до продвинутого).

Внутри много ссылок на курсы, статьи, материалы по теме

Забираем на GitHub

👉 DevOps Portal

Знаете ли вы?

SSH-сессии не исчезают, когда вы отключаетесь.

Пути:

/var/log/wtmp — история входов

/var/log/btmp — неудачные попытки входа

/var/log/lastlog — последний вход

Что могут увидеть специалисты по цифровой криминалистике:

- успешные логины;

- неудачные brute-force попытки;

- исходные IP-адреса;

- длительность сессий;

-какая учётная запись использовалась.

Вы отключились. Linux сохранил журнал посещений.

👉 DevOps Portal

Учимся сетям на практике

Вот пример сложной сетевой топологии, которую можно развернуть в playground от iximiuz Labs, где узлы – это реальные виртуальные машины, соединённые с произвольным количеством сетевых бриджей.

Пора поработать руками:
https://labs.iximiuz.com/playgrounds/flexbox

👉 DevOps Portal

Когда-нибудь задумывались, как Kubernetes-сервисы обрабатывают балансировку нагрузки?

Вот как это работает.

По умолчанию компонент kube-proxy в Kubernetes использует iptables для маршрутизации запросов (также поддерживается IPVS).

В iptables есть функция, называемая statistic mode random probability.

Эта функция является частью iptables и используется для фильтрации пакетов и NAT. Она позволяет создавать правила, которые случайным образом матчят определённый процент пакетов.

Например, мы протестировали endpoint сервиса, указывающий на деплоймент из трёх подов.

Он показал значение statistic mode random probability = 0.33, что по сути распределяет трафик между тремя подами.

Это скорее вероятностное распределение трафика, а не полноценная балансировка нагрузки.

- Оно не учитывает фактическую нагрузку на серверы.
- Не гарантирует равномерное распределение трафика во времени.
- Не поддерживает session persistence (липкие сессии)

👉 DevOps Portal

Нашёл максимально залипательный способ прокачать system design и облачную архитектуру – игра Server Survival

Это 3D tower defense, где вы играете за облачного архитектора: строите инфраструктуру, раскидываете файрволы, балансировщики, сторэджи, отбиваетесь от дудоса, следите за бюджетом и здоровьем сервисов.

По сути, интерактивный симулятор продакшн-нагрузки, только в формате игры 🥳

И да, проект опенсорс, код на GitHub

@IT_Portal

Самый распространённый способ запустить контейнер — использовать Docker CLI. Но что именно делает команда docker run? Чем она отличается от:

🔹 podman run

🔹 nerdctl run

🔹 ctr run

🔹 runc create/start

Мини-курс, чтобы научиться запускать контейнеры с разными рантаймами:
https://labs.iximiuz.com/skill-paths/run-containers-across-runtimes

👉 DevOps Portal

Репозиторий для изучения Prometheus и понимания, зачем и где его использовать

https://github.com/acend/prometheus-training

👉 DevOps Portal

Тормозят Docker-сборки? Используй мощь build cache

Build cache переиспользует слои образа и метаданные, чтобы ускорить сборку. Когда ты пересобираешь образ без изменений или с минимальными изменениями, билдер повторно использует результаты предыдущей сборки.

На картиинке наглядный пример того, как build cache работает между сборками

Если хочешь ускорить сборки, в этом туториале разобраны ключевые концепции и практики, которые помогают выжать максимум из кэша:
https://depot.dev/blog/ultimate-guide-to-docker-build-cache

👉 DevOps Portal

Kubernetes совет

Удалить все поды в неймспейсе

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

Сделать это можно с помощью флага --all

👉 DevOps Portal

Большинство людей сразу прыгают в Prometheus и Grafana, не понимая, какую именно задачу они на самом деле решают.

Я постоянно вижу это на собеседованиях. Человек говорит: «Мы используем Prometheus для мониторинга», но при этом не может объяснить, почему логи и метрики требуют разных пайплайнов, или что вообще происходит, когда CloudWatch перестаёт справляться на масштабе.

В observability вы решаете две принципиально разные проблемы.

Логи отвечают на вопрос "что произошло". Произошла ошибка. Пришёл запрос. Упал запрос к базе данных.
Это события - истории, которые рассказывает ваше приложение.

Метрики отвечают на вопрос "как система чувствует себя прямо сейчас". Латентность 200 мс. CPU 75%. 500 запросов в минуту. Это измерения.

Разные типы данных. Разные способы сбора. Разное хранение. И именно здесь большинство людей путается.

В прошлом месяце на моём DevOps-буткемпе мы собрали полноценную систему observability для микросервисов в Kubernetes.

Логи

Для логов мы использовали Fluentd sidecar-контейнеры, которые шарят volume с основным контейнером приложения:
- приложение пишет логи в volume;
- Fluentd читает их и отправляет дальше;
- чёткое разделение ответственности;
- на небольшом масштабе логи просто улетают напрямую в CloudWatch.

Но когда у вас тысячи строк логов в секунду, приходится добавлять слои:
- Lambda для форматирования.
- Kinesis для буферизации.
- OpenSearch для быстрых запросов по петабайтам данных.
- S3 для долгосрочного бэкапа.

Мы держали 7 дней в OpenSearch для активных расследований. 30 дней — в CloudWatch. Годы — в S3 для комплаенса. У каждого слоя разные характеристики по цене и производительности.

Метрики

Для метрик Prometheus скрейпит application endpoints каждые 30 секунд:
- разработчики инструментируют код клиентскими библиотеками Prometheus;
- экспонируют /metrics endpoint;
- Prometheus сам подтягивает данные.

Мы создали ServiceMonitor’ы, которые говорят Prometheus, какие pod’ы скрейпить на основе label’ов:
- Как только поднимаются новые pod’ы, Prometheus их обнаруживает и начинает скрейпить.
- Дальше Grafana визуализирует всё это.
- Мы импортировали готовые дашборды с grafana.com для мониторинга Kubernetes.
- И также собрали кастомные панели под метрики конкретного приложения.

Логи и метрики идут параллельно.

Когда что-то ломается, метрики показывают вам всплеск: error rate подпрыгнул в PM. Латентность выросла со 100 мс до 2 секунд.

Дальше вы идёте в логи: фильтруете по тому же окну времени, находите stack trace’ы и видите, что именно упало.

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

Мы всё это реализовали и оттраблшутали в лайв-созвоне: нагенерили метрики и логи и собрали дашборды в Grafana

Прочитать подробный пост можно здесь: https://open.substack.com/pub/akhileshmishra/p/youre-not-ready-for-kubernetes-observability

👉 DevOps Portal

How-To: как собрать eBPF-фаервол, который фильтрует пакеты по диапазонам IP

В большинстве туториалов показывают, как заблокировать один конкретный IP-адрес. Но в реальном мире (Kubernetes, автоскейлинг нод, короткоживущие ворклоады, managed-сервисы и т. п.) IP-адреса постоянно меняются, поэтому на практике имеет смысл работать именно с CIDR-диапазонами.

В этой статье вы узнаете, как правильно блокировать целые подсети:
https://labs.iximiuz.com/tutorials/ebpf-firewall-ed03d648

👉 DevOps Portal