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

Складність: [QUICK] - Рівень обізнаності

Час на виконання: 20-25 хвилин

Передумови: Модуль 3.1 (Хмарні нативні принципи), Модуль 3.2 (Екосистема CNCF)

Що ви зможете робити

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

Пояснити вплив хмарних обчислень на довкілля та TAG CNCF для екологічної сталості
Визначити функції Kubernetes, що зменшують марнування ресурсів: bin packing, автомасштабування та правильний розмір
Порівняти стратегії зменшення вуглецевого сліду: планування навантажень, spot instances та обмеження ресурсів
Оцінити як практики зеленого обчислення узгоджуються з оптимізацією витрат у cloud native середовищах

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

Дата-центри споживають 1-2% глобальної електроенергії — приблизно стільки ж, як уся авіаційна галузь. Зі зростанням впровадження cloud native зростає й екологічний слід. CNCF визнала це, створивши спеціальну TAG (Technical Advisory Group) для екологічної сталості. KCNA очікує обізнаності щодо того, як хмарні нативні практики перетинаються зі сталістю та що спільнота робить з цим.

“Найзеленіші обчислення — це ті, які ви не використовуєте.”

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

Вуглецевий слід хмари

┌─────────────────────────────────────────────────────────────┐
│              ВПЛИВ ХМАРИ НА ДОВКІЛЛЯ                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Дата-центри глобально:                                    │
│  • 1-2% глобального споживання електроенергії              │
│  • Зростання на 20-30% щорічно з попитом AI/ML            │
│  • Один великий кампус гіперскейлера може споживати       │
│    більше електроенергії, ніж невелике місто               │
│                                                             │
│  Куди йде енергія:                                         │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  ОБЧИСЛЕННЯ████████████████████████  ~40-50%               │
│  ОХОЛОДЖ.  ████████████████         ~30-40%                │
│  СХОВИЩЕ   ██████                   ~10-15%                │
│  МЕРЕЖА    ████                     ~5-10%                 │
│                                                             │
│  Джерела вуглецю:                                          │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  ОПЕРАЦІЙНИЙ  Енергія, споживана при роботі навантажень   │
│  (Scope 2)    → Залежить від електромережі                │
│                                                             │
│  ВТІЛЕНИЙ     Виробництво серверів, GPU, мережевого       │
│  (Scope 3)    обладнання → Фіксована вартість незалежно   │
│               від використання                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чому Cloud Native робить це кращим (і гіршим)

Перевага Cloud Native	Вплив на сталість
Автомасштабування	Зменшення масштабу при простої = менше витраченої енергії
Контейнеризація	Вища щільність на сервер = менше серверів потрібно
Мікросервіси	Можна масштабувати окремі компоненти, не моноліти
Масштабування до нуля	Serverless/KEDA може усунути споживання при простої

Ризик Cloud Native	Вплив на сталість
Надмірне забезпечення	Запит 4 CPU при використанні 0.5 = 87% марнотратства
Зомбі-навантаження	Забуті Deployments, що працюють нескінченно
Вибух AI/ML	GPU-інтенсивне тренування споживає величезну кількість енергії
Розростання мікросервісів	200 сервісів з sidecar проксі додають накладні витрати

CNCF TAG Environmental Sustainability

CNCF TAG Environmental Sustainability — організоване зусилля спільноти щодо впливу cloud native на довкілля.

┌─────────────────────────────────────────────────────────────┐
│              TAG ENVIRONMENTAL SUSTAINABILITY                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Що таке TAG:                                               │
│  Technical Advisory Groups — міжпроєктні робочі групи,     │
│  що консультують спільноту CNCF з конкретних тем           │
│                                                             │
│  Що робить ця TAG:                                          │
│  ─────────────────────────────────────────────────────────  │
│  • Визначає найкращі практики сталого cloud native        │
│  • Оцінює інструменти та проєкти на енергоефективність    │
│  • Публікує Cloud Native Sustainability Landscape          │
│  • Просуває вуглецеву обізнаність у проєктах CNCF         │
│  • Створює стандарти вимірювання впливу на довкілля        │
│                                                             │
│  Ключовий результат: Cloud Native Sustainability Landscape  │
│  (карта інструментів та проєктів повʼязаних зі сталістю)  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Для KCNA: Знайте, що CNCF має TAG спеціально для Environmental Sustainability і що спільнота ставиться до цього серйозно.

Kepler: Вимірювання енергії на Pod

