Руководство по установке#
В руководстве приведены инструкции по установке компонента Граничный прокси (IGEG).
Термины и определения#
Термин/аббревиатура |
Определение |
|---|---|
CPU |
Central Processing Unit, центральный процессор |
КБ |
Килобайт (КБ) — единица измерения количества информации, равная 1024 байтам |
МБ |
Мегабайт (МБ) — единица измерения количества информации, равная 1024 КБ |
ГБ |
Гигабайт (ГБ) — единица измерения количества информации, равная 1024 МБ |
ТБ |
Терабайт (ТБ) — единица измерения количества информации, равная 1024 ГБ |
TPS |
Ticks per Second, число тактов в секунду |
Милликор |
Метрическая единица измерения, используемая для измерения загрузки процессора |
Pod |
Набор контейнеров внутри узла кластера Kubernetes |
Deployment |
Набор инструкций для запуска приложения в Kubernetes |
Платформа |
Платформа оркестрации приложений с средствами автоматизации и управления на основе политик, например Kubernetes |
Сервисная сетка / Service Mesh |
Архитектурный паттерн реализации управляемых, безопасных, контролируемых, прозрачных взаимодействий между микросервисными приложениями, обеспечиваемый набором прокси (Сервисных и Граничных), установленных в namespace потребителя |
Istio SE |
Настраиваемая сервисная сетка с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в кластере Kubernetes |
Контрольная панель |
Проект, где запущены управляющие приложения (компонент POLM) |
Управление политиками / POLM |
Компонент Управление политиками |
Граничный прокси / IGEG |
Компонент Граничный прокси |
Сервисный прокси / SVPX |
Компонент Сервисный прокси |
Ingress Gateway |
Прокси для контроля внешнего трафика входящего в проект. Позволяет включать для входящего трафика такие функции как маршрутизация, балансировка нагрузки, безопасность и мониторинг |
Egress Gateway |
Прокси для контроля исходящего трафика из проекта. Egress позволяет применять правила мониторинга и правила маршрутизации к выходящему трафику |
Проект / namespace |
Изолированная область (пространство имен) в кластере Kubernetes, предназначенная для разграничения доступа к ресурсам кластера (Deployment, Service, и т.д.) |
Системные требования#
Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.
Системное программное обеспечение#
Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.
Категория ПО |
Обязательность установки (да/нет)* |
Наименование ПО |
Версия |
Продукт, функциональная совместимость с которым подтверждена** |
Описание |
|---|---|---|---|---|---|
Операционная система |
Да |
10 |
Рекомендовано. Правообладателем АО «СберТех» также рекомендована ОС – Platform V SberLinux OS Server, см. раздел «Платформенные зависимости» |
ОС контейнеров для запуска модулей компонента |
|
8 |
Опционально |
||||
Cреда контейнеризации |
Да |
1.19 и выше |
Рекомендовано. Правообладателем АО «СберТех» также рекомендована среда контейнеризации – Platform V DropApp, см. раздел «Платформенные зависимости» |
Платформа контейнеризации для запуска компонентов сервиса |
|
4.6 и выше |
Опционально |
||||
Средство контейнеризации |
Да |
19.03.14 |
Рекомендовано |
Инструмент для автоматизации работы с контейнерами |
|
Сервис централизованного хранения репозиториев артефактов (хранилище артефактов) |
Да |
3.42.0 |
Рекомендовано |
Интегрированная платформа для проксирования, хранения и управления зависимостями Java (Maven), образами, а также распространения ПО |
|
3.43.0 |
Опционально |
||||
Nexus Repository Manager OSS |
3.43.0 |
Опционально |
|||
Сервис централизованного хранения репозиториев исходного кода |
Да |
15.7 и выше |
Рекомендовано |
Хранение конфигураций при автоматизированной установке |
|
7.6.7 |
Опционально |
||||
Сервис интеграции и оркестрации микросервисов в облаке |
Нет |
1.6 и выше |
Опционально |
Сервис интеграции микросервисов в облаке |
|
Система хранения и распространения secrets |
Нет |
1.10 и выше |
Опционально |
Система, обеспечивающая безопасный и надежный способ хранения и распространения secrets |
|
Система мониторинга (сбор и хранение метрик) |
Нет |
2.37 и выше |
Рекомендовано. Правообладателем АО «СберТех» также рекомендован сервис для сбора прикладных и инфраструктурных метрик и отправки их в целевую систему хранения – Объединенный мониторинг Unimon Platform V Monitor, см. раздел «Платформенные зависимости» |
Система для сбора и хранения численных метрик |
|
Сервис для сбора метрик |
Нет |
Victoria metrics |
1.5 и выше |
Опционально |
Инструмент для сбора метрик |
Иное |
Нет |
NODE.JS |
14-buster |
Рекомендовано |
Кроссплатформенная среда исполнения с открытым исходным кодом |
Менеджер пакетов |
Нет |
3.8 и выше |
Опционально |
Инструмент для автоматизации создания, настройки и развертывания приложений и служб в k8s |
|
Иное |
Нет |
1.20.5 и выше |
Опционально |
Интерфейс командной строки для взаимодействия с кластером |
Примечание:
*
Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).
Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).
**
Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.
Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.
Платформенные зависимости#
У компонента IGEG реализована интеграция со следующими компонентами из состава продукта:
Наименование компонента |
Код |
Описание |
|---|---|---|
Управление политиками |
POLM |
Управление политиками из состава продукта Platform V Synapse Service Mesh формирует конфигурации компонент сервисного и граничного прокси |
Сервисный прокси |
SVPX |
Обработанная конфигурация загружается в виде настроек в SVPX. Также SVPX подписывается на рассылку конфигураций от POLM |
DevOps инструменты Service Mesh |
SMDL |
Сборка, установка и администрирование сервисов на Synapse |
Для настройки, контроля и функционирования компонента IGEG реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:
Наименование продукта |
Код |
Версия продукта |
Код и наименование компонента |
Обязательность установки (да/нет) |
Описание |
Аналог других производителей |
|---|---|---|---|---|---|---|
Platform V Monitor |
OPM |
4.1 |
LOGA/Журналирование |
Нет |
Сервис предназначен для сохранения логов и предоставляет возможности для их просмотра и анализа конечными пользователями (сотрудниками поддержки) |
Любой сервис сбора записей о событиях, совместимый с fluent-bit, например: Elasticsearch, InfluxDB |
MONA/Объединенный мониторинг Unimon |
Нет |
Продукт предназначен для сбора данных о производительности, доступности и работоспособности прикладных приложений и инфраструктуры |
Prometheus 2.37 и выше |
|||
Platform V DropApp |
K8S |
1.1 и выше |
K8SC K8S Core |
Нет |
Дистрибутив Kubernetes со встроенными механизмами мультитенантности и бессерверным исполнением |
Kubernetes |
Platform V SberLinux OS Server |
SLO |
8.7 |
INST Операционная система |
Нет |
OС контейнеров для запуска модулей компонента |
С Альт 8 СП |
Platform V Backend |
#BD |
4.2.0 и выше |
OTTS One-Time Password (OTP)/OTT |
Нет |
Сервис для аутентификации и авторизации межсервисных взаимодействий |
Примечание:
***
Да — компонент или продукт необходим для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данного компонента).
Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).
****
Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».
Аппаратные требования#
Для установки компонента требуется следующая конфигурация аппаратного обеспечения, рассчитанная в зависимости от схемы взаимодействия и количества TPS.
Процессор
CPU измеряется в милликорах (millicores). Один милликор равен 1⁄1000 ядра. 1000 милликоров = 1 ядро.
Память
Память измеряется в КБ, МБ, ГБ и ТБ.
Единицы измерения:
1024 bytes = 1 КБ;
1024 КБ = 1 МБ;
1024 МБ = 1 ГБ;
1024 ГБ = 1 ТБ.
На промышленных стендах для повышения надежности для критичных сервисов рекомендуется устанавливать request = limit.
Контейнер |
Режим работы приложения |
CPU Request, millicores |
Memory Request, MБ |
CPU Limit, millicores |
Memory Limit, MБ |
|---|---|---|---|---|---|
istio-proxy |
Ingress Gateway |
300 |
300 |
300 |
300 |
istio-proxy |
Egress Gateway |
300 |
300 |
300 |
300 |
Количество задействованных реплик компонента IGEG зависит от объема принимаемых данных.
Подготовка окружения#
Перед установкой проверьте соблюдение следующих условий:
Развернут и настроен кластер Kubernetes версии 1.19 и выше, в соответствии с требованиями, предъявляемыми к Платформе.
В проекте создана учетная запись с правами на загрузку артефактов.
Настроен доступ в Docker-репозиторий для публикации образов разрабатываемых приложений (Dev-репозиторий).
Для доступа в Kubernetes c использованием консоли, на рабочем месте должен быть установлен клиент Kubernetes (kubectl).
Для отладки IGEG необходимо иметь клиент istioctl, поставляется в дистрибутиве.
В случае использования дополнительных систем класса управления секретами, их использование совместно с граничным прокси рекомендуется согласно документации на соответствующие системы.
Установка#
Этот документ содержит названия переменных, которые применимы для различных сред контейнеризации, указанных в системных требованиях руководства по установке.
Установка ОТТ, LOGA, MONA, Prometheus и других платформенных зависимостей производится по инструкции, входящей в комплект соответствующих дистрибутивов.
В данном разделе рассмотрены 2 способа развертывания граничного прокси (сервисы Ingress Gateway и Egress Gateway) в проект в Kubernetes.
Yaml-файлы из дистрибутива можно загрузить с помощью Веб-интерфейса Kubernetes или Интерфейса командной строки Kubernetes.
Для установки в проект нужны права не ниже admin.
Независимо от выбора способа установки необходимо реализовать сертификаты и ключ для успешного взаимодействия LOGA fluent-bit (tengri_ca.cer/tengri.pem/tengri.key), про правила формирования необходимо уточнить в документации компонента LOGA fluent-bit.
Типовая схема установки в проект:

