Кожна нова хмара в компанії зазвичай означає ще один набір Terraform, ще одну інструкцію з деплою і ще один спосіб зробити все по-своєму. Витрати ростуть швидше, ніж кількість провайдерів. Platform engineering дозволяє розірвати цю залежність: golden path стає інтерфейсом, а конкретна хмара — реалізацією. Розробник описує, що йому потрібно — сервіс і production-база даних — а платформа сама вирішує, як це виглядає у гіперскейлері, а як у локального провайдера. У живому демо розробник створює новий сервіс через портал самообслуговування. Один шаблон, один Kubernetes-маніфест — і застосунок розгортається у двох хмарах одночасно. Однакова заявка на PostgreSQL в одній хмарі стає керованим сервісом бази даних, в іншій — базою під управлінням оператора в Kubernetes. Окремо — про межі підходу: IAM, сторедж і бекапи абстракція не приховує, і я покажу, чому це нормально. Після доповіді ви знатимете, як влаштований патерн «заявка → композиція» для баз даних у різних хмарах, з чого почати свій перший golden path без побудови власного PaaS, і які відмінності між хмарами варто показувати розробникам явно.

Практико-орієнтована архітектурна доповідь про інтеграцію AI-агента в операційний workflow highload data pipeline. Розглянемо сценарій каскадного збою: у пайплайн потрапляють пошкоджені дані, зависають черги Kafka, зростає навантаження на storage, тисячі Kubernetes pod’ів починають падати та пересоздаватися, деградує etcd, а PostgreSQL стає додатковою точкою навантаження. Також покажемо, як AI-агент, побудований на базі AWS Bedrock AgentCore, LangChain та MCP/Gateway, може виявляти ранні сигнали інцидентів, ізолювати corrupted messages, пропонувати human-approved remediation steps, захищати стабільність кластера та перетворювати noisy telemetry на конкретні кроки для відновлення системи.

У цій доповіді ми розглянемо практичний кейс впровадження ефективного автоскейлінгу інфраструктури з використанням HPA, VPA та Cluster Autoscaler. Працюючи зі стандартним VPA, ми зіткнулися з обмеженнями: нестачею гнучкості в налаштуванні інтервалів обчислення та конфліктами при одночасній роботі з HPA. Тому ми вирішили створити власний кастомний VPA-контролер. У новому рішенні ми: - Забезпечили коректну спільну роботу VPA та HPA на одних і тих самих ресурсах. - Реалізували механізм фільтрації короткочасних піків CPU на етапі запуску подів. - Оптимізували архітектуру: об'єднали функціонал трьох стандартних компонентів у єдиний под. - Використали нові можливості In-Place Pod Resize, які з'явилися у Kubernetes 1.33. Головний результат: оптимізація споживання ресурсів та зменшення вартості інфраструктури на 20–40%.

Це історія про реальний біль і дорослішання системи логування. Ми подивимось, як відсутність стандартів ламають observability. Я покажу, чому Kubernetes став точкою неповернення і змусив нас переглянути підхід до логів. Розберемо вимоги та архітектурні рішення, які дозволили повернути контроль. Поділюсь практичним досвідом побудови керованих лог-пайплайнів без магії і “чарівних інструментів”. Це чесна історія з продакшну.

Ця доповідь присвячена практичному досвіду переходу з класичної Istio-архітектури з sidecar-контейнерами на нову модель — Istio Ambient Mesh. Ми розповімо, як масштабування мікросервісної інфраструктури на Kubernetes призвело до зростання витрат на ресурси, ускладнення CI/CD та затримок у запуску сервісів. Пошук рішень привів нас до впровадження Ambient Mesh — архітектури без sidecar-контейнерів, яка значно спрощує mesh-інтеграцію і знижує інфраструктурні витрати. У доповіді буде детально розглянуто технічні аспекти міграції: як ми готувалися до переходу, які виклики виникали у процесі впровадження та як вдалося їх подолати у співпраці зі спільнотою Istio. Поділимось результатами, аналітикою, реальними метриками до/після та дамо практичні поради командам, які планують впровадження Ambient Mesh у production.

Коли на карту поставлена людська безпека, технічна надійність — не просто вимога. У цій доповіді розглянемо архітектуру, навантаження, WebSocket-рішення, масштабування Kubernetes та інші технічні аспекти створення карти повітряних тривог. Це історія не тільки про код, а й про відповідальність.

Kubernetes Controllers and Operators are a trending topic in conferences, interviews, and production today. I will share the story of the evolution of our Promotion (Release) system, from simple Kubernetes API REST calls to Informers and Controllers, based on my own experience. This story is particularly interesting because it serves as a great case for personal growth for you as well as for your DevOps/SRE team. It touches on Kubernetes architecture details, Networking, GitOps, IaC, Caching, development patterns, and Golang data structures. Even if you have no development experience (as is the case for most of our team), I will share how a Cursor AI assistant became yet another — though virtual — engineer on our team. Bonus: 10 years of Kubernetes & trends KubeCon24 North America.

There are many opinions regarding the deployment of databases in Kubernetes. However, the strong views of random individuals may not assist you in making the right decision for your specific situation. In this talk, you will receive a comprehensive list of problems and questions to address before moving your production database into Kubernetes. With that list, you will gain a better understanding of the associated risks, prepare for potential failures, and make an informed decision.

На конференції я представлю підхід до розширення можливостей Kubernetes, перетворюючи його на повноцінний приватний Cloud із підтримкою віртуалізації, ізольованих мереж та мультиорганізаційної аутентифікації.

Існує багато думок щодо розгортання баз даних у Kubernetes. Однак сильні переконання випадкових осіб можуть не допомогти вам ухвалити правильне рішення для вашої конкретної ситуації. У цій доповіді ви отримаєте вичерпний список проблем та питань, які варто врахувати перед перенесенням вашої продакшн-бази даних у Kubernetes. Завдяки цьому списку ви краще зрозумієте пов’язані ризики, підготуєтеся до потенційних збоїв та ухвалите обґрунтоване рішення.