Руководство администратора платформы Appliner

Общие сведения

Документ «Руководство администратора» предназначен для администрирования платформы Эпплайнер. Приведено описание конфигурирования и настройки программного обеспечения, описание действий администратора в различных режимах функционирования платформы.

Наименование

Полное наименование системы: Корпоративная low-code платформа Эпплайнер.

Условное обозначение: Платформа.

Назначение

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

Краткое описание функциональных возможностей

Создание модели данных – системы взаимосвязанных таблиц для хранения данных приложения;

Создание процедур с помощью визуального конструктора Blockly;

Создание веб-интерфейсов с помощью конструктора форм;

Создание исполняемых BPMN-процессов с помощью конструктора процессов;

Создание интеграций с автоматической генерацией документации с помощью конструктора интеграций;

Создание ИИ-помощников и ИИ-агентов, и встраивание их в любые процессы и процедуры с помощью конструктора цепочек.

Уровень подготовки администраторов 

Уровень подготовки администраторов Платформы должен удовлетворять следующим требованиям: 

• знание и опыт работы с оркестратором контейнеровKubernetes.

Перечень эксплуатационной документации, с которой необходимо ознакомиться администраторам Платформы

Для корректной работы с Платформы администратор помимо настоящего документа, должен дополнительно ознакомиться со следующими документами: 

• Корпоративная low-code платформа Эпплайнер Руководство пользователя.

Режимы функционирования Платформы

Платформа функционирует 7 дней в неделю, 365 (366) дней в году.

Платформа поддерживает следующие режимы функционирования:

• штатный режим – основной режим функционирования;
• режим сервисного обслуживания;
• аварийный режим.

Смена режимов функционирования Платформы осуществляется администратором Платформы, который оповещает пользователей о смене режима функционирования любым доступным способом (электронная почта, телефон и пр.).

Штатный режим функционирования Платформы

Штатный режим является основным режимом функционирования Платформы. В штатном режиме все пользователи Платформы могут осуществлять работу с функционалом системы в соответствии со своими ролями и правами доступа. 

Для штатного режима работы Платформы для всех ролей пользователей используются персонифицированные учетные записи. 

Сервисный режим функционирования Платформы

Сервисный режим функционирования Платформы является технологическим режимом, используемым для проведения регламентных работ и технического обслуживания Платформы. В данном режиме работа с системой пользователей, не являющихся администраторами, невозможна.

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

Аварийный режим Платформы

Аварийный режим возникает в случае нарушения в работе Платформы, вызванного техническими, программными проблемами, некорректными действиями эксплуатационного персонала Платформы, нарушениями в работе технических средств или в ситуациях, вызванных техногенными катастрофами. 

При возникновении нештатной ситуации осуществляется регистрация данного события. Эксплуатационный персонал Платформы выполняет работы по выявлению причин и устранению нештатной ситуации. В аварийном режиме работа пользователей с системой невозможна.

О возникновении аварийного режима функционирования Платформы администратор оповещает эксплуатационный персонал и пользователей Платформы (любым доступным способом). 

Требования к аппаратной части

Платформа функционирует на базе Kubernetes-кластера. Поддерживаемые дистрибутивы: RKE2, Talos Linux, а также managed-решения (Yandex Cloud Managed Kubernetes и аналоги).

Серверная часть (Kubernetes-кластер)

Минимальная конфигурация серверной части КТС Платформы, достаточная для тестирования и разработки:

Таблица 1 Минимальная конфигурация

Роль узла	Количество	CPU	RAM	Диск (ОС + данные)
Control-plane + Worker (совмещённая роль)	3	10 vCPU	32 GB	200 GB SSD

                                               

Для промышленной эксплуатации серверная часть должна быть собрана в отказоустойчивый кластер, в котором выход одного сервера из строя не остановит работу платформы, что соответствует требованиям Высокой доступности (High Availability).

Рекомендуемая конфигурация серверной части КТС Платформы, достаточная для промышленной эксплуатации: 

Таблица 2 Рекомендуемая конфигурация

Роль узла	Количество	CPU	RAM	Диск (ОС)	Диск (данные)
Control-plane            3	3	8 vCPU	16 GB	100 GB SSD	50 GB SSD (etcd)
Worker	3+	16 vCPU	64 GB	100 GB SSD	500 GB SSD
Worker GPU (для  AI-модуля, опционально)	1+	8 vCPU + GPU	32 GB	100 GB SSD	200 GB SSD

Требования к дисковому пространству (Persistent Volumes)

Компонент	Размер PVC	Количество реплик	Примечание
PostgreSQL	50 Gi	3	Основное хранилище данных платформы
Elasticsearch	30 Gi	3	Хранение логов (политика ротации: 3 дня)
MinIO (S3)	20 Gi	4	Объектное хранилище файлов
Prometheus	15 Gi	1	Хранение метрик мониторинга
Grafana	15 Gi	1	Конфигурация дашбордов
Kafka Ephemeral (по умолчанию)		3	Брокер сообщений, KRaft mode
Итого минимум	~355 Gi

Требования к сети

Сетевая конфигурация должна соответствовать следующим требованиям:

• Сетевой плагин (CNI): Cilium или Calico
• Пропускная способность между узлами: не менее 1 Gbps
• Внешний доступ: порты 80 (HTTP), 443 (HTTPS) через Ingress Controller
• Межузловое взаимодействие: порты 6443 (K8s API), 2379-2380 (etcd), 9345 (RKE2 join), 10250 (kubelet)
• Kafka external: NodePort 9094 (при необходимости внешнего доступа)

Требования к программному обеспечению

Операционная система серверов

На сервере должна быть установлена операционная система Linux не ниже следующих версий:

• Ubuntu 20.04+;
• RHEL/CentOS 8+;
• Debian 11+;
• Talos Linux 1.12+

Утилиты администрирования (рабочее место администратора)

Таблица 3 Утилиты администрирования

Утилита	Версия	Назначение
kubectl	совместимая с версией K8s	Управление кластером
helm	3.x	Управление Helm-чартами
yq	4+	Обработка YAML-конфигураций
bash	4+	Выполнение скриптов установки

Инфраструктурное ПО (устанавливается автоматически)

Обязательные компоненты

Таблица 4 Обязательные компоненты

Компонент	Версия	Назначение
cert-manager	v1.18.2	Автоматическое управление TLS-сертификатами
Traefik	v3.6.11	Ingress Controller (маршрутизация HTTP/HTTPS)
CloudNativePG Operator	1.28.0	Управление PostgreSQL-кластерами
PostgreSQL	18.0	Реляционная СУБД
PgBouncer	1.24.1	Пул соединений к PostgreSQL
MinIO	RELEASE.2024-04-18	S3-совместимое объектное хранилище
Strimzi Kafka Operator	0.48.0	Управление Apache Kafka
Apache Kafka	4.0.0	Брокер сообщений (KRaft mode, без ZooKeeper)

 

Опциональные компоненты (наблюдаемость и управление)

Таблица 5 Опциональные компоненты

Компонент	Версия	Назначение
Elasticsearch	8.5.1	Поиск и хранение логов
Logstash	8.5.1	Обработка и трансформация логов
Kibana	8.5.1	Визуализация и поиск по логам
Filebeat	8.5.1	Сбор логов со всех узлов кластера
Jaeger	1.53.0	Распределённая трассировка запросов
Prometheus	v0.78.2 (kube-prometheus-stack 66.2.2)	Сбор метрик и алертинг
Grafana	(в составе kube-prometheus-stack)	Визуализация метрик
Argo CD	v2.11.7	GitOps / непрерывная доставка
Kafka UI	latest	Веб-интерфейс управления Kafka
Rancher	2.11.0	Веб-интерфейс управления кластерами

