Анатомия Helm-чарта

Helm-чарт — это по сути просто хорошо организованная директория, где у каждого файла есть чёткое назначение.

Вот ключевые файлы:

- 𝗰𝗵𝗮𝗿𝘁.𝘆𝗮𝗺𝗹 — содержит метаданные чарта: имя, версия, описание
- 𝗺𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝘀 / 𝘁𝗲𝗺𝗽𝗹𝗮𝘁𝗲𝘀 — папка с шаблонами Kubernetes-манифестов без захардкоженных значений (по сути, аналог шаблонов в Ansible)
- 𝘃𝗮𝗹𝘂𝗲𝘀.𝘆𝗮𝗺𝗹 — содержит значения (например, имя образа, количество реплик), которые подставляются в шаблоны
- 𝗵𝗲𝗹𝗽𝗲𝗿𝘀.𝘁𝗽𝗹 — включает переиспользуемые блоки шаблонов, которые можно применять во всех темплейтах

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

Поэтому, когда используешь Helm-чарт из комьюнити, стоит потратить время на разбор его структуры.

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

Читать здесь: https://devopscube.com/create-helm-chart/

👉 DevOps Portal

Возможна потеря пакетов… или утечка данных, точно не уверен

👉 DevOps Portal

Проброс портов: используйте эти команды kubectl, чтобы получить локальный доступ к сервису пода без его внешнего экспонирования

👉 DevOps Portal

Little Snitch для Linux
https://obdev.at/products/littlesnitch-linux/index.html

Это приложение показывает все сетевые соединения и позволяет сразу блокировать нежелательный трафик прямо из интерфейса. Разработано той же командой, которая сделала версию для macOS / OS X.

👉 DevOps Portal

Этот кейс описывает, как была переработана нестабильная инфраструктура на Kubernetes в production-ready платформу для ML-нагрузок с использованием GPU, что позволило увеличить частоту деплоев с одного раза в неделю до 10+ раз в день

Читайте тут

👉 DevOps Portal

kube-bench проверяет соответствие

kube-hunter проверяет, насколько вы реально защищены.

Кластеры Kubernetes могут случайно засветить такие вещи, как API server, etcd или слабые настройки RBAC — и команда может этого даже не заметить.

kube-hunter помогает находить такие проблемы, ведя себя как реальный атакующий и прощупывая»кластер на уязвимости.

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

Он может запускаться:

- снаружи (как внешний атакующий),
- внутри кластера (в виде pod’а),
- или сканировать сеть, чтобы найти открытые сервисы.

Это делает его полезным для выявления реальных рисков — таких как открытые дашборды, публичные API endpoints или небезопасный доступ к etcd.

Инструменты вроде kube-bench и Trivy в основном проверяют конфигурации и известные уязвимости.

kube-hunter отличается тем, что моделирует реальные сценарии атак, а не просто проверяет соответствие требованиям.

Именно поэтому команды часто используют его на стадии pre-production, чтобы выявить практические проблемы с безопасностью до выхода в продакшн.

GitHub: kube-hunter

👉 DevOps Portal

Автоматизация тестирования инфраструктуры - тема, о которой легко рассуждать, но гораздо сложнее реализовать качественно на практике. В статье ниже показано, как выстроить многоуровневую стратегию тестирования для Terraform: от юнит-тестов с использованием terraform test, через интеграционные тесты с Terratest до полноценного CI/CD-пайплайна в GitHub Actions.

В статье три уровня тестирования сопоставлены с тем, когда и зачем использовать каждый из них. Плюс без прикрас показаны реальные компромиссы по времени и стоимости. Ошибка с go.sum и способ её исправления тоже включены, потому что именно с такими вещами обычно и сталкиваешься, когда собираешь всё это в единую схему.

Читайте тут

👉 DevOps Portal

Kubechecks позволяет пользователям GitHub и GitLab точно видеть, как их изменения повлияют на текущие деплойменты в Argo CD, а также автоматически запускать различные наборы проверок на соответствие перед слиянием

https://github.com/zapier/kubechecks

👉 DevOps Portal

Плейлист тру девопса в Spotify

👉 DevOps Portal

Helm-чарт Kubernetes Monitoring v4 вышел – почти шесть месяцев работы над исправлением реальных болевых точек:

Теперь destinations – это мапы, а не листы, коллекторы полностью настраиваемые, а multi-cluster конфиги нормально мерджатся и больше не разносит общие values-файлы

