DevOps через Git: насколько реально управлять всей инфраструктурой и deployment из Git?

Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.

Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение

OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.

Вместо привычного сценария:

> Зайди в AWS, поправь вот это.
> Потом сделай kubectl apply.
> А почему staging теперь отличается от production?

Получаем:

> Изменение инфраструктуры — commit.
> Изменение приложения — commit.
> Дальше автоматика сама приводит окружение к нужному состоянию.

И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.

Плюсы очевидны:
⏺меньше ручных действий;
⏺изменения проходят review;
⏺инфраструктура воспроизводима;
⏺rollback часто превращается в git revert;
⏺окружение можно восстановить из кода.

Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.

Отсюда возникают следующие вопросы:
⏺Что делать, если GitLab недоступен?
⏺Как внести emergency change?
⏺Кто имеет break-glass доступ?
⏺Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют?

И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬

Желаем продуктивной недели и спокойных дежурных смен!

Новостной дайджест от DevOps FM!

⌨️Делимся свежими новостями и релизами за прошедшую неделю.

⏺Kubeflow получил статус CNCF Graduated.

Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.

Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.

⏺AWS продолжает развивать Argo CD в EKS.

В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.

Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.

⏺IncidentRelay 2.0 — новый релиз self-hosted incident management.

Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.

IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.

⏺GitHub опубликовал разбор масштабного сбоя 17 августа.

Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.

Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.

Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.

#devops #инциденты #gitlab #kubeflow

Подборка интерактивных тренажеров для DevOps

⌨️ В эту пятницу собрали тренажеры, где можно на практике разбирать нетривиальные сценарии Kubernetes, networking и troubleshooting.

⏺ Deadnodes — тренировка в формате production-инцидента: получаем сломанное окружение, ищем root cause и восстанавливаем систему. Есть сценарии по Linux, Kubernetes, networking и базам данных.

⏺ iximiuz Labs — набор hands-on лабораториий с Linux, контейнерами и Kubernetes. Можно самостоятельно разбирать networking, container internals и troubleshooting-сценарии разной сложности.

⏺ Anycast и BGP — меняем маршруты и отключаем PoP, чтобы посмотреть, что происходит с трафиком и TCP-соединениями. Можно разобрать проблемы с long-lived connections и capacity при отказе части инфраструктуры.

⏺ Kubernetes Scheduler Simulator — практика работы с Filter/Score, resource requests, taints и tolerations. Можно посмотреть, почему Pod оказывается Pending, и сравнить стратегии размещения.

Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting.

Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях.

#девопс #тренажеры

А что, если AI посмотрит ваш Kubernetes?

AI-помощники для Kubernetes — уже далеко не новость.

Но становится интереснее, когда AI работает прямо в OpenShift Console и при включённом Cluster Interaction может получать актуальный контекст работающего кластера.

Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.

Собрали самое интересное 👇

1. Спросить вместо поиска по документации

Например:

How do I configure a custom ingress controller?

What are the prerequisite network requirements for setting up an OpenShift cluster?

Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.

2. Сгенерировать YAML

Можно попросить AI подготовить конфигурацию:

Generate a YAML file for a deployment running a basic NGINX server with 3 replicas.

Или:

Create a NetworkPolicy that limits traffic to pods in the production namespace.

Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.

3. Разобраться с проблемой

Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.

Например:

Why is my application pod stuck in ImagePullBackOff?

I am getting a CrashLoopBackOff error on my frontend pod. What is happening there?

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

4. Разобраться с виртуализацией

Для OpenShift Virtualization можно задавать вопросы вроде:

Is there a storage vMotion equivalent?

How do I import a VMware virtual machine into OpenShift Virtualization?

Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.

5. А теперь самое интересное — live-кластер

При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.

Например:

Show me all degraded pods running in the payment-processing namespace.

Are there any active security alerts or failed deployments on my cluster right now?

То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»

Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.

При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.


👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬

#DevOps #Kubernetes #OpenShift #AI

🔔Новостной дайджест от DevOps FM!

⏺ Вышел релиз Kubernetes 1.37.

