Развертывание Ключ-АСТРОМ вместе с Istio

В этом руководстве объясняется, как развернуть компоненты Ключ-АСТРОМ вместе с Istio. Развёртывание Ключ-АСТРОМ в Kubernetes содержит несколько компонентов, которым необходимо взаимодействовать друг с другом, с кластером Ключ-АСТРОМ и другими внешними ресурсами.

Дополнительную информацию о взаимодействии Ключ-АСТРОМ Operator и его управляемых компонентах см. на странице справки по сетевому трафику.

Ограничения

• Внедрение Istio в пространство имен Ключ-АСТРОМ Operator не поддерживается.
• В настоящее время не поддерживаются ответвления Istio (например, Maistra или OpenShift Service Mesh).
• Режим Istio Ambient Mode в этом руководстве не рассматривается, поскольку он все еще находится в стадии бета-тестирования.

Вопросы настройки

В этом руководстве рассматриваются две предустановленные конфигурации Istio, выбранные за их простоту и распространённость. Хотя Istio предлагает широкие возможности настройки, эти конфигурации служат лишь отправной точкой. В этом разделе объясняются сценарии настройки и даются рекомендации по выбору конфигурации Ключ-АСТРОМ, наилучшим образом соответствующей вашим потребностям. Обратите внимание, что Ключ-АСТРОМ не накладывает никаких ограничений на настройку Istio.

• Конфигурация Istio по умолчанию рекомендуется
  Это стандартное развёртывание Istio, то есть без специальной конфигурации сети. По сути, это результат следования официальному руководству по установке Istio. Это означает, что Istio устанавливается либо через Helm, либо istioctl в режиме sidecar с агентом узла CNI.
  Следуйте руководству по настройке конфигурации Istio по умолчанию (ниже), если Istio развернут соответствующим образом.
• Безопасная конфигурация Istio.
  Это представляет собой «безопасную» конфигурацию Istio. Однако это не означает, что мы считаем её наилучшим вариантом настройки безопасности в Istio или что её следует рассматривать, как руководство по обеспечению безопасности Istio. Эта настройка основана на параметрах, которые с наибольшей вероятностью повлияют на развёрнутые компоненты Ключ-АСТРОМ и их соединения. В этом сценарии предполагается, что Istio развёрнут со строгим mTLS и outboundTrafficPolicy настроен на REGISTRY_ONLY. Эти параметры существенно ограничивают входящие и исходящие соединения для рабочих нагрузок в сети.
  Выберите эту конфигурацию, если применимо хотя бы одно из нижеперечисленных положений:
  • Если вы включили mTLS в строгом режиме.
  • Если у вас есть набор outboundTrafficPolicy для REGISTRY_ONLY. Если ни один из вышеперечисленных пунктов не подходит, выберите конфигурацию Istio по умолчанию.
    Следуйте руководству по настройке безопасной конфигурации Istio (ниже), если Istio развернут соответствующим образом.

Отключение внедрения CNI Pods

Это актуально для вас, если к вашему развертыванию применимо все нижеперечисленное:

• Не поддерживается Ключ-АСТРОМ Operator развертывается внутри сети.
• Istio настроен на использование компонента CNI.
• Вы не настроили ни одного селектора пространства имен в DynaKube, который бы исключал пространство имен istio-system.

Во всех сценариях следует исключить модули Istio CNI из процесса внедрения Ключ-АСТРОМ Operator. В противном случае при добавлении нового узла в кластер может возникнуть взаимоблокировка.

И драйвер CSI, и агент CNI Istio являются DeamonSets и поэтому могут быть развернуты на любом (новом) узле в кластере.

• Модуль драйвера CSI будет внедрен Istio с помощью init-контейнера, который ожидает правильной настройки правил перенаправления, необходимых для работы прокси-сайдкара.
• Модуль CNI будет внедрен Ключ-АСТРОМ для включения требуемых двоичных файлов ЕдиногоАгента для инструментирования, которые предоставляются через том, предоставленный драйвером CSI на этом узле.

Это приводит к ситуации, когда оба модуля не могут запуститься:

• Модуль CNI ожидает, когда драйвер CSI будет готов предоставить данные.
• Модуль CSI ожидает, пока агент CNI предоставит перенаправления для прокси-сервера.

Кроме того, все остальные рабочие нагрузки, являющиеся целью внедрения Istio или Ключ-АСТРОМ и запланированные на этом узле, будут затронуты и не смогут запуститься.

Самый простой способ исключить модули CNI из внедрения Ключ-АСТРОМ Operator — добавить аннотацию oneagent.astromkey.com/inject: "false". Например, для развёртывания Istio в Helm добавьте к значениям диаграммы cni следующее:

cni:   podAnnotations:     oneagent.astromkey.com/inject: "false"

Руководство по настройке конфигурации Istio по умолчанию

Поскольку Ключ-АСТРОМ поддерживает Istio в конфигурации по умолчанию, вам достаточно включить параметр enableIstio только в DynaKube. Однако вам не нужно устанавливать этот параметр, если вы не планируете использовать ограничение outboundTrafficPolicy.

Если этот параметр включен, Ключ-АСТРОМ Operator развернёт ServiceEntries и VirtualServices и обеспечит взаимодействие внутри сети со всеми соответствующими компонентами Ключ-АСТРОМ и самой средой Ключ-АСТРОМ. ServiceEntries и VirtualServices работают независимо от того, является ли само пространство имён Ключ-АСТРОМ Operator частью сети (если discoveryfilter в Istio не задано значение no).

Это позволяет всем рабочим нагрузкам и ЕдинымАгентам подключаться к экземпляру АктивногоШлюза, а также всем необходимым соединениям — к среде Ключ-АСТРОМ. Следовательно, ожидается, что все функции Ключ-АСТРОМ будут работать.

ServiceEntries приводит к выполнению дополнительных DNS-запросов каждым прокси-сервером sidecar. Это может привести к дополнительной нагрузке на ваш DNS-сервер. Чтобы минимизировать количество URL-адресов и, следовательно, DNS-запросов, убедитесь, что сетевые зоны в вашей среде Ключ-АСТРОМ настроены правильно. Подробное описание настройки см. в документации по сетевым зонам Kubernetes. Если в вашей среде это невозможно или недостаточно, ознакомьтесь с разделом Istio DNS proxying для другого возможного способа решения проблемы.

Как работает enableIstio

Атрибут enableIstio— это удобная функция, которая автоматически создает ServiceEntries и VirtualServices используя конечные точки подключения, требуемые:

• Ключ-АСТРОМ Operator: использует apiUrl jпределения DynaKube.
• АктивныйШлюз: использует конечную точку /v1/deployment/installer/gateway/connectioninfo.
• ЕдиныйАгент, внедренный в пользовательские контейнеры: использует /v1/deployment/installer/agent/connectioninfo, который учитывает атрибут networkZone для маршрутизации.

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

Чтобы изменения атрибута enableIstio вступили в силу, необходимо удалить и повторно применить DynaKube.

Ручная настройка

Ручная настройка ServiceEntries может потребоваться VirtualServices в следующих случаях:

АктивныйШлюз

• Требование: необходимо, если модуль АктивногоШлюза является частью сети.
• Конфигурация: настраивается вручную ServiceEntries и VirtualServices на основе выходных данных конечной точки /v1/deployment/installer/gateway/connectioninfo.

cloudNativeFullstack и applicationMonitoring

• Требование: необходимо, если внедренные пользовательские приложения являются частью сети.
• Конфигурация: настраивается вручную ServiceEntries и VirtualServices на основе выходных данных конечной точки /v1/deployment/installer/agent/connectioninfo.

Руководство по настройке безопасной конфигурации Istio

В такой ограниченной среде, в зависимости от требуемых функций Ключ-АСТРОМ и других факторов, может потребоваться создать несколько дополнительных правил конфигурации для Istio. При выборе способа развертывания Ключ-АСТРОМ Operator следует учитывать несколько моментов, касающихся компонентов Ключ-АСТРОМ.

• Даже если на АктивномШлюзе включена маршрутизация, ЕдиныеАгенты будут переключаться на прямое подключение к среде Ключ-АСТРОМ, если АктивныйШлюз недоступен (например, если он находится внутри сети). Это означает, что данные мониторинга не будут потеряны, если некоторые ЕдиныеАгенты не смогут подключиться к АктивномуШлюзу из-за выбранной стратегии развертывания.
• Режимы мониторинга classicFullStack или cloudNativeFullStack создают модули с включённым сетевым подключением к хосту. Это означает, что эти модули никогда не смогут стать частью сети, поскольку Istio не поддерживает модули с сетевым подключением к хосту. Для classicFullStack эти модули обрабатывают все метрики приложения, тогда как для cloudNativeFullStack влияет только на мониторинг хоста.
• Некоторые функции АктивногоШлюза могут требовать прямого подключения к модулям (например, сбор метрик). При включении mTLS в Istio прямые подключения к IP-адресам модулей невозможны. Обходной путь для сбора метрик см. в разделе Слияние метрик в Istio (ниже).

Развертывание вне сети

В этом сценарии наименее сложное развёртывание происходит вне сети. Вам всё равно придётся включить параметр enableIstio в DynaKube. Возможные недостатки такого развёртывания:

• Обмен данными внутри сети с АктивнымШлюзом не будет защищён mTLS. Однако обмен данными по-прежнему шифруется по протоколу HTTPS.
• АктивныйШлюз не может подключиться ни к одному модулю или сервису внутри сети. Если вас интересует только сбор метрик, ознакомьтесь с решением Сбор метрик с помощью слияния метрик Istio (ниже).

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

