Руководство по установке#

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

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

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Примечание:

*

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

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

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

(!) В случае использования какой-либо другой облачной платформы, основанной на Kubernetes, необходимо убедиться, что в ее основе используется Kubernetes версии не ниже 1.19.

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

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

Для настройки, контроля и функционирования компонента реализована интеграция с программным продуктом, правообладателем которого является АО «СберТех»:

Примечание:

***

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

• Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

Аппаратные требования#

Минимальные ресурсы, необходимые для компонента Управление политиками (зависит от количества конфигурационных файлов и проектов):

Минимальные ресурсы, необходимые для компонента Istio Operator (зависит от количества конфигурационных файлов и проектов):

Состав дистрибутива#

В состав дистрибутива POLM входит:

Состав дистрибутива может быть расширен дополнительными конфигурациями, учитывающими прикладные требования клиента. Конфигурация может представлять собой Helm Chart, применяемый следующей командой:

helm install <имя_релиза_helm> <путь_к_папке_с_конфигурацией> 

Примечание:

*

Список компонент Istio SE в составе дистрибутива:

• install-cni — Istio CNI Plugin (требуется для настройки сетевых правил маршрутизации (iptables) Сервисного прокси);

• operator — приложение Istio Operator (сервис установки);

• pilot — приложение istiod (POLM);

• proxyv2 — приложение SVPX и IGEG.

Выбор способа установки#

Установку можно выполнить как с помощью Istio Operator (сервиса для установки Istio), так и с помощью Helm charts.

Подготовка окружения#

Перед установкой проверьте соблюдение следующих условий:

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

2. Для доступа в Kubernetes c использованием консоли на рабочем месте должен быть установлен клиент Kubernetes (kubectl), совместимой с кластером Kubernetes версии.

3. Для установки сервиса Управления политиками необходимо иметь клиент Istio (istioctl), поставляется в дистрибутиве.

4. В случае выбора способа установки сервиса Управления политиками через Helm charts, на рабочем месте должен быть установлен helm, версии не ниже 3.6.

5. На один кластер может быть одновременно установлена только одна контрольная панель.

Каких-либо требований безопасности к рабочему окружению и к платформе Kubernetes со стороны POLM не предъявляется.

Установка#

Этот документ содержит названия переменных, которые применимы для различных сред контейнеризации, указанных в системных требованиях руководства по установке.

Сборка образов компонент Istio SE#

Базовый образ#

Для сборки образов компонент необходимо предварительно подготовить базовый образ, на основе которого должны собираться образы компонент Istio SE.

К базовому образу предъявляются следующие требования:

• в базовом образе необходимо наличие утилиты iptables (при использовании istio-init контейнера вместо Istio CNI Plugin);

• в базовом образе для SVPX, IGEG, POLM и Istio Operator необходимо наличие пользователя с ID 1337 (UID), принадлежащего группе с ID 1337 (GID), при условии, что значения UID и GID, задаваемые в Dockerfile компонента, не будут переопределяться платформой Kubernetes (директивы runAsUser и runAsGroup) во время исполнения;

• в базовом образе для Istio CNI Plugin необходимо наличие пользователя с ID 0 (UID), принадлежащего группе с ID 0 (GID), при условии что значения UID и GID, задаваемые в Dockerfile компонента, не будут переопределяться платформой Kubernetes (директивы runAsUser и runAsGroup) во время исполнения.

Возможна сборка базового образа Istio на основе sberlinux.

Если необходимо закрыть возможность запуска исполняемой оболочки (shell или bash), можно удалить исполняемые файлы оболочек в Dockerfile для сборки базового образа:

FROM repo/sberlinux:latest
 
RUN rm /bin/bash
RUN rm /bin/sh

Способы администрирования компонент Istio, собранных без исполняемой оболочки, описаны в документации к IGEG и SVPX в Руководстве администратора.

Если базовый образ был предоставлен в виде архива, то загрузить его в ваш реестр образов можно следующими командами:

1. Загрузка образа из архива в локальный реестр образов:

docker load < <архив_с_образом>

2. Если требуется изменить tag загруженного из архива образа:

docker tag <старый_tag> <новый_tag>

3. Загрузка образа в реестр образов:

docker push <tag>

Компоненты Istio SE#

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

Также необходимо:

1. Проверить название образа перед push, чтобы был прописан полный путь.

2. Для каждого компонента перейти в папку package/bin/<название_компонента>.

3. Для сборки образа в качестве аргумента передать базовый образ:

docker build --build-arg BASE_IMAGE=<базовый_образ> -t <tag_компонента> .

Например:

docker build --build-arg BASE_IMAGE=sber-tech.com/istio-se/base:1.17 -t sber-tech.com/istio-se/pilot:1.17 .

Установка Istio#

Установить Istio можно с помощью Helm charts из дистрибутива, с помощью istioctl и с помощью Istio Operator. Использование Istio Operator является целевым способом установки и именно он будет рассмотрен далее по тексту документа. Установить istio-operator можно как с помощью istioctl, так и с помощью Helm charts.

Установка Istio Operator#

Предусловия:

1. В кластере создан проект, в котором будет развернута контрольная панель (обычно имя проекта задается как istio-system), далее проект контрольной панели.

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

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

4. В кластере создан проект, в котором будет развернут Istio Operator для установки контрольной панели в проект контрольной панели (обычно имя проекта задается как istio-operator), далее проект Istio Operator.

5. В проекте Istio Operator создана учетная запись с правами на загрузку артефактов.

6. В проекте Istio Operator имеются свободные ресурсы по лимитам и requests не менее, чем зарезервировано в конфигурационных артефактах.

С помощью istioctl#

Для установки следует выполнить следующие действия:

1. Выполните установку с помощью istioctl.