В новой версии добавили 67 изменений: 16 функций перешли в Stable, 23 — в Beta, ещё 27 получили статус Alpha.

Среди основных изменений — переход Metrics API в Stable, обновления сетевых компонентов, поддержка Pod Certificates и Cluster Trust Bundles, а также изменения в kube-proxy и cgroup. Релиз также включает обновления и улучшения для безопасности, управления ресурсами и работы кластера.

Подробнее об изменениях Kubernetes рассказали в своем блоге.


⏺Боты создают 98% трафика на git.kernel.org и заставляют ограничивать сервис.

git.kernel.org получает около 6 млн запросов в день, и около 98% из них — боты, которые массово запрашивают страницы отдельных коммитов, создавая постоянную нагрузку на серверы.

На пяти серверах 14–16 из 90 CPU-ядер постоянно заняты обработкой этих запросов, в результате администраторы начали отключать ресурсоёмкие операции, ограничивать анонимный доступ и сокращать количество доступных для обхода ссылок.

Детали читайте в статье.


⏺Amazon завершила покупку DuckLabs, разработчика DuckDB.

Сделка была закрыта 31 августа. Команда DuckDB присоединяется к AWS, при этом проект продолжит развиваться под руководством своих основателей. AWS планирует использовать технологии DuckDB для развития своего аналитического стека.

Подробнее на OpenNET.


⏺Для Debian 11 завершилась официальная LTS-поддержка.

31 августа закончился период LTS для Debian 11 Bullseye. Для части пакетов и архитектур доступна Extended LTS от Freexian — она продлевает поддержку до 2031 года.

Подробнее на OpenNET.


⏺Debian завершил голосование по правилам использования AI.

Ранее мы писали о голосовании Debian по правилам использования генеративного AI. Теперь голосование завершено: проект выбрал вариант Responsible Generative AI Use.

Подробности читайте в статье.

#новостной_дайджест #devopsfm #kubernetes #debian

🔔 Друзья, 9 сентября — День тестировщика, и в этот день в Москве пройдет ежегодная конференция, посвященная обеспечению качества и надежности ИТ-систем.

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

Будет особенно интересно инженерам по нагрузочному тестированию, QA-лидам, DevOps и SRE-специалистам.

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

📍 Москва, 9 сентября
⌨️ Очно и онлайн

Подробности и регистрация на сайте.
И в канале конференции.

🎙️ На волне DevOps FM!

Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.

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

🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.

🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.

🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.

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

#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering

Platform Engineering 2.0: как меняется роль внутренней платформы

Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.

Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?

В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.

При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.


Что добавляется:

⏺AI становится ещё одним типом нагрузки

Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.

То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.

⏺Пользователей становится больше

Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.

Отсюда практический вопрос: можно ли пользоваться платформой программно?

Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.

⏺FinOps перемещается ближе к созданию ресурсов

Стоимость становится частью решения ещё до развёртывания.

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

⏺Безопасность уходит глубже в платформу

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

Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.

⏺Платформа становится модульной

Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.

По сути, архитектура начинает выглядеть так:

Developer / ML Engineer / Agent
↓
Platform APIs
↓
Identity / Policy / Cost
↓
Kubernetes / Cloud / GPU / AI

И здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.


В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.

Спросить себя:

→ Можем ли мы быстро выдать специализированный ресурс?

→ Можем ли мы сделать это через API?

→ Знаем ли стоимость до развёртывания?

→ Можем ли мы применять политики на уровне платформы?

→ Может ли автоматизация или агент работать с платформой без человека?

Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️

#DevOps #Platformengineering

🔔В эфире DevOps FM – срединедельный дайджест новостей!

🔊 NVIDIA договорилась о покупке Hugging Face за $12,93 млрд.

NVIDIA объявила о соглашении по покупке Hugging Face — платформы с open-source и open-weight AI-моделями. После сделки Hugging Face должна сохранить открытый и мультиоблачный подход.

Для NVIDIA это возможность усилить позиции не только в GPU, но и в инфраструктуре для разработки и запуска AI-моделей. Закрытие сделки ожидается в первой половине 2027 года.

Детали сделки можно прочитать в блоге NVIDIA.