Прикладное ПО платформы

Таблица 6 Компоненты прикладного ПО

Модуль	Компоненты	Стек
Инфраструктурный	Deployment Manager, Service Creator	Java/Spring Boot, OpenResty/Lua
Платформенный	API Gateway, Platform Backend, Platform Frontend, Keycloak, License Manager, Integrations	Java/Spring Boot, Vue.js
Тенантный	Tenant Backend, Tenant Frontend, WebSocket Gateway, BPMS (Camunda)	Java/Spring Boot, Vue.js
Прикладной (per-app)	App Backend, App Frontend	Java/Spring Boot, Vue.js
AI-модуль	Container Runner, Chain Runner, Meta Assistant KF Backend	Go, Python

 

Конфигурирование серверной части

Общая архитектура развёртывания

Платформа разворачивается послойно. Каждый последующий уровень зависит от предыдущего:

Таблица 7 Уровни развертывания

Уровень	Наименование уровня	Содержимое уровня
Уровень 6	AI-модуль	container-runner, chain-runner, meta-assistant
Уровень 5	Приложения	app-backend, app-frontend (per-application)
Уровень 4	Тенанты	tenant-backend, tenant-frontend, websocket-gateway, bpms (создаютсядинамически, per-tenant namespace)
Уровень 3	Платформенные сервисы	api-gateway, platform-backend, platform-frontend,    keycloak, license-manager, integrations
Уровень 2	Платформа управления	deployment-manager, service-creator
Уровень 1	Инфраструктура	cert-manager, Traefik, PostgreSQL+PgBouncer, Kafka,  MinIO, ELK Stack, Jaeger, Prometheus+Grafana

 

Установка инфраструктуры

Установка выполняется единым скриптом init.sh. Основные конфигурационные параметры:

Таблица 8 Параметры конфигурации

Параметр	Описание	Пример
STORAGE_CLASS	StorageClass для всех PVC	local-path
ROOT_DOMAIN	Корневой домен платформы	platform.example.com
IMAGE_REGISTRY_OVERRIDE	Использование внутреннего registry (для закрытых контуров)	true/false
REGISTRY_MIRROR_HOST	Адрес внутреннего Docker Registry	registry.example.com

Каждый компонент управляется переменной *_ACTION со значениями: install, remove, skip.

Порядок установки компонентов

Компоненты устанавливаются в следующем порядке:

1. cert-manager (TLS-сертификаты)
2. Traefik Ingress Controller (маршрутизация)
3. ELK Stack (опционально): Elasticsearch → Logstash → Kibana → Filebeat
4. Jaeger (опционально, требует ELK)
5. Prometheus Stack (опционально)
6. MinIO (объектное хранилище)
7. CloudNativePG Operator + PostgreSQL Cluster (3 реплики)
8. PgBouncer (connection pooler)
9. Strimzi Kafka Operator + Kafka Cluster (3 брокера, KRaft mode)
10. Kafka UI
11. Appliner Infrastructure Chart (Deployment Manager + Service Creator)
12. Автоматическое создание платформы через API Deployment Manager
13. Автоматическое создание AI-модуля через API Deployment Manager

Структура пространства имен (namespaces)

После установки создаются следующие пространства имён:

Таблица 9 Пространства имен

Namespace	Назначение	Основные компоненты
cert-manager	Управление сертификатами	cert-manager, cainjector, webhook
traefik	Входящий трафик	Traefik Deployment
psql	База данных	CloudNativePG operator, PostgreSQL x3, PgBouncer x2
kafka	Брокер сообщений	Kafka brokers x3, Entity Operator, Kafka UI
kafka-operator	Оператор Kafka	Strimzi Operator
minio	Объектное хранилище	MinIO StatefulSet (4 реплики)
elk	Централизованное логирование	Elasticsearch x3, Logstash, Kibana, Filebeat (DaemonSet)
jaeger	Распределённая трассировка	Jaeger Agent (DaemonSet), Collector, Query
monitoring	Мониторинг	Prometheus, Grafana, Node Exporter (DaemonSet), kube-state-metrics
appliner-platform	Платформа Appliner	deployment-manager, service-creator, api-gateway, platform-backend, platform-frontend, keycloak, license-manager, integrations
appliner-ai	AI-модуль	container-runner, chain-runner, meta-assistant
tenant-<имя>	Per-tenant (создаётся автоматически)	tenant-backend, tenant-frontend, websocket-gateway, bpms, per-app pods

Конфигурация доменов и TLS

Все сервисы доступны через Traefik Ingress по шаблону:

Таблица 10 Конфигурация доменов

Домен	Назначение
platform.<ROOT_DOMAIN>	Платформа (Backend, Frontend, Keycloak, License Manager)
s3.<ROOT_DOMAIN>	MinIO S3 API
s3-console.<ROOT_DOMAIN>	MinIO Console (UI)
elastic.<ROOT_DOMAIN>	Elasticsearch API
kibana.<ROOT_DOMAIN>	Kibana UI
jaeger.<ROOT_DOMAIN>	Jaeger Query UI
kafka-ui.<ROOT_DOMAIN>	Kafka UI
grafana.<ROOT_DOMAIN>	Grafana
prometheus.<ROOT_DOMAIN>	Prometheus UI
<tenant>.<ROOT_DOMAIN>	Домен тенанта (создаётся автоматически)

TLS-сертификаты выпускаются автоматически через cert-manager с использованием ClusterIssuer на основе корпоративного CA-сертификата организации.

 

Описание необходимых конфигурационных файлов модулей подсистем

Основной файл конфигурации (init.sh)

Таблица 11 Конфигурация init.sh

Группа параметров	Описание
Домен и окружение	ROOT_DOMAIN, STORAGE_CLASS
Docker Registry	IMAGE_REGISTRY_OVERRIDE, REGISTRY_MIRROR_HOST
Namespaces	Индивидуальные для каждого компонента или единый через HELM_TARGET_NAMESPACE
Appliner Charts	Версия, OCI-registry, credentials
PostgreSQL	Хост PgBouncer, порт, credentials
Kafka	Имя кластера, аутентификация (SCRAM-SHA-512)
Keycloak	URL, realm, client ID, fetcher credentials
S3/MinIO	Endpoint, access/secret keys
TLS	Корневой CA-сертификат в PEM-формате

Helm Charts платформы

Таблица 12 Параметры Helm Charts

Chart	Компоненты	Ключевые параметры
appliner-infrastructure	deployment-manager, service-creator	global.domain, global.pgsql.*, global.keycloak.*, global.kafka.*, global.s3.*, global.helm.*
appliner-platform	api-gateway, platform-backend, platform-frontend, keycloak, license-manager, integrations	global.domain, global.keycloak_enabled, Kafka, корпоративный LDAP
appliner-tenant	tenant-backend, tenant-frontend, websocket-gateway, bpms	Per-tenant: TENANT_KEY, домен, DB credentials
appliner-application	app-backend, app-frontend	Per-app: PROJECT_NAME, DB/S3/Kafka credentials
appliner-ai	container-runner, chain-runner, meta-assistant-kf-backend	Kafka credentials per runner, GPU config

Конфигурационные шаблоны Deployment Manager

Deployment Manager хранит шаблоны для автоматической генерации values при развёртывании:

Таблица 13 Шаблоны Deployment Manager

Шаблон	Назначение
platform-helm.yaml	Values для платформенного чарта
tenant-helm.yaml	Values для тенантного чарта
app-helm.yaml	Values для чарта приложения
ai-helm.yaml	Values для AI-модуля

 

При создании тенанта/приложения Deployment Manager автоматически:

