Хмарна площина керування
Хмарна площина керування — це рівень інтерфейсів, API та сервісів, які дають змогу створювати, налаштовувати та керувати інфраструктурою, — окремо від площини даних, яка безпосередньо виконує ваші робочі навантаження та передає трафік. Кожен провайдер має власну; цей термін також охоплює системи, що керують кількома провайдерами як єдиною площиною.
Кожен елемент інфраструктури має два окремі рівні. Площина даних — це сама інфраструктура: віртуальні машини, що виконують ваш застосунок, мережа, яка передає пакети між ними, диск, що обробляє читання та запис. Площина керування — це все, що ви використовуєте, щоб вирішити, якою має бути ця інфраструктура, і змінити її: API, консоль, CLI, система прав доступу, яка визначає, хто може вносити зміни. Коли ви створюєте віртуальну машину в консолі хмарного провайдера, змінюєте розмір диска чи відкриваєте порт у брандмауері, ви працюєте саме з площиною керування. Екземпляр, що завантажується, додаткові гігабайти, які стають доступними, трафік, що починає надходити, — це площина даних, яка реагує на те, що їй сказала зробити площина керування.
Ця відмінність стає особливо корисною, коли команда працює з більш ніж одним провайдером. AWS має власну площину керування. Так само Google Cloud, Azure, Hetzner і кожен інший провайдер — кожен зі своєю консоллю, власною формою API, власними обліковими даними, власним уявленням про те, як називається «security group» чи «firewall rule». Команда, що працює з трьома хмарами та двадцятьма фізичними серверами, насправді керує трьома чи чотирма окремими площинами керування одночасно, плюс тим, що вона використовує для керування серверами, які взагалі не перебувають у жодній хмарі. Ніщо не змушує ці площини керування узгоджуватися одна з одною, і ніщо поза вашим власним процесом не робить зміну, внесену в одній із них, видимою для того, хто дивиться на іншу.
«Хмарна площина керування» також використовується у вужчому значенні — у Kubernetes площина керування це API-сервер, планувальник (scheduler) і controller-manager, які вирішують, де запускати поди, на відміну від kubelets і контейнерів, що безпосередньо виконують їх на вузлах. «Мультихмарна» або «уніфікована» площина керування розширює ту саму ідею на кількох провайдерів: єдине місце, щоб бачити інфраструктуру, яка фізично перебуває в кількох різних облікових записах, регіонах і у різних постачальників, і діяти щодо неї, замість окремого інтерфейсу для кожного провайдера. Вона не замінює базові площини керування провайдерів — запит все одно перетворюється на виклик API до AWS, Hetzner чи fleet-агента на фізичному сервері, — вона розташована поверх них, щоб той, хто вносить зміну, мав вивчити лише одну систему.
Чому ця відмінність важлива на практиці
Більшість інцидентів з інфраструктурою та прогалин в аудиті мають корені саме в проблемах площини керування, а не площини даних: зміна, яку ніхто не залогував, право доступу, яке ніхто не відкликав, правило брандмауера, відкрите в консолі одного провайдера, яке більше ніхто в команді не бачить. Коли кожна хмара має власну площину керування й власний журнал аудиту, питання «хто це змінив і коли» перетворюється на те, на яке доводиться відповідати, входячи в три чи чотири різні консолі та вручну звіряючи часові мітки — або не відповідати на нього взагалі. Для команд, що працюють у межах комплаєнс-фреймворків, таких як NIS2, ця прогалина — не просто незручність: історія змін, контроль доступу та докази інцидентів — це саме те, що аудитор чи регулятор запитує в першу чергу, і фрагментована площина керування — причина, чому ці докази часто не зібрані в одному місці.
Як тут допомагає Sencai
Sencai — це площина керування, яка розташована над нативними: вона підключається до облікових записів в одинадцяти хмарних провайдерах, а також до локальних (on-premise) і фізичних серверів через легкий fleet-агент, і інвентаризує все, що вже працює, одразу після підключення облікового запису — без потреби в міграції. Далі створення, запуск, зупинка, зміна розміру та видалення інстансів працюють однаково незалежно від провайдера. Ви можете підключити наявні облікові записи (нічого не переміщується, облікові дані залишаються відкличними на стороні провайдера) або дозволити Sencai безпосередньо виділяти й виставляти рахунки за потужності — і поєднувати обидва підходи в одній організації. Кожна дія в кожному підключеному провайдері потрапляє до єдиного незмінного (append-only) журналу аудиту з ланцюжком хешів, тож «хто це змінив і коли» — це запит, а не розслідування.
Переглянути інвентаризацію та надання ресурсів →