🔊 В vm2 нашли критическую уязвимость с обходом sandbox и RCE.

GitLab Threat Research обнаружила уязвимость с максимальным CVSS 10.0 в популярной Node.js-библиотеке vm2. Она позволяет обойти изоляцию и получить полный доступ к хост-системе.

Проблема затрагивает версии 3.11.6 и ниже при включённом require.external. Исправление доступно в 3.11.7.

Подробности читайте в исследовании GitLab.

🔊 Google Cloud пережил четырёхчасовой сетевой сбой.

1 сентября в зоне us-central1-b произошёл серьёзный сбой, затронувший Compute Engine, GKE, Cloud Run, Cloud SQL и другие сервисы.

Причиной стала ошибка во время планового обслуживания: последовательно были отключены все оптоволоконные пути к части инфраструктуры, из-за чего часть VM в зоне потеряла сетевую связность. Сбой продолжался 4 часа 11 минут.

Подробности инцидента — в отчёте Google Cloud.

🔊 Karmada получил статус CNCF Graduated.

Karmada стал первым проектом CNCF для управления несколькими Kubernetes-кластерами, достигшим статуса Graduated.

Платформа позволяет управлять приложениями сразу в нескольких кластерах, облаках и регионах, а в последних версиях развивает механизмы планирования для распределённых AI-нагрузок.

Подробнее — на сайте CNCF.

#новостной_дайджест #devopsfm #karmada #security #cloud

Как LegalOn адаптирует Platform Engineering под AI-агентов ⌨️

Продолжаем тему Platform Engineering — сегодня разбираем кейс LegalOn Technologies от Signadot. LegalOn Technologies от Signadot.

У LegalOn около 200 инженеров, GKE, Argo CD и собственная платформа Akupara. С появлением AI-агентов узким местом всё чаще становится уже не создание кода, а его проверка и доставка.

Архитектуру они разделили на три части:

⏺Контекст

Каталог продуктов в YAML используется как источник данных для Terraform и агентов. На основе Terraform HCL и Kubernetes-конфигураций они строят граф знаний, доступный через MCP.

По данным LegalOn, это снизило потребление токенов примерно на 25%.

⏺Соединение с реальным окружением

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

Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление

⏺Изолированная среда

Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.

Но здесь меняется сама роль платформы.

Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура

то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура

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

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

#DevOps #PlatformEngineering #LegalOn

Как дать командам доступ к метрикам Kubernetes и не открыть весь Prometheus?

Всем DevOps!🖖 В прошлом посте мы разбирали, как LegalOn перестраивает платформу для AI-агентов: даёт им нужный контекст и доступ к окружению, но оставляет чёткие границы действий.

В свежем материале CNCF инженеры Adobe разбирают похожую задачу для наблюдаемости: как дать командам самостоятельный доступ к метрикам, не открывая весь общий Prometheus.

В многопользовательском Kubernetes командам нужны собственные запросы и оповещения, но общий Prometheus нельзя открыть всем: его API не изолирует запросы по пространствам имён, а множество произвольных запросов создаёт на него нагрузку.

В Adobe решили проблему через промежуточный слой:
команда → проверка прав → ограничение области данных → Prometheus

Этот слой ограничивает запросы данными своего пространства имён. А нужные метрики при необходимости можно дополнительно отправлять в отдельный Prometheus команды — для графиков и оповещений.

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

В кейсе Adobe это помогло найти GPU, который 11 дней был выделен, включен, но не использовался.

Как у вас устроен доступ команд к метрикам: общий Prometheus с изоляцией или отдельный для каждой команды? Делитесь опытом в комментариях💬

В эфире DevOps FM – срединедельный дайджест новостей!

⏺В Forgejo обнаружили критическую уязвимость с RCE и CVSS 9.9.

CVE-2026-89094 позволяет выполнить произвольный код при обработке специально подготовленного шаблонного репозитория. Проблема затрагивает версии Forgejo до 16.0.4.

Если Forgejo используется во внутренней Git-инфраструктуре, стоит проверить версию и обновиться.

Подробнее в статье OpenNET.