1. Создаёт базу данных в PostgreSQL
2. Создаёт бакет в MinIO
3. Создаёт Kafka-пользователя и топики
4. Создаёт realm/client в Keycloak
5. Разворачивает соответствующий Helm-чарт с рассчитанными values

Ресурсы подов (значения по умолчанию)

Платформенные сервисы:

Таблица 14 Ресурсы платформенных сервисов

Сервис	CPU (request/limit)	Memory (request/limit)
API Gateway	5m / 600m	256Mi / 512Mi
Platform Backend	5m / 600m	256Mi / 512Mi
Platform Frontend	5m / 200m	32Mi / 128Mi
Keycloak	5m / 1000m	512Mi / 1024Mi
License Manager	5m / 600m	256Mi / 512Mi
Integrations	5m / 600m	256Mi / 512Mi
Deployment Manager	5m / 600m	256Mi / 512Mi
Service Creator	5m / 400m	256Mi / 2048Mi

 

Тенантные сервисы (per-tenant):

Таблица 15 Ресурсы тенатнных сервисов

Сервис	CPU (request/limit)	Memory (request/limit)
Tenant Backend	10m / 1000m	512Mi / 1024Mi
Tenant Frontend	5m / 200m	32Mi / 128Mi
BPMS (Camunda)	5m / 2000m	400Mi / 768Mi
WebSocket Gateway	10m / 1000m	256Mi / 512Mi

 

Прикладные сервисы (per-application):

Таблица 16 Ресурсы прикладных сервисов

Сервис	CPU (request/limit)	Memory (request/limit)
App Backend	50m / 1600m	512Mi / 1024Mi
App Frontend	5m / 200m	32Mi / 128Mi

 

AI-модуль:

Таблица 17 Ресурсы AI-модуля

Сервис	CPU (request/limit)	Memory (request/limit)
Container Runner	5m / 1000m	768Mi / 1536Mi
Chain Runner	5m / 600m	128Mi / 256Mi
Meta Assistant	5m / 600m	256Mi / 512Mi

Архитектура Helm Charts (важные элементы)

Управление TLS-сертификатами в Ingress

Каждый Ingress-ресурс в Helm Charts содержит условную логику выбора TLS-секрета. Поддерживаются три режима (по приоритету):

1. Wildcard-сертификат (global.tls.wildcartcert: true) — единый сертификат для всех поддоменов *.<ROOT_DOMAIN>. Используется Secret wildcard-tls-secret.
2. Кастомный сертификат (global.tls.customcert: true) — сертификат передаётся в values. Chart автоматически создаёт Secret platform-tls-secret (платформа) или tenant-tls-secret(тенант).
3. Автоматический (cert-manager) — при обоих параметрах falsecert-manager автоматически выпускает сертификат через ClusterIssuer и создаёт Secret вида <domain>-secret.

При автоматическом режиме Ingress получает аннотацию cert-manager.io/cluster-issuer, которая инициирует выпуск сертификата. При использовании кастомного или wildcard-сертификата аннотация не добавляется, Ingress ссылается на заранее созданный Secret.

Пример условной логики в шаблоне:

annotations:

  {{- if and (not .Values.global.tls.wildcartcert) (not .Values.global.tls.customcert) }}

  cert-manager.io/cluster-issuer: “{{ .Values.global.CERT_ISSUER }}”

  {{- end }}

spec:

  tls:

    – hosts:

      – “{{ .Values.global.domain }}”

      {{- if .Values.global.tls.wildcartcert }}

      secretName: “wildcard-tls-secret”

      {{- else if .Values.global.tls.customcert }}

      secretName: “platform-tls-secret”

      {{- else }}

      secretName: “{{ .Values.global.domain }}-secret”

      {{- end }}

Распространение корпоративного CA (externalCertificates)

Для обеспечения доверенного HTTPS-взаимодействия между внутренними сервисами платформы используется механизм распространения корпоративного CA-сертификата:

1. Администратор указывает PEM-содержимое CA-сертификата в global.externalCertificates.certificates
2. Helm-чарт создаёт Kubernetes ConfigMap с этим содержимым
3. ConfigMap монтируется как volume в каждый Pod по пути /usr/local/share/ca-certificates
4. Операционная система контейнера автоматически доверяет сертификатам, подписанным этим CA

Пример шаблона в Deployment:

containers:

  – name: service

    {{- if .Values.global.externalCertificates.enabled }}

    volumeMounts:

      – name: external-certs

        mountPath: /usr/local/share/ca-certificates

    {{- end }}

volumes:

  {{- if .Values.global.externalCertificates.enabled }}

  – name: external-certs

    configMap:

      name: {{ .Values.global.externalCertificates.configName }}

      optional: true

 {{- end }}

Этот механизм применяется во всех Helm-чартах:

Таблица 18 Состав Helm-чартов и сервисов платформы

Chart	ConfigMap	Сервисы
appliner-infrastructure	infrastructure-external-certificates	deployment-manager, service-creator
appliner-platform	platform-external-certificates	api-gateway, platform-backend, license-manager, integrations
appliner-tenant	Имя из global.externalCertificates.configName	tenant-backend, bpms, websocket-gateway
appliner-application	Имя из global.externalCertificates.configName	app-backend, app-frontend
appliner-ai	Имя из global.externalCertificates.configName	container-runner, chain-runner, meta-assistant

 

ДляAI-модуля (container-runner) используется альтернативный путь монтирования: /etc/pki/ca-trust/source/anchors (для RHEL/CentOS-based образов контейнеров).

Параметры в values.yaml:

global:

  externalCertificates:

    enabled: true

    configName: “platform-external-certificates”

    certificates:

      “ca.crt”: |

        —–BEGIN CERTIFICATE—–

        <PEM-содержимое корневого CA-сертификата организации>

       —–END CERTIFICATE—–

Java TLS trustStore

Java-сервисы платформы (api-gateway, integrations, websocket-gateway) используют JVM-параметр для подключения корпоративного CA в Java TLS trustStore:

env:

  – name: JAVA_TOOL_OPTIONS

    value: >-

     -Djavax.net.ssl.trustStore=/shared/cacerts

      -Djavax.net.ssl.trustStorePassword=changeit

Это обеспечивает доверие Java-приложений к сервисам с сертификатами, подписанными корпоративным CA, при HTTPS-взаимодействии между микросервисами внутри кластера.

Привязка к группам узлов (Node Affinity)

Все Deployment’ы платформы используют preferredDuringSchedulingIgnoredDuringExecution — мягкое ограничение, позволяющее Kubernetes предпочтительно размещать pod’ы на определённых группах узлов, но не блокирующее запуск при их недоступности:

affinity:

  nodeAffinity:

   preferredDuringSchedulingIgnoredDuringExecution:

      – weight: 1

        preference:

          matchExpressions:

            – key: name

              operator: In

              values:

                – {{ .Values.global.temp }}

Два типа групп узлов:

• global.temp — для временных/тестовых нагрузок
• global.stable — для стабильных/продуктовых нагрузок

Администратор может назначить метки узлам командой:

kubectl label node <node-name> name=<group-name>

Проверки жизнеспособности (Health Probes)

Все Java-сервисы используют Spring Boot Actuator для автоматических health-проверок Kubernetes:

Таблица 19 Проверки жизнеспособности

Тип проверки	Endpoint	Порт	Начальная задержка	Период
startupProbe	/actuator/health	9090	10 сек	10 сек
livenessProbe	/actuator/health/liveness	9090	30 сек	10 сек
readinessProbe	/actuator/health/readiness	9090	30 сек	10 сек

 

Назначение проверок:

