Модуль 3.10: Зелені обчислення та сталий розвиток

Складність: [QUICK] — рівень обізнаності та прикладного аналізу Час на проходження: 45–60 хвилин Передумови: Модуль 3.1 (Принципи Cloud Native), Модуль 3.2 (Екосистема CNCF), базові запити та ліміти ресурсів Kubernetes, а також уміння переглядати об’єкти Kubernetes за допомогою kubectl або його поширеного псевдоніма k.

Результати навчання

Після завершення цього модуля ви зможете:

Аналізувати, як запити ресурсів Kubernetes, неактивні репліки та утилізація вузлів перетворюються на фінансові втрати й вуглецевий слід.
Діагностувати поширені проблеми сталості у хмарних робочих навантаженнях, зокрема надмірне виділення ресурсів, зомбі-навантаження та неправильно застосоване вуглецево-обізнане планування.
Порівнювати правильне визначення розміру (right-sizing), автомасштабування, масштабування до нуля, спотові потужності та вуглецево-обізнане планування для різних типів навантажень.
Оцінювати, коли рішення GreenOps узгоджуються з цілями FinOps, а коли надійність, затримка або вимоги щодо резидентності даних обмежують екологічніший варіант.
Проєктувати практичний план покращення для робочого навантаження Kubernetes, спираючись на вимірювані сигнали сталості та безпечні операційні запобіжники.

Чому цей модуль важливий

Платформного інженера просять переглянути місячний рахунок за хмару після того, як продуктова команда поскаржилася, що рахунок подвоївся, хоча трафік майже не змінився. Перший дашборд показує гроші, а не вуглець, але патерн знайомий: три непродакшн-середовища досі працюють після того, як проєкт скасували, кілька сервісів запитують значно більше CPU, ніж використовують, а нічні задачі всі стартують під час того самого регіонального піку попиту. З погляду користувача нічого явно не зламано, проте платформа марнує електроенергію щогодини.

Це не вигадана управлінська історія. У 2022 році компанія 37signals публічно описала, як витрачала значно понад пів мільйона доларів на рік на хмарну інфраструктуру, перш ніж вирішила, що економіка більше не відповідає роботі, яку вона виконувала. Її відповіддю стало масштабніше рішення про репатріацію, а не вправа з тюнінгу Kubernetes, але урок чітко лягає для операторів кластерів: коли інфраструктура зростає без щільного зворотного зв’язку, марнотратство стає бізнес-проблемою задовго до того, як хтось матиме досконалу вуглецеву модель. Менша компанія може побачити той самий патерн як несподіваний п’ятизначний рахунок; більша компанія може побачити його як господарство середовищ, що простоюють, продубльованих сервісів і зарезервованих потужностей, за прибирання яких жодна команда не почувається особисто відповідальною.

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

Саме тому зелені обчислення належать до навчальної програми з Kubernetes. Cloud native системи спрощують створення більшої кількості навантажень, реплік, регіонів та автоматизації, але ті самі механізми можуть як зменшити марнотратство, так і примножити його. Контейнери покращують щільність лише тоді, коли запити ресурсів реалістичні. Автомасштабування зменшує незавантажені потужності лише тоді, коли його налаштовано на корисний сигнал. Вуглецево-обізнане планування допомагає лише тоді, коли навантаження справді може переміститися в часі або просторі.

Для KCNA мета не в тому, щоб зробити з вас спеціаліста з вуглецевого обліку. Мета — навчитися розпізнавати сталість як інженерну властивість, що з’являється під час архітектурних оглядів, планування потужностей, рішень про планування та операційних дашбордів. Сильний новачок може назвати практики зелених обчислень; сильніший практик може поглянути на навантаження й вирішити, яка практика є безпечною, вимірюваною і вартою застосування першою.

Робочий принцип цього модуля простий: найзеленіше обчислення — це обчислення, яке вам не потрібно виконувати. Спершу вимірюйте, далі усувайте марнотратство, а потім оптимізуйте роботу, яка має лишитися. Цей порядок запобігає двом поширеним невдачам: купівлі модного інструмента сталості, поки очевидно невикористані ресурси продовжують працювати, або сліпому урізанню ресурсів, що створює інциденти з надійністю й руйнує довіру до всієї програми.

Від хмарного марнотратства до вуглецевого впливу

Перший крок — пов’язати буденне рішення Kubernetes з екологічним наслідком. Коли Под запитує CPU та пам’ять, Kubernetes резервує потужності для цього Пода під час планування. Якщо Под запитує значно більше, ніж використовує, кластер може потребувати додаткових вузлів, навіть якщо реальне навантаження застосунку помістилося б на меншій кількості машин. Ці машини все одно споживають енергію, виділяють тепло, потребують охолодження і зрештою долучаються до циклів заміни обладнання.

┌────────────────────────────────────────────────────────────────────────────┐
│                    ВІД ЗАПИТУ РЕСУРСІВ ДО ВУГЛЕЦЕВОГО ВПЛИВУ               │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Розробник задає запити:                                                   │
│                                                                            │
│      cpu: "2"                                                              │
│      memory: "4Gi"                                                         │
│                                                                            │
│                         │                                                  │
│                         ▼                                                  │
│                                                                            │
│  Планувальник Kubernetes резервує потужності, навіть якщо реальне          │
│  використання нижче:                                                       │
│                                                                            │
│      запитано CPU:   2.0 ядра                                             │
│      спостережено CPU: 0.2 ядра                                           │
│      невикористаний резерв: 1.8 ядра                                      │
│                                                                            │
│                         │                                                  │
│                         ▼                                                  │
│                                                                            │
│  Автомасштабувальник кластера може тримати онлайн більше вузлів,           │
│  ніж потребує навантаження:                                               │
│                                                                            │
│      більше увімкнених серверів → більше охолодження → більше викидів      │
│      більший попит на обладнання → більше викидів від виробництва й утиліз.│
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Операційні викиди виникають від роботи системи: електроенергія для обчислень, зберігання, мережі та охолодження. Втілені (embodied) викиди виникають від виробництва, доставки, обслуговування й утилізації обладнання. Команди Kubernetes найбезпосередніше впливають на операційні викиди день у день, але їхні рішення також впливають на втілені викиди з часом, бо погана утилізація заохочує організації купувати чи орендувати більше обладнання, ніж потрібно.

Cloud native може зробити це краще. Добре керована платформа може щільно упаковувати навантаження, зменшувати кількість реплік, коли трафік падає, прибирати тестові середовища, що простоюють, та зміщувати відкладні задачі подалі від «брудніших» вікон мережі. Cloud native може зробити це й гірше. Розростання мікросервісів, накладні витрати сайдкарів, завеликі запити та забуті простори імен можуть створити сотні дрібних витрат, яких жодна окрема команда не помічає, доки сукупний рахунок і вуглецевий слід не стануть великими.

Cloud Native патерн	Як він може зменшити марнотратство	Як він може збільшити марнотратство
Контейнери	Вища щільність навантажень може зменшити кількість активних вузлів.	Погані запити можуть резервувати невикористані потужності й блокувати упаковку.
Автомасштабування	Репліки та вузли можуть зменшуватися, коли попит падає.	Хибні сигнали масштабування можуть додавати репліки без покращення якості сервісу.
Мікросервіси	Кожен компонент може масштабуватися незалежно за власним попитом.	Забагато постійно увімкнених сервісів і сайдкарів додають базові накладні витрати.
Мультирегіональний дизайн	Навантаження можуть наближатися до користувачів або до чистішої електроенергії.	Дубльовані активні стеки можуть працювати всюди навіть за малого трафіку.
Пакетна автоматизація	Задачі можуть виконуватися в дешевші чи чистіші періоди, коли дедлайни дозволяють.	Неконтрольовані задачі можуть стартувати разом і створювати уникні піки потужностей.

Підказка для активного навчання: Уявіть, що дві команди кожна запускають дашборд, який отримує мало трафіку. Команда A запускає одну репліку з реалістичними запитами. Команда B запускає три репліки із запитами CPU, удесятеро вищими за спостережуване використання. Перш ніж читати далі, вирішіть, яка команда створює більшу проблему планування і чому відповідь стосується зарезервованих потужностей, а не лише поточного використання CPU.

Важливий ментальний зсув полягає в тому, що сталість не є чимось окремим від хороших операцій. Кластер із реалістичними запитами, корисним автомасштабуванням і регулярним прибиранням зазвичай коштує менше й викидає менше. Складність не в тому, щоб повірити, що марнотратство — це погано; складність у тому, щоб обрати покращення, яке не зламає надійність, не приховає ризик і не перенесе викиди в інше місце.

Корисний спосіб перевірити цю ідею — запитати, чи навантаження виконує цінну роботу, резервує потужності для можливої роботи, чи просто існує, бо ніхто його не прибрав. Це різні проблеми. Цінна робота може потребувати ефективнішого дизайну, як-от краще кешування, черги або вибір обладнання. Зарезервовані потужності можуть потребувати правильного визначення розміру, автомасштабування чи змін у плануванні. Забута робота потребує власника та прибирання. Сприйняття всіх трьох як однієї «вуглецевої проблеми» веде до розпливчастих порад; їх розділення дає інженерам конкретний наступний крок.

