Docker vs. Kubernetes — от изолированных контейнеров к единой среде

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

Контейнер запускает приложение как отдельный процесс: отдельный сетевой стек (IP, интерфейсы и маршруты), своё PID-пространство и управление ресурсами через cgroups (CPU и память). Эти механизмы изолируют и сохраняют предсказуемость работы — один процесс, один контейнер.

На практике несколько процессов работают параллельно, обмениваются данными и используют общие ресурсы. Например, основной контейнер выполняет приложение, а вспомогательный (sidecar) собирает логи, проксирует трафик или ведёт метрики.

📱В статье от iximiuz Labs дан подробный разбор того, как Kubernetes реализует Pods на уровне Linux и можно ли воспроизвести функциональность Pod в чистом Docker.
Спойлер: можно, если вручную подключить сетевые и IPC namespace, но не всё получится — UTS, например, остаётся изолированным.

Полный разбор здесь ⬅️, а ниже — практика от iximiuz Labs
• Run a Sidecar Container in the Namespace of Another Container— проверь, как контейнеры делят namespace, как в Pod.
• Limit CPU and Memory Usage of a Docker Compose Application — узнай, как задать лимиты CPU и памяти через cgroups.

#devops #kubernetes #containers #pods

Пятничная подборка: Jupyter, оптимизация ИИ-нагрузок в Kubernetes и облачные тренды

Сегодня в эфире подборка подкастов, в которых эксперты обсуждают эволюцию Project Jupyter, распределение расходов ИИ-сервисов в новой версии Kubernetes, тренды ИИ в облаке.

⏺DOP 324:Kubernetes Resource Right-Sizing and Scaling with Zesty
Приглашенный гость Омар Хамерман, IT-архитектор Zesty.co, совместно с ведущими Дарином Поупом и Виктором Фарциком говорят о возможностях управления нагрузками ИИ в Kubernetes версии 1.33. Основное внимание уделяют автоматическому масштабированию. Послушать можно здесь.

⏺From Physics to the Future: Brian Granger on Project Jupyter in the Age of AI
Брайн Грэнджер совместно с главным редактором издания The New Stack (TNS) рассмотрели развитие архитектуры Jupyter, построенной на модульных и расширяемых компонентах, роль ИИ-агентов в разработке приложения. Больше подробностей тут.

⏺The CloudCast: AI & Cloud Trends for October 2025
Брайн Грэйсли и Брэндон Уичард разобрали тренды за последний месяц: анонсы от провайдеров, изменения в экосистемах OpenAI и вопросы безопасности облачной инфраструктуры. Подробнее здесь.

🔈Желаем приятного прослушивания и дежурств без алертов!

#kubernetes #jupyter #cloud #подкасты

Good practices: конфигурации в Kubernetes

Конфигурации – основа рабочей нагрузки Kubernetes. Опытные инженеры знают, что достаточно пропущенной кавычки, неактуальной API-версии или смещённого отступа в YAML для возникновения проблемы при деплое. Представляем подборку good practices с советами по стабилизации кластера — для новичков и опытных пользователей. Подробнее читайте здесь.👀

Общие practices:
⏺Используйте актуальную версию API
Kubernetes быстро развивается и обновляется. Менее актуальные API не работают корректно и приводят к сбоям при деплое. Проверяйте версию API, используя следующую команду:

kubectl api-resources 

⏺Храните конфиги под версионным контролем
Не применяйте файлы манифеста с десктопа, храните их в системе контроля версий, например, в Git. Если что-то сломается – вы быстро откатитесь к прошлому коммиту.
⏺Пишите конфиги в YAML, не в JSON
Технически работают оба формата для обмена и хранения данных, но YAML более удобен, по словам автора. В YAML используйте только true/false, т.к. yes/no/on/off могут парситься по-разному. Для надёжности берите в кавычки всё, что похоже на булево значение (например, "yes").
⏺Группируйте связанные объекты
Если ресурсы – часть одного сервиса, храните их в одном файле YAML-манифеста. Так легче отслеживать, ревьювить и разворачивать изменения.
Применяйте эту команду, чтобы задеплоить всё в папке:

kubectl apply -f configs/ 

🚀Стандартизированные конфигурации упрощают управление кластером и берегут нервы администратора. Следуйте базовым принципам: контроль версий, единая система меток, отказ от использования отдельных Pod-ов без контроллеров. Так, вы значительно сократите время на диагностику и устранение ошибок.

#kubernetes #k8s #clustermanagment #devops

Где тонко – там ChatGPT, где Docker – там патч

Из срочного – сообщаем о массовом сбое в работе ChatGPT 2 декабря. Пользователи из США, Канады, Великобритании, Индии и других стран направили запросы о превышении времени ожидания ответов в приложении в 22:11 Мск. Уже через час проблему устранили, но с чем были связаны неполадки до сих пор неизвестно.

⏺Анонс Kubernetes v1.35
В сникпике версии v1.35 Kubernetes прекращает поддержку cgroup v1, ipvs в kube-proxy и containerd 1.x, что требует обновления инфраструктуры для корректной работы кластера. Релиз включает в себя in-place обновление ресурсов подов, node declared features, расширенные возможности taints, user namespaces и нативное управление сертификатами подов, повышающие безопасность и надёжность.

