Към основното съдържание
A.I. Commerce Studio

Облак и платформа

Вътрешна Kubernetes платформа

Управляван клъстер с namespaces по екип, GitOps, политики и наблюдаемост като общ път за услугите.

Измислен сценарий. Примерна ситуация за илюстрация на подхода. Не е клиентски проект и не описва измерени резултати.

Бизнес проблем

Измислена компания има десетина услуги на виртуални машини с различни процеси за доставка. Новите екипи стартират бавно.

Допускания

  • Използва се управлявана услуга (AKS, EKS или GKE).
  • Услугите вече са в контейнери или могат да бъдат.
  • Има платформен екип.

Ограничения

  • Без промени директно в клъстера.
  • Всеки екип вижда само своите namespaces.
  • Тайните не са в Git.

Референтна архитектура

Схема на компонентите по етапи — илюстрация, не работеща система и не сертифициран дизайн.

  1. 01Вход

    • Git хранилища
    • Регистър на образи
  2. 02Доставка

    • GitOps контролер
    • Политики при приемане
  3. 03Платформа

    • Namespaces по екип
    • Ingress
    • Автомащабиране
  4. 04Наблюдение

    • Метрики
    • Журнали
    • Трасирания
Схемата като списък
ЕтапКомпоненти
ВходGit хранилища, Регистър на образи
ДоставкаGitOps контролер, Политики при приемане
ПлатформаNamespaces по екип, Ingress, Автомащабиране
НаблюдениеМетрики, Журнали, Трасирания

Интерфейси

ОтКъмЧрез
CIРегистърПодписани образи
GitOpsКлъстерPull модел
УслугиТайниExternal secrets

Поток на данните

  1. Кодът се изгражда и образът се подписва.
  2. Промяната в Git описва желаното състояние.
  3. GitOps прилага промяната.
  4. Политиките отхвърлят неподходящи манифести.
  5. Наблюдението показва здравето.

Граници на сигурността

  • RBAC по namespace.
  • Политики: без root, без привилегировани контейнери.
  • Тайни от външно хранилище.

Къде одобрява човек

  • Промени в продукционните манифести чрез преглед.
  • Изключения от политики.

Фази на внедряване

  1. 01 · Дизайн

    Клъстери, мрежа, мултитенантност.

  2. 02 · Основа

    Клъстер, GitOps, политики.

  3. 03 · Миграция

    Първите услуги.

  4. 04 · Експлоатация

    Обновявания и капацитет.

Ограничения

  • Не всяка услуга има нужда от Kubernetes.
  • Изисква платформен екип.

Компромиси

  • Общ клъстер срещу отделни — разходи срещу изолация.
  • Строги политики — по-бавен старт на екипите.

Имате подобна задача?

Ще започнем с оценка на текущото състояние и ще предложим реалистичен първи етап.