Існує також межа того, що Kubernetes може вирішити. Kubernetes може покращити розміщення, масштабування, спостережуваність і політики, але сам по собі не робить неефективний код застосунку ефективним. Сервіс, який виконує марнотратні повторні спроби, повертає величезні відповіді або без потреби переобчислює дорогі звіти, все одно спалюватиме енергію на ідеально налаштованому кластері. Тому зелені обчислення охоплюють кілька рівнів: дизайн застосунку зменшує обсяг роботи, Kubernetes зменшує невикористані резерви й погане розміщення, а вибір інфраструктури впливає на енергетичний профіль роботи, що лишилася.

Контекст сталості CNCF

Спільнота CNCF розглядає екологічну сталість як cloud native проблему, бо cloud native інструменти вирішують, де працюють навантаження, скільки існує реплік, скільки інфраструктури зарезервовано і яку телеметрію бачать оператори. CNCF TAG Environmental Sustainability підтримує ініціативи, пов’язані з побудовою, розгортанням, керуванням та експлуатацією cloud native застосунків із меншим екологічним впливом. Це спільнотна група, а не чарівний продукт, і її цінність походить зі спільних рекомендацій, робочих груп, ландшафтів та співпраці між проєктами.

┌────────────────────────────────────────────────────────────────────────────┐
│                  КОНТЕКСТ ЕКОЛОГІЧНОЇ СТАЛОСТІ CNCF                        │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  CNCF TAG Environmental Sustainability                                     │
│                                                                            │
│      ├─ Просуває сталі cloud native практики                                │
│      ├─ Підтримує проєкти та ініціативи в екосистемі                        │
│      ├─ Допомагає оцінювати підходи та інструменти сталості                 │
│      ├─ Публікує матеріали ландшафту та рекомендації спільноти              │
│      └─ Об'єднує практиків через зустрічі, репозиторії та Slack             │
│                                                                            │
│  Типові інженерні запитання                                                │
│                                                                            │
│      ├─ Чи може це навантаження безпечно працювати на менших ресурсах?      │
│      ├─ Чи може ця пакетна задача працювати, коли мережа чистіша?           │
│      ├─ Чи може цей сервіс переїхати в чистіший регіон без шкоди користув.? │
│      ├─ Чи можемо ми приписати енергоспоживання командам, простор. чи навант.?│
│      └─ Чи можуть типові налаштування платформи запобігти марнотр. до prod?  │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Це важливо, бо сталість потребує спільної мови. Якщо одна команда говорить лише про вартість, інша лише про вуглець, а ще одна лише про продуктивність, вони можуть проґавити той факт, що багато перших дій ідентичні. Правильне визначення розміру, прибирання, масштабування до нуля та краще планування зазвичай покращують більш ніж одну ціль. Конфлікт з’являється пізніше, коли екологічніший варіант має ціну у вигляді затримки, доступності, відповідності вимогам або міграції.

Екосистема CNCF також охоплює проєкти та суміжні інструменти, що допомагають командам вимірювати й діяти. Kepler вимірює пов’язані з енергією сигнали навантажень і експортує метрики Prometheus. KEDA та Knative можуть підтримувати кероване подіями масштабування й патерни масштабування до нуля. Goldilocks використовує дані Vertical Pod Autoscaler, щоб рекомендувати налаштування ресурсів. Carbon Aware SDK від Green Software Foundation може допомогти застосункам і автоматизації обирати чистіший час чи розташування, коли навантаження достатньо гнучкі.

Сфера спільноти	Запитання практика	Приклад інструмента чи практики
Вимірювання	Яке навантаження відповідальне за енергоспоживання?	Kepler, Prometheus, Grafana, хмарні вуглецеві звіти
Right-sizing	Чи близькі запити та ліміти до реального використання?	Рекомендації VPA, Goldilocks, огляди використання
Масштабування	Чи можуть репліки або вузли безпечно зменшуватися, коли попит падає?	HPA, KEDA, Knative, Cluster Autoscaler
Планування	Чи може гнучка робота виконуватися в чистіший час або місце?	Вуглецево-обізнане планування, пакетні черги, регіональне розміщення
Урядування	Чи можуть команди робити сталі типові налаштування повторюваними?	Політики платформи, шаблони сервісів, чек-листи оглядів

Для KCNA запам’ятайте форму екосистеми, а не зазубрюйте назву кожного проєкту. Патерн такий: вимірювання, усунення марнотратства, ефективне масштабування та вуглецево-обізнане розміщення. Якщо запитання запитує, яка група організовує cloud native екологічну сталість, відповідь — CNCF TAG Environmental Sustainability. Якщо запитання запитує, як побачити енергетичні сигнали окремих навантажень, Kepler — це важливий проєкт CNCF, який слід розпізнати.

Контекст спільноти також важливий, бо заяви про сталість потребують ретельної перевірки. Дашборд вендора може повідомити вуглецеве число, але платформний інженер усе одно має запитати, що саме вимірюється, що оцінюється приблизно, які охоплення викидів враховано і чи можна приписати це число власнику простору імен або сервісу. Хороша робота GreenOps ближча до інженерії надійності, ніж до піару. Вона починається з недосконалих, але корисних сигналів, документує припущення та покращує рішення поступово, замість того щоб заявляти про математичну точність там, де дані ще змодельовані.

Саме тому практики у стилі CNCF пасують до теми. Cloud native команди вже вміють ухвалювати операційні рішення на основі телеметрії, яка шумна, але придатна для дій, як-от перцентилі затримки, насиченість, рівень помилок і стан викочування. Енергетичні та вуглецеві дані слід обробляти з тією самою дисципліною. Число саме по собі не є вироком; це підказка дослідити форму навантаження, бізнес-цінність і безпечніші альтернативи.

Вимірювання перед оптимізацією

Команди часто починають роботу із зеленими обчисленнями з вгадування. Вони припускають, що найбільший сервіс — найгірший порушник, або що видалення малих навантажень не може мати значення, або що перехід до відомого «відновлюваного» регіону автоматично вирішує проблему. Ці здогади можуть бути хибними, бо енергоспоживання залежить від утилізації, обладнання, реплік, патернів запитів, охолодження та електромережі. Вимірювання не ухвалює рішення за вас, але воно тримає рішення чесним.

Kepler, тобто Kubernetes-based Efficient Power Level Exporter, — це експортер Prometheus, який оцінює енергоспоживання на рівні контейнера, Пода, процесу та вузла. Він використовує апаратні лічильники енергії там, де вони доступні, та моделі приписування навантажень, щоб пов’язати інформацію про потужність на рівні вузла з об’єктами Kubernetes. Результат за духом схожий на розподіл витрат: замість того щоб бачити лише місячний рахунок за хмару, команди можуть запитати, який простір імен, навантаження чи сервіс найбільше долучається до енергоспоживання.

┌────────────────────────────────────────────────────────────────────────────┐
│                         ПОТІК ВИМІРЮВАННЯ KEPLER                           │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  ┌──────────────────────────── Вузол Kubernetes ─────────────────────────┐ │
│  │                                                                        │ │
│  │  ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐   │ │
│  │  │ Pod: api        │    │ Pod: worker     │    │ Pod: dashboard  │   │ │
│  │  │ cpu + memory    │    │ cpu + memory    │    │ cpu + memory    │   │ │
│  │  └─────────────────┘    └─────────────────┘    └─────────────────┘   │ │
│  │                                                                        │ │
│  │  ┌──────────────────────────────────────────────────────────────────┐  │ │
│  │  │ Kepler DaemonSet                                                 │  │ │
│  │  │ читає апаратні лічильники та сигнали ядра                        │  │ │
│  │  │ приписує оцінки енергії до навантажень                           │  │ │
│  │  │ експортує метрики Prometheus із мітками Kubernetes               │  │ │
│  │  └──────────────────────────────────────────────────────────────────┘  │ │
│  │                                                                        │ │
│  └────────────────────────────────────────────────────────────────────────┘ │
│                                  │                                         │
│                                  ▼                                         │
│                         Prometheus збирає метрики                          │
│                                  │                                         │
│                                  ▼                                         │
│                     Дашборд Grafana або звіт GreenOps                      │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Вимірювання має обмеження. Публічні хмарні провайдери можуть не надавати кожен апаратний та енергетичний сигнал. Приписування навантажень часто є оцінкою, особливо на спільних вузлах. Дашборд може показати сильного кандидата на оптимізацію, але він не може вирішити, чи це навантаження є критичним для бізнесу, чутливим до затримки або обмеженим вимогами відповідності. Сприймайте енергетичні метрики як операційний доказ, який слід поєднувати з власністю над сервісом та контекстом надійності.

Корисний перший дашборд зазвичай містить запити ресурсів, спостережуване використання, кількість реплік, кількість вузлів та оцінки енергії чи вуглецю. Якщо енергетичні метрики недоступні, команди все одно можуть почати з проксі-сигналів, як-от низька утилізація, простори імен, що простоюють, невикористані PersistentVolume та застарілі Деплойменти. Найкращі дашборди показують тренди, а не лише знімки, бо навантаження, яке сьогодні тихе, може бути завантаженим під час нарахування зарплати, звітування чи сезонного трафіку.

Перша помилка вимірювання — ранжувати навантаження лише за поточним CPU. Поточний CPU корисний, але він пропускає зарезервовану пам’ять, постійне зберігання, мережеву передачу, кількість реплік та вплив на рівні вузла від обмежень планування. Навантаження з низьким CPU, але великим запитом пам’яті, все одно може завадити консолідації. Задача, що працює лише годину, може домінувати в денному енергетичному профілі, якщо вона одночасно стартує багато великих Подів. Тихий сервіс може навмисно очікувати рідкісного аварійного використання, тоді як «балакучий» сервіс може виконувати нешкідливі легкі перевірки. Вимірювання має звужувати дослідження, а не замінювати його.

Ще одна практична звичка — зберігати бізнес-контекст поруч із технічним сигналом. Мітки на кшталт owner, environment, app, cost-center та expires-at не є косметичними метаданими, коли починається робота зі сталості. Вони дають платформній команді змогу перейти від «цей простір імен виглядає так, ніби простоює» до «цей staging-простір імен належить команді документів, термін його дії минув минулого вівторка, і він не має продакшн-залежностей». Без цього контексту команда або небезпечно видаляє, або лишає марнотратство недоторканим, бо ніхто не може довести, що безпечно.

Сигнал	Що він показує	Як обережно його тлумачити
Запитаний CPU проти спостереженого CPU	Марнотратство планування й погана упаковка	Низьке використання може бути нормою для сплескових сервісів, тож перевірте історію перед урізанням.
Запитана пам’ять проти спостереженої пам’яті	Марнотратство резервування пам’яті й можливе надмірне виділення	Пам’ять має інший ризик, ніж CPU, бо ліміти можуть викликати OOM-вбивства.
Кількість реплік проти трафіку	Неактивні сервіси або сервіси з надмірною кількістю реплік	Деякі репліки потрібні для доступності навіть за низького трафіку.
Вік і власник простору імен	Зомбі-середовища та покинуті проєкти	Підтвердьте власність перед видаленням будь-чого у спільних кластерах.
Час старту й тривалість задачі	Відкладувана робота, яку можна змістити в чистіші вікна	Зміщуйте задачі лише тоді, коли бізнес-дедлайни та залежності дозволяють.
Регіон і резидентність даних	Можливості просторового зміщення	Чистіші регіони можуть порушувати вимоги щодо затримки, вартості чи регуляторні.

Підказка для активного навчання: Ваш дашборд показує сервіс із дуже низьким використанням CPU, але стабільним використанням пам’яті близько до його запиту. Що б ви знизили першим: CPU, пам’ять, обидва чи нічого? Вирішіть, які докази вам потрібні перед зміною кожного значення, бо збої CPU та пам’яті поводяться в Kubernetes по-різному.

Правильне визначення розміру та упаковка

Правильне визначення розміру (right-sizing) — це практика встановлення запитів і лімітів ресурсів близько до того, що навантаження насправді потребує, із достатнім запасом для звичайних коливань. У Kubernetes це одна з найцінніших практик сталості, бо запити впливають на планування. Под, що запитує два ядра CPU, резервує цей обсяг із погляду планувальника, навіть якщо зазвичай споживає малу частку ядра.

Упаковка (bin packing) — це здатність планувальника ефективно розміщувати навантаження на вузлах. Якщо запити точні, більше Подів можуть поміститися на меншій кількості вузлів без збільшення ризику. Якщо запити роздуті, планувальник бачить вузли як заповнені, поки реальний CPU простоює. Автомасштабувальник кластера тоді може додати вузли, навіть якщо наявні вузли могли б обслужити реальний попит.

┌────────────────────────────────────────────────────────────────────────────┐
│                         УПАКОВКА ЗА ЗАПИТАМИ                               │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Погані запити: планувальник бачить кожен Под як великий                    │
│                                                                            │
│      Місткість вузла A: 4 CPU                                               │
│      ┌────────────────────────────────────────────┐                        │
│      │ Под 1 запитує 2 CPU, але вживає 0.2 CPU      │                        │
│      │ Под 2 запитує 2 CPU, але вживає 0.2 CPU      │                        │
│      │ Планувальник вважає вузол повним             │                        │
│      └────────────────────────────────────────────┘                        │
│                                                                            │
│      Результат: більше вузлів лишається увімкненими заради малої роботи     │
│                                                                            │
│  Кращі запити: планувальник бачить реалістичний попит                       │
│                                                                            │
│      Місткість вузла B: 4 CPU                                               │
│      ┌────────────────────────────────────────────┐                        │
│      │ Под 1 запитує 250m CPU                       │                        │
│      │ Под 2 запитує 250m CPU                       │                        │
│      │ Под 3 запитує 250m CPU                       │                        │
│      │ Под 4 запитує 250m CPU                       │                        │
│      │ Більше навантажень містяться до додавання вузла │                     │
│      └────────────────────────────────────────────┘                        │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Правильне визначення розміру не те саме, що робити все крихітним. Сервіс із непередбачуваними сплесками може потребувати вищих запитів CPU, горизонтального автомасштабування або тесту продуктивності перед зменшенням запитів. Сервіс із інтенсивним споживанням пам’яті може потребувати щедрих запитів пам’яті, бо тиск пам’яті може спричинити витіснення або збої через брак пам’яті. Стала інженерія — це не безрозсудна мінімізація; це виділення ресурсів на основі доказів.

Vertical Pod Autoscaler може рекомендувати або коригувати запити на основі спостереженого використання. Goldilocks подає рекомендації VPA у спосіб, який командам легше переглядати. Перегляд людиною все одно має значення, бо інструменти бачать метрики, а не запуски продуктів, разові міграції, майбутні події з трафіком чи вартість перезапуску. Найбезпечніший перший робочий процес — спостерігати, рекомендувати, застосувати консервативну зміну, моніторити й повторити.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: internal-dashboard
  labels:
    app: internal-dashboard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: internal-dashboard
  template:
    metadata:
      labels:
        app: internal-dashboard
    spec:
      containers:
        - name: dashboard
          image: nginx:1.27
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Наведений вище маніфест — не універсальна рекомендація; це реалістична форма для невеликого внутрішнього дашборда в лабораторії. Продакшн-дашборд зі суворими вимогами щодо доступності може потребувати кількох реплік і PodDisruptionBudget. Дашборд із середовищем виконання, інтенсивним щодо пам’яті, може потребувати більше пам’яті. Сенс у тому, щоб обґрунтовувати запити доказами та вимогами сервісу, а не копіювати великі типові значення.

Правильне визначення розміру також змінює розмову між командами застосунків і платформними командами. Якщо платформа лише каже «ваш сервіс марнотратний», власник застосунку може почути звинувачення й захищати наявний стан. Якщо платформа показує часовий ряд запитаного CPU, використаного CPU, робочого набору пам’яті, перезапусків, затримки та історії викочувань, розмова стає інженерною. Команда може вирішити, чи спершу зменшити CPU, лишити пам’ять без змін, додати автомасштабування чи провести навантажувальний тест перед зміною продакшну.

Погляд планувальника особливо важливий для KCNA. Kubernetes планує за запитами, а не за оптимістичним майбутнім, де кожен контейнер поводиться чемно. Це робить запити контрактом із кластером. Зависокі — і контракт резервує потужності, які навантаження не використовує. Занизькі — і навантаження може потрапити на вузол, що не здатен підтримати його реальний попит під час піків. Стале налаштування — це те, яке відображає виміряну потребу плюс обґрунтований запас.

Рішення right-sizing	Хороші докази	Ризик за необачного виконання
Знизити запит CPU	Стабільне використання значно нижче запиту, а затримка здорова.	Тротлінг CPU або повільніша обробка запитів під час сплесків.
Знизити запит пам’яті	Робочий набір і пікова пам’ять стабільно нижчі за запит.	Витіснення, якщо вузол зазнає тиску пам’яті.
Встановити ліміт пам’яті	Застосунок має відому межу пам’яті, а поведінка перезапуску прийнятна.	OOM-вбивства, якщо ліміт надто тісний або трафік змінюється.
Зменшити репліки	Трафік, потреби доступності та толерантність до збоїв це дозволяють.	Ризик простою під час обслуговування вузлів або раптових сплесків.
Додати автомасштабування	Метрика відображає реальний попит, а поведінку масштабування протестовано.	Осциляція, сплески вартості або брак потужностей, якщо метрики запізнюються.

Звичка сеньйорного рівня — запитати, який режим збою вводить зміна. Зниження CPU зазвичай спричиняє повільнішу роботу або тротлінг; зниження пам’яті може завершити процеси. Зменшення реплік може заощадити енергію, але знизити стійкість до збоїв. Вуглецеві заощадження марні, якщо команда компенсує їх запуском аварійної інфраструктури пізніше, бо зміна спричинила нестабільність.

Опрацьоване right-sizing зазвичай починається поза продакшном. Staging або внутрішнє навантаження дають команді простір відпрацювати метод, перевірити дашборди й написати кроки відкату перед тим, як торкатися сервісів, що дивляться на користувача. Щойно команда довіряє робочому процесу, продакшн-зміни все одно мають бути поступовими. Застосовуйте одну зміну за раз, спостерігайте за показниками сервісу й результатами на рівні вузла та тримайте чіткий шлях відкату. Програми сталості зазнають невдачі, коли їх сприймають як один героїчний ривок прибирання; вони успішні, коли стають звичайною звичкою огляду.

Автомасштабування, масштабування до нуля та зомбі-навантаження

Автомасштабування зменшує марнотратство, коли пов’язує пропозицію з попитом. Horizontal Pod Autoscaler змінює кількість реплік Подів. Cluster Autoscaler змінює кількість вузлів. KEDA може масштабувати навантаження на основі джерел подій, як-от довжина черги, а деякі платформи можуть масштабувати сервіси до нуля, коли в них немає трафіку. Ці механізми потужні, бо вони усувають припущення, що вчорашній пік має працювати цілий день.

┌────────────────────────────────────────────────────────────────────────────┐
│                       РІВНІ МАСШТАБУВАННЯ В KUBERNETES                     │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Попит на навантаження змінюється                                          │
│             │                                                              │
│             ▼                                                              │
│  ┌──────────────────────────────┐                                          │
│  │ HPA або KEDA змінює репліки   │  менше або більше Подів для навантаження │
│  └──────────────────────────────┘                                          │
│             │                                                              │
│             ▼                                                              │
│  ┌──────────────────────────────┐                                          │
│  │ Планувальник розміщує Поди    │  запити вирішують, де Поди помістяться   │
│  └──────────────────────────────┘                                          │
│             │                                                              │
│             ▼                                                              │
│  ┌──────────────────────────────┐                                          │
│  │ Cluster Autoscaler змінює     │  менше або більше вузлів для кластера    │
│  │ кількість вузлів, коли можливо │                                          │
│  └──────────────────────────────┘                                          │
│                                                                            │
│  Виграш у сталості з'являється лише тоді, коли менше реплік дозволяє менше вузлів.│
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Автомасштабування Деплойменту з десяти реплік до двох заощаджує накладні витрати на рівні Пода, але найбільший інфраструктурний виграш з’являється, коли можна також прибрати вузли. Якщо інші навантаження або роздуті запити тримають вузли повними з погляду планувальника, кластер може не зменшитися. Саме тому right-sizing і автомасштабування слід сприймати як поєднану систему, а не як окремі пункти чек-листа.

Масштабування до нуля корисне для навантажень, які можуть терпіти холодні старти або не потрібні постійно. Непродакшн preview-середовища, внутрішні інструменти, обробники черг та сервіси розробки — поширені кандидати. API, що дивиться на користувача, зі суворою ціллю щодо затримки зазвичай не є хорошим кандидатом, якщо платформа не має перевіреного шляху прогріву й бізнес не приймає компроміс.

Зомбі-навантаження відрізняються від навмисно неактивних сервісів. Зомбі-навантаження — це Деплоймент, Job, база даних, простір імен або середовище, що більше не має дійсного власника чи призначення, але досі споживає ресурси. Kubernetes не дізнається автоматично, що проєкт скасували. Без міток власності, TTL-політик, закінчення терміну дії середовищ та регулярних оглядів зомбі-навантаження можуть працювати місяцями.

Тип навантаження	Кращий патерн GreenOps	Чому він пасує
API для користувача	Right-size, автомасштабування і достатньо реплік для доступності.	Низька затримка й надійність важливіші за часове зміщення.
Обробник черги	Масштабування за глибиною черги з низькою або нульовою кількістю неактивних реплік.	Попит видимий, а робота часто може трохи зачекати.
Нічний звіт	Запуск у чистіше вікно, коли дедлайни дозволяють.	Пакетна робота має гнучкий час і передбачувану тривалість.
Preview-середовище	Автоматичне закінчення дії після закриття pull request або по фіксованому терміну.	Тимчасові середовища — поширене джерело зомбі-марнотратства.
Внутрішній дашборд	Зменшити репліки, right-size запитів і розглянути зменшення поза робочими годинами.	Низький трафік і внутрішні користувачі зазвичай дозволяють консервативні заощадження.
Задача навчання моделі	Оцінити чистіші регіони, чистіші вікна та спеціалізоване обладнання.	Тривалі обчислення можуть створювати велику різницю у викидах.

Зупиніться й поміркуйте: Кластер щоночі зменшує Деплойменти, але рахунок за хмару майже не змінюється. Що б ви перевірили далі: репліки Подів, кількість вузлів, запити ресурсів чи все три? Корисна відповідь — усі три, бо виграші у сталості часто потребують, щоб увесь ланцюжок масштабування завершився.

Практична програма прибирання починається з міток. Кожен простір імен і навантаження мають мати власника, середовище, застосунок та політику закінчення дії там, де це доречно. Прибирання стає безпечнішим, коли платформні команди можуть відрізнити продакшн-сервіс від застарілого preview-простору імен. Без цих міток робота із зеленими обчисленнями перетворюється на ручне детективне розслідування, і команди починають боятися видаляти будь-що.

alias k=kubectl
k get deployments --all-namespaces \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,OWNER:.metadata.labels.owner,ENV:.metadata.labels.environment'

Перший рядок визначає поширений псевдонім k для kubectl, а другий рядок використовує його для запиту інвентаризації лише для читання. Вивід — це відправна точка, а не список на видалення. Відповідальний інженер підтверджує трафік, власність та залежності перед зменшенням масштабу чи видаленням навантаження, особливо у спільних кластерах.

Автомасштабування заслуговує на таку саму обережність. Обробник черги, що масштабується за глибиною черги, може бути чудовим покращенням сталості, бо навантаження має видимий беклог і часто може терпіти короткі очікування. Веб-API, що масштабується за середнім CPU, може поводитися погано, якщо кожен запит чутливий до затримки, метрика відстає від трафіку або час старту довгий. Масштабування до нуля може бути чудовим для preview-середовищ і сервісів розробки, але це поганий типовий вибір для сервісу, який має швидко відповісти на перший запит. Екологічніший патерн залежить від навантаження, а не є гаслом.

Прибирання зомбі часто є найшвидшим виграшем, бо воно усуває роботу, а не тюнінгує її. Складна частина — радше соціальна та процедурна, ніж технічна. Командам потрібна конвенція закінчення дії, спосіб сповіщати власників і шлях відкату чи відновлення на випадок випадкового видалення. Деякі організації використовують контролери TTL для просторів імен, прибирання pull-request-середовищ або періодичні підтвердження власників. Конкретний механізм важить менше, ніж звичка: тимчасові ресурси мають мати запланований кінець, а кожен довготривалий ресурс має мати живого власника.

Вуглецево-обізнане планування

Вуглецево-обізнане планування означає запуск гнучкої роботи тоді чи там, де електроенергія має нижчу вуглецеву інтенсивність. Той самий обсяг обчислень може мати різні викиди залежно від мікса мережі в той час і в тому місці. Саме тому пакетна задача може бути екологічнішою, якщо вона працює під час періоду високої доступності вітрової чи сонячної енергії або в регіоні з чистішою електроенергією, за умови, що бізнес-обмеження це дозволяють.

┌────────────────────────────────────────────────────────────────────────────┐
│                         ВУГЛЕЦЕВО-ОБІЗНАНЕ ПЛАНУВАННЯ                      │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Часове зміщення: оберіть КОЛИ                                              │
│                                                                            │
│      Висока вуглецева інтенсивність:  ██████████        ████████           │
│      Середня інтенсивність:           ██████    ████████        ████       │
│      Низька вуглецева інтенсивність:          █████████              ███████│
│                              06:00   12:00   18:00   00:00                │
│                                                                            │
│      Кандидат-дія: запускати відкладну пакетну роботу в низькі вікна.       │
│                                                                            │
│  Просторове зміщення: оберіть ДЕ                                            │
│                                                                            │
│      Регіон A: ближче до користувачів, вища вуглецевість мережі цієї години │
│      Регіон B: далі від користувачів, нижча вуглецевість мережі цієї години │
│                                                                            │
│      Кандидат-дія: переміщуйте лише навантаження, що терплять компроміс.    │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Слово «гнучкий» виконує тут більшу частину роботи. Продакшн-сервіс оформлення замовлення не може чекати кілька годин на чистішу електроенергію, бо користувачі очікують негайних відповідей. Нічна аналітична задача може зачекати, за умови що похідні звіти все одно завершаться до початку робочого дня. Задача навчання моделі машинного навчання може переміститися в інший регіон, якщо гравітація даних, приватність, вартість і доступність прискорювачів не блокують переміщення.

Вуглецево-обізнане планування також має ризик відскоку (rebound). Переміщення задачі в чистіший регіон може збільшити мережеву передачу, створити дубльоване зберігання або порушити резидентність даних. Затримка надто великого обсягу роботи в те саме чисте вікно може створити пік потужностей, що змусить додаткові вузли ввімкнутися. Зрілий дизайн GreenOps розглядає систему в цілому, а не оптимізує одну метрику ізольовано.

Обмеження	Запитання для постановки	Наслідок для планування
Затримка	Чи потрібна користувачу або системі негайна відповідь?	Сервіси з низькою затримкою зазвичай не можуть чекати на чистіші вікна.
Дедлайн	Коли результат має бути доступним?	Пакетні задачі можуть зміщуватися лише в межах запасу дедлайну.
Резидентність даних	Чи можуть дані юридично й за контрактом переміщатися між регіонами?	Деякі навантаження не можуть використовувати просторове зміщення.
Обсяг даних	Чи створить переміщення даних більше передачі й накладних витрат на зберігання?	Великі набори даних, можливо, краще обробляти там, де вони вже є.
Потужності	Чи переміститься багато задач у те саме вікно?	Пакетні черги потребують тротлінгу та пріоритетів.
Надійність	Що станеться, якщо чистіше вікно буде пропущено?	Планувальникам потрібні запасні правила, а не лише «ідеальні» плани.

Практичний вуглецево-обізнаний планувальник потребує політики, а не лише потоку вуглецевої інтенсивності. Політика має описувати, які навантаження придатні, як довго вони можуть чекати, які регіони дозволені та який запасний варіант використати, коли чистіших потужностей немає. Без політики вуглецева обізнаність перетворюється на крихкий скрипт, що може здивувати команди застосунків.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-aggregation
  labels:
    app: reporting
    carbon-aware: "candidate"
spec:
  schedule: "30 1 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: aggregate
              image: busybox:1.36
              command:
                - /bin/sh
                - -c
                - "date && echo aggregating-report-data && sleep 5"
              resources:
                requests:
                  cpu: "200m"
                  memory: "128Mi"
                limits:
                  cpu: "500m"
                  memory: "256Mi"

Цей CronJob можна запустити в кластері Kubernetes 1.35+, але мітка — лише маркер. Справжня вуглецево-обізнана платформа поєднувала б політику, вуглецеві дані, пакетну оркестрацію та контролери допуску чи розширення планувальника. На рівні KCNA зосередьтеся на тому, щоб вирішити, які навантаження придатні та які компроміси слід перевірити перед їх переміщенням.

Найбезпечніший вуглецево-обізнаний дизайн починається з класів придатності. Клас один — це трафік користувачів у реальному часі, який зазвичай лишається близько до користувачів і оптимізує марнотратство через right-sizing та автомасштабування. Клас два — це пакетна робота, прив’язана до дедлайну, що може зміщуватися в межах відомого часового вікна, якщо результат усе одно надходить вчасно. Клас три — це робота, яку можна перервати чи перезапустити, як-от CI, індексування, симуляції та деякі задачі навчання, що може терпіти спотові потужності чи чистіше регіональне розміщення. Клас чотири — це регульована робота чи робота з великим обсягом даних, яка може бути технічно гнучкою, але юридично чи економічно прив’язаною до місця.

Зробіть паузу й передбачте: якщо кожна команда змістить свої нічні задачі в ту саму низьковуглецеву годину, яка нова проблема може з’явитися? Відповідь — конкуренція за потужності. Чисте вікно може стати піковим вікном, якщо планувальник не має тротлінгу, пріоритетів чи запасної поведінки. Зрілі платформи уникають цього за допомогою черг, квот і дедлайнів, тож робота нижчого пріоритету поступається терміновій роботі, а пропущені вікна не блокують бізнес.

Вуглецево-обізнане планування також має бути придатним для аудиту. Якщо задача переміщується чи чекає, платформа має записати, чому ухвалено це рішення, який вуглецевий сигнал використано, який дедлайн застосовано і який запасний варіант був доступний. Цей запис захищає команду, коли звіт запізнюється чи регіон стає недоступним. Він також допомагає лідерам сталості відрізнити реальні скорочення вуглецю від паперових заяв, що ніколи не змінили поведінку навантажень.

GreenOps та FinOps разом

FinOps запитує, як хмарні витрати відображаються на бізнес-цінності. GreenOps запитує, як енергія та вуглець відображаються на корисній роботі. Ці дисципліни перекриваються, бо марнотратство дороге, а марнотратство викидає вуглець. Надмірно виділений Деплоймент, забутий простір імен та постійно увімкнений кластер розробки зазвичай погані в обох системах.

┌────────────────────────────────────────────────────────────────────────────┐
│                         ПЕРЕТИН FINOPS ТА GREENOPS                         │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Запитання FinOps:   Чи витрачаємо ми гроші на корисну роботу?             │
│  Запитання GreenOps: Чи викидаємо ми вуглець заради корисної роботи?       │
│                                                                            │
│  Спільні перші кроки:                                                       │
│                                                                            │
│      ├─ Прибрати невикористані навантаження                                 │
│      ├─ Right-size запитів і лімітів                                        │
│      ├─ Зменшити неактивні системи                                          │
│      ├─ Покращити упаковку й утилізацію вузлів                              │
│      ├─ Використовувати ефективні образи й шляхи старту                     │
│      └─ Надавати перевагу гнучкому плануванню для відкладної роботи         │
│                                                                            │
│  Відмінність: GreenOps також запитує про вуглець мережі, втілений вуглець,  │
│  життєвий цикл обладнання та час чи місце обчислень.                        │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Узгодженість найсильніша, коли дія усуває непотрібну роботу. Видалення зомбі-середовища заощаджує гроші й вуглець без складних дебатів. Right-sizing сервісу на основі доказів покращує упаковку й може зменшити кількість вузлів. Масштабування обробника черги до нуля, коли немає повідомлень, запобігає споживанню ресурсів у простої.

Узгодженість слабша, коли екологічніший варіант коштує більше, збільшує затримку або потребує інженерних зусиль, що витісняють роботу вищої цінності. Чистіший регіон може бути дорожчим або далі від користувачів. Спеціалізоване ефективне обладнання може потребувати змін у застосунку. Вуглецево-обізнана пакетна система може потребувати нових операційних засобів контролю. Сеньйорні інженери не вдають, що ці компроміси зникають; вони роблять компроміс явним і вимірюють результат.

Рішення	Погляд FinOps	Погляд GreenOps	Збалансована рекомендація
Видалити покинуті preview-простори імен	Негайне скорочення витрат	Негайне скорочення енергії та вуглецю	Робіть після перевірок власності й залежностей.
Зменшити роздуті запити CPU	Краща упаковка й менше вузлів	Менше увімкнених незавантажених потужностей	Робіть поступово з моніторингом і відкатом.
Перенести API в чистіший віддалений регіон	Може змінити вартість і передачу даних	Може зменшити вуглець мережі	Уникайте, якщо страждає затримка чи резидентність.
Змістити нічні звіти в чистіше вікно	Часто нейтрально або дешевше	Менше операційного вуглецю	Використовуйте дедлайни й запасні правила.
Тримати обладнання довше	Може відкласти капітальні витрати	Зменшує тиск втіленого вуглецю	Балансуйте з ефективністю, надійністю й життєвим циклом підтримки.
Використовувати спотові потужності для пакетних задач	Нижча ціна обчислень	Використовує наявні вільні потужності	Використовуйте лише тоді, коли переривання прийнятне.

Корисне запитання для наради: «Яка найменша зміна усуває підтверджене марнотратство без зміни користувацького досвіду?» Це запитання зазвичай веде до прибирання, запитів і масштабування перед переміщеннями регіонів чи складними планувальниками. Просунута робота зі сталості цінна, але вона має будуватися на основах, а не відволікати від очевидного марнотратства.

FinOps і GreenOps усе одно можуть законно розходитися. Зарезервовані інстанси або знижки за зобов’язаннями можуть на якийсь час зробити неефективну систему дешевою на вигляд, хоча вона досі споживає ресурси. Чистіший регіон може коштувати більше або потребувати більше мережевої передачі. Триваліше утримання обладнання може зменшити тиск втіленого вуглецю, але збільшити операційне споживання потужності чи ризик підтримки. Ці конфлікти не доводять, що сталість нереалістична. Вони доводять, що команді потрібна система ухвалення рішень, яка називає вартість, вуглець, надійність, дані та користувацький досвід окремими обмеженнями.

Тому найпереконливіші звіти GreenOps уникають абстрактної «доброчесної» мови. Вони кажуть, наприклад: «ми зменшили staging-репліки з чотирьох до однієї поза робочими годинами, кількість вузлів упала на два протягом нічного вікна, кількість провалених тестів не зросла, а відкат — це одна команда». Такий звіт промовляє водночас до інженерів, фінансових команд і команд сталості. Він пов’язує операційну зміну з вимірюваним результатом і робить залишковий ризик видимим.

Опрацьований приклад: аудит дашборда з низьким трафіком

Цей опрацьований приклад показує, як міркувати про навантаження, перш ніж вас попросять виконати такий самий аналіз самостійно. Сценарій навмисно невеликий, бо звичка важить більше за розмір маніфесту: дослідіть призначення, трафік, репліки, запити, ліміти та поведінку масштабування перед тим, як рекомендувати зміни.

Команда запускає внутрішній дашборд, який отримує кілька десятків відвідувань на день. Він корисний у робочі години, але не дивиться на користувача й не обробляє платежі. Поточний Деплоймент запитує великі ресурси й запускає три репліки у спільному кластері.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: internal-dashboard
  labels:
    app: internal-dashboard
    owner: platform-tools
    environment: internal
spec:
  replicas: 3
  selector:
    matchLabels:
      app: internal-dashboard
  template:
    metadata:
      labels:
        app: internal-dashboard
    spec:
      containers:
        - name: dashboard
          image: nginx:1.27
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"

Перший висновок — завеликі запити. Три репліки кожна запитують два ядра CPU та чотири ГіБ пам’яті, тож планувальник резервує шість ядер CPU й дванадцять ГіБ пам’яті, перш ніж розглядати будь-яке інше навантаження. Якщо спостережуване використання ближче до невеликого статичного дашборда, ці запити блокують упаковку й можуть тримати додаткові вузли онлайн. Правильна відповідь — не вгадувати крихітні значення назавжди, а переглянути метрики й застосувати консервативні запити, що відповідають реальному попиту.

Другий висновок — кількість реплік. Три репліки можуть бути виправдані для сервісу, що дивиться на користувача, з вимогами щодо доступності, але цей внутрішній дашборд має низький трафік і обмежену критичність. Однієї репліки може бути достатньо, або можна обрати дві, якщо команда хоче певної доступності під час обслуговування вузлів. Рекомендація має називати компроміс щодо надійності, а не вдавати, що менша кількість реплік завжди правильна.

Третій висновок — відсутні ліміти та відсутня політика життєвого циклу. Ліміти CPU й пам’яті самі по собі не є рішенням сталості, але вони захищають вузол від несподіваної некерованої поведінки й роблять використання ресурсів простішим для осмислення. Навантаженню також бракує плану поза робочими годинами чи масштабування до нуля. Якщо дашборд не потрібен поза робочими годинами, заплановане зменшення масштабу або керований подіями патерн могли б іще зменшити споживання у простої.