⏺GitLab Patch Release: 18.6.1, 18.5.3, 18.4.5
Патч-релизы GitLab устранят множество багов и уязвимостей, поэтому рекомендуем обновиться. Среди исправлений – небезопасная многопоточность при кешировании CI/CD, DoS-уязвимости валидации JSON, проблема обхода аутентификации при регистрации.

⏺Docker и CVE-2025-12735.
Docker устранили критическую уязвимость CVE-2025-12735 (удалённое выполнение кода в Kibana). Команда не только выпустила патч для пользователей, но и внесла исправление в LangChain.js в upstream, чем повысила безопасность для всех проектов, использующих эту библиотеку. Такой подход направлен на защиту всей экосистемы.

#kubernetes #gitlab #docker #chatgpt

От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
⏺Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update

2. Разворачиваем базовое окружение для инфраструктуры:

cub space create infra

3. Устанавливаем Helm-чарт через ConfigHub:

cub helm install --space infra \
  --use-placeholder=false \
  --namespace monitoring \
  prometheus prometheus-community/kube-prometheus-stack \
  --version 79.6.1

• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

⏺Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod
2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

⏺Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

⏺Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only

Prod

cub unit get --space prod prometheus --data-only

Получаем готовый YAML, а не шаблон или переменную.

⏺Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*registry.compromised.com.*'"

Поиск образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*quay.io.*'"

👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops

Пятничное чтиво от DevOps FM

Сегодня поговорим об инфраструктурных мелочах с большими последствиями.

👀Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.

👀5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.

👀Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.

🚀Приятного чтения! Пусть все инциденты сегодня будут только на Habr.

#пятничноечтиво #kubernetes #devops #security

CPU limits в работе с Kubernetes

💬В одном из недавних постов мы рассмотрели, как объяснить особенности Kubernetes CPU & Memory Requests, Limits по-человечески, сегодня обсудим опыт пользователей Reddit в работе с лимитами в проде. Весь тред можете прочесть здесь.

🗣По результатам опроса, в котором приняло участие 247 человек, ~54% используют CPU limits, но с небольшими оговорками:

ThePapanoob
В вопросе не отражены нюансы. Существует множество кейсов и в некоторых действительно нужно применять CPU limits, в других они только мешают работе

lulzmachine

Обычно начинаю без них, но всегда добавляю позже. Всеми способами избегаю «шумных соседей» (поды или контейнеры, которые

потребляют много ресурсов

и мешают другим подам нормально работать на том же ноде)

Xeroxxx

Да, мы используем лимиты в проде. Requests и Limits устанавливаются одинаково. Для скейлинга используем karpenter.

⏺Чуть меньше половины опрошенных не видит смысла в CPU limits при наличии CPU requests:

romeo_pentium

CPU limits становится причиной троттлинга и неиспользованных CPU. Мы всегда можем работать с CPU requests. Преимущество в том, что контейнер не будет использовать CPU request другого контейнера.
Linux kernel троттлит ваш CPU по мере его приближения к лимиту.
Без лимитов производительность выше, и я не нашел преимуществ в их установке.

Ariquitaun

CPU limits обычно приводят к снижению производительности. Нам нужны только CPU requests для гарантии базового уровня производительности на проде.
С памятью дела обстоят по-другому – ООМ приведет к прекращению рабочих нагрузок в самое неподходящее время, а иногда к «убийству» нодов.

th0th

Я преимущественно использую requests, limits очень редко. Я предпочитаю следить за фактическим использованием и обвновлять request по необходимости.
У меня установлены алерты на превышение CPU в нодах, использовании памяти. Мне кажется, безопаснее опираться на систему оповещений, чем на последствия использования лимитов, по типу троттлинга.

Какой алгоритм работы в проде используете вы и ваши коллеги? Делитесь опытом в комментариях👀

#kubernetes #cpu #cpu_limits #cpu_requests

🛡Безопасность в Docker: SBOM и выявление уязвимостей

Сегодня разбираем, как обеспечить безопасность цепочки поставок в Docker на примере практического гайда Shamsher Khan: Advanced Docker Security: From Supply Chain Transparency to Network Defense. Подробно разберем обеспечение прозрачности цепочки поставок с помощью SBOM, спецификации ПО (Lab 07), а подробнее об установке эшелонированной защиты от DDoS и ботов (Lab 08) можете прочесть здесь.

👀Почему тема важна в сообществе?
• В 2021 инцидент с Log4Shell, ошибкой в библиотеке Log4j, указал на большую проблему современной разработки – незнание состава контейнеров.
• Кибератака SolarWinds произошла в том же году, что инцидент выше.

⏺В статье представлены две лабы, задеплоить можно уже сегодня:
1. Обеспечение прозрачности цепочки поставок с помощью SBOM (Lab 07)
2. Эшелонированная защита от DDoS и ботов (Lab 08)

💬Обеспечиваем безопасность цепочки поставок со SBOM (Lab 07)
Рассмотрим Dockerfile:

FROM python:3.11-slim 
COPY requirements.txt . 
RUN pip install -r requirements.txt 
COPY app.py . CMD ["python", "app.py"]

Вопрос знатокам: какие пакеты в этом образе? Без SBOM мы можем догадаться: e.g. Python 3.11, requirements.txt и OS уязвимости.
SBOM позволяет получить полный список всех компонентов, версий и лицензий, сгенерированный за секунды.

🚀На старт, внимание, SBOM
В статье представлен демо-скрипт для выполнения с последовательностью из 12-ти шагов.