Kepler (Kubernetes-based Efficient Power Level Exporter) — найважливіший проєкт у цій сфері. Не можна зменшити те, чого не можна виміряти.

┌─────────────────────────────────────────────────────────────┐
│              KEPLER                                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Що: Експортує метрики споживання енергії на Pod           │
│  Як:  Використовує eBPF та апаратні лічильники (RAPL,     │
│       ACPI)                                                │
│  Вихід: Метрики Prometheus (Вати на Pod/контейнер)         │
│  Статус: Проєкт CNCF Sandbox                              │
│                                                             │
│  ┌──────────────────────────────────────────────────┐      │
│  │                Вузол Kubernetes                   │      │
│  │                                                    │      │
│  │  ┌─────────────┐  ┌─────────────┐                │      │
│  │  │   Pod A      │  │   Pod B      │                │      │
│  │  │  150 мВт     │  │  800 мВт     │                │      │
│  │  └─────────────┘  └─────────────┘                │      │
│  │                                                    │      │
│  │  ┌──────────────────────────────────────────┐    │      │
│  │  │  Kepler (DaemonSet)                       │    │      │
│  │  │  Використовує eBPF для відстеження       │    │      │
│  │  │  циклів CPU на Pod                        │    │      │
│  │  │  Відображає цикли → енергію через         │    │      │
│  │  │  моделі потужності                        │    │      │
│  │  │  Експортує як метрики Prometheus          │    │      │
│  │  └──────────────────────────────────────────┘    │      │
│  └──────────────────────────────────────────────────┘      │
│                          │                                  │
│                          ▼                                  │
│                    Prometheus → Grafana                     │
│                    (енергетичні дашборди)                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ключовий висновок: Kepler дає видимість споживання енергії на рівні Pod. Без нього ви знаєте лише загальне споживання сервера — ви не можете визначити, які навантаження відповідальні. Це як алокація витрат у FinOps, але для вуглецю.

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

Не вся електроенергія однакова. Кіловат-година опівночі в Норвегії (гідроенергія) має значно менший вуглецевий вплив, ніж кіловат-година опівдні у мережі з переважанням вугілля.

┌─────────────────────────────────────────────────────────────┐
│              ВУГЛЕЦЕВО-ОБІЗНАНЕ ПЛАНУВАННЯ                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Ідея: Запускайте навантаження КОЛИ і ДЕ мережа           │
│  найчистіша                                                │
│                                                             │
│  ЧАСОВЕ ЗМІЩЕННЯ (коли)                                     │
│  ─────────────────────────────────────────────────────────  │
│  Відкладіть несрочні завдання на час, коли вуглецева       │
│  інтенсивність мережі найнижча                             │
│                                                             │
│  Приклад: Тренувальне завдання може працювати вночі,       │
│  коли вітрова енергія на піку і мережа на 80% чистіша     │
│                                                             │
│  ┌────────────────────────────────────────────┐            │
│  │  Вуглецева інтенсивність протягом 24 годин:│            │
│  │                                            │            │
│  │  Висока████                    ████        │            │
│  │        ████████            ████████        │            │
│  │  Низька    ████████████████                │            │
│  │       6:00   полудень 18:00  опівніч       │            │
│  │                                            │            │
│  │  → Плануйте пакетні завдання в НИЗЬКІ вікна│            │
│  └────────────────────────────────────────────┘            │
│                                                             │
│  ПРОСТОРОВЕ ЗМІЩЕННЯ (де)                                   │
│  ─────────────────────────────────────────────────────────  │
│  Направляйте навантаження в регіони з чистішою мережею     │
│                                                             │
│  Приклад: Запускайте у Швеції (гідро) замість              │
│  Польщі (вугілля) коли можливо                             │
│                                                             │
│  Джерело даних: API вуглецевої інтенсивності               │
│  (WattTime, Electricity Maps, Carbon Aware SDK)            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Важливий нюанс: Вуглецево-обізнане планування працює лише для відкладних або переміщуваних навантажень. Ваш продакшен API, що обслуговує запити користувачів, не може чекати до опівночі. Але пакетна обробка, тренування моделей, бекапи та CI/CD пайплайни часто можуть.

Сталі хмарні нативні практики

Правильний розмір: Найбільший виграш

Найвпливовіше, що більшість організацій може зробити — припинити надмірне забезпечення.