• startupProbe — определяет момент, когда приложение полностью запустилось. До его прохождения liveness и readiness не проверяются.
• livenessProbe — если приложение “зависло” и не отвечает, Kubernetes автоматически перезапускает контейнер.
• readinessProbe — если приложение временно не готово обслуживать запросы (например, загрузка конфигурации), Kubernetes временно убирает pod из балансировки.

Маршрутизация (Traefik Middlewares)

Каждый уровень платформы создаёт набор Traefik CRD Middleware для управления HTTP-трафиком.

Платформенный уровень:

Таблица 20 Маршрутизация платформенного уровня

Middleware	Назначение
<project>-cors	Настройка CORS-заголовков (Access-Control-Allow-Origin, Methods, Headers)
<project>-buffering	Буферизация запросов (без лимита размера body)
<project>-rewrite-api-gateway	Перенаправление /api-gateway/… → /…(strip prefix)
<project>-rewrite-platform-backend	Маршрутизация /api/tenants/… через API Gateway с аутентификацией
<project>-rewrite-license-manager	Маршрутизация /api/licenses/… через API Gateway с аутентификацией

 

Тенантный уровень:

Таблица 21 Маршрутизация тенантного уровня

Middleware	Назначение
<project>-cors	CORS-заголовки для домена тенанта
<project>-buffering	Буферизация с лимитом 32KB response body
<project>-rewrite-backend	Перенаправление /backend/… → /…
<project>-rewrite-api	Маршрутизация /api/… через API Gateway с аутентификацией Keycloak
<project>-rewrite-bpms-engine-rest	Перенаправление /camunda/engine-rest/…→ /engine-rest/…
<project>-rewrite-storybook	Перенаправление /storybook/… → /…

 

Все Middleware создаются автоматически при развёртывании Helm-чарта и привязываются к Ingress-ресурсам через аннотации:

traefik.ingress.kubernetes.io/router.middlewares: <namespace>-<project>-cors@kubernetescrd,<namespace>-<project>-buffering@kubernetescrd

Управление секретами (Secrets Management)

Helm Charts автоматически создают отдельные Kubernetes Secrets для каждого типа подключения. Это обеспечивает разделение доступа и возможность ротации отдельных credentials:

Таблица 22 Управление секретами

Тип Secret	Формат имени	Содержимое
Docker Registry	<project>-docker-config-secret	Credentials для приватного Docker registry (тип kubernetes.io/dockerconfigjson)
PostgreSQL	<project>-postgres-secret	host, port, dbname, username, password
Kafka	<project>-kafka-secret	bootstrap_servers, security_protocol, sasl_mechanism, username, password
S3/MinIO	<project>-s3-secret	endpoint, access_key, secret_key, bucket
Keycloak	<project>-keycloak-secret	realm, client_id, client_secret, base_url
TLS	platform-tls-secret / tenant-tls-secret	tls.crt, tls.key (PEM-формат, тип kubernetes.io/tls)

 

Все Secret’ы создаются в формате stringData (не base64-encoded в шаблонах) для читаемости и удобства отладки. Kubernetes автоматически кодирует значения при хранении.

Параметр CERT_ISSUER

Infrastructure Chart передаёт переменную CERT_ISSUER (значение по умолчанию: my-ca-issuer) в компоненты управления платформой:

env:

  – name: CERT_ISSUER

    value: “{{ .Values.global.CERT_ISSUER }}”

Эта переменная используется при программном создании Ingress-ресурсов для новых тенантов и приложений — Service Creator добавляет аннотацию cert-manager.io/cluster-issuer со значением CERT_ISSUER к каждому создаваемому Ingress, что инициирует автоматический выпуск TLS-сертификата для домена нового тенанта.

Стратегия обновления (Deployment Strategy)

Все Deployment’ы поддерживают конфигурируемую стратегию обновления через values.yaml:

strategy:

  type: RollingUpdate

  rollingUpdate:

    maxSurge: 1

    maxUnavailable: 0

По умолчанию используется RollingUpdate — Kubernetes создаёт новый pod перед удалением старого, обеспечивая zero-downtime обновления.

Количество реплик

Каждый сервис имеет настраиваемое количество реплик через replicaCount в values:

replicaCount: 1    # по умолчанию

Для высоконагруженных систем рекомендуется увеличивать replicaCount для критичных сервисов:

• API Gateway: 2-3
• Platform Backend: 2-3
• Tenant Backend: 2+ (per-tenant)

Инструменты администрирования

Таблица 23 Инструменты администрирования

Инструмент	Назначение	Тип доступа
kubectl	Управление Kubernetes-кластером (pods, services, secrets, logs)	CLI
helm	Управление Helm-релизами (установка, обновление, откат)	CLI
Grafana	Дашборды мониторинга (CPU, RAM, сеть, HTTP latency)	Web: https://grafana.<ROOT_DOMAIN>
Kibana	Поиск и визуализация логов	Web: https://kibana.<ROOT_DOMAIN>
Jaeger UI	Распределённая трассировка запросов между микросервисами	Web: https://jaeger.<ROOT_DOMAIN>
Kafka UI	Управление Kafka: топики, потребители, сообщения	Web: https://kafka-ui.<ROOT_DOMAIN>
Keycloak Admin Console	Управление пользователями, ролями, realms	Web: https://platform.<ROOT_DOMAIN>/auth/admin
Rancher	Графический интерфейс управления кластерами	Web: https://rancher.<ROOT_DOMAIN>
Argo CD	GitOps: статус deployments, синхронизация	Web (если установлен)
MinIO Console	Управление бакетами, объектами, пользователями	Web: https://s3-console.<ROOT_DOMAIN>
Prometheus	Просмотр метрик, PromQL-запросы	Web: https://prometheus.<ROOT_DOMAIN>

 

Типовые операции администрирования

Остановка системы

Остановка прикладного ПО (без потери данных):

# Масштабирование всех deployments до 0 реплик

kubectl scale deployment –all –replicas=0 -n appliner-platform

kubectl scale deployment –all –replicas=0 -n <namespace-тенанта>

kubectl scale deployment –all –replicas=0 -n appliner-ai

Остановка отдельного компонента инфраструктуры:

helm uninstall <имя-релиза> -n <namespace>

Полная остановка всей инфраструктуры:

# Установить action=remove для нужных компонентов и запустить init.sh

export INFRASTRUCTURE_CHART_ACTION=”remove”

export KAFKA_UI_ACTION=”remove”

# … остальные компоненты

./init.sh

Запуск системы

Первичная установка / восстановление после полной остановки:

# Настроить переменные окружения

export CERT_MANAGER_ACTION=”install”

export TRAEFIK_ACTION=”install”

export MINIO_ACTION=”install”

export CLOUDNATIVE_PG_OPERATOR_ACTION=”install”

export POSTGRES_CLUSTER_ACTION=”install”

export PGBOUNCER_ACTION=”install”

export KAFKA_OPERATOR_ACTION=”install”

export KAFKA_CLUSTER_ACTION=”install”

export KAFKA_UI_ACTION=”install”

export INFRASTRUCTURE_CHART_ACTION=”install”

export PLATFORM_CREATION=”true”

export AI_CREATION=”true”

./init.sh

Восстановление после масштабирования до 0:

kubectl scale deployment –all –replicas=1 -n appliner-platform

kubectl scale deployment –all –replicas=1 -n <namespace-тенанта>

kubectl scale deployment –all –replicas=1 -n appliner-ai

Просмотр состояния системы

Состояние узлов кластера:

kubectl get nodes -o wide

Состояние всех компонентов платформы:

kubectl get pods -A | grep -E “appliner|psql|kafka|elk|minio|traefik|monitoring|jaeger|cert-manager”

Состояние Helm-релизов:

helm list -A

Состояние PostgreSQL:

kubectl get clusters.postgresql.cnpg.io -n psql

Ожидаемый результат: STATUS: Cluster in healthy state, READY: 3/3.

Состояние Kafka:

kubectl get kafka -n kafka

Ожидаемый результат: READY: True.

Состояние сертификатов:

kubectl get certificates -A

Все сертификаты должны быть в состоянии READY: True.

Проверка PersistentVolumeClaims:

kubectl get pvc -A

Все PVC должны быть в состоянии Bound.

Через Grafana: дашборды Kubernetes (node capacity, pod status, network), PostgreSQL, Kafka.

Просмотр журналов прикладного программного обеспечения

Через kubectl (реальное время):

# Логи конкретного pod’а

kubectl logs <pod-name> -n <namespace>

 

# Логи всех pod’ов сервиса

kubectl logs -l app=<service-name> -n <namespace> –tail=100

 

# Следить за логами в реальном времени

kubectl logs -f <pod-name> -n <namespace>

 

# Логи предыдущего контейнера (после перезапуска)

kubectl logs <pod-name> -n <namespace> –previous

Через Kibana (централизованные логи):

1. Открыть https://kibana.<ROOT_DOMAIN>
2. Перейти в раздел Discover
3. Фильтры:

• kubernetes.namespace_name: “<namespace>” — логи по namespace
• kubernetes.labels.app: “<service>” — логи конкретного сервиса
• log.level: “error” — только ошибки

1. Retention: 3 дня (ILM Policy Filebeat: rollover при 50 GB или 1 день, удаление через 3 дня)

Через Jaeger (трассировка запросов):

1. Открыть https://jaeger.<ROOT_DOMAIN>
2. Выбрать сервис из списка
3. Анализ цепочки вызовов между микросервисами

Просмотр логов программного обеспечения промежуточного уровня

PostgreSQL:

kubectl logs -l cnpg.io/cluster=postgres -n psql

kubectl logs -l cnpg.io/cluster=postgres,role=primary -n psql

PgBouncer:

kubectl logs -l app.kubernetes.io/name=pgbouncer -n psql

Kafka:

kubectl logs -l strimzi.io/cluster=platform-kafka -n kafka

Traefik:

kubectl logs -l app.kubernetes.io/name=traefik -n traefik

cert-manager:

kubectl logs -l app.kubernetes.io/name=cert-manager -n cert-manager

CloudNativePG Operator:

kubectl logs -l app.kubernetes.io/name=cloudnative-pg -n psql

Уровень узла (systemd):

# На узле кластера:

journalctl -u rke2-server.service  # для Control-plane узлов

journalctl -u rke2-agent.service   # для Worker-узлов

Замена сертификатов

Платформа реализует двухуровневую систему TLS-сертификатов:

1. Ingress TLS — сертификаты для внешнего HTTPS-доступа (через cert-manager или кастомные)
2. Internal CA (externalCertificates) — корпоративный CA-сертификат для внутренней коммуникации между сервисами

Архитектура TLS

Уровень 1: Внешний доступ (Ingress TLS)

Управляется через параметр global.tls в Helm values. Три режима (по приоритету):

Таблица 24 Режимы внешнего доступа

Режим	Параметр	Описание
Wildcard	global.tls.wildcartcert: true	Используется wildcard-сертификат из секрета wildcard-tls-secret
Кастомный	global.tls.customcert: true	Сертификат передаётся в values (global.tls.crt / global.tls.key), создаётся Secret
cert-manager (автоматический)	Оба false	cert-manager автоматически выпускает сертификат через ClusterIssuer

При wildcartcert=true или customcert=true Infrastructure Chart создаёт Kubernetes Secret типа kubernetes.io/tls:

• Для платформы: wildcard-tls-secret или platform-tls-secret
• Для тенантов: tenant-tls-secret

При обоих false — cert-manager выпускает сертификат автоматически при создании Ingress.

Уровень 2: Внутренняя коммуникация (Internal CA)

Все Helm-чарты платформы содержат механизм распространения корпоративного CA-сертификата для межсервисного взаимодействия по HTTPS:

Механизм:

1. В global.externalCertificates.certificates указывается CA-сертификат в PEM-формате
2. Helm-чарт создаёт ConfigMap с именем из global.externalCertificates.configName
3. ConfigMap монтируется в каждый Pod по пути /usr/local/share/ca-certificates
4. Java-сервисы дополнительно используют CA через JVM trustStore (JAVA_TOOL_OPTIONS)

Параметры values.yaml:

global:

  externalCertificates:

    enabled: true

    configName: “platform-external-certificates”

    certificates:

      “ca.crt”: |

        —–BEGIN CERTIFICATE—–

        <PEM-содержимое корневого CA-сертификата>

       —–END CERTIFICATE—–

ClusterIssuer

cert-manager использует ClusterIssuer типа CA, который ссылается на Kubernetes Secret (содержит tls.crt и tls.key корневого CA). Этот же CA-сертификат распространяется как externalCertificates для внутреннего доверия.

Рисунок 1

 

Замена корневого CA-сертификата

Шаг 1. Обновить Secret для cert-manager:

 

kubectl create secret tls my-local-ca

  –cert=new-ca.crt

  –key=new-ca.key

  -n cert-manager

  –dry-run=client -o yaml | kubectl apply -f –

Шаг 2. Обновить externalCertificates в values всех чартов:

Обновить переменную APPLINER_EXTERNAL_CERT_CA_CRT в init.sh содержимым нового ca.crt и перевыполнить установку Infrastructure Chart:

 

export INFRASTRUCTURE_CHART_ACTION=”install”

./init.sh

Deployment Manager автоматически распространит обновлённый CA при следующем обновлении платформы/тенантов.

Шаг 3. Перевыпустить Ingress-сертификаты:

# Удаление TLS-секретов инициирует автоматический перевыпуск cert-manager

 

kubectl get certificates -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.spec.secretName}{“n”}{end}’ |

  while read line; do

    ns=$(echo $line | cut -d/ -f1)

    secret=$(echo $line | cut -d/ -f2)

    kubectl delete secret “$secret” -n “$ns”

  done

Шаг 4. Перезапустить pod’ы для подхвата нового ConfigMap:

 

kubectl rollout restart deployment -n appliner-platform

kubectl rollout restart deployment -n appliner-ai

# Для каждого тенанта:

kubectl rollout restart deployment -n tenant-<name>

Шаг 5. Проверить работоспособность:

 

# Проверить статус сертификатов

kubectl get certificates -A

 

# Проверить ConfigMap с CA

kubectl get configmap platform-external-certificates -n appliner-platform -o yaml

 

# Проверить доступность сервисов

kubectl get pods -n appliner-platform

Использование кастомного сертификата (без cert-manager)

Для использования собственного сертификата вместо автоматической выдачи через cert-manager:

 

# В values Infrastructure Chart:

global:

  tls:

    customcert: true

    crt: |

      —–BEGIN CERTIFICATE—–

      <fullchain PEM — включая промежуточные сертификаты>

     —–END CERTIFICATE—–

    key: |

      —–BEGIN PRIVATE KEY—–

      <private key PEM>

      —–END PRIVATE KEY—–

Chart автоматически создаст Secret platform-tls-secret (для платформы) или tenant-tls-secret (для тенанта), который будет использован всеми Ingress-ресурсами.

 

Использование wildcard-сертификата

Для единого wildcard-сертификата на весь домен (*.<ROOT_DOMAIN>):

 

global:

  tls:

    wildcartcert: true

    crt: |

      —–BEGIN CERTIFICATE—–

      <wildcard fullchain PEM>

      —–END CERTIFICATE—–

    key: |

      —–BEGIN PRIVATE KEY—–

      <wildcard private key PEM>

      —–END PRIVATE KEY—–