💬Шаг 1: установка инструментов.

# Install Syft (SBOM generation) 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 

# Install Grype (vulnerability scanning) 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 

# Verify installation 
syft version grype version

💬Шаг 2: установка SBOM

From a Docker image
syft nginx:alpine -o spdx-json > nginx-sbom.json

# From a directory
syft dir:./myapp -o cyclonedx-json > myapp-sbom.json

# Multiple formats at once
syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json

💬Шаг 3: выявляем уязвимости

# Scan the SBOM
grype sbom:./nginx-sbom.json

# Or scan image directly
grype nginx:alpine

💬Шаг 4: сравниваем версии SBOM

# Generate SBOMs for two versions
syft myapp:v1.0 -o json > v1.0-sbom.json
syft myapp:v2.0 -o json > v2.0-sbom.json

# Compare (using provided script)
./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json



💬Шаг 5: выявляем уязвимости в SBOM

# Scan the SBOM
grype sbom:./nginx-sbom.spdx.json

# Or scan image directly
grype nginx:alpine

💬Шаг 6: определяем типы уязвимостей по параметрам

# Only show CRITICAL and HIGH
grype nginx:alpine --fail-on high

# Only show CRITICAL
grype nginx:alpine --fail-on critical

# Show only specific severity
grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")'

# Export vulnerabilities to JSON
grype nginx:alpine -o json > vulnerabilities.json

В шагах 7 и 8 сравниваем версии SBOM и ищем конкретные пакеты, а в 9 – рассматривает отчёт/журнал SBOM

💬Финальный шаг, 12: интеграция в CI/CD (Azure DevOps)

azure-pipeline.yml

- task: Docker@2
  inputs:
    command: build
    dockerfile: '**/Dockerfile'
    tags: $(Build.BuildId)

- script: |
    syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json
  displayName: 'Generate SBOM'

- script: |
    grype sbom:./sbom.json --fail-on high
  displayName: 'Scan for Vulnerabilities'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'sbom.json'
    artifactName: 'SBOM'

👨‍💻В результате, скорость реагирования при обнаружении уязвимостей сокращается с 14 до 2 дней, осуществляется поддержка 3-х форматов (SPDX, CycloneDX, Syft JSON) и гарантируется полное соответствие требованиям – EO 14028.

👩‍💻Делимся репозиториями:
• Syft – установка SBOM
• Grype – выявление уязвимостей
• Docker Security Practical Guide – полный гайд с Lab 07 и Lab 08

#devsecops #SBOM #zerotrust #kubernetes

Обновления 2026: Kubernetes 1.35, Debian 13.3, Zena и Argo

👨‍💻Уже среда? По расписанию – первый новостной дайджест этого года.

⏺Функции в Kubernetes 1.35
В начале месяца Kubernetes анонсировали функцию In-Place Pod Resize Graduates to Stable с изменением в CPU-лимитах и запросах. Отслеживайте ресурсы внутри работающего пода, без перезапуска контейнера. Также анонсировали две функции: Toleration операторов для числовых сравнений (alpha), Gt(больше чем) и Lt(меньше чем) spec.tolerations, и управления credential-плагинами для kubectl. Ознакомиться с use-кейсами по альфа-функции здесь а с полным описанием функций бета-версии тут.

⏺Обновленный Debian: исправили ошибки, добавили патчи
Вышло обновление в дистрибутиве Debian Trixie на базе ядра Linux 6.12.63-1 LTS. Команда подчеркивает – релиз не является новой версией и включает обновленный набор пакетов. В версию 13.3 были включены пакеты для ansible, apache, dpdk, flatpak,gnome-shell с upstream-релизами, исправлены ошибки в awfull, calibre, composer и др. Команда устранила комплекс проблем: переполнение целочисленных значений, некорректный анализ переменных окружения, ошибка отказа в обслуживании, инициализации длины буфера шифрования. Ознакомиться со списком пакетов тут, обновления безопасности и общая информация здесь.

⏺Мятный Linux 22.3 – что нового?
Состоялся релиз Linux Mint «Zena» на ядре Linux 6.14 и базе Ubuntu 24.04 LTS, поддержка версии осуществляется до 2029 года (LTS). В обновлении преобразовали инструмент «System Reports», актуальное название «System Information», добавили страницы для просмотра детализированного списка подключённых USB-устройств с типом, идентификатором и группировкой по контроллерам, информацию о PCI-устройствах, PCI ID и используемых драйверах. Также представили функцию управления «System Administration» со страницей «Boot menu», где вы можете задать время отображения и параметры загрузки. Подробнее об обновлении здесь, а инструкцию для сборки на Cinnamon 6.6, Xfce 4.18 и MATE 1.26 найдете тут.

⏺Argo CD Agent: управление кластерами и приложениями
Red Hat объявили о выходе Argo CD Agent совместно с релизом Red Hat OpenShift GitOps 1.19. Пользовательский интерфейс и API разворачиваются в централизованной control plane, а ключевые компоненты, такие как application-controller, – локально в каждом кластере. В релизе представлены два режима работы: управляемый и автономный. Для обеспечения отказустойчивой EDS ввели два компонента. Principle передает команды, статусы между Control hub и агентами управляющих кластеров, а Agent обеспечивает масштабируемость. Подробности обновления здесь, инструкция по установке агента тут.

#дайджест #kubernetes #linux #gitops #argocd