┌─────────────────────────────────────────────────────────────┐
│              ПРОБЛЕМА НАДМІРНОГО ЗАБЕЗПЕЧЕННЯ                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Типове використання кластера Kubernetes: 15-25%           │
│                                                             │
│  Запитано:  ████████████████████████████████  2 CPU       │
│  Фактично                                                  │
│  використ.: ████████                          0.5 CPU     │
│                                                             │
│  Це означає 75% виділених ресурсів МАРНУЮТЬСЯ              │
│  Витрачені ресурси = витрачена енергія = витрачений вуглець│
│                                                             │
│  Рішення:                                                  │
│  ─────────────────────────────────────────────────────────  │
│  • VPA (Vertical Pod Autoscaler): авто-налаштування запитів│
│  • Регулярні аудити: перегляд запитів ресурсів vs          │
│    фактичне використання                                   │
│  • Goldilocks: рекомендує налаштування ресурсів            │
│    на навантаження                                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ключові практики

Практика	Що це означає	Вплив
Правильний розмір	Узгодження запитів ресурсів з фактичним використанням	Зменшує витрачені обчислення на 50-75%
Масштабування до нуля	Вимкнення навантажень без трафіку (KEDA, Knative)	Усуває споживання енергії при простої
Spot/preemptible інстанси	Використання надлишкової хмарної потужності	Використовує ресурси, що вже існують
Ущільнення	Ефективне пакування Podʼів на менше вузлів	Менше увімкнених вузлів
Автомасштабування кластера	Видалення вузлів при зниженні попиту	Зменшення інфраструктури, не лише Podʼів
Знищення зомбі-навантажень	Пошук та видалення забутих Deployments	Припиняє витрачати енергію на невикористані сервіси
Ефективні образи	Менші образи контейнерів, distroless бази	Менше мережевих передач, швидше завантаження

GreenOps: Де FinOps зустрічає сталість

┌─────────────────────────────────────────────────────────────┐
│              GREENOPS                                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  FinOps:    "Скільки КОШТУЄ це навантаження?"              │
│  GreenOps:  "Скільки ВУГЛЕЦЮ випускає це навантаження?"   │
│                                                             │
│  Вони значно перетинаються:                                │
│  ─────────────────────────────────────────────────────────  │
│  • Надмірно забезпечені ресурси витрачають гроші І енергію │
│  • Простоюючі навантаження коштують грошей І випускають    │
│    вуглець                                                 │
│  • Правильний розмір економить гроші І зменшує викиди      │
│  • Spot інстанси дешевші І використовують надлишкову       │
│    потужність                                              │
│                                                             │
│  Ключова відмінність:                                       │
│  ─────────────────────────────────────────────────────────  │
│  • Метрика FinOps: долари                                  │
│  • Метрика GreenOps: грами CO2 еквіваленту (gCO2eq)       │
│                                                             │
│  GreenOps додає:                                            │
│  • Вуглецеву інтенсивність електромережі                  │
│  • Втілений вуглець обладнання                             │
│  • Вуглецево-обізнані рішення планування                   │
│  • Звітність та відповідність щодо сталості               │
│                                                             │
│  ┌─────────────────────────────────────┐                   │
│  │  FinOps ∩ GreenOps = зменшення     │                   │
│  │  марнотратства                      │                   │
│  │                                     │                   │
│  │  Більшість дій FinOps також є       │                   │
│  │  хорошими діями GreenOps            │                   │
│  └─────────────────────────────────────┘                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Інструменти та проєкти

Інструмент/Проєкт	Що він робить	Статус
Kepler	Вимірює споживання енергії на Pod використовуючи eBPF	CNCF Sandbox
Green Software Foundation	Міжгалузева організація, що визначає патерни та стандарти зеленого ПЗ	Галузевий орган
Carbon Aware SDK	Бібліотека для запитів вуглецевої інтенсивності електромереж	Green Software Foundation
Kube-green	Автоматично вимикає непродакшен навантаження у неробочий час	Відкритий код
Goldilocks	Рекомендує правильний розмір запитів ресурсів використовуючи дані VPA	Відкритий код Fairwinds
Cloud Carbon Footprint	Оцінює вуглецеві викиди від використання хмарного провайдера	Відкритий код (ThoughtWorks)

Чи знали ви?

