MemOps 😃

Ingress-nginx уходит в прошлое. С марта 2026 поддержка прекратилась. А что вместо него? Предлагаем посмотреть на Gateway API, новый стандарт Kubernetes SIG.

23 июля в 17:00 старший SRE-инженер MWS Cloud Евгений Макеев на практике покажет:

⚫️ чем маршрутизация Gateway API отличается от Ingress
⚫️ как выбрать контроллер
⚫️ как установить Gateway API в Managed Kubernetes
⚫️ как настроить безопасное подключение через TLS-сертификат

Будет полезно для DevOps, платформенным инженерам и разработчикам.

Регистрируйтесь по ссылке

ownCloud Infinite Scale (oCIS) — новая платформа для синхронизации и обмена файлами, которая станет основой вашей платформы управления данными.

Infinite Scale - это облачная микросервисная архитектура и серверные приложения последнего поколения. Она не зависит от внешних программных пакетов, таких как PHP или базы данных, что устраняет все сложности, связанные с их использованием. Благодаря своей современной архитектуре, Infinite Scale предоставляет все модели развертывания для облачной инфраструктуры и оптимизированные настройки масштабирования для достижения наилучших результатов при минимальных затратах. Концепция единого бинарного файла значительно упрощает управление сервером по сравнению с любыми другими методами развертывания.

Infinite Scale поддерживает следующие клиенты ownCloud:
- веб
- Android
- iOS
- Рабочий стол

Для синхронизации и совместного использования файловых пространств с масштабируемой серверной частью на базе Reva с использованием открытых и хорошо определенных API, таких как WebDAV и CS3.

Infinite Scale ориентирован на простоту установки и эксплуатации и поставляется в виде единого исполняемого файла или контейнера, позволяющего масштабировать систему от Raspberry Pi до кластера Kubernetes путем изменения конфигурации и запуска нескольких сервисов по мере необходимости. Мультисервисная архитектура позволяет адаптировать функциональность под ваши потребности и повторно использовать уже существующие сервисы, например, при использовании Keycloak.

📌 Подробнее: https://github.com/owncloud/ocis

MemOps 🤨

SnapScheduler — контроллер Kubernetes, который автоматически создает снапшоты PVC (PersistentVolumeClaim) по расписанию, используя встроенный механизм VolumeSnapshot. Он не зависит от CSI-драйвера, пока тот поддерживает VolumeSnapshot, и работает с любым сторедж-классом, поддерживающим снапшоты.

Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.

Как это работает:
Вы создаете ресурс SnapshotSchedule, в котором указываете:
- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает VolumeSnapshot объекты автоматически.

Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом snapshot=true, и хранить максимум 5 последних.

📌 Подробнее: https://github.com/backube/snapscheduler

MemOps 🤨

4 MCP-сервера, о которых стоит знать каждому DevOps-инженеру

1. Kubernetes MCP
- расследовать pod’ы в CrashLoopBackOff;
- дебажить неудачные деплои;
- анализировать состояние кластера.

https://github.com/Flux159/mcp-server-kubernetes

2. AWS MCP
- разбирать резкие скачки расходов в AWS;
- находить неиспользуемые ресурсы;
- troubleshooting облачной инфраструктуры.

https://github.com/awslabs/mcp

3. Terraform MCP
- проверять Terraform-планы;
- находить drift в инфраструктуре;
- объяснять изменения в инфраструктуре.

https://github.com/hashicorp/terraform-mcp-server

4. Grafana + Prometheus MCP
- расследовать скачки latency;
- анализировать production-инциденты;
- объяснять alert storms.

https://github.com/grafana/mcp-grafana
https://github.com/pab1it0/prometheus-mcp-server

MemOps 🤨

MemOps 😃

Кто работает, когда ничего не работает: от алерта до постмортема

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

Когда 20 ноября 2025 года из-за ошибки в конфигурации одного коммутатора отказала дисковая подсистема всей платформы, пятьдесят наших клиентов одновременно открыли тикеты. В этот момент выяснилось главное: техническая проблема была одна, а коммуникационных — десятки. Инцидент в инфраструктуре можно устранить за часы; инцидент доверия, если им не управлять, длится гораздо дольше. Именно поэтому зрелая поддержка — это не инженер за терминалом, а параллельно работающая система: одни чинят, другие в этот момент разговаривают с бизнесом клиента.

📌 Подробнее: https://habr.com/ru/companies/k2tech/articles/1054620/

MemOps 🤨

MemOps 😃

Новая конвертация из CPU Shares cgroup v1 в CPU Weight v2

Я рад объявить о реализации улучшенной формулы конвертации из CPU shares cgroup v1 в CPU weight cgroup v2. Это улучшение решает критические проблемы с распределением приоритетов CPU для рабочих нагрузок Kubernetes при запуске на системах с cgroup v2.

📌 Подробнее: https://kubernetes.io/blog/2026/01/30/new-cgroup-v1-to-v2-cpu-conversion-formula

MemOps 🤨

MemOps 😃

kubecfg — менеджер конфигурации Kubernetes для тех, кто часто переключает контексты и нуждается в большем, чем просто тонкая обертка вокруг kubectl config.

📌 Подробнее: https://github.com/kadirbelkuyu/kubecfg

MemOps 🤨

MemOps 😃

Удаленное выполнение кода в Kubernetes через узлы/прокси GET Permission

В этом посте я опишу, как выполнять код на каждом Pod во многих кластерах Kubernetes при использовании учетной записи службы с разрешениями nodes/proxy GET. Эта проблема была первоначально сообщена через процесс раскрытия уязвимостей Kubernetes и закрыта как работающая по назначению.

📌 Подробнее: https://grahamhelton.com/blog/nodes-proxy-rce

MemOps 🤨

Аетос: От хаоса к инженерному совершенству — 3-летняя трансформация

Как мы трансформировали производительность инженерии, построив Платформу внутреннего разработчика (IDP), которая теперь обрабатывает ~50 млн API-вызовов в день, управляет 14 000 ВМ и обеспечивает 80+ релизов в год, и чему вы можете научиться из нашего пути.

📌 Подробнее: https://medium.com/@charudatha/aet%C3%B2s-from-chaos-to-engineering-excellence-a-3-year-transformation-51a3f778678a

MemOps 🤨

MemOps 😃