2. Для установки оператора запустите istioctl со следующими аргументами:

operator

init

\--kubeconfig=<путь_к_файлу_kubeconfig>

\--operatorNamespace=<имя_проекта_для_установки_Istio_Operator>

\--hub=<ссылка_хранилище_с_артефактами_Istio>

\--imagePullSecrets=<имя_Secret_для_выкачки_артефактов>

\--watchedNamespaces=<имя_проекта_контрольной_панели>

\--tag=<docker_тэг_артефактов>

\--image=<ссылка_на_docker_образ_с_оператором>

\--resources=<json_объект_с_ресурсами_для_Istio_Operator>

Пример:

istioctl operator init --kubeconfig=./kubeconfig.json --operatorNamespace=istio-operator --hub=my.corp.cloud.ru/sber --imagePullSecrets=default-secret --watchedNamespaces=istio-system --tag=custom-1.11.2-alt

Если использовать аргумент image, то аргументы hub и tag будут проигнорированы. С помощью аргумента image можно задать образ с sha256, например: --image=my.company/repo@sha256:123456

Аргумент resources используется для проставления ресурсов для pod Istio Operator, например: --resources="{"resources": {"limits": {"cpu": "200m", "memory": "256Mi"}, "requests": {"cpu": "50m", "memory": "128Mi"}}}"

Значение ресурсов по умолчанию:

 resources:
   limits:
     cpu: 200m
     memory: 256Mi
   requests:
     cpu: 50m
     memory: 128Mi

Аргумент может использоваться для переопределения значения ресурсов по умолчанию, например: --resources="{"resources": "requests": {"cpu": "150m", "memory": "256Mi"}}}"

В данном примере будут переопределены значения requests, а значения лимитов останутся значениями по умолчанию.

Если задать watchedNamespaces='', то Istio Operator будет обрабатывать конфигурации IstioOperator (конфигурация для установки Контрольной панели (Управления политиками)) со всего кластера. Иначе, при использовании watchedNamespaces со значениями, отличными от пустых, Istio Operator будет обрабатывать конфигурации IstioOperator только в перечисленных проектах.

Пример:

istioctl operator init --kubeconfig=./kubeconfig.json >--operatorNamespace=istio-operator --hub=my.corp.cloud.ru/sber >--imagePullSecrets=default-secret --watchedNamespaces='' >--tag=custom-1.11.2-alt

С помощью Helm charts#

Для установки Helm charts выполните следующую команду:

helm install <имя_шаблона> <путь_к_папке_с_Helm_charts> --namespace <имя_проекта_для_установки>

Пример:

helm install istio-base istio/base -n istio-system

Аргументы можно задать в файле values.yaml в той же папке или же через аргумент --set.

helm install <имя_шаблона> <путь_к_папке_с_Helm_charts> --namespace <имя_проекта_для_установки> --set <путь_к_ключ>=<значение>

Пример:

helm install <имя_шаблона> <путь_к_папке_с_Helm_charts> --namespace <имя_проекта_для_установки> --set watchedNamespaces=istio-system --set operator.resources.cpu=200m

Набор всех значений можно посмотреть в содержимом самого шаблона.

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

Установив оператор, можно устанавливать istiod. Для этого необходимо выполнить следующие действия:

1. Установку через консоль выполните с помощью kubectl.

2. Для установки контрольной панели в проекте контрольной панели создайте ресурс IstioOperator.

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

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: <название_ресурса_может_быть_любым>
spec:
  profile: default
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>
  meshConfig:
    rootNamespace: <имя_проекта_контрольной_панели>
  components:
    egressGateways:
      - name: istio-egressgateway
        enabled: <флажок_включения_egress>
    ingressGateways:
      - name: istio-ingressgateway
        enabled: <флажок_включения_ingress>
    cni:
      enabled: false
    pilot:
      enabled: true
  values:
    global:
      imagePullSecrets:
        - <имя_Secret_для_выкачки_артефактов>
      istioNamespace: <имя_проекта_контрольной_панели>
      imagePullPolicy: IfNotPresent
    pilot:
      resources:
        limits:
          cpu: <лимиты_CPU>
          memory: <лимиты_Memory>
        requests:
          cpu: <реквесты_CPU>
          memory: <реквесты_Memory>

Пример шаблона с заполненными параметрами:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istiocontrolplane
spec:
  profile: default
  hub: my.corp.cloud.ru/sber
  tag: custom-1.11.2-alt
  meshConfig:
    rootNamespace: istio-system
  components:
    egressGateways:
      - name: istio-egressgateway
        enabled: true
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
    cni:
      enabled: false
    pilot:
      enabled: true
  values:
    global:
      imagePullSecrets:
        - default-secret
      istioNamespace: istio-system
      imagePullPolicy: IfNotPresent
    pilot:
      resources:
        limits:
          cpu: 1000m
          memory: 2Gi
        requests:
          cpu: 1000m
          memory: 2Gi

Создать ресурс через консоль можно следующими командами:

• сохранив ресурс IstioOperator в файл, загрузить его в проект контрольной панели:

  kubectl --kubeconfig=<путь_к_файлу_kubeconfig> apply -f <файл_с_ресурсом_IstioOperator>
  

• создать ресурс IstioOperator можно, передав его напрямую из потоков ввода данных консоли (stdin):