Краща перша редакція могла б виглядати так у лабораторії. У продакшні ви б перевірили спостережувані метрики, затримку, поведінку перезапуску й вимоги користувачів перед застосуванням.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: internal-dashboard
  labels:
    app: internal-dashboard
    owner: platform-tools
    environment: internal
    sustainability.kubedojo.io/reviewed: "true"
spec:
  replicas: 1
  selector:
    matchLabels:
      app: internal-dashboard
  template:
    metadata:
      labels:
        app: internal-dashboard
    spec:
      containers:
        - name: dashboard
          image: nginx:1.27
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Навчальний сенс — у послідовності рішень. Спершу класифікуйте навантаження. По-друге, порівняйте запитані ресурси зі спостережуваним використанням. По-третє, розгляньте кількість реплік відносно потреб надійності. По-четверте, додайте запобіжники, як-от ліміти, мітки, власність і моніторинг. Нарешті, переконайтеся, що кластер справді може прибрати вузли чи звільнити потужності після зміни. Без цього останнього кроку команда може святкувати менший маніфест, поки та сама кількість вузлів продовжує працювати.

Перш ніж проводити подібний огляд самостійно, передбачте, яку рекомендацію було б найважче захистити на продакшн-огляді: зниження CPU, зниження пам’яті, зменшення реплік чи додавання зменшення поза робочими годинами. Більшість команд виявляють, що пам’ять і репліки потребують найбільше контексту, бо їхні режими збою гостріші. CPU часто може деградувати поступово, тоді як тиск пам’яті може вбити процес, а зменшення реплік може прибрати резервування під час обслуговування. Це не означає, що такі зміни заборонені; це означає, що докази й запобіжники мають відповідати ризику.

Опрацьований приклад також показує, чому огляди сталості мають завершуватися верифікацією, а не гарнішим маніфестом. Якщо Деплоймент змінюється, але кількість вузлів ніколи не падає, платформа все одно може виграти від звільненого запасу, проте вуглецева заява має бути меншою. Якщо кількість вузлів падає, але затримка погіршується, зміна може бути неприйнятною. Якщо затримка лишається здоровою, а вузли зменшуються, команда має повторюваний патерн. Зелені обчислення стають інженерією, коли висновок витримує вимірювання.

Патерни та антипатерни

Патерни зелених обчислень найдієвіші, коли усувають підтверджене марнотратство, водночас зберігаючи чітку обіцянку сервісу. Продакшн-сервіс оформлення замовлення, staging-обробник конвертації, preview-простір імен і щотижнева задача навчання моделі не повинні отримувати однакового поводження. Платформній команді потрібні патерни, що пов’язують призначення навантаження з конкретним операційним рішенням, бо розпливчасті поради зі сталості часто перетворюються або на нешкідливі дашборди, або на ризиковане урізання ресурсів.

Наведені нижче патерни навмисно консервативні. Вони починаються з видимості й власності, бо це передумови безпечної дії. Далі вони рухаються до right-sizing, масштабування й планування, що можуть дати більші заощадження, але потребують сильніших доказів. Зріла платформа використовує ці патерни як типові у шаблонах, чек-листах оглядів і прокладених шляхах, щоб командам не доводилося наново відкривати ті самі рішення під час кожного огляду інцидентів чи огляду витрат.

Патерн	Коли використовувати	Чому він працює	Міркування щодо масштабу
Мітки власника й терміну дії	Непродакшн-простори імен, preview-середовища, спільні кластери та тимчасові проєкти	Прибирання стає безпечним, бо відповідальна команда й передбачений час життя видимі.	Автоматизуйте нагадування перед видаленням і тримайте процес відновлення на випадок випадкового прибирання.
Right-sizing на основі доказів	Сервіси зі стійким розривом між запитом і використанням та стабільною історією продуктивності	Резервування планувальника стають ближчими до реального попиту, покращуючи упаковку й зменшуючи невикористаний запас.	Застосовуйте зміни поступово, особливо для пам’яті й навантажень, чутливих до затримки.
Масштабування за попитом	Обробники черг, внутрішні інструменти, пакетні процесори й сервіси з передбачуваними сигналами попиту	Репліки зменшуються, коли роботи немає, і зростають, коли надходить корисна робота.	Переконайтеся, що менша кількість реплік зрештою може зменшити кількість вузлів чи звільнити обмежені потужності.
Вуглецево-обізнані пакетні вікна	Задачі із запасом дедлайну, можливістю перезапуску та чіткими обмеженнями даних	Робота може виконуватися, коли вуглецева інтенсивність мережі нижча, без впливу на користувачів.	Використовуйте квоти й пріоритети, щоб багато задач не створювали нового піку в тому самому вікні.
Звітність GreenOps плюс FinOps	Огляди, де фінанси, платформа й команди сталості несуть спільну відповідальність	Компроміси вартості, вуглецю й надійності видимі в одному записі рішення.	Відокремлюйте усунення марнотратства від складніших змін регіону, обладнання чи архітектури.

Антипатерни зазвичай починаються з правильної ідеї, застосованої надто широко. Правда, що менше реплік може заощадити ресурси, але не кожен сервіс має працювати з однією реплікою. Правда, що чисті мережі важливі, але не кожне навантаження може переміститися. Правда, що марнотратство CPU поширене, але зміни пам’яті можуть провалюватися інакше, ніж зміни CPU. Робота платформного інженера — зберегти корисний принцип, відкидаючи небезпечний скорочений шлях.

Антипатерн	Що йде не так	Краща альтернатива
Дашборд «вуглецевого театру»	Команди святкують вуглецевий графік, не змінюючи запитів, реплік, прибирання чи поведінки планування.	Поєднуйте кожен дашборд із власником, кандидат-дією, очікуваним впливом і сигналом верифікації.
Універсальне масштабування до нуля	Сервіси, що дивляться на користувача чи операційні, отримують холодні старти, пропущені сповіщення чи недоступні перші запити.	Обмежте масштабування до нуля придатними навантаженнями й визначте мінімум реплік для критичних періодів.
Сліпе урізання пам’яті	Поди перезапускаються чи витісняються, спричиняючи повторні спроби, провалені задачі та аварійну надкорекцію.	Перегляньте піки пам’яті, робочий набір, історію перезапусків і ризик OOM перед зміною запитів чи лімітів.
Стрибки між регіонами без аналізу даних	Передача даних, дубльоване зберігання, обмеження резидентності чи затримка стирають уявний вуглецевий виграш.	Оцінюйте просторове зміщення лише після того, як відомі розташування даних, розташування користувачів, юридичні межі та дедлайни.
Разовий спринт прибирання	Марнотратство повертається, бо шаблони, мітки й правила власності не змінилися.	Перетворіть прибирання на повторювану можливість платформи з типовими мітками, терміном дії та звітністю.

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

Система ухвалення рішень

Коли з’являється можливість для сталості, не починайте з запитання, який інструмент справляє найбільше враження. Почніть із запитання, який вид марнотратства чи вуглецевої можливості перед вами. Наведене нижче рішення розраховане на міркування рівня KCNA: класифікуйте навантаження, визначте обмеження, оберіть консервативну дію й визначте верифікацію перед викочуванням. Цей потік не дає команді застосовувати вуглецево-обізнане планування до API реального часу чи видаляти навантаження просто тому, що їхній поточний трафік низький.

┌────────────────────────────────────────────────────────────────────────────┐
│                         ПОТІК РІШЕНЬ GREENOPS                              │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  1. Чи навантаження досі потрібне?                                          │
│        ├─ Ні або невідомий власник → підтвердьте власність, далі завер./видал.│
│        └─ Так → продовжуйте                                                 │
│                                                                            │
│  2. Чи запити значно вищі за спостережуване використання?                   │
│        ├─ Так → консервативно right-size й моніторте збої                   │
│        └─ Ні → продовжуйте                                                  │
│                                                                            │
│  3. Чи попит коливається або зникає на тривалі періоди?                     │
│        ├─ Так → додайте автомасштаб., заплан. зменшення або масшт. до нуля   │
│        └─ Ні → продовжуйте                                                  │
│                                                                            │
│  4. Чи може робота переміститися в часі або просторі?                       │
│        ├─ Так → оцініть вуглецево-обізнане планування з запобіжниками        │
│        └─ Ні → оптимізуйте ефективність, образи, повтори й архітектуру       │
│                                                                            │
│  5. Чи зміна безпечно зменшила вузли, запас, енергію чи вуглець?            │
│        ├─ Так → запишіть патерн і зробіть його повторюваним                  │
│        └─ Ні → перегляньте гіпотезу або відкотіть                            │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Система навмисно завершується верифікацією, бо заяви GreenOps легко перебільшити. Менший запит CPU — корисна зміна планування, але це не те саме, що виміряне скорочення вуглецю. Затримана пакетна задача може працювати під час чистішого вікна мережі, але команда все одно має перевірити пропущені дедлайни, накопичення черги й переміщення даних. Верифікація не мусить бути досконалим вуглецевим обліком на рівні KCNA; вона має пов’язувати інженерну дію зі спостережуваними наслідками.

