Skip to content
Приватний Kubernetes

Private Kubernetes Deployment for Autonomous Reliability Infrastructure

Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.

Кластери під керуванням клієнта

Розділення площин керування та виконання

Патерни ізоляції простору імен

Сумісність із гібридними та анклавними моделями

Навіщо приватна оркестрація

Чому підприємствам потрібна приватна оркестрація

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

  • -Наявні стандарти кластерів і пайплайни GitOps
  • -Володіння вузлами та мережею з боку платформної команди
  • -Потреба тримати чутливі робочі навантаження поза мультитенантним SaaS-виконанням
  • -Регульовані середовища з ізоляцією на рівні простору імен
Кластери клієнта

Запуск інфраструктури виконання в кластерах під керуванням клієнта

Агенти виконання можуть розгортатися як робочі навантаження в кластерах, якими ви керуєте. Планування та затвердження можуть виконуватися в хмарних, приватних хмарних або on-prem площинах керування залежно від політики.

  • -Агенти плануються так само, як інші внутрішні сервіси
  • -Сумісність із CNI та механізмами політик клієнта
  • -Вхідний доступ до кластера не потрібен
  • -Підтримка мультикластерних флотів із часом
Розділення площин

Розділення площини керування та площини виконання

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

Приватне виконання в Kubernetes

Сумісні з виконанням агенти в кластерах під керуванням замовника, а не повне встановлення платформи.

Площина керування (замовник або Zof)Кластер Kubernetes замовникаПлощина керуванняПідписанняПростір іменАгент виконанняРобочі навантаженняСекретиАртефактиМежа телеметрії
  • -Чітка межа для огляду безпеки
  • -Чутливі дані часу виконання залишаються в просторах імен виконання
  • -API площини керування не виконують тести проти захищених застосунків напряму
  • -Гібридні розділення поширені в корпоративних розгортаннях
Агенти K8s

Агенти виконання Kubernetes

Агенти розроблені для сумісності з Kubernetes клієнта, а не як заміна вашої платформної команди. Визначення розміру, висока доступність та оновлення відповідають стандартам вашого кластера.

  • -Розгортання через схвалені клієнтом маніфести або оператори
  • -Дотримання обмежень ресурсів та політик безпеки подів
  • -Ідентифікація раннерів і списки дозволів для хостів виконання
  • -Поетапні розгортання за простором імен або кластером
Межі

Безпечні межі виконання

Простори імен, мережеві політики та облікові записи сервісів ізолюють виконання від непов’язаних робочих навантажень. Секрети монтуються під час виконання, а не зберігаються в Zof Cloud.

  • -RBAC у межах простору імен
  • -Інтеграція із зовнішніми менеджерами секретів, де це підтримується
  • -Опціональне узгодження з service mesh
  • -Аудит подій життєвого циклу агентів
Внутрішнє тестування

Тестування лише внутрішніх застосунків

Валідуйте мікросервіси, внутрішні API та адмін-інтерфейси, доступні з мереж кластера, не виставляючи їх у публічний інтернет.

  • -Внутрішньокластерні тести між сервісами
  • -Лише через ingress, де це дозволяє політика
  • -Поєднання з edge-раннерами для застарілих систем поза кластером
  • -Націлювання з урахуванням графа зменшує шум
Ізоляція

Ізоляція простору імен

Команди зіставляють бізнес-підрозділи або середовища з просторами імен, що мають окремі політики, термін зберігання та режими доказів.

  • -Розділення dev / staging / prod
  • -Квоти для кожної команди та обмеження паралельності
  • -Сховища доказів у межах простору імен
  • -Робочі процеси просування між просторами імен
Секрети

Обробка секретів

Облікові дані надаються під час виконання через PAM або інтеграції з секретами кластера. Довготривалі секрети за замовчуванням не копіюються до зовнішнього SaaS.

  • -Перевага надається короткоживучим токенам
  • -PAM-сумісні шаблони
  • -Жодного збереження секретів у площині планування без затвердження
  • -Ротація відповідно до ваших стандартів
Артефакти

Маршрутизація артефактів

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

Гібридна архітектура виконання

Хмарна оркестрація з розподіленими локальними флотами виконання.

Хмара / приватна хмараСередовище виконання замовникаКеруванняІнтелектВиконавець VPCГраничний виконавецьКінцева точкаЛокальний виконавець (on-prem)
  • -S3-сумісні, NFS або внутрішньокластерні томи
  • -Політики зберігання для кожного простору імен
  • -Контрольні суми та підписування для пакетів
  • -Опціональне просування до централізованого каталогу доказів
Телеметрія

Межі телеметрії

Метрики та журнали агентів можуть залишатися у внутрішньокластерних стеках спостережуваності. Централізовані дашборди можуть отримувати лише зведення з метаданих.

  • -OpenTelemetry-сумісні шаблони там, де це підтримується
  • -Редагування перед експортом за межі контуру
  • -Кореляційні ідентифікатори для аудиту
  • -Без обов'язкового вивантаження повних журналів
Управління

Корпоративне управління

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

  • -Версія політики прив'язана до запусків
  • -Ланцюжки схвалень для продакшн-шляхів
  • -Інтеграція із записами про зміни в ITSM
  • -Експорт для GRC та внутрішнього аудиту
Гібридні шаблони

Шаблони гібридної архітектури

Виконання в Kubernetes часто співіснує з раннерами у VPC, периферійними майданчиками та агентами на кінцевих точках під єдиною площиною керування.

  • -Єдиний граф та оркестрація флоту
  • -Узгоджена модель капсул на всіх поверхнях
  • -Політики доказів для кожної поверхні
  • -Огляд архітектури визначає порядок розгортання
Поширені запитання

Питання щодо on-prem розгортання

Поширені запитання від команд з інфраструктури та безпеки.

Ні. Виконання відбувається через раннери, розгорнуті клієнтом усередині вашої мережі. Zof не потребує вхідного доступу до захищених сегментів.
Next step

Обговоріть безпечне розгортання з Zof

Перегляньте сегментацію, керування капсулами та розміщення раннерів разом із командами, які підтримують регульовані підприємства.

01Zof Console

Єдина поверхня для стану, операцій і того, що потребує уваги наступним.

Автентифікований центр, який команди інженерії, QA та SRE відкривають щодня: стан якості, поточні запуски, покриття за модулями та те, що потребує уваги наступним.

ОПЕРАЦІЙНІ KPI

  • Запуски
  • Покриття
  • Ризик

У реальному часі для кожного середовища, у яке ви випускаєте.

ОСНОВА РОБОТИ

  • Специфікації
  • Тести
  • Розклади

Від специфікації до запланованого регресійного тестування.

ЗАПОБІЖНИКИ

  • RBAC
  • SSO
  • аудит

Кожна дія приписана конкретній людині.

LIVE/console
Головний командний центр Zof AI, що показує 12 запусків із 94% успішних, 3 відкриті критичні проблеми, 84% покриття, чотири смуги відстежуваності модулів, конвеєр специфікацій, найближчі розклади та рекомендовані подальші дії з бічною панеллю активних запусків.
Home view · Checkout Service · Staging · captured live from the product.
  • 01 · RUNS · 24H

    94% pass

    12 runs across staging

  • 02 · COVERAGE

    84%

    Across four modules

  • 03 · ACTIVE RUNS

    3 running

    Live on this branch

  • 04 · NEXT ACTIONS

    Recommended

    Triage gaps, new spec

Розгортання у приватному Kubernetes для автономної надійності | Zof AI