🎙️Слушаем пятничную подборку подкастов в DevOps FM!

⏺Flox, Nix, and Reproducible Software Systems от Software Engineering Daily. В новом выпуске затронули проблему воспроизводимости и безопасности в современной разработке ПО и обсудили, как подход Nix к управлению пакетами и зависимостями повышает воспроизводимость и безопасность, а также роль Flox в проектах. Болл предложил варианты деплоя без классических больших Docker-образов, поднял вопросы мультиархитектурных разрешений зависимостей (разрешение «closures» и групп пакетов) и их ограничения на практике. Узнать детали – здесь.

⏺We Broke Our EKS Cluster Autoscaler with the AL2023 Migration от Kube FM. Барт Фарелл разбирает инцидент, который возник при миграции EKS на Amazon Linux 2023. Почему после обновления AMI автоскейлер потерял AWS-права в кластере, как корректно внедрить IRSA (IAM Roles for Service Accounts), проверить зависимость конкретных подов от IAM-ролей нодов и очистить устаревшие IAM-разрешения, чтобы сократить атаки после миграции – слушайте тут.

⏺ Engineering Around Extreme S3 Scale with R. Tyler Croy от Last week in AWS. Р. Тайлер Крой, инженер Scribd, рассуждает с Кори Куинном о проблеме хранения миллиардов объектов в облачном объектном хранилище S3 и. Как организовать работу, когда простые задачи обходятся компании в 100 000 долларов. В подкасте услышите тезисы о распределении бюджета на инфраструктуру в облаке, опыт Scribd, накопленный за 18 лет на рынке. Крой настаивает – стандартные решения больше не работают при большом потоке вводных данных, нужно генерировать новые. Подробности – здесь.

Приятного прослушивания и пятниц без инцидентов🛡

#подкаст #devops #kubernetes #eks

Релизы и безопасность

Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.

⏺Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут.

⏺Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения. VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь.

⏺Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.

#devops #cozystack #mxlinux #kubernetes #platformengineering

Чем запомнился январь? Релизы Jenkins, Cluster API в Kubernetes и альтернативы Ingress-nginx

Всем DevOps! В эту среду сосредоточимся на изменения в политике безопасности Jenkins, новые сценарии обновлений в Cluster API и обсуждение альтернатив Ingress-nginx.

⏺Jenkins – изменения в политике безопасности, RPM-пакетировании для Red Hat и openSUSE
В релизе Jenkins 2.528.3 добавили поддержку Java 25 для контроллера и агентов, а также образы Windows Server 2022 для контейнеров. Для LTS RPM и DEB репозиториев введён новый GPG-ключ, который администраторам нужно принять при обновлении. Серьёзные изменения версии 2.528.3 коснулись управления Content Security Policy через интерфейс и API для плагинов. Пакеты Jenkins для Red Hat и openSUSE объединены в единый RPM-репозиторий с новым адресом: https://pkg.jenkins.io/rpm-stable/ . Для прошлых LTS-версий Jenkins (2.528.3 и раньше) сохранён отдельный архивный репозиторий: https://pkg.jenkins.io/redhat-stable-legacy/ .Больше о релизе – тут.

⏺Cluster API v1.12 – обновления «на месте» и «в цепочке»
В блоге Kubernetes вышла статья о новой версии Cluster API, инструменте для декларативного управления жизненным циклом кластеров. Подобно тому, как в Kubernetes можно использовать StatefulSets или Deployments для управления группой pod-ов, в Cluster API можно использовать MachineDeployments для управления группой nod-ов. В релизе представлены обновления in-place через update-extensions, теперь изменения применяются к существующим нодам без пересоздания, и chained upgrades для обновления несколько минорных версий без ручного вмешательства. Смотрите на GitHub – подробности о релизе, преимущества обновлений.

⏺Архив Ingress-nginx: какие альтернативы?
В уходящем году команда проекта Ingress-nginx сообщила о прекращении поддержки в марте 2026, подробнее писали тут. В блоге CNCF опубликовали статью о преимуществах и недостатках перехода на другой контроллер входящего трафика (Cilium Ingress, Traefik, HAProxy Ingress), или внедрения Kubernetes Gateway API. На примере Cilium Ingress первый вариант был признан самым быстрым: вы вносите минимальные изменения в манифесты приложений, CI/CD и работаете со встроенной функцией мониторинга. По версии CNCF переход на Gateway API от Cilium – самый оптимальный. Как мигрировать на Cillium Ingress – тут, а подробнее о переходе на Gateway API – здесь.

#devops #kubernetes #cloudnative #opensource

Релизы и прекращение поддержки: Kubespray, AWS LBC и проекты Linux

🚀Среда – маленькая дайджестная пятница. Сегодня обсудим, что меняется в Kubespray и AWS Load Balancer Controller, почему LFS и BLFS делают ставку на systemd, и как Debian GNU/Hurd из нишевого проекта выходит к стабильным релизам.

⏺Официальное заявление от служб Kubernetes
Если вы все-таки решили остаться с Ingress NGINX, у Kubernetes для вас плохие новости. После прекращения поддержки проекта – готовьтесь к атакам. Текущие версии развертывания будут продолжать работать, но без постоянного отслеживания изменений, вы узнаете о вредоносе слишком поздно. Подробнее – тут.