Развертывание АктивногоШлюза внутри сети

Наиболее совместимый вариант развёртывания — развёртывание только АктивногоШлюза внутри сети. Этот вариант развёртывания наиболее целесообразен, если большая часть отслеживаемых рабочих нагрузок также входит в сеть или если вам требуется, чтобы АктивныйШлюз напрямую подключался к подам внутри сети (например, для сбора данных Prometheus).

1. Убедитесь, что пространство имен Ключ-АСТРОМ Operator не помечено для внедрения Istio (istio-injection метка не установлена).

2. Пометьте модули АктивногоШлюза для внедрения Istio, добавив в DynaKube следующее:

apiVersion: astromkey.com/v1beta5 kind: DynaKube metadata:   name: your-dynakube-name spec:   enableIstio: true   activeGate:     labels:       sidecar.istio.io/inject: "true"

3. Перезапустите модули АктивногоШлюза, чтобы запустить внедрение.

4. необязательно Вы можете включить связь ЕдиныхАгентов за пределами сети с АктивнымШлюзом, развернув следующий ресурс PeerAuthentication:

apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:   name: ag-no-mtls # <yourname>   namespace: astromkey-operator # <operator namespace> spec:   mtls:     mode: PERMISSIVE   selector:     matchLabels:       app.kubernetes.io/managed-by: astromkey-operator       app.kubernetes.io/name: activegate

Все коммуникации с АктивнымШлюзом по-прежнему будут зашифрованы с использованием HTTPS.

Настройте драйвер Ключ-АСТРОМ Operator CSI с Istio в режиме REGISTRY_ONLY

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

Предпосылки

• Istio установлен и настроен в режиме REGISTRY_ONLY.
• Не поддерживается Драйвер Ключ-АСТРОМ Operator CSI внедряется с помощью Istio.
• codeModulesImage поле указывается в конфигурации драйвера CSI.

Настроить ServiceEntry для драйвера CSI

1. Создайте ServiceEntry.

Эта конфигурация ServiceEntry позволяет драйверу Ключ-АСТРОМ Operator CSI взаимодействовать с указанным реестром образов. Без этой конфигурации процесс извлечения образа завершится ошибкой. См. пример ServiceEntry ниже docker.io.

apiVersion: networking.istio.io/v1 kind: ServiceEntry metadata:   name: codemodules-docker-io   namespace: astromkey spec:   hosts:   - index.docker.io   - auth.docker.io   - production.cloudflare.docker.com   location: MESH_EXTERNAL   ports:   - name: https-443     number: 443     protocol: HTTPS   resolution: DNS

2. Примените ServiceEntry.

Сохраните и примените указанную выше конфигурацию к файлу.

kubectl apply -f serviceentry.yaml

Сбор метрических данных с использованием слияния метрик Istio

Сбор метрик Ключ-АСТРОМ осуществляется через АктивныйШлюз и настраивается с помощью аннотаций. В результате АктивныйШлюз подключается напрямую к модулям Pod на настроенной конечной точке для сбора метрик. Как уже упоминалось, это прямое подключение не работает со строгим mTLS.

Istio предоставляет функцию, называемую слиянием метрик, которая использует (широко распространённые) аннотации prometheus.io/... для настройки дополнительной конечной точки в прокси-сервере sidecar, обслуживающем метрики Istio и Envoy, а также метрики приложения, определяемые аннотациями. Эта вновь созданная конечная точка исключена из mTLS и, следовательно, доступна извне сети, несмотря на то, что mTLS находится в строгом режиме.

Теперь вы можете указать аннотации Ключ-АСТРОМ на эту конечную точку для сбора метрик Istio и приложения. Если вы не хотите собирать дополнительные метрики Istio и Envoy, вы можете исключить их, используя аннотацию metrics.astromkey.com/filter и исключив метрики istio_* и envoy_*.

Таким образом, АктивныйШлюз вне (или внутри) сети может собирать метрики из модулей внутри сети.

Пример всех необходимых аннотаций:

apiVersion: v1 kind: Pod metadata:   annotations:     ...     metrics.astromkey.com/path: /stats/prometheus # Endpoint created by Istio     metrics.astromkey.com/port: "15020" # Port of the Envoy sidecar     metrics.astromkey.com/scrape: "true"     prometheus.io/path: /metrics # Metric endpoint of the application     prometheus.io/port: "8080" # Metric port of the application     prometheus.io/scrape: "true"     ...

Имейте в виду, что Istio перезапишет аннотации prometheus.io/... к сгенерированной конечной точке и порту при применении указанного выше модуля. Это означает, что полученный модуль в кластере не будет соответствовать применённому YAML-файлу.