В проекте может быть установлен как отдельно Ingress Gateway, так и Egress Gateway. Процесс установки подходит для различных схем расположения сервисов IGEG в проектах.
Через веб-интерфейсе Kubernetes#
Авторизуйтесь в веб-интерфейсе Kubernetes:

В веб-интерфейсе выберите нужный проект (1).
Нажмите на + для добавления нового ресурса в проект (2).
По умолчанию уже будет открыта вкладка Create from input. Вставьте в текстовую область (3) загружаемый ресурс.
Нажмите Upload (4).
Через интерфейс командной строки Kubernetes#
C помощью команды импортировать ресурс, сохраненный в yaml файл, в проект:
kubectl apply --kubeconfig- <путь_к_kubeconfig_файлу> -f <yaml_файл_с_конфигурацией> -n <имя_проекта>`
Пример:

Содержание дистрибутива#
В состав дистибутива IGEG входят следующие артефакты:
Deployment.yaml (istio-ingressgateway) — конфигурационный файл, представляющий собой приложение Ingress gateway;
Deployment.yaml (istio-egressgateway) — конфигурационный файл, представляющий собой приложение Egress gateway;
Service.yaml (ingressgateway) — конфигурационный файл, позволяющий настраивать коммуникацию между прикладными сервисами и Ingress gateway;
Service.yaml (egressgateway) — конфигурационный файл, позволяющий настраивать коммуникацию между прикладными сервисами и Egress gateway;
Secret.yaml (istio-ingressgateway-certs) — конфигурационный файл, для работы с чувствительными данными;
Secret.yaml (istio-egressgateway-certs) — конфигурационный файл, для работы с чувствительными данными;
Secret.yaml (istio-ingressgateway-ca-certs) — конфигурационный файл, для работы с чувствительными данными;
Secret.yaml (istio-egressgateway-ca-certs) — конфигурационный файл, для работы с чувствительными данными.
Deployment.yaml (istio-ingressgateway)
kind: Deployment
apiVersion: apps/v1
metadata:
name: istio-ingressgateway
labels:
app: istio-ingressgateway
istio: ingressgateway
spec:
selector:
matchLabels:
app: istio-ingressgateway
istio: ingressgateway
template:
metadata:
labels:
app: istio-ingressgateway
istio: ingressgateway
annotations:
prometheus.io/path: /stats/prometheus
prometheus.io/port: '15020'
prometheus.io/scrape: 'true'
sidecar.istio.io/inject: 'false'
spec:
restartPolicy: Always
schedulerName: default-scheduler
terminationGracePeriodSeconds: 30
securityContext: {}
containers:
- resources:
limits:
cpu: <лимиты_по_cpu>
memory: <лимиты_по_памяти>
requests:
cpu: <реквесты_по_cpu>
memory: <реквесты_по_памяти>
readinessProbe:
httpGet:
path: /healthz/ready
port: 15021
scheme: HTTP
initialDelaySeconds: 1
timeoutSeconds: 1
periodSeconds: 2
successThreshold: 1
failureThreshold: 30
terminationMessagePath: /dev/termination-log
name: istio-proxy
env:
- name: PROXY_CONFIG
value: |
{"discoveryAddress":"<имя_сервиса_istiod_контрольной_панели>.<имя_проекта_контрольной_панели>.svc:15012"}
- name: JWT_POLICY
value: third-party-jwt
- name: PILOT_CERT_PROVIDER
value: istiod
- name: CA_ADDR
value: '<имя_сервиса_istiod_контрольной_панели>.<имя_проекта_контрольной_панели>.svc:15012'
- name: NODE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- name: INSTANCE_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.podIP
- name: HOST_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP
- name: SERVICE_ACCOUNT
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.serviceAccountName
- name: ISTIO_META_WORKLOAD_NAME
value: istio-ingressgateway
- name: ISTIO_META_OWNER
value: >-
kubernetes://apis/apps/v1/namespaces/<имя_проекта>/deployments/istio-ingressgateway
- name: ISTIO_META_MESH_ID
value: cluster.local
- name: TRUST_DOMAIN
value: cluster.local
- name: ISTIO_META_UNPRIVILEGED_POD
value: 'true'
- name: ISTIO_META_CLUSTER_ID
value: Kubernetes
securityContext:
capabilities:
drop:
- ALL
privileged: false
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
ports:
- containerPort: 15021
protocol: TCP
- containerPort: 8080
protocol: TCP
- containerPort: 8443
protocol: TCP
- containerPort: 31400
protocol: TCP
- containerPort: 15443
protocol: TCP
- name: http-test
containerPort: 15090
protocol: TCP
imagePullPolicy: Always
volumeMounts:
- name: istio-envoy
mountPath: /etc/istio/proxy
- name: istiod-ca-cert
mountPath: /var/run/secrets/istio
- name: istio-token
readOnly: true
mountPath: /var/run/secrets/tokens
- name: istio-data
mountPath: /var/lib/istio/data
- name: socket
mountPath: /var/run/secrets/workload-spiffe-uds
- name: podinfo
mountPath: /etc/istio/pod
- name: ingressgateway-certs
readOnly: true
mountPath: /etc/istio/ingressgateway-certs
- name: ingressgateway-ca-certs
readOnly: true
mountPath: /etc/istio/ingressgateway-ca-certs
terminationMessagePolicy: File
image: <ссылка_на_образ proxy из состава дистрибутива>
args:
- proxy
- router
- '--domain'
- $(POD_NAMESPACE).svc.cluster.local
- '--proxyLogLevel=warning'
- '--proxyComponentLogLevel=misc:error'
- '--log_output_level=default:info'
volumes:
- name: istiod-ca-cert
configMap:
name: istio-ca-root-cert
defaultMode: 256
- name: podinfo
downwardAPI:
items:
- path: labels
fieldRef:
apiVersion: v1
fieldPath: metadata.labels
- path: annotations
fieldRef:
apiVersion: v1
fieldPath: metadata.annotations
defaultMode: 256
- name: istio-envoy
emptyDir: {}
- name: istio-data
emptyDir: {}
- name: istio-token
projected:
sources:
- serviceAccountToken:
audience: istio-ca
expirationSeconds: 43200
path: istio-token
defaultMode: 256
- name: socket
emptyDir: {}
- name: ingressgateway-certs
secret:
secretName: istio-ingressgateway-certs
defaultMode: 256
optional: true
- name: ingressgateway-ca-certs
secret:
secretName: istio-ingressgateway-ca-certs
defaultMode: 256
optional: true
dnsPolicy: ClusterFirst
Deployment.yaml (istio-egressgateway)
kind: Deployment
apiVersion: apps/v1
metadata:
name: istio-egressgateway
labels:
app: istio-egressgateway
istio: egressgateway
spec:
selector:
matchLabels:
app: istio-egressgateway
istio: egressgateway
template:
metadata:
labels:
app: istio-egressgateway
istio: egressgateway
annotations:
prometheus.io/path: /stats/prometheus
prometheus.io/port: '15020'
prometheus.io/scrape: 'true'
sidecar.istio.io/inject: 'false'
spec:
restartPolicy: Always
schedulerName: default-scheduler
terminationGracePeriodSeconds: 30
containers:
- resources:
limits:
cpu: <лимиты_по_cpu>
memory: <лимиты_по_памяти>
requests:
cpu: <реквесты_по_cpu>
memory: <реквесты_по_памяти>
readinessProbe:
httpGet:
path: /healthz/ready
port: 15021
scheme: HTTP
initialDelaySeconds: 1
timeoutSeconds: 1
periodSeconds: 2
successThreshold: 1
failureThreshold: 30
terminationMessagePath: /dev/termination-log
name: istio-proxy
env:
- name: PROXY_CONFIG
value: |
{"discoveryAddress":"<имя_сервиса_istiod_контрольной_панели>.<имя_проекта_контрольной_панели>.svc:15012"}
- name: JWT_POLICY
value: third-party-jwt
- name: PILOT_CERT_PROVIDER
value: istiod
- name: CA_ADDR
value: '<имя_сервиса_istio_контрольной_панели>.<имя_проекта_контрольной_панели>.svc:15012'
- name: NODE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- name: INSTANCE_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.podIP
- name: HOST_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP
- name: SERVICE_ACCOUNT
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.serviceAccountName
- name: ISTIO_META_WORKLOAD_NAME
value: istio-egressgateway
- name: ISTIO_META_OWNER
value: >-
kubernetes://apis/apps/v1/namespaces/<имя-проекта>/deployments/istio-egressgateway
- name: ISTIO_META_MESH_ID
value: cluster.local
- name: TRUST_DOMAIN
value: cluster.local
- name: ISTIO_META_UNPRIVILEGED_POD
value: 'true'
- name: ISTIO_META_CLUSTER_ID
value: Kubernetes
securityContext:
capabilities:
drop:
- ALL
privileged: false
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
ports:
- containerPort: 8080
protocol: TCP
- containerPort: 8443
protocol: TCP
- name: http-test
containerPort: 15090
protocol: TCP
imagePullPolicy: Always
volumeMounts:
- name: istio-envoy
mountPath: /etc/istio/proxy
- name: istiod-ca-cert
mountPath: /var/run/secrets/istio
- name: istio-token
readOnly: true
mountPath: /var/run/secrets/tokens
- name: istio-data
mountPath: /var/lib/istio/data
- name: socket
mountPath: /var/run/secrets/workload-spiffe-uds
- name: podinfo
mountPath: /etc/istio/pod
- name: egressgateway-certs
readOnly: true
mountPath: /etc/istio/egressgateway-certs
- name: egressgateway-ca-certs
readOnly: true
mountPath: /etc/istio/egressgateway-ca-certs
terminationMessagePolicy: File
image: <ссылка_на_образ>
args:
- proxy
- router
- '--domain'
- $(POD_NAMESPACE).svc.cluster.local
- '--proxyLogLevel=warning'
- '--proxyComponentLogLevel=misc:error'
- '--log_output_level=default:info'
volumes:
- name: istiod-ca-cert
configMap:
name: istio-ca-root-cert
defaultMode: 256
- name: podinfo
downwardAPI:
items:
- path: labels
fieldRef:
apiVersion: v1
fieldPath: metadata.labels
- path: annotations
fieldRef:
apiVersion: v1
fieldPath: metadata.annotations
defaultMode: 256
- name: istio-envoy
emptyDir: {}
- name: istio-data
emptyDir: {}
- name: istio-token
projected:
sources:
- serviceAccountToken:
audience: istio-ca
expirationSeconds: 43200
path: istio-token
defaultMode: 256
- name: socket
emptyDir: {}
- name: egressgateway-certs
secret:
secretName: istio-egressgateway-certs
defaultMode: 256
optional: true
- name: egressgateway-ca-certs
secret:
secretName: istio-egressgateway-ca-certs
defaultMode: 256
optional: true
dnsPolicy: ClusterFirst
Service.yaml (ingressgateway)
kind: Service
apiVersion: v1
metadata:
name: ingressgateway
spec:
ports:
- name: <имя порта>
protocol: TCP
port: <порт>
targetPort: <порт>
selector:
app: <pod_label>
type: ClusterIP
Service.yaml (egressgateway)
kind: Service
apiVersion: v1
metadata:
name: egressgateway
spec:
ports:
- name: <имя порта>
protocol: TCP
port: <порт>
targetPort: <порт>
selector:
app: <pod_label>
type: ClusterIP
Secret.yaml (istio-ingressgateway-certs)
kind: Secret
apiVersion: v1
metadata:
name: istio-ingressgateway-certs
data:
tls.key: >-
tls.crt: >-
type: Opaque
Secret.yaml (istio-ingressgateway-ca-certs)
kind: Secret
apiVersion: v1
metadata:
name: istio-ingressgateway-ca-certs
data:
ca-chain.cert.pem: >-
type: Opaque
Secret.yaml (istio-egressgateway-certs)
kind: Secret
apiVersion: v1
metadata:
name: istio-egressgateway-certs
data:
tls.key: >-
tls.crt: >-
type: Opaque
Secret.yaml (istio-egressgateway-ca-certs)
kind: Secret
apiVersion: v1
metadata:
name: istio-egressgateway-ca-certs
data:
ca-chain.cert.pem: >-
type: Opaque
Подключение к POLM#
Подключение к POLM осуществляется путем указания имени сервиса POLM в параметре <имя_сервиса_istiod_контрольной_панели>.<имя_проекта_контрольной_панели> шаблона Deployment приведенного выше.
Генерация сертификатов#
Для тестовых целей на стенде разработки и тестирования можно использовать самоподписанные сертификаты. Для генерации самоподписанных сертификатов, воспользуйтесь инструкцией:
Создайте файл config.conf конфигурации для генерации запроса на выдачу (подпись) сертификата:
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default =
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default =
localityName = Locality Name (eg, city)
localityName_default =
organizationName = Organization Name (eg, company)
organizationName_default = Test
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = dev
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = test.ru
DNS.2 = test2.ru
DNS.3 = test3.ru
Сгенерируйте рутовый ключ и сертификат:
openssl req -x509 -sha256 -nodes -days 3365 -newkey rsa:2048 -subj '/O=SynTest/CN=test.syn' -keyout root.key -out ca-chain.cert.pem
Создайте CSR и выпустите сертификат:
openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key -config config.conf
openssl x509 -req -days 2365 -CA ca-chain.cert.pem -CAkey root.key -set_serial 0 -in tls.csr -out tls.crt -extensions req_ext -extfile config.conf
Интеграция граничного прокси с Системой управления секретами (Хранилище secrets)#
В случае необходимости интеграции в Deployment граничного прокси добавьте следующие нотации и метки:
apiVersion: apps/v1
kind: Deployment
spec:
template:
metadata:
annotations:
vault.hashicorp.com/agent-init-first: "true" # смонтировать секреты до запуска основного контейнера
vault.hashicorp.com/agent-inject: "true" # обеспечивает инъекцию инит-контейнера и Sidecar vault-agent в Pods граничного прокси
vault.hashicorp.com/namespace: <пространство в хранилище>
vault.hashicorp.com/agent-inject-secret-chain.crt: "true" # vault.hashicorp.com/agent-inject-secret - статичная яасть, chain.crt - имя файла, который будет создан Sidecar vault-agent
vault.hashicorp.com/agent-inject-secret-tls.crt: "true"
vault.hashicorp.com/agent-inject-secret-tls.key: "true"
vault.hashicorp.com/agent-inject-template-chain.crt: | # где chain.crt - имя файла сертификата с цепочкой УЦ, который будет создан Sidecar vault-agent
{{- with secret "<пространство в хранилище>/<имя секрета>" -}}
{{ .Data.chain }}
{{- end }}
vault.hashicorp.com/agent-inject-template-tls.crt: | # где tls.crt - имя файла сертификата, который будет создан Sidecar vault-agent
{{- with secret "<пространство в хранилище>/<имя секрета>" -}}
{{ .Data.crt }} #поле в секрете называется "crt"
{{- end }}
vault.hashicorp.com/agent-inject-template-tls.key: | # где tls.key - имя файла приватного ключа, который будет создан Sidecar vault-agent
{{- with secret "<пространство в хранилище>/<имя секрета>" -}}
{{ .Data.key }} #поле в секрете называется "key"
{{- end }}
vault.hashicorp.com/agent-pre-populate: "true" #обеспечить наличие секретов до запуска основного контейнера Istio-proxy
vault.hashicorp.com/role: ciNNNNNNNN_xxx # роль в SecMan, получаемая при подключению к хранилищу
vault.hashicorp.com/secret-volume-path: /etc/certs/some-path #директория, в которую будут помещены файлы из секрета
vault.hashicorp.com/agent-limits-cpu: 500m # здесь и ниже лимиты и запросы ресурсов для vault-agent sidecar
vault.hashicorp.com/agent-limits-mem: 128Mi
vault.hashicorp.com/agent-requests-cpu: 250m
vault.hashicorp.com/agent-requests-mem: 64Mi
vault.hashicorp.com/agent-volumes-default-mode: "0400"
vault.hashicorp.com/agent-inject-containers: istio-proxy # ограничиваем контейнеры, в которые монтируются секреты,
labels
secman-injector: enabled #обеспечивает подключение Pods к SecMan
Интеграция граничного прокси с ОТТ-Sidecar#
Установка и настройка ОТТ-Sidecar в Pod граничного прокси должна осуществляться в соответствии с инструкцией по установке ОТТ. Для настройки граничного прокси:
Добавьте в Deployment IGEG emptyDir volume для обеспечения информационного обмена с ОТТ-Sidecar и примонтируйте его по пути /mnt/ott-uds-socket:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: istio-proxy
volumeMounts:
- mountPath: /mnt/ott-uds-socket
name: ott-uds-socket
volumes:
- emptyDir:
medium: Memory
name: ott-uds-socket
Создайте в namespace c IGEG ресурс EnvoyFilter для включения авторизации:
kind: EnvoyFilter
apiVersion: networking.istio.io/v1alpha3
metadata:
name: ott-authz-filter
spec:
workloadSelector:
labels:
app: ott-egressgateway # Соответствует метке вашего Deployment IGEG, то есть применяется только туда
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: envoy.filters.network.http_connection_manager
portNumber: 11443 # Указанный порт соответствует порту, определенному ресурсом networking.istio.io/gateway - вы создали его, когда настраивали маршрутизацию через Egress
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.sbt_authz
typed_config:
'@type': "type.googleapis.com/udpa.type.v1.TypedStruct"
typeUrl: type.googleapis.com/envoy.extensions.filters.http.sbt_authz.v3.SbtAuthz
value:
api: STANDARD
authorize_only_request: true # false - авторизуются как HTTP Request, так и HTTP Response, true - только запрос
failure_mode_allow: false # Запрещает трафик при недоступности сервера авторизации
transport_api_version: V3
grpc_service:
google_grpc:
stat_prefix: sbt_authz
target_uri: 'unix:/mnt/ott-uds-socket/ott.socket' # путь к файлу соответствует точке монтирования в Deployment
timeout: 5s # значение as is на фактическую производительно влияние не оказывает но необходимо для корректного запуска, может быть скорректировано по результатам НТ
sidecar_role: EGRESS # Флаг того, что фильтр устанавливается на Egress proxy, для Ingress - INGRESS соответственно
with_request_body: # Параметр, указывающий фильтру, что в запрос к сервису авторизации также нужно добавлять тело HTTP запроса, если оно присутствует;
allow_partial_message: false
max_request_bytes: 100000 # данный параметр ограничит максимальный размер запроса. в случае превышения запрос не пройдет авторизацию или проверку целостности - указывайте его с запасом
pack_as_bytes: false # Флаг того, что тело запроса передается в виде строки в сервис авторизации, в случае необходимости поддержки бинарного тела - true;
Фильтр sbt_authz позволяет проводить авторизацию и контроль целостности как для HTTP-запросов, так и для ответов (то есть авторизация работает и в одну и в другую сторону). В случае, если достаточно авторизации только запроса, то можно использовать фильтр ext_authz в конфигурации ниже. Для корректной работы авторизации через фильтр ext_authz также требуется скорректировать configMap с настройками OTT-sidecar, прописав туда поле OTT_OPER_MODE в соответствии с документацией на ОТТ.
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: envoy.filters.network.http_connection_manager
portNumber: 12443
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.ext_authz
typed_config:
'@type': >-
type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
grpc_service:
google_grpc:
stat_prefix: ext_authz
target_uri: 'unix:/mnt/ott-uds-socket/ott.socket'
timeout: 5s
transport_api_version: V3
failure_mode_allow: false # Запрещает трафик при недоступности сервера авторизации
with_request_body:
allow_partial_message: false
max_request_bytes: 1000000
pack_as_bytes: false
workloadSelector:
labels:
app: ott-egressgateway
Обновление#
Для обновления IGEG переустановите релиз с новой версией дистрибутива. Процесс установки новой версии описан в разделе «Установка». Старая версия Deployment удаляется (заменяется) новой. Старт может осуществляться с использованием различных стратегий, в зависимости от требований приложений, запущенных в данном Pod. Возможные стратегии старта:
rollingUpdate — старый Pod не будет остановлен, пока новый еще не стартовал, для минимизации времени простоя;
recreate — старый Pod будет остановлен, и после этого будет запущен новый (запуск обычно происходит быстрее, чем в случае rollingUpdate);
canary — быстрое обновление Pod для нескольких пользователей с дальнейшим полным обновлением.
При переходе с версии IGEG 3.6 (Istio 1.12) и ниже на 3.7 (Istio 1.17) и выше необходимо добавить в Deployment Ingress / Egress один volume и один volumeMount:
volumes:
- name: socket
emptyDir: {}
...
volumeMounts:
- name: socket
mountPath: /var/run/secrets/workload-spiffe-uds
Необходимость связана с тем, что в Istio версии 1.17.x и 1.19x для обмена сертификатами с istiod Envoy использует протокол UDS (Unix Domain Socket) вместо xDS (Discovery Service).
По умолчанию pilot-agent в контейнере istio-proxy (как Sidecar или как Ingress/Egress) ищет UDS-сокет по стандартному пути, чтобы с его помощью подключиться к istiod и получить сертификаты:
/var/run/secrets/workload-spiffe-uds
И если у pilot-agent не получается создать файл сокета по этому пути, то контейнер istio-proxy не стартует.
Если проект подключен к ControlPlane с Istio SE 1.17.x и 1.19x, то Sidecars будут созданы с необходимыми volumes и volumeMounts.
Убедитесь, что в контейнере istio-proxy Egress или Ingress, конфигурация которых определена вручную, создается volume и volumeMount по пути /var/run/secrets/workload-spiffe-uds.
Удаление#
Для удаления IGEG достаточно удалить Deployment конфигурацию из кластера. Данное действие может повлиять на маршрутизацию запросов в namespace: при замене IGEG на другой прокси требуется перенастройка маршрутизации трафика в соответствии с документацией на выбранный продукт.
Проверка работоспособности#
Проверка работоспособности платформенных зависимостей производится по инструкции, входящей в комплект соответствующих дистрибутивов.
Проверка Deployment#
Зайдите в Deployment (после авторизации слева в Workloads выберите раздел Deployments, в списке выберите нужный Deployment).
В Deployment перейдите во вкладку редактирования, нажав иконку пера сверху справа.
В массиве status:conditions проверьте значения:
* для type: Progressing должны быть установлены:
* status: 'True';
* reason: NewReplicaSetAvailable;
* message: ReplicaSet "%Имя граничного прокси%" has successfully progressed;
* для type: Available должны быть установлены:
* status: 'True';
* reason: MinimumReplicasAvailable;
* message: Deployment has minimum availability.
Пример граничного прокси, прошедшего проверку работоспособности Deployment:

Проверка модулей Deployment#
Зайдите в нужный проект.
Зайдите в Pod (после авторизации слева в Workloads выберите раздел Pods, в списке выберите нужный Pod).
В Pod посмотрите значения во вкладке Containers :

Корректным будет условие: все контейнеры отмечены зеленым кружочком, в блоке Status у полей Ready и Started значения
true.
Также можно выполнить проверку через консоль.
Для этого достаточно выполнить команду:
kubectl --kubeconfig= <путь_к_kubeconfig> -n <имя_проекта> get pods
Пример:

В графе Ready значение у Pod граничного прокси должно быть M/N, где M — количество успешно работающих контейнеров, а N — общее количество работающих контейнеров. Если M = N, то все успешно запустилось, если же M < N, то необходимо либо еще подождать, пока контейнеры запустятся, либо посмотреть раздел «Часто встречающиеся проблемы и пути их устранения».
Проверка логов контейнера#
Зайдите в нужный проект.
В меню выберите пункт Workload/Pods.
На странице найдите нужный Pod.
Перейдите по ссылке в этот Pod.
Перейдите на вкладку ≡ (Logs). В консоли не должно быть ошибок.

Корректным условием является отсутствие логов с ошибками и запись:
Info Envoy proxy is ready:

Также можно выполнить проверку через консоль.
Для этого достаточно выполнить команду: kubectl --kubeconfig=<путь_к_kubeconfig> -n <имя_проекта> logs <имя Pod>
Пример:

Если указано сообщение Info Envoy proxy is ready, — значит все корректно установилось и функционирует.
Интеграционные взаимодействия#
При реализации взаимодействий с использованием ОТТ, LOGA, MONA и Prometheus, необходимо ознакомиться с методами проверки работоспособности в документации указанных компонент.
Откат#
Откат компонента на одну из предыдущих версий (не позднее 3 по счету от текущей) происходит с помощью развертывания YAML-файлов из дистрибутива предыдущей версии.
Действия аналогичны описанным в подразделе «Установка», но в данном случае требуются YAML-файлы предыдущей версии. Deployment новой версии удаляется из namespace. Устанавливаемая версия IGEG должна соответствовать версии POLM.
Часто встречающиеся проблемы и пути их устранения#
Проблема |
Пути решения |
|---|---|
Граничный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready |
Проверьте корректность подключения к контрольной панели. |
До прикладного приложения не доходят запросы |
Проверьте логи граничного прокси. Возможные варианты сообщений описаны ниже |
В логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем и корректность параметров host/порт в конфигурационных файлах прикладного проекта — Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний host, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания host/порт |
В логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule |
В логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Если используется автоматическая аутентификация ISTIO_MUTUAL — проверьте наличие конфликта в разделе trafficPolicy конфигурационного файла DestinationRule, относящегося к проблемному сервису, и раздела |
В логе граничного прокси видно сообщение: |
Авторизуйтесь в прикладном проекте. Проверьте наличие вызываемого сервиса — в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис — в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение running |
В логе граничного прокси видны сообщения: |
Проверьте имена портов в объектах Service: они должны иметь формат <протокол>-<номер_порта>. Если имя порта начинается с |
Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели.
Чек-лист валидации установки#
Проверьте наличие полномочий в namespace, не ниже admin.
Заполните в шаблонах переменные для указания требуемых значений.
При необходимости сгенерируйте сертификаты для внешних взаимодействий.
При использовании внешних систем управления секретами разместите сертификаты и ключи в хранилище secrets или разместите их в кластере Kubernetes путем создания ресурсов Secret.
Создайте ресурсы по конфигурационным файлам, входящим в дистрибутив IGEG, в зависимости от требуемой конфигурации (согласно разделу «Установка»).
При необходимости использования дополнительных интеграций (ОТТ, система управления секретами) — настройте взаимодействие по соответствующим инструкциям.
Проверьте работоспособность установленных прокси.
Проверьте, что Pods с Ingress Gateway и Egress Gateway имеют статус Running и запущены все контейнеры (столбец Ready).
Перейдите внутрь Pod, выберите раздел Logs и проверьте, что в нем нет никаких ошибок. Подробнее в подразделе «Проверка логов контейнера».
Проверьте интеграции компонента IGEG с внешними системами и компонентами. Порядок проверки приведен в подразделе «Проверка работоспособности интеграций».