Что значит засквошить образ контейнера? 🤔

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

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

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

Практика: https://labs.iximiuz.com/challenges/squash-bloated-container-image

👉 DevOps Portal

Я большой фанат ArgoCD и использования его для управления приложениями в Kubernetes в рамках подхода GitOps. Если вы уже крутите ArgoCD, то ручное обновление тегов образов в репозитории после каждого CI-билда – это вроде бы мелочь, но со временем превращается в нудную рутину

ArgoCD Image Updater закрывает эту боль: он отслеживает ваш container registry и автоматически триггерит деплои.

Особенно актуален свежий релиз v1.1.1 – в нём появился подход на базе CRD, который нормально работает с multisource-приложениями в ArgoCD. Раньше, в версиях на аннотациях, такого не было. Это вполне практичное обновление для команд, использующих Helm-чарты с вынесенными values-репозиториями.

Alexy Pulivelil показывает полный сетап на EKS, включая подводные камни с write-back методами, лимитами registry и стратегиями обновления. Рекомендую посмотреть, если используете ArgoCD

https://alexypulivelil.medium.com/stop-manually-editing-gitops-files-argocd-image-updater-on-kubernetes-0aa44bc9abbf

👉 DevOps Portal

🚨 Обнаружена уязвимость высокой критичности CVE (CVE-2026-4342) в ingress-nginx.

Данная уязвимость позволяет внедрять конфигурацию и потенциально выполнять произвольный код во всех версиях ниже v1.13.9, v1.14.5 и v1.15.1.

Поскольку ingress-nginx переведён в статус EOL (End of Life), пользователям настоятельно рекомендуется как можно скорее обновиться и выполнить миграцию.

Подробности: https://github.com/kubernetes/kubernetes/issues/137893

👉 DevOps Portal

Почему pod’ы DaemonSet игнорируют cordon?

Когда вы выполняете kubectl cordon, Kubernetes помечает ноду таинтом:

node.kubernetes.io/unschedulable:NoSchedule.

Планировщик видит этот taint и перестаёт размещать на ноде новые podы.

Но если посмотреть на ваш logging agent или CNI plugin, запущенный как DaemonSet, он всё равно продолжает работать

Почему?

Потому что контроллер DaemonSet автоматически добавляет каждому pod toleration:

node.kubernetes.io/unschedulable:NoSchedule.

Благодаря этому podы DaemonSet игнорируют taint, выставленный cordon

И это сделано намеренно, потому что DaemonSet используются для критичных системных компонентов, таких как:

- сборщики логов
- агенты мониторинга
- CNI-плагины

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

Если они остановятся, вы потеряете наблюдаемость и сетевую связность на этих нодах.

Если хотите глубже разобраться в taints и tolerations, прочитайте следующий гайд:

Читать здесь: https://courses.devopscube.com/courses/certified-kubernetes-administrator-course/lectures/55659898

👉 DevOps Portal

Анатомия 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