Создаётся Secret wildcard-tls-secret, используемый всеми Ingress-ресурсами на всех уровнях (платформа, тенанты, приложения).

 

Замена сертификата отдельного сервиса

 

# Удалить TLS-секрет — cert-manager автоматически пересоздаст

kubectl delete secret <имя-tls-секрета> -n <namespace>

 

# Проверить статус перевыпуска

kubectl describe certificate <имя> -n <namespace>

Диагностика проблем с сертификатами

 

# Просмотр статуса всех Certificate ресурсов

kubectl get certificates -A

 

# Детали конкретного сертификата (срок, статус, ошибки)

kubectl describe certificate <имя> -n <namespace>

 

# Проверка ConfigMap с CA

kubectl get configmap platform-external-certificates -n appliner-platform -o yaml

 

# Логи cert-manager при проблемах выпуска

kubectl logs -l app.kubernetes.io/name=cert-manager -n cert-manager

 

# Проверка trustStore внутри Java-контейнера

kubectl exec -n appliner-platform <pod> — keytool -list -keystore /shared/cacerts -storepass changeit

 

# Проверка срока действия сертификата в Secret

kubectl get secret <tls-secret> -n <namespace> -o jsonpath='{.data.tls.crt}’ |

  base64 -d | openssl x509 -noout -dates

Параметр CERT_ISSUER

 

Deployment Manager и Service Creator используютпеременную CERT_ISSUER для автоматического создания Ingress-ресурсов при развёртывании тенантов и приложений. При создании нового тенанта Service Creator создаёт Ingress с аннотацией cert-manager.io/cluster-issuer, что инициирует автоматический выпуск TLS-сертификата для домена тенанта.

 

Журналирование событий

Архитектура централизованного логирования