⏺Kubespray v.2.30.0 – поддержки Ingress NGINX больше не будет
В минорной версии Kubespray объявили о прекращении поддержки обновлений Ingress NGINX в следующих релизах, поместили в архив Dashboard, в качестве альтернативы предложен Headlamp. Опция containerd_discard_unpacked_layers доступна для containerd версии 2.1 и старше, а API адрес теперь определяется на основе переменной kube_apiserver_global_endpoint, поэтому убедитесь, что ваши endpoint-ы указаны правильно и к ним есть доступ со всех nod. Больше обновлений – здесь.

⏺Что нового в AWS Load Balancer Controller v.3.0.0?
В релизе представлена поддержка Gateway API v1.3.0, доступная для прода. В LBC поддерживаются маршруты L4 (NLBGatewayAPI), L7 (ALBGatewayAPI). В версию включили багфиксы, из важного в релизе – обновленные CRD-ы (включая Gateway CRD) и устранение критической ошибки при обновлении webhook-сертификатов (#4541). Если вы используете enableCertManager=true flag при развертывании в Helm, столкнетесь со сбоями в работе. В LBC v.3.0.0 – проблема уже решена. Подробнее о мажорной версии – тут.

⏺Изменения в Linux – LFS, BLFS переходят на systemd
Linux From Scratch (LFS), Beyond Linux From Scratch (BLFS) прекращают поддержку System V из-за повышенной нагрузки и особенностей новых требований от GNOME, Plasma от KDE.

Брюс Даббс сообщил, что в проекте работают волонтеры-энтузиасты, которые не справляются с нагрузкой. С сентября 2025 было сделано 70 коммитов в LFS и 1155 коммитов в BLFS. Даббс упоминает множественные этапы проверок при обновлениях пакетов и релизах – как для System V, так и для systemd. С требованиями от GNOME и KDE, которые ориентируются на функционал systemd, у редакции просто не будет хватать времени на миграцию и обход. Больше об анонсе – здесь

⏺Debian GNU/Hurd на FOSDEM'26 – стабильная работа и выход дистрибутивов
На FOSDEM разработчики Debian GNU/Hurd, платформы для разработки, сервера и настольной системы, представили доклад по этапам развития проекта и планам на 2026. Из отличительных особенностей – проект стабильно работает на архитектуре x86_64 с частичной поддержкой SMP, 75% пакетов теперь собираются для Hurd, добавили поддержку Rust, Go, OCaml, Java. Также нас ждёт выпуск дистрибутивов Guix/Hurd и Alpine/Hurd. Подробнее о проекте – тут.

#kubernetes #aws #linux #debian #opensource

Как CPU weight влияет на Kubernetes: переход на cgroup v2

👩‍💻 Итамар Холдер из Red Hat разбирает новую формулу перехода CPU shares из cgroup v1 в CPU weight для cgroup v2. Ранее при простом пересчёте контейнеры с 1 CPU получали слишком низкий приоритет по сравнению с процессами вне Kubernetes, а мелкие CPU-запросы невозможно было точно распределять внутри под-cgroups. Новая формула восстанавливает приоритет по умолчанию.

⌨️Внедрение и практика
• Изменение реализовано на уровне OCI-рантаймов (runc ≥1.3.2, crun ≥1.23), а не в Kubernetes. Внедрение новой формулы зависит от того, какой OCI-рантайм используется в вашем кластере.
runc поддерживает новую формулу с версии 1.3.2
crun – с версии 1.23
• Перед применением тестируйте значения CPU weight в staging.
• Обратите внимание на инструменты мониторинга и кастомные системы управления ресурсами – прежние формулы могут дать неверные прогнозы и метрики.
Новая формула CPU weight нужна для расстановки приоритетов контейнеров, управления CPU-запросами и для предсказуемости распределение ресурсов, что особенно важно в работе с высокими нагрузками.

❕Что почитать дальше:
Kubernetes GitHub Issue #131216 – подробный технический разбор с примерами и обсуждением выбора формулы.
KEP-2254: cgroup v2 – исходник cgroup v2 в Kubernetes.
Документация по cgroup в Kubernetes – актуальные рекомендации по управлению ресурсами.

#devops #kubernetes #containers

Срединедельная подборка новостей

🗣До весны осталось… два новостных дайджеста. Что запомнилось по итогам недели?

⏺Обновления Linux
В Linux 7.0 ускорили обработку сетевых пакетов. Разработчики вручную встроили функцию timecounter_cyc2time(), т.к. компилятор не справлялся с этим автоматически. В тестах это дало +12% производительности UDP на 100ГБ сетевых картах. Такая оптимизация важна для новых сетевых протоколов, которые требуют точных отметок времени, например для Swift congestion control в TCP. Кроме того, улучшили работу подсистемы таймеров при переходе сервера в режим ожидания. Коммит – здесь, подробности – тут.

⏺Chrome 145 – обновления безопасности
Google анонсировала стабильную версию браузера. Традиционно, усилили безопасность и обновили sandbox. Также добавили DBSC (Device Bound Session Credentials) для привязки сессий к конкретному устройству. Ввели разделение прав доступа для защиты от CSRF-атак, устранили 11 уязвимостей, в том числе критические – CVE-2026-2313 (CSS), CVE-2026-2314 (Codecs), CVE-2026-2315 (WebGPU). Обратите внимание, в новой версии нельзя откатить User-Agent Reduction. Для корпоративных пользователей Google поддерживает ветку Extended Stable с 8-недельным циклом обновлений. Релиз следующей версии – 10 марта. Подробнее – тут.

⏺Отчёт об инцидентах в GitHub
GitHub опубликовали отчёт за январь 2026, где описали два крупных инцидента. 13 января на 46 минут проблема возникла у Copilot Chat и интеграции с IDE из-за ошибки конфигурации при обновлении модели GPT‑4.1, а через два дня увеличились задержки и тайм-ауты в сервисах репозиториев, API, Actions, уведомлениях и при авторизации при обновлении инфраструктуры БД. Инциденты от 9 февраля войдут в отчёт марта, а подробнее о решениях – здесь.

⏺В каких средах Kubernetes HPA менее эффективен?
На InfoQ выкатили статью о проблемах autoscaling-а приложений для edge-инфраструктуры в Kubernetes. В ней автор поясняет, Horizontal Pod Autoscaler (HPA) не работает для сценариев с низкой латентностью и ограниченными ресурсами. HPA использует пропорциональную формулу и опирается на метрики типа CPU, что в edge-среде ведет к позднему масштабированию и росту числа подов. Модели не хватает гибкости при нестабильной нагрузке (IoT-шлюзы, игровые серверы). В качестве решения автор делится опытом использования Custom Pod Autoscaler (CPA), описывает архитектуру, логику на Python, интеграцию с системой метрик Prometheus, а также демонстрирует результаты нагрузочного тестирования. По сравнению с HPA алгоритм обеспечивает меньшую амплитуду колебаний числа реплик, стабильную латентность, снижение потребления CPU. Подробнее – тут.

⏺Оптимизация работы с дашбордами
Fiveonefour Docs разобрали, как снизить нагрузку на базы OLTP и улучшить производительность дашбордов. В гайде автор описывает настройку CDC (Debezium, ClickPipes), репликацию данных и безопасный переход на ClickHouse без изменения логики. В статье также описан ИИ-workflow через MooseStack, где ассистенты (Claude Code, Cursor, Codex) работают с проверкой запросов и тестированием на локальном окружении, что ускоряет миграцию. Почитать – здесь, разобрать гайд – тут.

#devops #kubernetes #linux #новостнаяподборка

Сезоны сменяют друг друга, а наш дайджест выходит по расписанию.

👀Инцидент Trivy
1 марта зафиксировали атаку ИИ-бота: hackerbot-claw получил доступ к репозиториям в GitHub Actions. Пострадали несколько проектов Microsoft, DataDog и CNCF, а репозиторий Trivy был переименован в `aquasecurity/private-trivy `и вместо публичного кода был запушен пустой репо, массово удалены релизы, артефакты и обсуждения. Об инциденте – тут, а также в обсуждении.

⏺На GitLab вышел патч-релиз 18.9.1, 18.8.5, 18.7.5
В релизе представлены исправления для обеспечения безопасности. Включили защиту от CVE-2026-0752 в Mermaid, и несколько DoS уязвимостей в контейнерах, Jira и обработке merge request’ов (CVE-2025-14511, CVE-2026-1662, CVE-2026-1388). Также устранили проблемы при лимите запросов в импортере Bitbucket Server, создании переменных для CI джобов и контролем доступа в пакетных репозиториях. Обратите внимание при обновлении: на одиночных nod-ах переход займет время, ожидайте downtime, на на множественных – применяйте принцип zero-downtime. Подробнее – на GitHub.

⏺ Шон Вэбб отчитался о проделанной в феврале 2026 в HardenedBSD.
Большая часть времени ушла на расследование kernel crash в ветке 15-STABLE. Ожидаем новых сборок на этой неделе или в рамках обновления 1 апреля 2026. По проекту mesh-сетей (Meshtastic + Reticulum + HardenedBSD) ведется работа по созданию proof-of-concept. Также опубликовали скрипт на Python для exec-over-meshtastic. В части инфраструктурой разработки приняли решение о постепенной миграции части репозиториев с self-hosted GitLab в Radicle. Отчёт– здесь.

⏺На портале Percona вышел отчёт о серии уязвимостей, затрагивающих все версии Valkey.
Часть проблем исправлена в версиях valkey-server и valkey-bloom, поэтому мы настоятельно рекомендуем обновиться. Исправления затронули CVE-2025-67733, ошибки обработки символов null в скриптах Lua, CVE-2026-21864, некорректная обработка ошибок парсинга RDB в модулях, CVE-2026-21863, некорректной валидации пакетов в cluster bus и CVE-2026-27623, DoS перед аутентификацией.
Без обновления можете:
⁃ ограничить команды EVAL, EVALSHA, FCALL, RESTORE через ACL
⁃ изолировать cluster bus порт
⁃ проверить модули на корректную обработку IO-ошибок
Подробнее – здесь.

⏺Не мигрируйте, пока не ознакомитесь
В блоге Kubernetes описали поведение Ingress-NGINX, которое важно учитывать при миграции на Gateway API. Автор уточняет, что речь пойдет исключительно об этом контроллере, а не NGINX Ingress от F5. Из основных особенностей работа с префиксами regex в Ingress-NGINX, которые не учитывает регистр. При переносе может пострадать маршрутизация. Следующая особенность – use-regex влияет на все Ingress с теми же хостами. Если хотя бы один Ingress для хоста содержит use-regex: "true", все пути считываются как regex. В Gateway API exact остаётся exact. После миграции такие запросы начнут возвращать 404. Также в статье упоминают автоматические редиректы и нормализацию URL перед matching. Как безопасно переехать – указали тут.

#devops #gitlab #valkey #kubernetes #новостная_подборка

Хватит копипастить в YAML

👨‍💻В этот понедельник разбираем статью Джанлуки Марденте про управление кластерами Kubernetes с помощью Sveltos.

Традиционно команды сталкиваются с рассинхронизацией и ошибками при работе в оркестраторе. Возможные причины – копипаста в YAML и как следствие, перегрузка в чартах, ручной патчинг. Автор статьи предлагает следующее решение: централизованный «Intent» и Surgical Post-Processor, который определяет, что и куда деплоим.

Суть подхода в распределении: система определяет «Intent», затем автоматически ищет кластеры через метаданные и применяет точечные патчи для конкретных регионов. Все локальные настройки хранятся как «Policy Packets» и связываются с приложением только при деплое (концепция Late Binding). Основной инструмент в работе – Sveltos, набор контроллеров Kubernetes, которые работают в управляемом кластере. Он определяет патчи для каждого кластера и включает в YAML-манифест. В статье автор привёл пример на базе US- и EU-кластеров.

👀Важно: при ограничении инфраструктуры ДЦ и облаками, адаптируйте скрипты авторизации, endpoint-ы и политики безопасности.

Подробнее о подходе и кейсах — в статье.

#девопс #kubernetes

Наконец-то среда…

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

⏺Rust 1.94.0
Выкатили новую версию Rust, с поддержкой множества окон (array_windows). Поскольку каждое окно имеет тип &[T; N], его можно напрямую «разобрать» в параметрах, например |[a, b, c, d]|, и компилятор выведет значение автоматически. Данный метод оптимизирует работу с файлами, и оставляет ручную индексацию в прошлом. Также представили Include для включения файлов конфигураций Cargo. Подробнее – в документации. Наконец, в Rust 1.94.0 добавили поддержку TOML 1.1 для манифестов и конфигураций и стабилизировали API-шники для работы с инициализацией, константами и `const`-контекстом. Одно из заметных улучшений – более гибкий синтаксис inline-таблиц, новые цепочки escape и временные условия.
Если прошлую версию устанавливали через rustup, используйте $ rustup update stable или загляните в заметки. А почитать обо всём сразу – тут.

⏺FreeBSD 14.4
Команда анонсировала пятый релиз стабильной/14 ветки, посвященный памяти Кена Смита, бывшего руководителя команды Release Engineering. Изменения повлияют на деплой, автоматическую инициализацию и безопасность SSH. OpenZFS обновили до 2.2.9, что улучшит стабильность в хранении данных, nuageinit совместим с cloud-init для поддержки команд настройки сети, установки пакетов и записи файлов конфигурации. Дополнительно обновили системные инструменты, документацию и выкатили много контента. Версия поддерживается до 31 декабря 2026 года, а вся ветка 14.x – до ноября 2028 года. Подробнее о новой версии – читайте здесь.

⏺Патч-релиз nginx 1.29.6
В версии сосредоточились на багфиксах и улучшении стабильности работы с инструментом. Решили проблему с проксированием HTTP/2 с задействованным кэшем, улучшили обработку заголовков с разделителями и обработку ошибок keylog callback, исправили сборки BPF для новых версий Linux. Обновили README, советуем изучить – тут.

⏺Что делать с истекающим сроком TLS-сертификата?
На портале dev.to опубликовали статью с текущими реалиями поэтапного сокращения сроков сертификатов. Уже с 15 марта срок уменьшится с 398 дней до 200, затем 15 марта 2027 — до 100, а к 15 марта 2029 — до 47. С увеличением сервисом и доменов инструменты вроде Certbot или решения Kubernetes не всегда обеспечивают эффективное отслеживание. Командам не хватает централизованного управления: учёта, видимости цикла, оповещений и доступа к API для интеграции в CI/CD. В статье представлено авторское решение – KrakenKey, сервис управления сертификатами, прослойка над ACME. Подробнее – в статье.

⏺Безопасность в Kubernetes
В блоге CNCF разобрали проблему при работе с секретами Kubernetes. Часто образы «подтягиваются» из приватных зеркал и кеша, особенно в изолированных средах. Настройка аутентификации на уровне нодов усложняет управление кредами и создаёт риски для безопасности. Саша Грунерт предлагает следующее решение – настройка CRI-O Credential Provider, интегрированного с kubelet. Плагин динамически аутентифицирует данные из секретов, ограниченных по namespace, и создаёт временные файлы для CRI-O. Когда kubelet «подтягивает» образ, то передаёт плагину информацию о поде и образе. Такой подход сохраняет безопасность: под видит только свои namespace, доступ к чужим кредам ограничен. Подробнее – на портале.

#обновления #kubernetes #новостная_подборка

Дайджест в DevOps FM!

☀️Солнечная среда и свежие релизы. Что может быть лучше в середине рабочей недели?

⏺Весеннее обострение или атака в цепочке поставок.
На этот раз в PyPI нашли вредонос библиотеки LiteLLM. Были украдены API-ключи для подключения к OpenAI, Anthropic и другим провайдерам. Проблема коснулась SSH-ключей, конфигураций Kubernetes, Docker, токенов AWS, GCP, Azure, секретов непрерывной интеграции и доставки (CI/CD). Безопасная версия доступна с 22 марта. Атака – одна из серии от команды PCP. Если у вас были установлены версии LiteLLM 1.82.7 или 1.82.8, рекомендуем заменить API-ключи и проверить пайплайны в CI/CD.

Подробнее – на GitHub, а разбор мартовских атак от команды PCP – в блоге Wiz.

⏺Вы в зоне риска, если работали с aquasec/trivy, применяли теги версий 0.69.4, 0.69.5, or 0.69.6 или последней версии с 19 по 23 марта. В блоге Docker дали рекомендации для проверки окружения: найдите скомпрометированный образ Trivy по его digest’ам, удалите все затронутые образы, обновитесь до aquasec/trivy:0.69.3, а затем проведите полную ротацию секретов на всех системах, где этот образ мог работать.

Пошаговая инструкция – здесь.

⏺CNCF опубликовали отчёт за Q1: что нового?
Сообщество значительно приросло – с 15.6 до 19.9 миллионов, что составляет 28% за 6 месяцев. Облачный гибрид – самый популярный формат, 34% разработчиков включили его в рабочий цикл. Тенденция связана с новыми политиками регуляторов. Практики платформенной инженерии, инженерии хаоса и работы со множеством управляемых кластеров внедрили 88% разработчиков. В сфере ИИ до 7.3 миллионов специалистов работают в рамках подхода Cloud Native. Подробности – в отчёте.

⏺Выкатили релиз KubeVirt v1.8 с поддержкой Kubernetes v1.35. В нём улучшили политики конфиденциальности для работы с ВМ, представили прослойку Hypervisor Abstraction для работы со множественными уровнями системы виртуализации (бэкенды гипервизора) за пределами KVM, а так же включили ворклоады ИИ и HPC. Теперь KubeVirt лучше понимает, как устроены CPU, память и PCIe-устройства на хосте. Все обновления в SIG – в заметках о релизе и обзоре от CNCF.

⏺Дождались – Ingress2Gateway 1.0, ассистент при миграции. Основное изменение – поддержка более 30 аннотаций вместо 3 (CORS, TLS между балансировщиком, сопоставление с регулярным выражением (regex matching)). В Ingress2Gateway 1.0 улучшили форматирование и систему уведомлений. Теперь не нужно тратить время на поиск подводных камней и устранение ошибок в конфигах. Пошаговый туториал оставили – здесь.

⏺Kyverno, инструмент политики как кода, прошел все уровни ревью на GitHub. В честь "выпуска" Брайан Грант, СТО CofigHub-а, выкатил статью с описанием основных функций: ограничение ресурсов Kubernetes на примере запрета использования :latest тега, проверку политик и работу триггеров.
Всё интересное – здесь.

⏺DataDog описали архитектуру Karpenter, автоскейлера кластеров Kubernetes. Логика сервиса учитывает пропускную способность, оптимизирует потребление ресурсов и улучшает работу приложений. Речь идет о поддержке оптимизации NodePool-ум, агностическим провайдером, и учёте особенностей инфрастуктуры облачных окружений провайдером NodeClass.
Подробнее об инструменте наблюдаемости – тут.

#devops #инциденты #kubernetes #cncf #новостная_подборка

А у вас спина белая! Шутки шутками, а новостную среду никто не отменял.

⏺ В конце марта службы Kubernetes напомнили о выходе версии 1.36. Уже в следующем обновлении уберут поддержку параметра externalIPs, плагина gitRepo, улучшат работу с метками для снижения задержек запуска подов в SELinux-системах, улучшат передачу ServiceAccount токенов внешним системам. В конце апреля мы также получим поддержку меток taints и tolerations при динамическом распределении ресурсов по дефолту и работу с разделами устройств с делением на юниты.

⏺ Tekton достиг второй ступени зрелости CNCF. Проект Kubernetes – набор готовых инструментов открытого исходного кода для систем с комбинацией непрерывной интеграции и доставки (CI/CD). Tekton используется для построения, тестирования и развертывания в облаках или on-premise. Он работает внутри кластеров Kubernetes и в отличие от Jenkins, например, K8S от Tekton не нуждается в физическом сервере. Обо всех компонентах – читайте здесь.

⏺ Вышла первая часть о LLM в Kubernetes. CNCF рассказали об ограничениях: контейнеризатор просто следит за планированием и изоляцией рабочих процессов. При развертывании через Olama Kubernetes настроит все рабочие процессы, но не сможет определить тип информации, корректность промта или ограничить доступ к инструментам. В блоге привели целый фреймворк для понимания рисков настройки LLM.

⏺ В блоге AWS перечислили, какие ресурсы использовать для построения высокофункционирующих приложений. LMI предоставляет выбор типов инстансов и снижает операционную перегрузку. Всего представили три шага при билде: создание поставщика (с требованиями и конфигурацией для EC2), функции (с привязкой к поставщику) и публикация версии (развертывание на инстансах EC2). Больше советов и лучших практик от AWS – тут.

⏺ От ZAP (Chrome/Firefox/Edge) вышел туториал по установке дополнений к OWASP PTK 9.8.0. В улучшенной версии все находки отображаются как нативные оповещения, а сам сервис определяет риски. В PTK SAST фокус на работе внутренних и внешних скриптов страницы (eval, Function, небезопасное использование innerHTML, атак на DOM и пр). Подробнее о версии ZAP 0.3.0 читайте здесь.

#kubernetes #cncf #aws #новостная_подборка