⏺Вышел Cilium 1.20 с новыми возможностями для сетей Kubernetes.

Обновили Gateway API до версии 1.6, добавили ExternalAuth, TCPRoute и UDPRoute, а также поддержку IPv6 в AWS ENI IPAM.

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

Больше об изменениях читайте в блоге CNCF.

⏺Исследователи показали способ подмены идентичности рабочей нагрузки в SPIFFE/SPIRE.

Получив root на узле, атакующий может подменить данные cgroup, которые агент SPIRE использует для определения рабочей нагрузки, и получить криптографический идентификатор другой нагрузки.

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

Подробнее — в исследовании Unit 42.

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

Масштаб повреждений оказался больше расчётного сценария отказа, поэтому часть ресурсов в Бахрейне и ОАЭ восстановить не удалось.

Часть клиентов перенесла нагрузки в другие регионы. Ещё один пример того, что резервирование между зонами доступности не защищает от сценариев, затрагивающих физическую инфраструктуру региона.

Детали читайте в Reuters.

#новостной_дайджест #devopsfm #kubernetes #security #cilium #aws

👩‍💻 Что нового в Kubernetes 1.37?

Бодрый DevOps! В эту пятницу разбираем свежие материалы команды Kubernetes о v1.37 Garhwal. Выбрали несколько изменений, о которых стоит почитать перед обновлением кластера.

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

Разбор масштабирования до нуля.

⏺Больше контроля над памятью.
Memory QoS перешёл в Beta. Kubernetes получает более точный контроль за потреблением памяти контейнерами.

Как работает новый механизм.

⏺Kubernetes без root.
Компоненты ноды теперь можно запускать от непривилегированного пользователя. Ещё один шаг к уменьшению привилегий в кластере.

Разбор rootless-режима.

⏺GPU и другие специализированные ресурсы.
DRA получил новые возможности для более гибкого распределения ресурсов — особенно актуально для кластеров с GPU.

Подробнее о DRA.

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

А если хочется погрузиться глубже — держите полный обзор изменений Kubernetes 1.37.

Желаем всем хороших выходных и спокойных дежурств!🛡

#девопс #kubernetes #пятничное_чтиво

Новостной дайджест от DevOps FM!

Делимся свежими новостями и важными изменениями в мире DevOps и инфраструктуры за прошедшую неделю.⌨️

⏺В KVM нашли уязвимость, позволяющую гостевой системе получить доступ к памяти хоста.

CVE-2026-89775 затрагивает ARM64-системы с включённой вложенной виртуализацией. При определённых условиях гостевая система может читать и записывать память ядра хоста.

Проблема появилась в Linux 6.16 и исправлена в версиях 6.18.51 и 7.2.5. Для дистрибутивов стоит проверить доступность исправлений.

Подробнее — в материале OpenNET.

⏺GitHub усилил защиту GitHub Actions.

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

Отдельные ограничения появились для pull_request_target: при неправильной настройке он может привести к выполнению недоверенного кода с доступом к секретам репозитория.

Читайте подробности в блоге GitHub.

⏺GitHub переводит ubuntu-latest на Ubuntu 26.04.

С 19 октября по 19 ноября GitHub начнёт поэтапно переводить ubuntu-latest с Ubuntu 24.04 на 26.04.

Для CI это означает изменение окружения без изменений в самих workflow: обновятся версии системных пакетов и предустановленных инструментов.

Если используется ubuntu-latest, GitHub рекомендует заранее проверить сборки на Ubuntu 26.04 или зафиксировать ubuntu-24.04.

Детали узнавайте в статье на GitHub.

⏺В Kubernetes 1.37 добавили отслеживание неиспользуемых PVC.

PersistentVolumeClaimUnusedSinceTime перешла в статус Beta и включена по умолчанию.

Теперь Kubernetes может помечать PVC как Unused, если его не использует ни один работающий Pod, и фиксировать время перехода в это состояние.

Это позволит находить давно неиспользуемые PVC и использовать эту информацию для последующей очистки.

Подробности — в блоге Kubernetes.

#новостной_дайджест #devopsfm #kubernetes #github #linux