• Filebeat развёрнут как DaemonSet на каждом узле кластера;
• Собирает логи всех контейнеров из /var/log/containers/*.log;
• Автоматически добавляет Kubernetes-метаданные (namespace, pod name, labels);
• Автоматически определяет уровень лога (ERROR, WARN, INFO, DEBUG, TRACE, FATAL);
• Передаёт в Elasticsearch по HTTPS с аутентификацией.

Рисунок 2

 

Политика хранения логов

• ILM Policy: filebeat-3d;
• Hot phase: rollover при достижении 50 GB или 1 день;
• Delete phase: удаление данных старше 3 дней;
• Elasticsearch: 3 реплики, 30 Gi storage каждая;
• Индексы создаются автоматически по шаблону filebeat-*.

Типы журналируемых событий

Таблица 25 Типы журналируемых событий

Источник	Описание	Фильтр в Kibana
Прикладные сервисы (Java/Go)	Бизнес-логика, ошибки, HTTP-запросы	kubernetes.labels.app: “<service>”
Keycloak	Аутентификация, авторизация	kubernetes.labels.app: “keycloak”
API Gateway	Входящие запросы, маршрутизация	kubernetes.labels.app: “api-gateway”
Kafka	Работа брокеров, consumer groups	kubernetes.namespace_name: “kafka”
PostgreSQL	SQL-операции, ошибки, failover	kubernetes.namespace_name: “psql”
Ingress (Traefik)	Входящий трафик, ошибки маршрутизации	kubernetes.namespace_name: “traefik”
cert-manager	Выпуск и обновление сертификатов	kubernetes.namespace_name: “cert-manager”

Дополнительные системы наблюдения

• Prometheus + Grafana — метрики (CPU, memory, HTTP latency, JVM heap, DB connections, Kafka consumer lag);
• Jaeger — распределённая трассировка (trace ID, span duration, inter-service calls);
• Kubernetes Events — события кластера (kubectl get events -A –sort-by=’.lastTimestamp’).

Резервное копирование программных и информационных ресурсов

Стратегия резервного копирования

Таблица 26 Резервное копирование

Компонент	Метод	Частота (рекомендуемая)	RPO
etcd (метаданные K8s)	Автоматические snapshot RKE2	Каждые 6 часов	6 часов
PostgreSQL	pg_dumpall / CloudNativePG Backup CRD	Ежедневно	24 часа
MinIO	mc mirror	Ежедневно	24 часа
Kafka	Retention policy	Непрерывно	Зависит от retention
Keycloak	Realm export	При изменениях	N/A
Helm-релизы	Встроенная история ревизий	Автоматически	N/A

etcd (Kubernetes)

# Автоматические snapshot RKE2 (настроены по умолчанию):

• Каждые 6 часов
• Хранение последних 4 snapshot’ов

Расположение: /var/lib/rancher/rke2/server/db/snapshots/

 

# Ручной snapshot:

rke2 etcd-snapshot save –name manual-backup-$(date +%Y%m%d)

 

# Список snapshot’ов:

rke2 etcd-snapshot ls

 

# Восстановление из snapshot (ВНИМАНИЕ: остановить все узлы кроме одного):

rke2 server –cluster-reset –cluster-reset-restore-path=/path/to/snapshot

PostgreSQL

Через pg_dump (ручной бэкап):

kubectl exec -n psql $(kubectl get pods -n psql -l cnpg.io/cluster=postgres,role=primary -o name | head -1)

  -c postgres — pg_dumpall -U postgres > backup_$(date +%Y%m%d).sql

Бэкап отдельной базы:

kubectl exec -n psql $(kubectl get pods -n psql -l cnpg.io/cluster=postgres,role=primary -o name | head -1)

  -c postgres — pg_dump -U postgres <database_name> > backup_db_$(date +%Y%m%d).sql

Через CloudNativePG Backup CRD (при настроенном S3-хранилище):

kubectl apply -f – <<EOF

apiVersion: postgresql.cnpg.io/v1

kind: Backup

metadata:

  name: backup-$(date +%Y%m%d-%H%M%S)

  namespace: psql

spec:

  cluster:

    name: postgres

EOF

Восстановление:

# Из pg_dump:

kubectl exec -i -n psql $(kubectl get pods -n psql -l cnpg.io/cluster=postgres,role=primary -o name | head -1)

  -c postgres — psql -U postgres < backup_20260101.sql

MinIO (объектное хранилище)

# Через MinIO Client (mc)

mc alias set platform https://s3.<ROOT_DOMAIN> <access_key> <secret_key>

 

# Зеркалирование всех данных

mc mirror platform/ /backup/minio/

 

# Зеркалирование конкретного бакета

mc mirror platform/<bucket-name> /backup/minio/<bucket-name>

 

# Проверка целостности

mc diff platform/ /backup/minio/

Kafka

• Retention policy настраивается per-topic (по умолчанию 7 дней)
• Конфигурация топиков хранится в Kubernetes CRD (KafkaTopic) — покрывается snapshot etcd
• Для полного бэкапа данных Kafka рекомендуется использовать MirrorMaker 2

Keycloak

# Export realm через Keycloak Admin API

kubectl exec -n appliner-platform $(kubectl get pods -n appliner-platform -l app=keycloak -o name | head -1)

  — /opt/keycloak/bin/kc.sh export –dir /tmp/export –realm <realm-name>

 

# Копирование файлов export’а

kubectl cp appliner-platform/<keycloak-pod>:/tmp/export ./keycloak-backup/

Helm-релизы

# Просмотр истории всех релизов

helm list -A

helm history <имя-релиза> -n <namespace>

 

# Откат к предыдущей версии

helm rollback <имя-релиза> <revision> -n <namespace>

 

# Экспорт текущих values для бэкапа

helm get values <имя-релиза> -n <namespace> -o yaml > values-backup.yaml

Нештатные ситуации

Pod не запускается (CrashLoopBackOff / ImagePullBackOff)

Диагностика:

# Описание pod’а (события, причина ошибки)

kubectl describe pod <pod-name> -n <namespace>

 

# Логи предыдущего контейнера

kubectl logs <pod-name> -n <namespace> –previous

 

# События namespace

kubectl get events -n <namespace> –sort-by=’.lastTimestamp’

ImagePullBackOff — недоступен Docker Registry:

• Проверить доступность registry из кластера;
• Проверить корректность imagePullSecrets в Deployment;
• Проверить Secret <project>-docker-config-secret (credentials).

CrashLoopBackOff — ошибка приложения:

• Анализ логов предыдущего контейнера (–previous);
• Проверка переменных окружения (правильность подключений к БД, Kafka, Keycloak);
• Проверка доступности зависимых сервисов (PostgreSQL, Kafka, Keycloak).

PostgreSQL: кластер недоступен

# Статус кластера

kubectl get clusters.postgresql.cnpg.io postgres -n psql

 

# Просмотр событий оператора

kubectl describe clusters.postgresql.cnpg.io postgres -n psql

 

# CloudNativePG автоматически выполняет failover при падении primary

# Если все реплики недоступны — удалить pod’ы для принудительного пересоздания:

kubectl delete pods -l cnpg.io/cluster=postgres -n psql

# Оператор автоматически пересоздаст pod’ы и восстановит кластер

 

# Проверка PgBouncer (connection pooler):

kubectl get pods -l app.kubernetes.io/name=pgbouncer -n psql

kubectl logs -l app.kubernetes.io/name=pgbouncer -n psql

Kafka: брокеры недоступны

# Статус кластера

kubectl get kafka -n kafka

kubectl get pods -l strimzi.io/cluster=platform-kafka -n kafka

 

# Описание с деталями проблемы

kubectl describe kafka platform-kafka -n kafka

 

# Рестарт (Strimzi Operator пересоздаст pod’ы)

kubectl delete pods -l strimzi.io/cluster=platform-kafka -n kafka

 

# Проверка Entity Operator (управление топиками и пользователями)

kubectl get pods -l strimzi.io/name=platform-kafka-entity-operator -n kafka

Дисковое пространство заполнено (PVC)

# Проверить использование внутри pod’а

kubectl exec -n <namespace> <pod-name> — df -h

 

# Проверить состояние PVC

kubectl get pvc -A

 

# Для Elasticsearch — принудительная очистка старых индексов:

(Обычно ILM делает это автоматически). Если не работает:

# Подключиться к Elasticsearch и удалить старые индексы

 

# Для PostgreSQL — увеличить PVC (если StorageClass поддерживает expansion):

kubectl patch pvc <pvc-name> -n psql -p ‘{“spec”:{“resources”:{“requests”:{“storage”:”100Gi”}}}}’

 

# Если StorageClass не поддерживает expansion — выполнить миграцию данных на новый PVC

Узел кластера недоступен

# Проверить статус узлов

kubectl get nodes -o wide

 

# Kubernetes автоматически перенесёт pod’ы на другие узлы (через 5 минут по умолчанию)

 

# Принудительное удаление pod’ов с недоступного узла (если автоматика не сработала):

kubectl delete pods –field-selector spec.nodeName=<node-name> –all-namespaces –force –grace-period=0

 

# Удаление узла из кластера (если он не будет восстановлен):

kubectl drain <node-name> –ignore-daemonsets –delete-emptydir-data –force

kubectl delete node <node-name>

Сертификат истёк

# Проверить все сертификаты

kubectl get certificates -A

 

# Определить истекшие

kubectl get certificates -A -o jsonpath='{range .items[*]}{.metadata.name}{” “}{.metadata.namespace}{” “}{.status.notAfter}{“n”}{end}’

 

# Принудительный перевыпуск — удалить TLS-секрет

kubectl delete secret <tls-secret-name> -n <namespace>

# cert-manager автоматически пересоздаст сертификат

 

# Если cert-manager сам не работает:

kubectl logs -l app.kubernetes.io/name=cert-manager -n cert-manager

kubectl rollout restart deployment cert-manager -n cert-manager

 

# Если проблема с CA Secret:

kubectl get secret my-local-ca -n cert-manager

kubectl describe clusterissuer my-ca-issuer

Helm-релиз в состоянии failed

# История релиза (показывает все ревизии и их статус)

helm history <имя-релиза> -n <namespace>

 

# Откат к рабочей ревизии

helm rollback <имя-релиза> <номер-ревизии> -n <namespace>

 

# Если откат невозможен:

helm uninstall <имя-релиза> -n <namespace>

# Переустановка через init.sh или Deployment Manager API

Deployment Manager не отвечает

# Проверить pod

kubectl get pods -n appliner-platform -l app=deployment-manager

kubectl logs -l app=deployment-manager -n appliner-platform –tail=50

 

# Проверить health endpoint

kubectl exec -n appliner-platform <dm-pod> — curl -s http://localhost:9090/actuator/health

 

# Проверить подключение к зависимостям:

# – PostgreSQL (через PgBouncer)

# – Keycloak

# – Kafka

 

# Рестарт

kubectl rollout restart deployment <deployment-manager-name> -n appliner-platform

 

# Проверить восстановление

kubectl get pods -n appliner-platform -l app=deployment-manager -w

1. Сервисы не могут подключиться к PostgreSQL

# Проверить PgBouncer

kubectl get pods -l app.kubernetes.io/name=pgbouncer -n psql

kubectl logs -l app.kubernetes.io/name=pgbouncer -n psql

 

# Проверить PostgreSQL primary

kubectl get pods -l cnpg.io/cluster=postgres,role=primary -n psql

 

# Проверить credentials в secrets

kubectl get secret <project>-postgres-secret -n <namespace> -o yaml

 

# Проверить сетевую доступность из pod’а приложения

kubectl exec -n <namespace> <app-pod> — nc -zv <pgbouncer-host> <port>

Kafka consumer lag растёт

# Через Kafka UI: проверить consumer groups и их lag

 

# Через CLI (внутри Kafka pod’а):

kubectl exec -n kafka platform-kafka-brokers-0 — bin/kafka-consumer-groups.sh

  –bootstrap-server localhost:9092

  –describe –all-groups

 

# Возможные причины:

# – Потребитель остановлен или замедлен

# – Недостаточно ресурсов (CPU/Memory) у потребителя

# – Проблемы с сетью между потребителем и Kafka

 

# Решение: перезапуск потребителя или увеличение replicaCount

kubectl rollout restart deployment <consumer-deployment> -n <namespace>

Traefik: Ingress не маршрутизирует трафик

# Проверить Traefik pod

kubectl get pods -n traefik

kubectl logs -l app.kubernetes.io/name=traefik -n traefik –tail=50

 

# Проверить Ingress ресурсы

kubectl get ingress -A

kubectl describe ingress <ingress-name> -n <namespace>

 

# Проверить Middleware

kubectl get middleware -A

 

# Проверить что TLS-секрет существует и валиден

kubectl get secret <tls-secret> -n <namespace>

 

# Рестарт Traefik

kubectl rollout restart deployment traefik -n traefik

Ниже приведён список **IT-терминов**, присутствующих в предоставленном документе, с их общепринятыми определениями.

 

Термины и определения

Таблица 27 Термины и определения

№	Термин	Общепринятое определение
1	Low-code платформа	Среда разработки, позволяющая создавать приложения с минимальным объёмом ручного программирования, используя визуальные конструкторы и готовые модули.
2	BPMN (Business Process Model and Notation)	Стандарт нотации для моделирования бизнес-процессов, понятный как техническим специалистам, так и бизнес-аналитикам.
3	Kubernetes (K8s)	Платформа с открытым исходным кодом для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями.
4	Кластер	Группа взаимосвязанных компьютеров (узлов), работающих как единая система для обеспечения высокой доступности и масштабируемости.
5	Control-plane	Набор компонентов Kubernetes, управляющих состоянием кластера (планировщик, API-сервер, менеджер контроллеров).
6	Worker узел (нода)	Сервер в составе Kubernetes-кластера, на котором выполняются контейнеры приложений (поды).
7	High Availability (HA)	Свойство системы сохранять работоспособность при отказе одного или нескольких её компонентов.
8	Persistent Volume (PV)	Ресурс в Kubernetes, предоставляющий абстракцию для хранения данных с жизненным циклом, независимым от пода.
9	Persistent Volume Claim (PVC)	Запрос пользователя на выделение определённого объёма и типа хранилища из Persistent Volume.
10	Ingress	Объект Kubernetes, управляющий внешним доступом к сервисам кластера (маршрутизация HTTP/HTTPS).
11	Ingress Controller	Реализация (компонент), которая выполняет правила, заданные в Ingress (например, Traefik).
12	CNI (Container Network Interface)	Стандарт и набор плагинов для конфигурации сетевого взаимодействия контейнеров (например, Cilium, Calico).
13	etcd	Распределённое высоконадёжное хранилище типа «ключ-значение» для данных о состоянии кластера Kubernetes.
14	TLS (Transport Layer Security)	Криптографический протокол для шифрования и аутентификации при передаче данных (HTTPS).
15	CA (Certificate Authority)	Доверенный центр сертификации, выпускающий цифровые сертификаты.
16	cert-manager	Инструмент Kubernetes для автоматического управления и выпуска TLS-сертификатов.
17	ClusterIssuer	Ресурс cert-manager, определяющий способ выпуска сертификатов для всего кластера.
18	Docker Registry	Хранилище для образов контейнеров Docker (приватное или публичное).
19	Helm	Пакетный менеджер для Kubernetes, использующий «чарты» для развёртывания приложений.
20	Helm-чарт (chart)	Набор файлов с шаблонами Kubernetes-ресурсов, описывающий приложение для установки через Helm.
21	GitOps	Практика управления инфраструктурой через Git как единственный источник истины.
22	PostgreSQL	Реляционная система управления базами данных с открытым исходным кодом.
23	PgBouncer	Лёгкий менеджер пула соединений для PostgreSQL.
24	Operator (Kubernetes Operator)	Паттерн автоматизации — программный контроллер, управляющий сложными приложениями (например, CloudNativePG Operator).
25	Kafka	Распределённая платформа для потоковой передачи сообщений (брокер сообщений).
26	Брокер сообщений	Промежуточное ПО для асинхронного обмена сообщениями между сервисами.
27	Топик (topic)	Логический канал в Kafka для сообщений (производители → потребители).
28	Consumer lag	Отставание потребителя в Kafka — разница между последним сообщением и прочитанным.
29	KRaft mode	Режим работы Kafka без ZooKeeper (координация самими брокерами).
30	MinIO	Реализация объектного хранилища, совместимого с Amazon S3.
31	S3 (Simple Storage Service)	Стандарт объектного хранилища (Amazon S3 API).
32	ELK Stack (Elasticsearch, Logstash, Kibana)	Набор инструментов для централизованного логирования: сбор, хранение/поиск, визуализация.
33	Filebeat	Лёгкий сборщик логов для пересылки файлов логов в Elasticsearch (часто как DaemonSet).
34	DaemonSet	Тип ресурса Kubernetes, обеспечивающий запуск пода на каждом узле кластера.
35	ILM (Index Lifecycle Management)	Механизм управления жизненным циклом индексов в Elasticsearch (ролловер, удаление).
36	Jaeger	Инструмент для распределённой трассировки запросов.
37	Распределённая трассировка	Метод отслеживания выполнения запроса через множество микросервисов.
38	Prometheus	Система мониторинга и сбора метрик с временными рядами (PromQL).
39	Grafana	Платформа для визуализации данных и построения дашбордов.
40	Node Exporter	Экспортёр метрик ОС (CPU, память, диск, сеть) для Prometheus.
41	kube-state-metrics	Сервис метрик о состоянии объектов Kubernetes (подов, деплойментов).
42	Argo CD	Инструмент непрерывной доставки (CD) для Kubernetes (GitOps).
43	Rancher	Веб-интерфейс для управления несколькими Kubernetes-кластерами.
44	Keycloak	Платформа для управления идентификацией и доступом (аутентификация, SSO).
45	Realm (Keycloak)	Изолированное пространство в Keycloak для пользователей, клиентов, ролей.
46	ImagePullBackOff	Состояние пода при неудачной загрузке образа из Docker Registry.
47	CrashLoopBackOff	Состояние, при котором контейнер постоянно падает при запуске.
48	RollingUpdate	Стратегия обновления с постепенной заменой старых подов новыми (zero-downtime).
49	ReplicaCount	Количество идентичных реплик (экземпляров) пода.
50	Zero-downtime обновление	Обновление без прерывания обслуживания пользователей.
51	Probes (startup/liveness/readiness)	Механизмы проверки здоровья контейнеров (запуск, жив ли, готов ли принимать трафик).
52	ConfigMap	Объект Kubernetes для хранения конфигурационных данных (пары ключ-значение).
53	Secret	Объект Kubernetes для хранения конфиденциальных данных (пароли, токены, ключи).
54	Node Affinity	Механизм указания правил размещения подов на определённых узлах.
55	StorageClass	Ресурс Kubernetes, определяющий классы хранилищ с разными характеристиками.
56	Snapshot (etcd/БД)	Моментальный снимок состояния системы для восстановления после сбоя.
57	RPO (Recovery Point Objective)	Максимально допустимый объём потери данных (время между бэкапом и сбоем).
58	pg_dump / pg_dumpall	Утилиты PostgreSQL для создания логических резервных копий.
59	RKE2	Дистрибутив Kubernetes, сертифицированный CNCF, для безопасных production-сред.
60	Talos Linux	Специализированный минималистичный Linux-дистрибутив только для Kubernetes.
61	API Gateway	Единая точка входа для клиентских запросов к микросервисам (маршрутизация, аутентификация).
62	WebSocket Gateway	Шлюз для двустороннего асинхронного обмена по протоколу WebSocket.
63	CORS (Cross-Origin Resource Sharing)	Механизм, разрешающий или запрещающий запросы к ресурсам с другого домена.
64	Middleware (в Traefik)	Промежуточный слой в Traefik, модифицирующий запрос/ответ (CORS, перезапись пути).
65	TrustStore	Хранилище доверенных сертификатов в Java (JVM) для проверки TLS-соединений.
66	Spring Boot Actuator	Подпроект Spring Boot с production-готовыми endpoint’ами для мониторинга (health, metrics).
67	Blockly	Библиотека Google для создания визуальных редакторов программирования с блоками.
68	Camunda	Платформа для управления BPMN-процессами и рабочими потоками.
69	Deployment (Kubernetes)	Ресурс Kubernetes, описывающий желаемое состояние приложения (образ, реплики, стратегия).
70	Pod	Наименьший развёртываемый объект в Kubernetes (один или несколько контейнеров).
71	Namespace	Виртуальный кластер внутри физического Kubernetes для изоляции ресурсов.
72	StatefulSet	Контроллер для приложений с состоянием (требуют стабильных идентификаторов и хранилища).
73	Managed Kubernetes	Сервис облачного провайдера с управляемым Kubernetes-кластером (например, Yandex Cloud Managed Kubernetes).