https://grafana.com/blog/kubernetes-monitoring-helm-chart-v4-biggest-update-ever-/

👉 DevOps Portal

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

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

Вот несколько примеров

👉 DevOps Portal

Docker Tip

Вот как можно проанализировать, что раздувает образ.

Как вы, возможно, знаете, каждый Docker-образ состоит из слоёв.

Каждый слой добавляется отдельной инструкцией в вашем Dockerfile.

И именно эти слои могут объяснить, почему образ получается большим, долго билдится или плохо кешируется.

Вот как можно посмотреть слои и понять, что изменилось в каждом из них.

Можно воспользоваться утилитой dive.

Она даёт наглядное представление о:

✅ каждом созданном слое
✅ какие файлы были добавлены или изменены
✅ сколько места занимает каждый слой

Когда начинаешь анализировать слои образа, можно понять:

- какая команда добавляет лишний «вес»
- как оптимизировать Dockerfile для более компактных и эффективных сборок

Также утилита показывает image efficiency score — метрику, которая отражает, сколько данных дублируется или расходуется впустую между слоями образа

👉 DevOps Portal

Docker 101: Загрузка образа для конкретной платформы

Имя образа описывает, где он хранится: реестр, репозиторий и тег. Но в нём нет информации о целевой платформе (операционная система и архитектура CPU). Тогда как же docker pull подтягивает нужную сборку?

Учись на практике: https://labs.iximiuz.com/challenges/docker-pull-image-for-platform

👉 DevOps Portal

KAOS — это Kubernetes-наной координацитивный фреймворк для деплоя и оркестрации AI-агентов с интеграцией MCP-инструментов, поддержкой мультиагенти, иерархической делегации, OpenAI-совместимыми эндпоинтами, а также визуальным дашбордом для мониторинга и дебага

GitHub: kaos

👉 DevOps Portal

SecurityContext в Kubernetes - одна из самых важных и при этом часто игнорируемых частей безопасности Kubernetes

Он применяется на уровне Pod и Container.

🔵 Уровень Pod → значения по умолчанию для ВСЕХ контейнеров
🟢 Уровень контейнера → кастомные настройки для каждого контейнера (переопределяют Pod-level)

Вот практический гайд, в котором разбираем:

- Почему важно запускать контейнеры не от root
- Какой UID по умолчанию назначается Pod’ам
- Разницу между SecurityContext на уровне Pod и контейнера (с примерами)
- Как Kubernetes обрабатывает образы контейнеров с non-root пользователями и без них

Читать здесь:
https://newsletter.devopscube.com/p/secure-kubernetes-pods-with-securitycontext

👉 DevOps Portal

Объяснение Route 53 Private Hosted Zone

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

- Разбор Route 53 Private Hosted Zones
- Понимание работы AWS DNS Resolver
- Наглядный пошаговый разбор DNS-флоу с использованием VPN
- Как работает AWS DNS Resolver внутри VPC

Подробный блог: https://devopscube.com/route53-private-hosted-zone/

👉 DevOps Portal

Совет дня по Linux

Большинство людей используют echo для вывода информации

Но в многих случаях его также можно использовать, чтобы избежать ошибок

echo позволяет развернуть подстановочные знаки и понять, что произойдёт, ещё до выполнения команды.

👉 DevOps Portal

Когда тебя наняли на роль DevOps,
но в итоге ты ещё и тащишь на себе SRE, Cloud Engineering и обязанности Incident Manager-а.

👉 DevOps Portal

Архитектура Argo CD: разбор

К концу этого материала вы:

Поймёте, как Argo CD реально работает под капотом.

Внутри:

- Ключевые компоненты и их фактические роли
- Как они взаимодействуют между собой и синхронизируют изменения
- Как Argo CD хранит данные и как правильно настраивать бэкапы
- Как запускать Argo CD в режиме высокой доступности
- Безопасность и мониторинг (Prometheus + Grafana)

и многое другое…

Подробный гайд: https://devopscube.com/argo-cd-architecture

👉 DevOps Portal

AWS Lambda за 40 секунд

👉 DevOps Portal

Краткий совет по Linux

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

$ pgrep firefox

Вы можете использовать это с подстановкой команды, чтобы завершить процесс:

$ kill -9 $(pgrep firefox)

👉 DevOps Portal