У першому кварталі 2026 року CNCF Platform Engineering Technology Community Group (TCG) запустила оновлення двох основних документів:Офіційний документ щодо платформи як продуктуіМодель зрілості розробки платформи. Мета спільноти — випустити чернетку до KubeCon EU 2026 і включити безпеку інструментів ШІ в управління платформою. У той же час практична стаття, опублікована CNCF 29 травня 2026 року, дуже проста: сучасна доставка більше не обмежена кодом програми, а платформою, на якій вона розміщена. Для такої команди, як Wishes Niu Technology, яка займається індивідуальною корпоративною розробкою, це речення ближче до реальних проблемних точок, ніж «наймання ще двох серверних модулів» — дрейф середовища, ключі, записані в конвеєр, відкат на основі усних домовленостей і спостереження, щоб почекати, поки щось піде не так.
1. Спочатку демонтуйте три шари, а потім поговоріть про те, чи варто нам використовувати K8?
Наведена вище практика CNCF поділяє платформу наРівень інфраструктури, рівень платформи, рівень додатків, і чітке попередження: якщо три шари помістити на той самий склад занадто рано, подальші витрати на технічне обслуговування різко зростуть. Рівень інфраструктури відповідає за мережу, кластери, дзеркальні сховища та ключові бази; рівень платформи надає контролери GitOps, політики, сервісні мережі та спостережувані компоненти; прикладний рівень — це бізнес-мікросервіси клієнта. Найпоширенішою помилкою в проектах налаштування є написання бізнес-коду клієнта, сценаріїв Jenkins і параметрів кластера в одному документі. В результаті весь склад повинен бути змінений при зміні середовища.
1.1 Малі та середні команди не повинні копіювати список інструментів великих виробників
У тій самій статті також визнається, що передчасне стекування інструментів, що перекриваються, є типовою пасткою в екосистемі CNCF. Istio, OpenTelemetry та багатокластерний ApplicationSet можна встановити після встановлення. Для користувальницьких проектів із піврічним циклом доставки більш прагматичний мінімальний набір: визначення середовища, яке можна відтворити, конвеєр збірки зі скануванням і підписом, а також метод випуску, який розглядає Git як єдину істину. Без цих трьох речей так звана «трансформація мікросервісу» просто розбиває моноліт на купу процесів, які копіюють конфігурації один одного.
2. Ставтеся до платформи як до продукту, а не до набору сценаріїв експлуатації та обслуговування
CNCF пише розробку платформи як «Платформа як продукт». Суть полягає не в тому, щоб купити ще один набір порталів, а в тому, щобВнутрішні розробники як клієнти. Одним із ключових моментів перегляду білої книги та моделі зрілості 2026 року є додавання реальних сценаріїв, щоб організації могли оцінити, на якому рівні вони перебувають, і змінити лише одне на наступному кроці. Якщо спеціалізоване програмне забезпечення збирає Jenkins з нуля, пише Dockerfile з нуля та подає заявку на тестову бібліотеку з нуля для кожного проекту, цикл доставки буде з’їдений «дубльованим податком на оплату праці». Перша мета внутрішньої платформи розробки (IDP) — забезпечити золотий шлях для подібних проектів: створити сховище, подати заявку на середовище, запустити тестування, переглянути та опублікувати. Розробники лише заповнюють бізнес-розбіжності.
- Декларативна інфраструктура: Навколишнє середовище можна реконструювати, замість того, щоб «тільки Лао Ван може сісти на цю машину».
- Безперервне узгодження GitOps: статус кластера залежить від Git, і вручну kubectl, внесені до виробництва, потрібно відновити.
-
Ланцюжок поставок увімкнено за замовчуванням: сканування залежностей, підписування зображень, заборона
latestТеги, перехоплені перед входом у кластер. - Спостережливість — це здатність платформи: індикатори, журнали та сигнали тривоги надаються за золотим шляхом, замість додавання набору після виходу в Інтернет.
3. Безпеку ланцюжка поставок потрібно перенести на «до розгортання»
Практика IDP CNCF розділяє будівництво, перевірку безпеки та зміни інфраструктури в незалежні трубопроводи. Конвеєр додатків відповідає за компіляцію, модульне тестування, SAST, сканування Trivy на наявність залежностей і підписання Cosign перед входом у склад; конвеєр безпеки повторно перевіряє підписи, сканує зображення та використовує KubeSec для перегляду маніфесту; лише після передачі коду контролеру GitOps дозволено синхронізуватися. Їхні спостереження у внутрішньому експериментальному середовищі такі: рівень успіху розгортання зріс з приблизно 70% у ручних процесах до приблизно 95%, підготовка інфраструктури скоротилася з годин до менш ніж 15 хвилин, і близько 80% виявлення вразливостей можна запобігти до початку виробництва. Ці цифри отримано з лабораторії та попередньої версії, і їх неможливо безпосередньо вписати в зобов’язання клієнтів, але напрямок зрозумілий——Змініть верифікацію з «людей, які дивляться на екран» на «відмову з конвеєра»。
| рівень | Можливості платформи | Що відповідає індивідуальному проекту? | Не робіть цього відразу |
|---|---|---|---|
| інфраструктура | Мережа, кластер, склад, ключ | Три комплекти баз для тестування клієнтом/попереднього випуску/виробництва | Змініть групу безпеки вручну, не записуючи код |
| платформа | GitOps, стратегія, спостереження | Уніфікований випуск, уніфікований відкат і уніфікований сигнал | Кожен проект будує власну філософію Дженкінса |
| додаток | Незалежно опубліковані бізнес-послуги | Замовлення, інвентаризація, затвердження та інші модулі клієнтів | Помістіть ключ і бізнес-код на одне зображення |
| управління | Підписи, правила прийому, аудит | Пункти про безпеку та приймання в контрактах можна перевірити машиною | Усно домовтеся «сканувати ще раз перед виходом в Інтернет» |
4. Послідовність посадки для групи налаштування
Моделі зрілості наголошують на практичних наступних кроках, а не на купівлі порталу відразу. Wishing Niu Technology рекомендує прорізати найвужчий золотий шлях відповідно до типу проекту: наприклад, «Сервіс Java + MySQL + сховище об’єктів» слід спочатку пройти, а потім розширити до інтерфейсу та черги повідомлень. Стратегії доступу, такі як Kyverno, надають пріоритет лише перехопленнюlatestКлавіші віддзеркалення та відкритого тексту; Istio суворо дотримується mTLS і не має бути універсальним для всіх кластерів. Як написано в практичній статті, надто раннє ввімкнення Strict призведе до відключення всіх служб без побічних колясок. Правильний підхід полягає в тому, щоб спочатку бути Permissive, а потім вирізати за простором імен.
- Спочатку заморозьте набір модулів середовища (мережа, обчислення, ключ) і використовуйте файли змінних, щоб розрізняти розробку/попередню версію/виробництво.
- Потім перетворіть продукт збірки на «перевіряний артефакт»: лише коли номер версії, звіт про сканування та підпис буде записано, його можна буде попередньо випустити.
- Тоді нехай Git стане порталом випуску, а відкат дорівнює відкату коміту, а не входу в систему для перезапису файлу.
- Останній крок — створення порталу самообслуговування. Без перших трьох кроків портал – це просто хаос, загорнутий у кнопки.
Розробка платформи полягає не в тому, щоб зробити спеціальні проекти «схожими на хмарні». Що він хоче вирішити: друга поставка системи такого ж типу не повинна бути повільнішою за першу. Якщо ви оцінюєте групу паралельних корпоративних систем, спочатку підрахуйте, скільки годин команда витрачає щотижня на «очікування середовища, виправлення конфігурації, вгадування, хто її змінив», а потім вирішіть, з якої лінії бізнесу слід відрізати золотий шлях. Це легше прийняти на наступному етапі, ніж спочатку намалювати грандіозний план середньої стадії.