Тренування однієї великої AI моделі може випустити стільки CO2, скільки пʼять автомобілів за все їхнє життя — Дослідники оцінили, що тренування GPT-3 спожило приблизно 1,287 МВт·год електроенергії. Бум AI робить сталість дата-центрів найбільш актуальною інфраструктурною проблемою десятиліття.
Більшість кластерів Kubernetes працюють при 15-25% використання — Це означає, що 75-85% забезпечених обчислювальних потужностей витрачаються марно. Якби кожна організація правильно підібрала розмір своїх кластерів, колективна економія енергії була б величезною — еквівалентною закриттю тисяч дата-центрів по всьому світу.
Ісландія та Скандинавія стають центрами AI дата-центрів — Не лише через холодне повітря (безкоштовне охолодження), але й через багату відновлювану енергію (геотермальну, гідро, вітрову). Вуглецево-обізнані рішення щодо розташування вже перетворюють те, де будуються дата-центри.

Поширені помилки

Помилка	Чому це шкодить	Правильне розуміння
Ігнорувати сталість як “не моя робота”	Регуляторний та клієнтський тиск зростає	Інженери приймають рішення щодо забезпечення, що визначають споживання енергії
Зосереджуватись лише на операційному вуглеці	Пропускаєте велику частину	Втілений вуглець (виробництво обладнання) може бути 50%+ загального — продовження терміну служби обладнання має значення
Надмірне забезпечення “на всякий випадок”	Типова поведінка у більшості організацій, масове марнотратство	Використовуйте автомасштабування та VPA замість статичного надмірного забезпечення
Вважати що хмара = зелено	Хмарні провайдери не є вуглецево-нейтральними за замовчуванням	Регіон хмари та час доби мають значення; не всі регіони використовують відновлювану енергію
Вуглецево-обізнане планування для всього	Не всі навантаження можна відкласти	Лише відкладні навантаження (пакетні, тренування, CI/CD) отримують вигоду; чутливі до затримок сервіси не можуть чекати

Тест

1. Що вимірює Kepler у кластері Kubernetes?

A) Затримку мережі між Podʼами B) Споживання енергії на Pod C) Вуглецеву інтенсивність електромережі D) Фінансову вартість кожного навантаження

Відповідь

B) Споживання енергії на Pod. Kepler (Kubernetes-based Efficient Power Level Exporter) використовує eBPF та апаратні лічильники потужності для оцінки споживання енергії на рівні Pod, експортуючи метрики до Prometheus. Це проєкт CNCF Sandbox.

2. Що таке вуглецево-обізнане планування?

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

Відповідь

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

3. Який типовий рівень використання ресурсів у кластерах Kubernetes?

A) 80-90% B) 50-60% C) 15-25% D) 1-5%

Відповідь

C) 15-25%. Більшість кластерів Kubernetes значно надмірно забезпечені, працюючи лише при 15-25% використання. Це означає, що 75-85% виділених ресурсів витрачаються марно. Правильний підбір розміру запитів ресурсів — найбільший виграш сталості для більшості організацій.

4. Яка група CNCF зосереджена на екологічній сталості в cloud native?

A) SIG-Scheduling B) TAG Environmental Sustainability C) WG-Green-Compute D) SIG-Energy

Відповідь

B) TAG Environmental Sustainability. CNCF має спеціальну Technical Advisory Group (TAG) для Environmental Sustainability, що визначає найкращі практики, оцінює інструменти та просуває вуглецеву обізнаність у хмарній нативній екосистемі.

5. Як GreenOps повʼязаний з FinOps?

A) Це абсолютно не повʼязані дисципліни B) GreenOps замінює FinOps C) Вони значно перетинаються — зменшення марнотратства економить і гроші, і вуглець D) FinOps є підмножиною GreenOps

Відповідь

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

6. Які навантаження найкраще підходять для вуглецево-обізнаного планування?

A) Усі продакшен навантаження B) Чутливі до затримок API endpointʼи C) Відкладні навантаження як пакетні завдання, тренування моделей та CI/CD пайплайни D) Лише середовища розробки

Відповідь

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

Підсумок

Дата-центри споживають 1-2% глобальної електроенергії — швидко зростаючи з попитом AI/ML
CNCF TAG Environmental Sustainability очолює зусилля спільноти
Kepler (CNCF Sandbox) вимірює споживання енергії на Pod використовуючи eBPF
Вуглецево-обізнане планування: запускайте відкладні навантаження коли/де мережа найчистіша (часове та просторове зміщення)
Правильний розмір — найбільший виграш — більшість кластерів працюють лише при 15-25% використання
Ключові практики: правильний розмір, масштабування до нуля, spot інстанси, ущільнення, знищення зомбі-навантажень
GreenOps = FinOps + сталість; зменшення марнотратства економить гроші І вуглець
Памʼятайте: найзеленіші обчислення — це ті, які ви не використовуєте

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

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