Руководство прикладного разработчика#

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

Системные требования#

Для использования компонента Сервисный прокси необходимо выполнение следующих пререквизитов:

1. Кластер Kubernetes (версии 1.19 и выше) развернут и настроен в соответствии с требованиями, предъявляемыми к Платформе.

2. В проекте создана учетная запись с правами на создание конфигураций.

3. Настроен доступ для публикации образов разрабатываемых приложений в Docker-репозиторий.

4. На рабочей машине пользователя установлен клиент Kubernetes (kubectl) для доступа в Kubernetes c использованием консоли.

5. На рабочей машине пользователя установлен клиент istioctl, поставляемый в дистрибутиве.

Также для подключения SVPX необходим проект, подключенный к интеграционной платформе.

Подключение и конфигурирование#

Подключение#

Чтобы запустить приложение с сервисным прокси, необходимо добавить его аннотацию в Deployment приложения.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'

Конфигурирование#

Сценарий 1. Управление трафиком сервисного прокси#

Конфигурационные файлы

Базовая конфигурация сервисного прокси осуществляется путем автоматического получения конфигурационного файла от компонента POLM. Администрирование компонента POLM описано в документе «Руководство по системному администрированию» POLM.

Для выполнения указанных действий пользователь Kubernetes должен иметь полномочия create на ресурсы групп networking.istio.io, security.istio.io в соответствующем namespace.

1. Подключение к интерфейсу управления

Для подключения через веб-интерфейс Платформы выполните следующие шаги:

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

2. Установите конфигурационные файлы

Для установки через веб-интерфейс Платформы:

Для установки через консоль Платформы:

Типы конфигурационных файлов#

Для настройки сервиса SVPX могут быть применены следующие типы конфигурационных файлов:

• DestinationRule;

• VirtualService;

• ServiceEntry.

Destination Rule

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

Пример настройки политик балансировки:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN

Можно настроить отдельные политики, для разных версий приложений, на которые ссылается общий сервис приложения "ratings". В примере ниже показано правило, применяющее тип балансировки "round robin" для всего трафика, направленного на подгруппу "testversion" и объединяющую все endpoints (Pods) с метками "version:v3":

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN
  subsets:
  - name: testversion
    labels:
      version: v3
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN

Можно определить балансировку в зависимости от портов на которые поступает трафик:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookinfo-ratings-port
spec:
  host: ratings.prod.svc.cluster.local
  trafficPolicy: # Apply to all ports
    portLevelSettings:
    - port:
        number: 80
      loadBalancer:
        simple: LEAST_CONN
    - port:
        number: 9080
      loadBalancer:
        simple: ROUND_ROBIN

Virtual Service

Несколько полезных терминов для понимания контекста перенаправления трафика:

Сервис — единица поведения приложения, связанная с уникальным именем в реестре служб Платформы. Сервис содержит некоторое количество сетевых конечных точек, привязанных к инстансам Deployment (Pods).

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

Источник — клиент вызывающий сервис.

Хост(host) — адрес, используемый клиентом при попытке соединения с сервисом.

Модель доступа — приложения обращаются только к целевому сервису (host) без знания отдельных версий (подмножеств) сервисов. Фактический выбор версии определяется сервисным прокси.

VirtualService — определяет набор правил для маршрутизации трафика, адресованного на определенный host. Каждое правило имеет критерии соответствия, по которым трафик будет отправлен в нужном направлении. Источник трафика также может быть одним из критериев соответствия в правилах маршрутизации.

Следующий пример маршрутизирует HTTP трафик по умолчанию на Pods сервиса reviews версии "version: v1”, но для трафика содержащего URI с /wpcatalog/ или /consumercatalog/ будет выполнена перезапись значения URI на /newcatalog и трафик будет перенаправлен на Pods с метками “version: v2”.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - name: "reviews-v2-routes"
    match:
    - uri:
        prefix: "/wpcatalog"
    - uri:
        prefix: "/consumercatalog"
    rewrite:
      uri: "/newcatalog"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
  - name: "reviews-v1-route"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1

Подмножества направления маршрутизации описаны в связанном с сервисом DestinationRule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews.prod.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Service Entry

ServiceEntry включает дополнительные записи во внутренний реестр сервисов Service Mesh так, чтобы система обнаружения сервисов имела доступ к дополнительно описанным сервисам.

ServiceEntry описывает свойство сервиса (DNS имя, порты, протоколы). Эти сервисы могут быть расположены как в кластере Kubernetes, так и вне его (baremetal, VM, и т.д.).

Следующий пример описывает несколько внешних сервисов для доступа к ним от внутренних приложений по HTTPS. Сервисный прокси проверяет значение SNI в сообщении ClientHello, чтобы направить трафик на внешний сервис.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-svc-https
spec:
  hosts:
  - api.dropboxapi.com
  - www.googleapis.com
  - api.facebook.com
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS

Сценарий 2. Создание и монтирование volumes в контейнер SVPX#

Для записи различных volumes используется монтирование директорий в файловую систему Pod. В Deployment приложения нужно добавить аннотацию:

sidecar.istio.io/userVolume: >-

          [ {"name": "имя volume", "volume":

          {"ключ":"значение"}} ]

sidecar.istio.io/userVolumeMount: >-

          [ {"name": "имя volume",  "mountPath":

          "заданная директория volume",  "readonly": false} ]

Теперь при инжектировании образа SVPX указанные volume добавляются в контейнер SVPX (istio-proxy).

Пример 1.#

Монтирование новых директорий в файловую систему Pod для хранения сертификатов:

sidecar.istio.io/inject: 'true' # инжектирование sidecar istio-proxy
sidecar.istio.io/proxyImage: >-
registry.ХХХ.ХХХ.ru/pprb/ci01994970/ci02320655_synapse_security/istio/proxyv2@sha256:5b76427736afcc0f9eb6d3fd0f75cf89e5007049533ebe21806d1edd0e0ae610 # указание к применению образа

sidecar.istio.io/userVolume: >-

          [ {"name": "egressgateway-certs", "secret":

          {"secretName":"istio-egressgateway-certs"}},  {"name":

          "egressgateway-ca-certs", "secret":

          {"secretName":"istio-egressgateway-ca-certs"}} ]

sidecar.istio.io/userVolumeMount: >-

          [ {"name": "egressgateway-certs",  "mountPath":

          "/etc/istio/egressgateway-certs",  "readonly": false},  {"name":

          "egressgateway-ca-certs",  "mountPath":

          "/etc/istio/egressgateway-ca-certs",  "readonly": false} ]

При отсутствии аннотации sidecar.istio.io/proxyImage образ скачивается из контрольной панели

Пример 2.#

sidecar.istio.io/userVolumeMount: '[{"name": "valgrind", "mountPath": "/tmp/valgrind"}]'
sidecar.istio.io/userVolume: '[{"name": "valgrind", "emptyDir": {"medium": "Memory"}}]

Миграция на текущую версию#

После обновления контрольной панели требуется перезапуск pod с контейнером прокси. Новая версия загрузится автоматически.

Быстрый старт#

Для получения примера конфигурации Sidecar сервисного прокси подключите его в Deployment с помощью аннотации sidecar.istio.io/inject: 'true':

kind: Deployment
apiVersion: apps/v1
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: 'true'

И далее посмотрите yaml-конфигурацию в Pod приложения.

Использование программного компонента#

Компонент Сервисный прокси используется для маршрутизации и обеспечения безопасности трафика между приложениями.

Часто встречающиеся проблемы и пути их устранения#

Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели.