Хорошая статья о том как Kubernetes распределяет Pods по Nodes.

Рассматривается как и в целом работа scheduler’а, так и принципы работы механизмов для распределения Pods:

- nodeSelector
- Node affinity
- Pod affinity/anti-affinity
- Taints and tolerations
- Topology constraints
- Scheduler profiles

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

👉 DevOps Portal

SAST: руководство для начинающих

Статья про Static Application Security Testing. Автор кратко описывает что это такое, зачем оно нужно и почему это важно. Также рассказывает про способы анализа, которые могут быть «под капотом» у анализатора

Рассматривается следующее:
- «Grep»-техника (она же pattern-matching)
- Control Flow Analysis
- Data Flow Analysis
- Taint Analysis

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

Хорошее руководство для новичков, которые только начинают свой путь в SAST ✌️

👉 DevOps Portal

Советы по работе с 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