cat <<EOF | kubectl -n istio-system --kubeconfig=kubeconfig.json apply -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: <название_ресурса_может_быть_любым>
spec:
  components:
    cni:
      enabled: false
    egressGateways:
      - enabled: <флажок_включения_egress>
        name: istio-egressgateway
    ingressGateways:
      - enabled: <флажок_включения_ingress>
        name: istio-ingressgateway
    pilot:
      enabled: true
  hub: <ссылка_хранилище_с_артефактами_Istio>
  meshConfig:
    rootNamespace: <имя_проекта_контрольной_панели>
  profile: default
  tag: custom-1.11.2-alt
  values:
    global:
      imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - <имя_Secret_для_выкачки_артефактов>
      istioNamespace: <имя_проекта_контрольной_панели>
    pilot:
      resources:
        limits:
          cpu: <лимиты_CPU>
          memory: <лимиты_Memory>
        requests:
          cpu: <реквесты_CPU>
          memory: <реквесты_Memory>
EOF

Установка компонента Управление политиками через пользовательский интерфейс#

Установив оператор, можно устанавливать istiod. Для этого необходимо выполнить следующие действия:

1. Установку через пользовательский интерфейс выполните с помощью веб-интерфейса Kubernetes.

2. Для установки контрольной панели в проекте контрольной панели создайте ресурс IstioOperator.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: <название_ресурса_может_быть_любым>
spec:
  profile: default
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>
  meshConfig:
    rootNamespace: <имя_проекта_контрольной_панели>
  components:
    egressGateways:
      - name: istio-egressgateway
        enabled: <флажок_включения_egress>
    ingressGateways:
      - name: istio-ingressgateway
        enabled: <флажок_включения_ingress>
    cni:
      enabled: false
    pilot:
      enabled: true
  values:
    global:
      imagePullSecrets:
        - <имя_Secret_для_выкачки_артефактов>
      istioNamespace: <имя_проекта_контрольной_панели>
      imagePullPolicy: IfNotPresent
    pilot:
      resources:
        limits:
          cpu: <лимиты_CPU>
          memory: <лимиты_Memory>
        requests:
          cpu: <реквесты_CPU>
          memory: <реквесты_Memory>

Пример:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istiocontrolplane
spec:
  profile: default
  hub: my.corp.cloud.ru/sber
  tag: custom-1.11.2-alt
  meshConfig:
    rootNamespace: istio-system
  components:
    egressGateways:
      - name: istio-egressgateway
        enabled: true
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
    cni:
      enabled: false
    pilot:
      enabled: true
  values:
    global:
      imagePullSecrets:
        - default-secret
      istioNamespace: istio-system
      imagePullPolicy: IfNotPresent
    pilot:
      resources:
        limits:
          cpu: 1000m
          memory: 2Gi
        requests:
          cpu: 1000m
          memory: 2Gi

Создать ресурс IstioOperator в проекте контрольной панели через веб-интерфейс можно несколькими способами.

1 способ — предварительно сохранить ресурс IstioOperator в файл, загрузить его из файла:

1. В веб-интерфейсе выберите проект контрольной панели (1).

2. Нажмите на + для добавления нового ресурса в проект контрольной панели (2).

3. Нажмите Create from file .

4. Нажмите на ••• (3) для выбора файла, содержащего ресурс IstioOperator.

5. Нажмите Upload (4).

2 способ — вставить содержимое ресурса IstioOperator напрямую в веб-интерфейсе:

1. В веб-интерфейсе выберите проект контрольной панели (1).

2. Нажмите на + для добавления нового ресурса в проект контрольной панели (2).

3. По умолчанию уже будет открыта вкладка Create from input.

4. Вставьте в текстовую область (3) ресурс IstioOperator.

5. Нажмите Upload (4).

Примечание. Если использовать Istio CNI Plugin (выставить spec.components.cni.enabled = true), образ которого запускается не под root (директива USER в базовом Dockerfile использована с некоторым значением, отличным от root), то для запуска pods CNI Plugin необходимо выдать им root права. Сделать это можно с помощью следующих настроек в IstioOperator:

spec:
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
              - path: spec.template.spec.securityContext
                value: 'runAsUser: 0'

Или с помощью задания privileged. Можно также одновременно использовать обе настройки.

spec:
  values:
    cni:
      privileged: true

Пример такой конфигурации:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
  metadata:
    name: istiocontrolplane
  spec:
    profile: default
    hub: my.corp.cloud.ru/sber
    tag: custom-1.11.2-alt
    meshConfig:
      rootNamespace: istio-system
      components:
        egressGateways:
          - name: istio-egressgateway
            enabled: true
        ingressGateways:
          - name: istio-ingressgateway
            enabled: true
        pilot:
          enabled: true
        cni:
          enabled: true
          k8s:
            overlays:
              - kind: DaemonSet
                name: istio-cni-node
                patches:
                  - path: spec.template.spec.securityContext
                    value: 'runAsUser: 0'
      values:
        cni:
          privileged: true
        global:
          imagePullSecrets:
            - default-secret
          istioNamespace: istio-system
          imagePullPolicy: IfNotPresent
        pilot:
          resources:
            limits:
              cpu: 1000m
              memory: 2Gi
            requests:
              cpu: 1000m
              memory: 2Gi

Пример конфигурации IstioOperator для равномерного распределения pods istiod по nodes кластера#

Равномерное распределение istiods можно обеспечить, используя стандартные средства программного обеспечения оркестровки контейнеризированных приложений.

Наиболее подходящим инструментом, позволяющим управлять расположением pods, является affinity и anti-affinity.

Пример affinity для POLM#

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
...
spec:
  ...
  components:
    ...
    pilot:
      enabled: true
      k8s:
        affinity:
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 1
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                      - key: "app"
                        operator: In
                        values:
                          - "istiod"
                  topologyKey: "kubernetes.io/hostname"
    ...

До применения конфигурации список из десяти pods istiod выглядел следующим образом:

cab-wsm-0071416:charts $ kubectl get pod -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName -n crpv-13229-system
NAME                             STATUS    NODE
istiod-system-75d9cb6cf4-5qsch   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-8p8fg   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-jf989   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-kr8c7   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-lgp4r   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-m7xml   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-pjgtp   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-wmx95   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-wx5dq   Running   worker-03.**.solution
istiod-system-75d9cb6cf4-z6qr4   Running   worker-03.**.solution

Можно заметить, что pods расположились на одной node.

После применения конфигурации видно равномерное распределение pods по nodes:

cab-wsm-0071416:charts $ kubectl get pod -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase,NODE:.spec.nodeName -n crpv-13229-system
NAME                             STATUS    NODE
istiod-system-84f847c7b8-2ddc6   Running   worker-02.**.solution
istiod-system-84f847c7b8-595sw   Running   worker-02.**.solution
istiod-system-84f847c7b8-l949m   Running   worker-05.**.solution
istiod-system-84f847c7b8-nlxcz   Running   worker-04.**.solution
istiod-system-84f847c7b8-qvtpm   Running   worker-05.**.solution
istiod-system-84f847c7b8-qzgsw   Running   worker-01.**.solution
istiod-system-84f847c7b8-tv6wj   Running   worker-06.**.solution
istiod-system-84f847c7b8-wf2dq   Running   worker-04.**.solution
istiod-system-84f847c7b8-z8b47   Running   worker-01.**.solution
istiod-system-84f847c7b8-zpxhk   Running   worker-03.**.solution

Настройка сетевых правил маршрутизации pod#

Для работы SVPX необходимо настроить сетевые правила таблицы маршрутизации. Эту настройку можно выполнить несколькими способами:

1 способ — использовать Istio CNI Plugin.

Istio CNI Plugin представляет из себя плагин настройки сети pod, устанавливающийся в кластер в виде DaemonSet. То есть на каждой node кластера есть специальный плагин, который настраивает сеть контейнера при необходимости.

2 способ — использовать istio-init контейнер.

istio-init контейнер — это контейнер, который запускается до старта основных контейнеров, в его задачи входит настройка сети pod.

Одним из основных отличий между этими подходами является то, что в случае использования Istio CNI Plugin необходимо выдавать права (настройки безопасности) только на DaemonSet, а в случае с istio-init эти права выдаются на все проекты, где будет производиться запуск Сервисного прокси.

По умолчанию будет использоваться istio-init контейнер. Если требуется использовать cni, то необходимо указать в конфигурационном файле IstioOperator spec.cni.enabled: true.

Особенности установки Istio CNI Plugin#

Важной особенностью является то, что Istio CNI Plugin устанавливается на nodes кластера с помощью DaemonSet, который, в свою очередь, использует hostPath (монтирование файловой системы node к контейнеру в виде volume) для установки (по факту копирования) на файловую систему исполняемого бинарного файла Istio CNI Plugin и необходимых для его работы дополнительных файлов.

DaemonSet использует следующие директории для установки Istio CNI Plugin:

• mountPath - /host/opt/cni/bin, hostPath - задается в настройке cni.cniBinDir (значение по умолчанию /opt/cni/bin). Это директория для бинарных файлов CNI плагинов. В нее происходит копировании исполняемого бинарного файла Istio CNI Plugin, наименование файла - istio-cni;

• mountPath - /host/etc/cni/net.d, hostPath - задается в настройке cni.cniConfDir (значение по умолчанию /etc/cni/net.d). Это директория для конфигурационных файлов, которые используются при запуске CNI плагинов. В нее происходит копирование конфигурационного файла, используемого далее Istio CNI Plugin'ом, наименование файла - ZZZ-istio-cni-kubeconfig;

• mountPath - /var/run/istio-cni, hostPath - /var/run/istio-cni. Это директория для UDS сокета, для передачи логов из istio-cni (исполняемый бинарный файл Istio CNI Plugin) в install-cni (наименование контейнера DaemonSet).

Из особенностей установки стоит отметить:

1. Для установки Istio CNI Plugin у пользователя, под которым запущен процесс контейнера install-cni (контейнер из DaemonSet), должны быть соответствующие права на запись в директории, указанные в hostPath. Это связано с особенностями взаимодействия с файловой системой node.

2. В большинстве случаев права на данные директории имеют только root:root пользователи, именно поэтому UID:GID Istio CNI Plugin по умолчанию — root:root.

3. Если же на node используются некоторые реализации системы принудительного контроля доступа, к примеру, SELinux или AppArmor, то необходимо дополнительно настроить securityContext DaemonSet. Самый простой способ — privileged (пример настройки есть далее по тексту). Немаловажным является тот факт, что такого рода настройка может создавать некоторую потенциальную уязвимость на кластере и, в большинстве случаев, стоит избегать privileged у контейнеров. Также можно дополнительно обратиться за консультацией к поддержке продукта для помощи в адаптации securityContext под ваш конкретный кейс.

4. Исполняемый бинарный файл istio-cni имеет следующие права: 755 или же -rwxr-xr-x. Помимо владельца и группы, права на запуск нужны всем остальным для того, чтобы Container Runtime, используемый в кластере, мог запустить Istio CNI Plugin (Container Runtime может работать под UID и/или GID, отличным от процесса install-cni контейнера).

Дополнительные настройки Istio CNI Plugin#

WATCH_FULL_PATH#

DaemonSet Istio CNI при установке Istio CNI Plugin следит за изменениями в директориях, перечисленных выше в разделе Особенности установки Istio CNI Plugin. При каких-либо изменениях в данных директориях, DaemonSet Istio CNI переустанавливает все файлы, упомянутые в разделе Особенности установки Istio CNI Plugin.

В этих директориях могут быть какие-либо изменения, не связанные с самим Istio CNI Plugin, которые будут приводить к полной переустановке Istio CNI Plugin. Для того чтобы не переустанавливать при внесении в директории изменений, его не затрагивающих, можно выставить для DaemonSet env WATCH_FULL_PATH в значении true.

Благодаря этой настройке DaemonSet Istio CNI будет следить не просто за изменениями в директориях, а за изменениями самих файлов, которые он установил. К примеру, без этой настройки, DaemonSet следит за директорией /host/opt/cni/bin, с включенной настройкой - следит уже за файлом /host/opt/cni/bin/istio-cni, что, в свою очередь, сводит к минимуму количество лишних переустановок Istio CNI Plugin.

Пример настройки

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
spec:
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
              - path: 'spec.template.spec.containers[name:install-cni].env[-1]'
                value: |-
                  name: WATCH_FULL_PATH
                  value: 'true'
  ...

REINSTALL_TOKEN_SEPARATELY#

DaemonSet Istio CNI при установке Istio CNI Plugin следит изменениями в директориях, перечисленных выше в разделе Особенности установки Istio CNI Plugin. При каких-либо изменениях в данных директориях, DaemonSet Istio CNI переустанавливает все файлы, упомянутые в разделе Особенности установки Istio CNI Plugin.

Так как token service account Istio CNI может ротироваться (это делается средствами платформы Kubernetes), то его ротация приводит к изменениям в директории, за которой наблюдает DaemonSet Istio CNI. Что, в свою очередь, приводит к переустановке всех файлов Istio CNI Plugin, а не только к обновлению ZZZ-istio-cni-kubeconfig, содержащего token service account Istio CNI.

Поменять это поведение можно с помощью env REINSTALL_TOKEN_SEPARATELY, выставленным в значении true. Эта настройка меняет поведение таким образом, что если был изменен token service account Istio CNI (к примеру, случилась ротация token), то DeamonSet обновит исключительно kubeconfig файл ZZZ-istio-cni-kubeconfig и не будет переустанавливать все остальные файлы Istio CNI Plugin.

Пример настройки

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 ...
spec:
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
              - path: 'spec.template.spec.containers[name:install-cni].env[-1]'
                value: |-
                  name: REINSTALL_TOKEN_SEPARATELY
                  value: 'true'
  ...

Same Validation Port для istio-validation контейнера#

При использованиии Istio CNI Plugin, в SVPX встраивается init контейнер istio-validation. istio-validation контейнер используется для проверки корректности настроенных правил маршрутизации (iptables) для SVPX. Для обратной соместимости с более старыми версиями продукта проверка считается успешной, если правила настроены хотя бы для одного из специально зарезервированных портов: 15006 или 15001.

При необходимости, можно скорректировать поведение istio-validation контейнера, выставив настройку .Values.global.proxy_init.sameValidationPort в true с целью провпроверки только одного порта - 15006. Такая настройка позволяет более точно определять, что правила настроились именно для порта 15006, используемого в последних версиях продукта. Или же выставить ее в false, чтобы проверка шла для портов 15001 и 15006. По умолчанию настройка выставлена в true.

Как настроить service account projected token#

Платформа Kubernetes по умолчанию сама настраивает монтирование token в файловую систему pod. Если платформа поддерживает projected token, то значение expirationSeconds по умолчанию составляет 3607, а defaultMode 420, что может не соответствовать требованиям безопасности, необходимым администратору АС.

Поменять эти параметры можно, выставив значение настройки automountServiceAccountToken как false. По умолчанию платформой Kubernetes значение выставляется в true. И прописав volume и volumeMount с projected token вручную.

Пример настройки:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
...
spec:
...   
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
	            # Выставляем automountServiceAccountToken = false, чтобы выключить автоматическое монтирование token платформой Kubernetes
              - path: spec.template.spec.automountServiceAccountToken
                value: false
                # Задаем вручную projected token (создаем volume)
              - path: 'spec.template.spec.volumes[-1]'
                value: |-
                  name: token
                  projected:
                    sources:
                      - serviceAccountToken:
	                      # Время жизни
                          expirationSeconds: 600
                          path: token
                      - configMap:
                          name: kube-root-ca.crt
                          items:
                            - key: ca.crt
                              path: ca.crt
                      - downwardAPI:
                          items:
                            - path: namespace
                              fieldRef:
                                apiVersion: v1
                                fieldPath: metadata.namespace
                    # Mode на монтируемые файл
                    defaultMode: 256
                # Монтируем projected token (создаем volumeMount)
              - path: spec.template.spec.containers[name:install-cni].volumeMounts[-1]
                value: |-
                  name: token
                  readOnly: true
                  mountPath: /var/run/secrets/kubernetes.io/serviceaccount

Tolerations#

Стоит отметить, что по умолчанию DaemonSet Istio CNI Plugin ставится и на master nodes кластера.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
...
spec:
...
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
              - path: 'spec.template.spec.tolerations'

Ресурсы#

Также для CNI Plugin можно задавать настройки по ресурсам.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
...
spec:
...
  values:
    cni:
    ...
      resources:
        limits:
          cpu: <лимиты_CPU>
          memory: <лимиты_Memory>
        requests:
          cpu: <реквесты_CPU>
          memory: <реквесты_Memory>

Multus#

Также стоит отметить, что если на платформе Kubernetes используется Multus, то в конфигурации установки Istio CNI необходимо задать следующие параметры:

Шаблон

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 ...
spec:
  components:
    cni:
      enabled: true
    ...
  ...
  values:
    sidecarInjectorWebhook:
      injectedAnnotations:
        k8s.v1.cni.cncf.io/networks: istio-cni
    global:
      istioNamespace: <проект_cni>
    cni:
      chained: false
      cniBinDir: <path_to_multus_bin>
      cniConfDir: <path_to_cni_multus_net.d>
      cniConfFileName: istio-cni.conf
      logLevel: debug
      privileged: true
      resources:
        limits:
          cpu: <лимиты_CPU>
          memory: <лимиты_Memory>
        requests:
          cpu: <реквесты_CPU>
          memory: <реквесты_Memory>

А в конфигурации IstioOperator, с помощью которой производилась установка контрольной панели, задать:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
  values:
    sidecarInjectorWebhook:
      injectedAnnotations:
        k8s.v1.cni.cncf.io/networks: istio-cni
  ...

Пример

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
...
spec:
 components:
   cni:
     enabled: true
   ...
 ...
 values:
   sidecarInjectorWebhook:
     injectedAnnotations:
       k8s.v1.cni.cncf.io/networks: istio-cni
   global:
     istioNamespace: istio-cni
   cni:
     chained: false
     cniBinDir: /opt/multus/bin
     cniConfDir: /etc/cni/multus/net.d
     cniConfFileName: istio-cni.conf
     logLevel: debug
     privileged: true
     resources:
       limits:
         cpu: 300m
         memory: 500Mi
       requests:
         cpu: 300m
         memory: 500Mi

Установка CNI в отдельный проект отдельной конфигурацией#

Если на кластере предполагается установка одновременно более чем одной контрольной панели, то удобнее будет устанавливать Istio CNI Plugin в отдельный проект с использованием отдельной конфигурации IstioOperator.

Для этого достаточно создать отдельный ресурс IstioOperator c пустым профилем, который будет создавать только конфигурационные файлы для работы cni-plugin. Таким образом, если будем выключать (удалять) control-plane, то это никак не затронет cni-plugin, и мы сможем отдельно его обновлять.

Пример конфигурации cni-plugin

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-cni
  namespace: istio-cni
spec:
  components:
    cni:
      enabled: true
      k8s:
        overlays:
          - kind: DaemonSet
            name: istio-cni-node
            patches:
              - path: spec.template.spec.tolerations
      namespace: istio-cni
  hub: my.registry.ru
  profile: empty
  tag: 1.17
  values:
    global:
      istioNamespace: istio-cni
    cni:
      resources:
        limits:
          cpu: 300m
          memory: 500Mi
        requests:
          cpu: 300m
          memory: 500Mi

После чего в конфигурации контрольных панелей необходимо удалить все упоминания cni и задать параметр spec.values.istio_cni.enabled=true

Пример

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-default
  namespace: istio-system
spec:
  components:
    egressGateways:
      - enabled: false
        name: istio-egressgateway
    ingressGateways:
      - enabled: false
        name: istio-ingressgateway
    pilot:
      enabled: true
  hub: my.registry.ru
  meshConfig:
    defaultDestinationRuleExportTo:
      - .
    defaultServiceExportTo:
      - .
    defaultVirtualServiceExportTo:
      - .
    discoverySelectors:
      - matchLabels:
          istio.io/rev: istio-system
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY
  profile: default
  revision: istio-system
  tag: 1.17
  values:
    ...
    istio_cni:
      enabled: true
    pilot:
      resources:
        limits:
          cpu: 500m
          memory: 2Gi
        requests:
         cpu: 300m
         memory: 500Mi

Настройка логирования SVPX и IGEG#

В зависимости от значения IstioOperator: spec.meshConfig.accessLogFile запись access-логов всех контейнеров istio-proxy в проектах, подключенных к текущей контрольной панели, может быть включена, выключена, направлена в stdout или перенаправлена в файл. По умолчанию все access-логи istio-proxy выводятся в stdout (т.е. отображаются в интерфейсе контейнера), это соответствует значению /dev/stdout:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-demo
spec:
  ...
  meshConfig:
    accessLogFile: /dev/stdout
  ...

При этом в config_dump Envoy для каждого листенера будет указан параметр access_log со значением "path": "/dev/stdout":

       "access_log": [
   {
      "name": "envoy.access_loggers.file",
      "filter": {
         "response_flag_filter": {
            "flags": [
               "NR"
            ]
         }
      },
      "typed_config": {
         "@type": "type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog",
         "path": "/dev/stdout",
         "log_format": {
            "text_format_source": {
               "inline_string": "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n"
            }
         }
      }
   }
]     

Если задать вывод access-лога в файл, то вывод access-логов в интерфейс контейнера будет прекращен, и запись будет осуществляться только в этот файл.

Также папка с этим файлом должна быть указана как volume и volumeMount в каждом контейнере istio-proxy подключенных проектов, чтобы у Envoy были права на создание файла и запись:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-demo
spec:
  ...
  meshConfig:
    accessLogFile: /etc/istio/proxy/access.log
  ...

Чтобы иметь возможность одновременно отображать access-логи контейнеров istio-proxy в интерфейсе и направлять их в файлы, можно воспользоваться параметром extensionProviders.

Один из них должен быть настроен на /dev/stdout, в других можно определить пути к файлам, куда проекты, подключенные к данной контрольной панели, смогут записывать access-логи Envoy.

Пример настройки:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-demo
  namespace: istio-system
spec:
  meshConfig:
    extensionProviders:
    - name: envoy_default
      envoyFileAccessLog:
        path: /dev/stdout
    - name: envoy_file
      envoyFileAccessLog:
        path: /etc/istio/proxy/access.log

На уровне проектов и конкретных Deployment можно будет воспользоваться этими настройками, создав ресурс типа Telemetry.

Примеры настройки логирования в граничных прокси (ingress, egress) и на сайдкарах приложений находятся в документации на компоненты IGEG и SVPX в Руководстве по администрированию.

Подключение проекта#

Добавляем label на проект, чтобы MutatingWebhookConfiguration реагировал на создание pods в этом проекте и добавлял istio-proxy:

Шаблон

kubectl label namespace <проект> istio.io/rev=<лейбл_из_значения_revision>

Пример

kubectl label namespace dev-project istio.io/rev=istio-system

Проверить все проекты на наличие label можно с помощью команды:

kubectl get namespace- L istio.io/rev

Чтобы отключить проект от istio, удаляем label:

kubectl label namespace <проект> istio.io/rev-

Для работы CNI плагина необходимо в тестовом проекте создать ресурс NetworkAttachmentDefinition. Название соответствует параметру, указанному в injectedAnnotations.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: istio-cni

Если в проектах есть NetworkPolicies, которые ограничивают трафик между проектами, то может быть так, что нет физического доступа у istio-proxy в тестовых проектах к istiod. В данном случае нужно создать дополнительный ресурс NetworkPolicy в проекте с Istio и прописать, по какому признаку разрешать трафик. Например:

Шаблон

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: istio-mesh
  namespace: istio-system
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              istio.io/rev: <лейбл_из_значения_revision>
  policyTypes:
    - Ingress

Пример

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: istio-mesh
  namespace: istio-system
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              istio.io/rev: istio-system
  policyTypes:
    - Ingress

Установка в OpenShift (опционально)#

Установка в OpenShift отличается от приведенной выше некоторыми аспектами, описанными ниже.

Установка Istio SE версии 1.17.x в кластер OpenShift#

Примечание#

Делаем установку Istio версии SberEdition, например, 1.2.1.3.

Установка оператора и выдача прав должна быть осуществлена пользователем, у которого есть права cluster-admin.

Отличие установки OpenShift от установки в Kubernetes заключается в выделении дополнительных прав, настройки правил маршрутизации pod и обеспечение доступа между kubeapi-server и POLM.

Выделение прав#

В OpenShift используется механизм SecurityContextConstrains (SCC), ограничивающий SecurityContext pods Istio SE, поэтому необходимо выделить дополнительные права в проекты Istio.

Для работы Istio CNI Plugin нужно выдать права privileged на service account istio-cni.

Шаблон

oc project <имя_проекта_cni>
oc adm policy add-scc-to-user privileged system:serviceaccount:<имя_проекта_cni>:istio-cni

Пример

oc project istio-cni
oc adm policy add-scc-to-user privileged system:serviceaccount:istio-cni:istio-cni

Также можно создать специальный SCC исключительно для Istio CNI Plugin ввиду того, что привилегии, выдаваемые privileged, являются излишними.

Минимально необходимые SCC:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  annotations:
  kubernetes.io/description: 'istio-cni SCC for istio CNI plugin.'
  name: istio-cni
allowHostPorts: false
runAsUser:
  type: RunAsAny
allowHostDirVolumePlugin: true # Необходим, чтобы install-cni смог скопировать файлы Istio CNI на node.
seLinuxContext:
  type: RunAsAny
readOnlyRootFilesystem: false # Необходим, чтобы install-cni смог скопировать файлы Istio CNI на node.
fsGroup:
  type: RunAsAny
groups: []
defaultAddCapabilities: null
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - emptyDir
  - hostPath
  - secret
allowHostNetwork: true # Необходимо для того, чтобы на Istio CNI не действовали другие CNI плагины и он не пытался настроить сеть сам себе, так как этот флажок говорит использовать сеть node, а не pod.
allowPrivilegeEscalation: true # Необходим, чтобы бинарник Istio CNI плагина мог настраивать iptables
allowPrivilegedContainer: true # Необходим для поднятия UDS лисенера (для логирования работы Istio CNI плагина) и чтобы install-cni смог скопировать файлы Istio CNI на node

Выдать его можно следующей командой:

Шаблон

oc project <имя_проекта_cni>
oc adm policy add-scc-to-user istio-cni system:serviceaccount:<имя_проекта_cni>:istio-cni

Пример

oc project istio-cni
oc adm policy add-scc-to-user istio-cni system:serviceaccount:istio-cni:istio-cni

Настройка сетевых правил маршрутизации pod#

Использование Istio CNI Plugin#

В OpenShift используется CNI Plugin Multus. Это стоит учесть при использовании Istio CNI Plugin. Как настроить CNI для работы с Multus описано в одноименном разделе настоящего документа.

Использование istio-init#

Так как в OpenShift используется механизм SecurityContextConstrains, ограничивающий SecurityContext pods Istio SE, а istio-init контейнер требует для своей работы права, необходимые для настройки, то необходимо выделить дополнительные права в проекты Istio.

Обеспечение доступа между kubeapi-server и POLM#

В OpenShift по умолчанию используются политики, ограничивающие доступ между проектами напрямую. Поэтому при установке Istio необходимо получить подтверждение от сопровождения инфраструктуры, что между kubeapi-server и POLM нет ограничений на сетевой доступ. Убрать такие ограничение в рамках одного кластера можно с помощью конфигурации NetworkPolicies.

Пример:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-default
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: default
  policyTypes:
    - Ingress

Обновление#

Обновление проводится администраторами кластеров. Для обновления версии в проекте требуется выполнить действия из пункта «Установка компонента Управление политиками» через пользовательский интерфейс или «Установка компонента Управление политиками» через консоль. При установке обновления происходит полное затирание установленных ранее компонент. Дополнительно предварительно удалять POLM нет необходимости.

В случае, если обновление происходит с версии 3.6 на версию 3.7, то необходимо выполнить следующие действия:

1. Обновите Istio Operator путем установки helm charts.

2. Обновите Istio CNI Plugin (нюансы см. ниже в текущем разделе).

3. Обновите CP Istio.

4. Проверьте работоспособность pods.

SVPX и IGEG версии 1.12 должны быть обратно совместимы с POLM 1.17.

Особенности обновление CNI: Так как у DaemonSet отсутствует livenessProbe, то при обновлении оператором возникают ошибки. Поэтому необходимо сначала удалить Istio CNI Plugin.

Если установка была произведена с помощью Istio Operator, то в ресурсе IstioOperator, с помощью которого была установлена контрольная панель, необходимо обновить значение image в следующих секциях:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
spec:
  values:
    global:
      ...
      proxy:
        image: <ссылка_на_образ_istio-proxy>
      proxy_init:
        image: <ссылка_на_образ_istio-proxy>
    pilot:
      image: <ссылка_на_образ_istiod>
  ...

или

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
spec:
  ...
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>

Если же установка была произведена с помощью helm, то необходимо обновить значение image в values.yaml:

global:
  ...
  proxy:
    image: <ссылка_на_образ_istio-proxy>
  proxy_init:
    image: <ссылка_на_образ_istio-proxy>
pilot:
  image: <ссылка_на_образ_istiod>

или

global:
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>

Если же используется Istio CNI Plugin, то его образ также необходимо обновить аналогично предыдущим шагам. В случае, если использовался Istio Operator:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
spec:
  ...
  profile: empty
  values:
    cni:
      image: <ссылка_на_образ_Istio_CNI_Plugin>

или

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  ...
spec:
  ...
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>

В случае, если установка Istio CNI Plugin производилась через helm:

cni:
  image: <ссылка_на_образ_Istio_CNI_Plugin>

или

global:
  hub: <ссылка_хранилище_с_артефактами_Istio>
  tag: <docker_тэг_артефактов>

Приведенные сценарии соответствуют стратегии обновления компонента POLM в среде контейнеризации Rolling.

Удаление#

Удаление Istio#

Чтобы удалить Istio, достаточно удалить соответствующий ресурс IstioOperator, с помощью которого была развернута та или иная версия control-plane.

Важно, что перед удалением не должно быть ни одного поднятого приложения, запущенного с sidecar istio-proxy, в том числе и ingress и egress gateway, иначе оператор будет бесконечно пытаться удалить ресурс.

Удаление оператора#

В случае установки Istio Operator с помощью istioctl для удаления необходимо выполнить следующую команду:

istioctl operator remove -n <проект_istio-operator>

В случае установки Istio Operator с помощью helm для удаления необходимо выполнить команду аналогичную команде установки:

helm uninstall <имя_шаблона> --namespace <проект_istio-operator>

Проверка работоспособности#

Проверка работоспособности Istio Operator#

При установке оператора через istioctl в результате работы будет написан статус успешности установки.

Пример успешной установки:

Для проверки работоспособности можно также проверить статус pod Istio Operator и его логи. Подробнее в пункте «Чек-лист валидации установки» настоящего документа.

Пример проверки статуса pod через консоль:

Пример проверки логов pod через консоль:

Если процесс установки завис и/или долгое время не выводятся успешные результаты установки, то необходимо зайти в проект Istio Operator и проверить наличие ошибок в Events и/или логах pod Istio Operator. Подробнее в пунктах «Часто встречающиеся проблемы и пути их устранения» и «Чек-лист валидации установки» настоящего документа.

Проверка работоспособности istiod (Управление политиками)

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

1. Зайдите в проект контрольной панели.

2. В меню выберите пункт Workload/Pods.

3. На странице найдите нужный pod.

4. Перейдите по ссылке в этот pod.

5. Перейдите на вкладку ≡ (Logs). В консоли не должно быть ошибок.

Также можно сделать это через консоль:

1. Проверьте статусы pods:

    kubectl --kubeconfig=<путь_к_файлу_kubeconfig> get pods -n <проект_контрольной_панели>
   

Пример:

2. Проверьте лог pods на наличие ошибок:

    kubectl --kubeconfig=<путь_к_файлу_kubeconfig> logs <имя_pod> -n <проект_контрольной_панели>
   

Пример:

Чек-лист проверки работоспособности интеграций#

Проверка интеграции с компонентом IGEG

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

1. Зайдите в проект, в котором установлен IGEG.

2. В меню выберите пункт Workload/Pods.

3. На странице найдите нужный pod.

4. Перейдите по ссылке в этот pod.

5. Перейдите на вкладку ≡ (Logs). В консоли не должно быть ошибок, также должна быть запись вида Envoy proxy is ready.

Также можно сделать это через консоль:

1. Проверьте статусы pods:

   kubectl --kubeconfig=<путь_к_файлу_kubeconfig> get pods -n <проект_в_котором_установлен_IGEG>

2. Проверьте лог pods на наличие ошибок:

   kubectl --kubeconfig=<путь_к_файлу_kubeconfig> logs <имя_pod> -n <проект_в_котором_установлен_IGEG>

Проверка интеграции с компонентом SVPX

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

1. Зайдите в проект, в котором установлен SVPX.

2. В меню выберите пункт Workload/Pods.

3. На странице найдите нужный pod.

4. Перейдите по ссылке в этот pod.

5. Перейдите на вкладку ≡ (Logs). В консоли не должно быть ошибок, также должна быть запись вида Envoy proxy is ready.

Также можно сделать это через консоль:

1. Проверьте статусы pods:

   kubectl --kubeconfig=<путь_к_файлу_kubeconfig> get pods -n <проект_в_котором_установлен_SVPX>

2. Проверьте логи pods на наличие ошибок:

   kubectl --kubeconfig=<путь_к_файлу_kubeconfig> logs <имя_pod> -n <проект_в_котором_установлен_SVPX>

Откат#

Откат компонента на одну из предыдущих версий (не позднее 3 по счету от текущей) происходит с помощью развертывания компонент из дистрибутива предыдущей версии, они затирают текущую инсталляцию.

Действия аналогичны описанным в подразделе «Установка», но в данном случае требуется дистрибутив предыдущей версии.

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

Чек-лист валидации установки#