Якщо ви бачите	Оберіть спершу	Уникайте спершу	Сигнал верифікації
Застарілий простір імен із незрозумілим власником	Перевірку власності та робочий процес закінчення дії	Негайне видалення без огляду залежностей	Підтвердження власника, відсутність залежності від трафіку, успішне прибирання
Запит CPU значно вищий за використання	Консервативне зниження запиту CPU	Урізання пам’яті без доказів щодо пам’яті	Тротлінг CPU, затримка, доступний запас вузла
Внутрішній сервіс із низьким трафіком	Огляд реплік і можливе зменшення поза робочими годинами	Масштабування до нуля для критичних сервісів	Кількість реплік, доступність, кількість перезапусків, звіти користувачів
Staging-обробник на основі черги	Масштабування у стилі KEDA чи за глибиною черги	Фіксовану високу кількість реплік цілу ніч	Глибина черги, затримка обробки, кількість реплік, тиск вузла
Пакетна задача, гнучка щодо дедлайну	Вуглецево-обізнане часове вікно із запасним варіантом	Переміщення регульованих даних між регіонами	Успіх дедлайну, вуглецевий сигнал, передача даних, повтори задачі
Чистіший, але віддалений регіон	Повний огляд компромісів	Припущення, що нижчий вуглець мережі завжди виграє	Затримка, вартість передачі, схвалення резидентності, оцінка загальних викидів

Використовуйте систему як розмову-огляд, а не як механічний чек-лист. Деякі рішення потребують більш ніж одного проходу. Staging-сервіс може потребувати міток власника, нижчих запитів, меншої кількості реплік і масштабування з урахуванням черги. Продакшн-сервіс може потребувати спершу лише right-sizing, бо затримка й доступність лишають мало простору для експериментів із плануванням. Головне — тримати обсяг достатньо малим, щоб його верифікувати, і достатньо оборотним, щоб зберегти довіру.

Чи знали ви?

Kepler — це CNCF Sandbox-проєкт для енергетичних метрик Kubernetes: Він експортує метрики Prometheus, що допомагають командам оцінювати енергоспоживання на рівні навантажень, роблячи розмови GreenOps конкретнішими за вгадування на рівні вузла.
Простій не означає безкоштовність: Тихий контейнер усе одно може резервувати пам’ять, тримати процеси живими, утримувати потужності планування й долучатися до того, що вузол лишається увімкненим, навіть коли користувачі не надсилають трафіку.
Вуглецево-обізнане планування залежить від гнучкості: Та сама ідея, що добре працює для пакетних задач, може бути хибною для API, що дивляться на користувача, бо затримана робота прийнятна лише тоді, коли навантаження має запас дедлайну.
Втілений вуглець змінює розмову про обладнання: Заміна серверів новішим ефективним обладнанням може зменшити операційну енергію, але впливи виробництва й утилізації означають, що найкраща відповідь залежить від аналізу життєвого циклу, а не лише від споживання потужності.

Типові помилки

Помилка	Чому це трапляється	Як це виправити
Сприйняття сталості лише як проблеми інженерних служб	Команди застосунків задають запити, репліки, повтори, образи й розклади, що прямо впливають на попит на інфраструктуру.	Зробіть сталість частиною огляду навантажень і типових налаштувань платформи.
Зменшення реплік без перевірки потреб доступності	Менша кількість реплік може спричинити простої під час обслуговування вузлів, викочувань чи сплесків трафіку.	Класифікуйте навантаження й задокументуйте компроміс щодо надійності перед зменшенням реплік.
Надто агресивне зниження запитів пам’яті	Тиск пам’яті може витіснити Поди чи спричинити OOM-вбивства, призводячи до нестабільності й переробок.	Використовуйте історичні піки пам’яті та поведінку перезапуску перед зміною налаштувань пам’яті.
Очікування, що саме лише автомасштабування Подів зменшить викиди	Вузли можуть лишатися онлайн, якщо запити, DaemonSet’и чи інші навантаження заважають зменшенню.	Перевірте весь ланцюжок від реплік до планування й до прибирання вузлів.
Застосування вуглецево-обізнаного планування до живих API	Сервіси, що дивляться на користувача, зазвичай не можуть чекати на чистіші вікна мережі без шкоди затримці.	Залиште часове зміщення для пакетних, навчальних, звітних, CI та іншої відкладної роботи.
Видалення навантажень лише на основі низького трафіку	Деякі системи з низьким трафіком є інструментами відповідності, адміністрування чи аварійними з реальною цінністю.	Підтвердьте власність, призначення, залежності й шлях відновлення перед видаленням.
Оптимізація однієї метрики ізольовано	Екологічніший регіон може додати затримку, передачу даних, дубльоване зберігання чи ризик відповідності.	Оцінюйте вартість, вуглець, надійність, резидентність даних і вплив на користувача разом.
Вимірювання один раз і припущення, що результат постійний	Трафік, релізи, сезонні події та власність команд змінюються з часом.	Переглядайте тренди й плануйте повторювані аудити сталості.

Тест

1. Ваша команда знаходить Деплоймент із п’ятьма репліками, кожна з яких запитує одне повне ядро CPU, але метрики за останні два тижні показують, що кожна репліка зазвичай споживає менш ніж 100m CPU. Сервіс внутрішній, із низьким трафіком, і не є частиною шляху реагування на збої. Що ви маєте порекомендувати першим?

A) Негайно видалити Деплоймент, бо він явно невикористаний
B) Консервативно зменшити запити й кількість реплік, потім моніторити затримку, перезапуски та поведінку зменшення вузлів
C) Перемістити Деплоймент в інший хмарний регіон, бо вуглецево-обізнане планування завжди дає найбільші заощадження
D) Збільшити ліміт CPU, щоб сервіс завершував роботу швидше й викидав менше вуглецю

Відповідь

B) Консервативно зменшити запити й кількість реплік, потім моніторити затримку, перезапуски та поведінку зменшення вузлів. Докази вказують на надмірне виділення, але безпечна інженерна відповідь — виміряна зміна, а не видалення. Right-sizing запитів покращує упаковку, а зменшення реплік може бути доречним для внутрішнього сервісу з низьким трафіком. Верифікація має значення, бо виграш у сталості найсильніший, коли кластер справді може звільнити потужності чи прибрати вузли.

2. Платформна команда хоче застосувати вуглецево-обізнане планування до кожного навантаження в кластері. Кластер містить API оформлення замовлення з ціллю затримки 200 мс, нічний генератор інвойсів і щотижневу задачу навчання моделі машинного навчання. Які навантаження є найкращими кандидатами?

A) Лише API оформлення замовлення, бо воно має найбільшу бізнес-цінність
B) Генератор інвойсів і задача навчання, якщо їхні дедлайни й обмеження даних дозволяють зміщення
C) Усі три навантаження, бо вся електроенергія має вуглецевий вплив
D) Жодне з навантажень, бо Kubernetes не може запускати пакетні задачі

Відповідь

B) Генератор інвойсів і задача навчання, якщо їхні дедлайни й обмеження даних дозволяють зміщення. Вуглецево-обізнане планування найкраще працює для відкладних чи переміщуваних навантажень. API оформлення замовлення має відповідати негайно, тож його затримка зашкодила б користувачам. Пакетне звітування й задачі навчання часто мають запас дедлайну, але команді все одно потрібно перевірити резидентність даних, потужності й запасні правила.

3. Ваш дашборд GreenOps показує, що простір імен майже не має мережевого трафіку, але кілька Деплойментів досі резервують CPU й пам’ять. Мітка проєкту вказує на ініціативу, що завершилася місяці тому. Яка найвідповідальніша наступна дія?

A) Підтвердити власність і залежності, потім зменшити масштаб чи видалити зомбі-навантаження через узгоджений процес прибирання
B) Ігнорувати простір імен, бо низький мережевий трафік означає, що він не викидає вуглецю
C) Додати більше реплік, щоб простір імен був високодоступним, якщо хтось скористається ним пізніше
D) Перемістити простір імен в інший регіон, не запитуючи власника

Відповідь

A) Підтвердити власність і залежності, потім зменшити масштаб чи видалити зомбі-навантаження через узгоджений процес прибирання. Це ймовірно сценарій зомбі-навантаження, але видалення все одно має бути контрольованим. Неактивні навантаження можуть резервувати потужності й допомагати тримати вузли онлайн. Перевірки власності, перевірки залежностей і шлях відкату чи відновлення запобігають перетворенню прибирання заради сталості на операційний інцидент.

4. Фінансовий керівник каже: «Цього кварталу нас турбує лише вартість, а не вуглець». Лідер сталості каже: «Ми маємо ігнорувати вартість і обрати регіон із найнижчим вуглецем». Як платформній команді сформулювати перший план покращення?

A) Почати з дій усунення марнотратства, як-от right-sizing, прибирання та зменшення масштабу, бо вони зазвичай зменшують і вартість, і вуглець
B) Обрати лише найдешевший регіон, бо хмарні провайдери автоматично вирішують усі питання сталості
C) Обрати лише регіон із найчистішою мережею, бо затримка й передача даних не впливають на сталість
D) Зупинити програму, поки обидва керівники не погодяться на єдину метрику

Відповідь

A) Почати з дій усунення марнотратства, як-от right-sizing, прибирання та зменшення масштабу, бо вони зазвичай зменшують і вартість, і вуглець. FinOps і GreenOps сильно перекриваються, коли дія усуває непотрібну роботу. Переміщення регіонів можуть мати компроміси, але прибирання й right-sizing зазвичай легші перші дії. Таке формулювання дає обом керівникам вимірюваний прогрес, лишаючи складніші компроміси для явного огляду.

5. Команда знижує запити CPU для багатьох сервісів і бачить кращу заплановану потужність, але рахунок за хмару й кількість вузлів лишаються майже незмінними після кількох днів. Що їм слід дослідити далі?

A) Чи може автомасштабування кластера прибирати вузли, чи інші запити блокують упаковку і чи DaemonSet’и або групи вузлів задають мінімум
B) Чи встановлено Prometheus, бо Prometheus автоматично вимикає невикористані сервери
C) Чи кожен сервіс має ліміт пам’яті, бо ліміти пам’яті завжди зменшують кількість вузлів
D) Чи версія Kubernetes рівно 1.35, бо старіші патч-версії не можуть масштабуватися

Відповідь

A) Чи може автомасштабування кластера прибирати вузли, чи інші запити блокують упаковку і чи DaemonSet’и або групи вузлів задають мінімум. Менші запити допомагають лише тоді, коли решта системи може використати звільнені потужності. Мінімуми груп вузлів, накладні витрати DaemonSet’ів, решта роздутих запитів і обмеження розміщення — усе це може завадити прибиранню вузлів. Верифікація сталості має йти за повним ланцюжком масштабування.

6. Команда пропонує перемістити велику аналітичну задачу в чистіший регіон. Задача читає багато терабайтів із бази даних, що має лишатися в початковому регіоні з регуляторних причин. Яка найкраща оцінка?

A) Перемістити задачу попри все, бо чистіша електроенергія завжди виграє
B) Відхилити будь-яке вуглецево-обізнане планування для організації
C) Порівняти вуглецеві заощадження з передачею даних, дубльованим зберіганням, обмеженнями відповідності, часом виконання та вимогами дедлайну
D) Прибрати ліміти ресурсів із задачі, щоб вона завершилася, перш ніж мережа стане бруднішою

Відповідь

C) Порівняти вуглецеві заощадження з передачею даних, дубльованим зберіганням, обмеженнями відповідності, часом виконання та вимогами дедлайну. Просторове зміщення може зменшити вуглець, але воно не є автоматично правильним. Переміщення великих наборів даних може створити додаткові мережеві та накопичувальні накладні витрати, а регуляторні обмеження можуть цілком заблокувати переміщення. Сеньйорна оцінка розглядає систему в цілому, а не одне число вуглецевої інтенсивності.

7. Ваша команда хоче бачити енергоспоживання окремих навантажень для просторів імен Kubernetes, щоб власники сервісів могли пріоритезувати оптимізацію. Хмарний провайдер дає лише загальні інфраструктурні звіти. Який підхід найкраще відповідає потребі?

A) Розгорнути телеметрію енергії на рівні навантажень, як-от Kepler, і експортувати метрики в Prometheus для аналізу просторів імен і Подів
B) Використовувати лише kubectl get pods, бо імен Подів достатньо, щоб точно обчислити вуглець
C) Замінити кожен Деплоймент на StatefulSet, бо StatefulSet’и сталіші
D) Вимкнути всі ліміти, щоб навантаження могли вільніше ділити вузли

Відповідь

A) Розгорнути телеметрію енергії на рівні навантажень, як-от Kepler, і експортувати метрики в Prometheus для аналізу просторів імен і Подів. Kepler призначений оцінювати й надавати пов’язані з енергією метрики для навантажень Kubernetes. Вимірювання все одно потребують обережного тлумачення, але вони дають командам значно кращі докази, ніж лише загальні інфраструктурні звіти. Імена й типи контролерів самі по собі не дають приписування енергії.

Практична вправа: побудуйте план огляду GreenOps

Мета: Відпрацювати діагностику марнотратства сталості й проєктування безпечного плану покращення для робочого навантаження Kubernetes. Ця вправа — самостійна робота; опрацьований приклад вище показав патерн міркування, а тепер ви застосуєте його до іншого сценарію без наданого розв’язку.

Ви переглядаєте staging-навантаження для сервісу конвертації документів. Продакт-менеджери кажуть, що сервіс потрібен у робочі години для тестування, але вночі він отримує майже жодних запитів. Розробники також згадують, що конвертації ставляться в чергу, тож короткі затримки прийнятні під час staging-тестів. Перегляньте маніфест і створіть план GreenOps, що покращує сталість, не вдаючи, що надійність staging неважлива.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: document-converter-staging
  labels:
    app: document-converter
    environment: staging
    owner: docs-team
spec:
  replicas: 4
  selector:
    matchLabels:
      app: document-converter
      environment: staging
  template:
    metadata:
      labels:
        app: document-converter
        environment: staging
    spec:
      containers:
        - name: converter
          image: nginx:1.27
          resources:
            requests:
              cpu: "1500m"
              memory: "2Gi"
            limits:
              cpu: "2"
              memory: "3Gi"

Завдання

Створіть коротку нотатку огляду, що містить три частини. По-перше, визначте ймовірні джерела марнотратства в маніфесті й поясніть, чому кожне з них має значення для планування, кількості вузлів чи енергії, що витрачається в простої. По-друге, запропонуйте безпечніший переглянутий маніфест або напрям політики, як-от нижчі запити, менше реплік, кероване подіями масштабування, зменшення поза робочими годинами чи підхід масштабування на основі черги. По-третє, визначте, як ви б верифікували зміну після викочування за допомогою метрик або команд Kubernetes.

Запропоновані команди

Використовуйте ці команди як приклади, якщо у вас є практичний кластер Kubernetes 1.35+. Це безпечні команди інспекції, і вони допомагають пов’язати паперову вправу з реальними операціями кластера. Якщо у вас немає доступного кластера, опишіть очікувані докази, які ви б запросили в платформної команди.

k get deployment document-converter-staging -o yaml
k top pods -l app=document-converter
k get pods -l app=document-converter -o wide
k describe deployment document-converter-staging

Псевдонім k було введено раніше в модулі. Це лише скорочення оболонки для kubectl; воно не змінює авторизацію, контекст, поведінку простору імен чи безпеку команди.

k get deployment document-converter-staging

Критерії успіху

Ваш огляд визначає щонайменше три ймовірні джерела марнотратства, зокрема кількість реплік, запити ресурсів, простій staging-середовища або відсутнє масштабування з урахуванням черги.
Ваші рекомендації розрізняють безпечні staging-зміни й ризиковані продакшн-припущення, а не заявляють, що всі навантаження мають масштабуватися до нуля.
Ваш план пояснює, як зміна могла б зменшити тиск на вузли чи енергію, що витрачається в простої, а не лише як вона змінює YAML.
Ваш розділ верифікації містить щонайменше два вимірювані сигнали, як-от спостережуваний CPU, спостережувана пам’ять, кількість реплік, очікувані Поди, кількість вузлів, затримка, глибина черги чи кількість перезапусків.
Ваш план містить відкат чи запобіжник, як-от відновлення реплік, збільшення запитів, спостереження за OOM-вбивствами чи встановлення мінімуму реплік у робочі години.
Ваша відповідь використовує той самий патерн міркування, що й опрацьований приклад: класифікуйте навантаження, порівняйте запити з використанням, оберіть практику, потім верифікуйте результат.

Рефлексія

Коли завершите, запитайте, чи ваш план заощаджує вуглець, усуваючи реальне марнотратство, чи лише переносить ризик на іншу команду. Хороші зміни GreenOps вимірювані й оборотні. Вони покращують систему ресурсів, зберігаючи обіцянки сервісу, що досі мають значення.

Джерела

Документація Kubernetes: керування ресурсами для Подів і контейнерів
Документація Kubernetes: горизонтальне автомасштабування Подів
Документація Kubernetes: CronJob
Документація Kubernetes: керування ресурсами за допомогою kubectl
Kubernetes Autoscaler: Cluster Autoscaler
Kubernetes Autoscaler: Vertical Pod Autoscaler
CNCF TAG Environmental Sustainability
Документація проєкту Kepler
Документація KEDA: масштабування Деплойментів, StatefulSet’ів і користувацьких ресурсів
Документація Knative: налаштування меж масштабування
Проєкт Fairwinds Goldilocks
Green Software Foundation: Carbon Aware SDK
Green Software Foundation: специфікація Software Carbon Intensity
kubernetes.io: pods — Документація Подів прямо каже, що kube-scheduler використовує запити ресурсів для вибору розміщення на вузлі.
kubernetes.io: node autoscaling — Документація автомасштабування вузлів охоплює виділення для непланованих Подів, консолідацію й той факт, що рішення про консолідацію використовують запити, а не реальне використання.
tag-env-sustainability.cncf.io: about — Офіційна сторінка «About» TAG прямо описує його призначення й обсяг.
github.com: kepler — README репозиторію Kepler описує його як експортер Prometheus, що вимірює метрики енергоспоживання для навантажень Kubernetes.
github.com: quickstart.md — Швидкий старт VPA каже, що VPA готовий рекомендувати й встановлювати запити ресурсів для Подів.
github.com: keda — README KEDA описує KEDA як кероване подіями автомасштабування для Kubernetes і прямо згадує масштабування, зокрема до нуля й від нуля.
github.com: serving — README Knative Serving прямо перелічує автоматичне масштабування вгору й вниз до нуля серед своїх примітивів.
cncf.io: kepler — Сторінка проєкту CNCF прямо стверджує, що Kepler було прийнято на рівні зрілості Sandbox.

Наступний модуль

Вітаємо! Ви завершили Частину 3: Cloud Native архітектура. Переходьте до Частини 4, щоб дослідити доставку застосунків.