текст перекладу
Коротка історія баз даних
Бази даних були невід’ємною частиною зберігання та отримання інформації протягом століть, еволюціонуючи від простих бібліотечних каталогів до складних цифрових систем. Ранні бази даних були ієрархічними та орієнтованими на дерева, але реляційні бази даних здійснили революцію в зберіганні даних у 1970-х роках за допомогою мови структурованих запитів (SQL). З часом з’явилися NoSQL бази даних для роботи з неструктурованими даними, а графові бази даних набули популярності завдяки своїй здатності обробляти складні зв'язки.
Перехід від традиційного файлового зберігання до баз даних дозволив швидший та ефективніший доступ до даних. У сучасному світі бази даних служать основою численних додатків — від корпоративних систем до технологій, що працюють на ШІ. Проте їх структура і філософія суттєво відрізняються від онтологій, що впливає на їх придатність для пам'яті агентів ШІ.
Створення реляційних баз даних
Реляційні бази даних спираються на структуровані таблиці з попередньо визначеними схемами. Процес створення включає:
- Нормалізація: Організація даних для зменшення надлишковості та покращення узгодженості шляхом структурування інформації в зв'язані таблиці.
- Визначення схеми: Створення таблиць, визначення атрибутів, налаштування обмежень і встановлення зв'язків між таблицями для забезпечення цілісності даних.
- Оптимізація запитів: Використання індексації, кешування та оптимізації для підвищення продуктивності і забезпечення ефективного отримання даних.
- Цілісність і узгодженість даних: Забезпечення обмежень на дані, використання первинних і зовнішніх ключів та забезпечення транзакційної цілісності за допомогою принципів ACID (атомарність, цілісність, ізоляція, довговічність).
Це завжди будується з нуля.
Реляційні бази даних відмінно підходять для зберігання структурованих даних, але мають труднощі з гнучкими та змінними моделями даних, що робить їх менш адаптованими для агентів ШІ, які потребують відкритого навчання. Жорсткість схем може обмежувати здатність динамічно включати нові знання.
Створення онтологій
Онтології, на відміну від баз даних, визначають зв'язки та значення між концепціями, а не просто зберігають дані. Створення онтологій включає пошук хороших, вже описаних і взаємодіючих основ:
- Основні онтології: Створення абстрактних, загальних концепцій та зв'язків, які служать основою для більш специфічних онтологій.
- Онтології за галузями: Розширення знань у певній області, наприклад, у медицині чи фінансах, для уточнення і надання більшої специфікації.
- Бізнесові та прикладні онтології: Налаштування знань для бізнес-додатків, що забезпечує узгодженість з галузевими стандартами та потребами підприємств.
- Взаємодія онтологій: Забезпечення сумісності між різними онтологіями для забезпечення безперебійного обміну даними та інтеграції між агентами ШІ та системами.
Онтології сприяють міркуванню та висновку знань, що робить їх підходящими для агентів ШІ, які повинні еволюціонувати разом з новою інформацією. Вони підтримують адаптивність, дозволяючи ШІ робити висновки з існуючих відносин без необхідності вручну оновлювати їх.
NULL проти Я не знаю
Реляційні бази даних працюють за принципом Closed World Assumption (CWA) — якщо факт не є в базі даних, то він вважається хибним. Відсутні дані призводять до значення NULL, що означає, що система не може надати визначену відповідь.
Онтології працюють за принципом Open World Assumption (OWA) — відсутність даних не означає їх неіснування, це просто відсутність знань. Агентам ШІ це підходить, оскільки вони можуть поступово удосконалювати свої знання без явних прогалин. На відміну від реляційних баз даних, де відсутність значень може порушити запити, системи на основі онтологій можуть робити припущення про можливі відносини або запитувати додаткову інформацію.
Дедуктивні бази даних
Дедуктивні бази даних використовують логічні правила для виведення нових фактів з існуючих даних. Вони включають:
- Запити на основі правил: Використання мов програмування на основі логіки, таких як Datalog, для виведення прихованих знань з явних фактів.
- Рекурсивне виведення: Встановлення відносин між різними точками даних через логічне доведення, що дозволяє агентам ШІ робити висновки за межами збережених фактів.
- Автоматичне міркування: Покращення інтелекту бази даних за допомогою виведених висновків, покращуючи процеси прийняття рішень без потреби прямого втручання людини.
Хоча потужні, дедуктивні бази даних залишаються обмеженими попередньо визначеними правилами і не мають адаптивності в динамічних середовищах. На відміну від онтологій, вони не можуть легко пристосуватися до еволюційних знань.
Щоб дізнатися більше про дедуктивні бази даних
Графові бази даних у відкритому світі
Графові бази даних зберігають дані у вигляді вузлів і зв'язків, що робить їх більш підходящими для динамічних архітектур пам'яті ШІ. Їхні особливості включають:
- Гнучка схема: Легко адаптується до нових даних та відносин, на відміну від реляційних баз даних, які вимагають жорстких схем.
- Ефективні запити на відносини: Оптимізовані для отримання з'єднаних даних, графові бази даних показують надзвичайно хороші результати у знаннявих графах, що базуються на ШІ.
- Масштабованість для складних мереж: Підтримують графи знань і механізми виведення, дозволяючи ефективно представляти ієрархічну та взаємопов'язану інформацію.
Агенти ШІ, що використовують графові бази даних, можуть безперешкодно інтегрувати нову інформацію без необхідності змінювати схему, на відміну від реляційних баз даних. Така структура дозволяє ШІ робити складні висновки на основі відносин між концепціями.
Виклик іменування в відкритому світі
Онтології та графові бази даних стикаються з проблемами унікальної ідентифікації сутностей у відкритих світах. На відміну від реляційних баз даних, де існують строгі ідентифікатори, пам'ять ШІ повинна:
- Обробляти неоднозначність: Розрізняти подібні сутності, використовуючи контекст та семантичні відносини.
- Підтримувати еволюцію ідентичностей: Пристосовуватися до змін властивостей сутностей з часом без необхідності вручну оновлювати схему.
- Забезпечувати сумісність: Забезпечити послідовність іменувань через різні набори даних за допомогою глобально унікальних ідентифікаторів.
Технології семантичного вебу, такі як RDF та OWL, допомагають вирішити ці проблеми, надаючи стандартизовані рамки для представлення сутностей.
Онтології — це про взаємодію
Одна з основних переваг онтологій — це їх взаємодія між різними системами. Вони надають спільне розуміння, що сприяє:
- Обміну даними: Безшовна інтеграція між агентами ШІ, забезпечуючи ефективну комунікацію та співпрацю.
- Повторне використання знань: Стандартизовані рамки для навчання ШІ, знижуючи надмірність і підвищуючи ефективність знань.
- Міжгалузеве міркування: Об’єднання різних джерел знань у єдину структуру, що дозволяє агентам ШІ робити висновки через різні галузі.
Онтології дозволяють агентам ШІ взаємодіяти з різноманітними наборами даних, покращуючи їх здатність до міркування та сприяючи семантичній взаємодії.
Вірність та гнучкість онтологій
Онтології надають структуровану, але адаптивну основу для представлення знань. Ключові переваги включають:
- Висока точність представлення: Збереження складних відносин у галузі, при цьому зберігаючи семантичну багатогранність.
- Динамічний розвиток: Легко адаптуються до нових знань, розширюючи існуючі онтології, а не жорстко перевизначаючи схеми.
- Неперевершена гнучкість: Можливість додавати нові знання без порушення існуючих структур.
текст перекладу
Edge Computing
Давайте уточнимо одне питання, Edge computing означає практику обробки даних ближче до джерела їх генерування (на "краю" мережі), а не лише в централізованих дата-центрах або хмарній інфраструктурі. Для нас це означає обробку даних безпосередньо в магазинах, складах тощо.
Проблема
Отже, давайте повернемося на крок назад. У нас є повністю функціональне розгортання, яке можна масштабувати та впроваджувати на тисячах хостів, але тепер нам потрібно це підтримувати? Хіба ми не мали б виявити це ще на початку? Так, зараз поясню:
Розуміння операцій Day 0, Day 1 та Day 2
У світі управління життєвим циклом концепції Day 0, Day 1 і Day 2 є критично важливими для розуміння того, як ефективно управляти та підтримувати системи. Ці концепції не просто модні терміни, а необхідні фази, що гарантують успіх і сталість будь-якого розгортання, і це те, до чого я намагаюся звертатися в будь-якій системі, яку я проектую.
- Day 0: Ця фаза полягає в плануванні, розробці концепції та архітектурному дизайні. Вона включає всебічне дослідження, створення проектів та встановлення основних цілей для проекту. Для нашого проекту Edge computing Day 0 означало розуміння вимог наших систем магазинів, розробку інфраструктурних планів і дорожніх карт для вибору архітектури та відповідних технологій.
- Day 1: Це фаза, коли відбуваються розробка та розгортання. Вона включає налаштування інфраструктури, конфігурацію систем та впровадження програмного забезпечення. На цьому етапі ми реалізуємо наші плани. У нашому випадку це означало розгортання кластерів K3s від Rancher, налаштування необхідних мережевих і сховищних рішень і забезпечення працездатності вузлів. Ось тут і з'явився цей потяг..
- Day 2: Після того, як система запущена, починаються операції Day 2. Ця фаза включає підтримку, моніторинг та оптимізацію системи. Саме на цьому етапі ми стикаємося з реальними проблемами підтримки стабільної роботи системи. Для нашого налаштування Edge computing, Day 2 має включати постійні оновлення, патчі та управління розгортанням без порушення роботи магазинів.
Я знаю, що ви думаєте — Тож уже на Day 0 ми врахували можливість цієї системи, чому ми не помітили цього раніше? Ну, ми помітили — але мої думки були такими:
“Ну, ми все одно оновлюємо сотні/тисячі вузлів автоматично — що ще 3000? Це повинно бути нормально...” — Райан два роки тому
Для виконання таких оновлень нам довелося б запланувати час для систем, коли можуть бути виконані оновлення. Наші системи магазинів працюють в умовах часткової ізоляції. Ми використовуємо корпоративні проксі, кеші та всілякі мережеві магії, щоб наші системи могли працювати навіть під час відключень, і останнє, чого ми хочемо — це проблеми з оновленнями Ubuntu, оновленнями програмного забезпечення або просто завантаженням контейнерів з нашого центрального репозиторію.
Хоча технічно з цим нічого не порушено, і хороша автоматизація дійсно можлива, я почав замислюватися, чи немає простішого рішення.
Виклики з операціями Day 2
Тепер я буду на 100% прозорим і зовсім чесним тут.
текст перекладу
Після індивідуальної сесії з їхніми розробниками та громадським адвокатом, стало зрозуміло, що їхня дорожня карта дійсно розробляється спільнотою.
Перш ніж ми перейдемо до налаштування Day 2, давайте швидко поглянемо, як ми розгортаємо Kubernetes на великій кількості пристроїв на краю мережі.
Розгортання Talos на великій кількості пристроїв
Talos можна запустити різними способами, найпростіший і найшвидший метод — це завантажити образ на вашому улюбленому гіпервізорі, хмарному екземплярі, локальній платформі контейнеризації та використовувати talosctl. Я завжди шукаю швидкий старт, але цього недостатньо для продуктивного налаштування. Як зробити продуктивне налаштування так само простим, як швидкий старт¹? Враховуючи всі аспекти дизайну системи, топології та інфраструктури, ми раптом опиняємося в складному лабіринті рішень та обходів. Talos Linux підтримує багато варіантів розгортання: PXE-завантаження, netboot для baremetal, хмара, одночасно на одинарних платах, локально — вибір за вами. Ми вибрали метод NoCloud.
NoCloud з Talos
NoCloud — це джерело даних для cloud-init, яке дозволяє провізувати Talos Linux без потреби у повноцінному хмарному постачальнику або складній мережевій налаштуванні завантаження. Замість цього воно використовує локальні конфігураційні файли або дані користувача для ініціалізації системи, що робить його ідеальним для розгортання в великих масштабах без втручання.
За допомогою NoCloud ви можете досягти того ж рівня автоматизації та незмінності, як і при netboot, але з меншою кількістю залежностей. Це особливо підходить для середовищ, таких як локальні гіпервізори, одноплатні комп'ютери або навіть bare-metal машини, де завантаження через мережу може бути надмірним.
Ми розгортаємо наші спеціально створені образи на всіх наших системах магазинів, встановлюємо серійний номер SMBIOS в нашому API (про це далі), і як тільки образ починає завантажуватися, він звертається до нашого API для налаштування вузлів.
Звучить просто, чи не так? Але реальність трохи складніша. Для вирішення цих складнощів Talos пропонує корпоративне рішення під назвою Omni, яке фактично позбавляє від проблем з управлінням "API частини" процесу. Без Omni вам доведеться налаштувати API для обробки provisioning user-data, meta-data та network маніфестів — це критично важливо для визначення того, як повинні бути налаштовані та працювати вузли Talos. Omni спрощує цей робочий процес, роблячи його набагато доступнішим для команд, які хочуть розгортати Talos на великій кількості пристроїв.
Дізнайтеся більше про Omni і спробуйте це самостійно, якщо у вас є домашня лабораторія — це чудове доповнення 😉
Створення образів
Для створення образів Talos ми використовуємо Packer, потужний інструмент, який автоматизує процес створення образів машин. Ось як це працює: Packer завантажує необхідний образ Talos за допомогою Talos Image Factory API, записує його на диск, а потім оформляє його для розповсюдження. Цей спрощений підхід гарантує, що наші образи будуть послідовними, актуальними та готовими до розгортання на нашій інфраструктурі.
Image Factory API особливо корисний, оскільки дозволяє налаштувати образ Talos з попередньо налаштованими параметрами, ядром або іншими модифікаціями, пристосованими до нашого середовища. Після того, як образ підготовлений, Packer бере на себе важку роботу з пакування його у формат, придатний для наших конвеєрів розгортання.
Цей процес є критично важливою частиною нашого робочого процесу, і це те, що я детально розгляну в наступній статті, де пройду через деталі налаштування Packer, інтеграції з Talos Image Factory API та оптимізації процесу створення образів для масштабованості. Слідкуйте за новинами!
Провізія Talos на великій кількості пристроїв
Процес провізії наших 3,5 тисячі вузлів Talos був як захоплюючим, так і складним, з кількома труднощами на шляху.
Мережеві особливості
Наші системи магазинів працюють на різних мережах, включаючи 4G з'єднання, виділені лінії MPLS та інші. Така різноманітність приносить певні обмеження для мережі.
текст перекладу
Наприклад, через проектування мережі трафік часто маршрутизується через центральну точку, що може створювати вузькі місця. Уявіть, що потрібно завантажити 12 контейнерних образів для кожного магазину через 1,000 магазинів — це 12,000 запитів на завантаження образів! На щастя, нові версії Talos підтримують кешування OCI образів (яке я ще не налаштував). Це була одна з проблем, яку я порушив перед командою Talos, і вони серйозно до цього підійшли. Дякуємо, хлопці!
Інша особливість, з якою ми зіткнулися, — це проблеми з MTU. Ви, напевно, чули вислів: "Якщо це не DNS, то це MTU"... Нам потрібно було забезпечити, щоб вузли Talos були налаштовані з MTU 1300, щоб уникнути проблем з підключенням. Легко витратити години на пошук причин, чому певні розгортання здаються "пошкодженими".
Проксі
Так, 2025 рік, а проксі все ще використовуються — наразі нам просто треба з цим миритися. Ми наразі хостимо центральний реєстр контейнерів з кешем через проксі, використовуючи Harbor, який справляється з цим чудово. Harbor дозволяє нам використовувати такі функції, як сканування образів, ліміти та інше. Однак налаштування нашого всього середовища для роботи через проксі було певним кошмаром. На щастя, containerd приходить на допомогу, і його конфігурація може бути безперешкодно застосована через Talos. Ми використовуємо дзеркалення реєстрів, ось приклад налаштування нашого дзеркала реєстру в Talos:
registries:
mirrors:
"docker.io":
endpoints:
- "https://cr.domain.com/v2/dockerio"
overridePath: true
"gcr.io":
endpoints:
- "https://cr.domain.com/v2/gcr"
overridePath: true
"ghcr.io":
endpoints:
- "https://cr.domain.com/v2/ghcr"
overridePath: true
"registry.k8s.io":
endpoints:
- "https://cr.domain.com/v2/k8sio"
overridePath: true
"quay.io":
endpoints:
- "https://cr.domain.com/v2/quay-proxy"
overridePath: true
Ця конфігурація відповідає наступному config.toml для containerd:
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://cr.domain.com/v2/dockerio"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
endpoint = ["https://cr.domain.com/v2/gcr"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."ghcr.io"]
endpoint = ["https://cr.domain.com/v2/ghcr"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.k8s.io"]
endpoint = ["https://cr.domain.com/v2/k8sio"]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."quay.io"]
endpoint = ["https://cr.domain.com/v2/quay-proxy"]
Для додаткової інформації перегляньте документацію реєстру containerd.
Усі образи з ghcr.io завантажуються через наш реєстр контейнерів без будь-яких змін у файлах розгортання.
Результат? Ми можемо розгортати образи з будь-яких з цих реєстрів без необхідності змінювати файли розгортання.
Міркування щодо проектування API
Для того щоб ця конфігурація працювала безперебійно, всі NoCloud образи повинні мати можливість взаємодіяти з центральним API, здатним зберігати KubeConfig файли — або хоча б дані, необхідні для їх створення. Наше API також повинно керувати сертифікатами та супутніми метаданими. Оскільки ми використовуємо OIDC для автентифікації користувачів через наші кластери, ця конфігурація також повинна бути оброблена через API.
Крім того, система повинна підтримувати ротацію сертифікатів і надавати можливість моніторити здоров’я та продуктивність наших кластерів на місцях. Для досягнення цього буде корисний UI або CLI, що забезпечить зручний інтерфейс для моніторингу та керування кластерами.
Мережеві налаштування, як згадувалося раніше, є ще одним критичним компонентом. Це включає налаштування MTU, proxy налаштування, DNS та інше. Також нам потрібно додавати власний Certificate Authority (CA) для обробки TLS-перехоплення нашим проксі.
текст перекладу
Динамічне налаштування hostname і міток вузлів, які надають метадані для місцезнаходження магазину на кожному вузлі, є ще однією вимогою.
Крім того, API має обробляти налаштування мережевого інтерфейсу та керувати будь-якими додатковими дисками, підключеними до системи.
Маючи на увазі всі ці моменти, можна почати сумніватися, чи варто витрачати зусилля на розробку власного рішення — особливо коли такі інструменти, як Omni або Cluster API (Sidero), вже пропонують потужний функціонал "з коробки".
Результат? Потужний API в поєднанні з CLI, який може:
- Динамічно налаштовувати та керувати 3,500 кластерами.
- Безперешкодно підключатися до будь-якого кластера, використовуючи talosctl та kubectl.
- Виконувати ротацію сертифікатів та оновлення за допомогою стандартних робочих процесів.
- Надавати UI, вбудований у нашу внутрішню платформу для централізованого управління.
Це поєднання гарантує масштабованість, гнучкість та зручність використання, що робить його всеосяжним рішенням для наших потреб великомасштабного розгортання.
Наступний скріншот — це швидкий погляд на нашу внутрішню платформу магазину, з оглядом вузлів Talos та їхнього статусу. Зверніть увагу на розбіжність версій 1.9.1 і 1.7.1? Ми якраз перебуваємо в процесі оновлення 🙂
Платформа магазину
Це все на даний момент. У наступній частині я детально розгляну внутрішню роботу нашого Talos Provisioner API — основи нашої системи управління кластерами великого масштабу. Я розповім про його архітектуру, проблеми, з якими ми зіткнулися під час розробки, і як ми їх подолали. Від обробки динамічного налаштування та керування сертифікатами до інтеграції з OIDC і забезпечення безперервних оновлень, є багато цікавих моментів. Також я поділюся деякими уроками та найкращими практиками для тих, хто хоче побудувати або масштабувати подібне рішення.
Залишайтеся з нами для погляду за лаштунки того, як ми перетворили складну задачу на оптимізовану, масштабовану систему, яка без зусиль керує тисячами кластерів.
До того часу не соромтеся звертатися з питаннями або ділитися власним досвідом у коментарях — я з радістю почую, як інші вирішують ці проблеми!
О, і я залишу це тут, вам може знадобитися! https://www.siderolabs.com/platform/saas-for-kubernetes/
¹ Після роздумів щодо цього, talosctl насправді дуже добре виконує роль розгортання "підприємницького класу" кластера. Однак, для розгортання цього на великому масштабі потрібне інше рішення інструментів.
Перекладено з: 3000+ Clusters Part 2: The journey in edge compute with Talos Linux