Установка узлового агента Istio CNI#

Узловой агент Istio CNI используется для настройки перенаправления трафика для podов в mesh. Он запускается как DaemonSet, на каждом узле, с повышенными привилегиями. Узловой агент Istio CNI можно использовать в двух режимах data plane Istio.

Для режима sidecar data plane узловой агент Istio CNI является необязательным. Он устраняет необходимость запуска привилегированных init-контейнеров в каждом podе в mesh, заменяя эту модель одним привилегированным podом узлового агента на каждом узле Kubernetes.

Узловой агент Istio CNI обязателен в режиме ambient data plane.

В этом документе рассматривается использование узлового агента Istio CNI как необязательной части режима sidecar data plane.

#Предварительные требования

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

• Huawei Cloud CCE
• Среды с высокими требованиями к безопасности. (Например, среды, в которых запрещено использовать разрешения NET_ADMIN и NET_RAW в рабочих нагрузках)

#Среды, в которых можно использовать Istio CNI

• Любой кластер Kubernetes, в котором включена поддержка CNI

#Среды, в которых нельзя использовать Istio CNI

• Кластеры, в которых отключена поддержка Kubernetes CNI (только среды разработки, такие как KIND)

#Установка узлового агента Istio CNI

Сначала установите service mesh как обычно. После установки пока не добавляйте никаких сервисов (то есть не выполняйте внедрение Sidecar). Затем выполните следующие шаги для установки и настройки Istio CNI.

#Установка с компонентом ServiceMesh Istio CNI

В большинстве сред базовый кластер Istio с включенным компонентом istioCni можно установить с помощью следующих команд:

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        namespace: kube-system

#Дополнительная конфигурация

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        namespace: kube-system
        # Advanced configuration
        values:
          logLevel: info
          cniBinDir: ""
          cniConfDir: /etc/cni/net.d
          cniConfFileName: ""
          cniNetnsDir:
          excludeNamespaces:
            - istio-system
            - kube-system
          chained: true
          provider: default

#Проверка

# Adjust the -nkube-system part if the Istio CNI agent is installed in another namespace:
kubectl -nkube-system get po -lk8s-app=istio-cni-node

#Обработка внедрения init container

По умолчанию Istio использует webhook для внедрения контейнера istio-init для прозрачного перехвата трафика. Чтобы использовать Istio CNI вместо контейнера istio-init, необходимо настроить ресурс ServiceMesh следующим образом:

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  istioConfig:
    cni:
      enabled: true
      provider: default

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

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

После того как компонент Istio CNI установлен и правильно настроен, в podах будут выполнены следующие изменения:

• Контейнер istio-init больше не будет присутствовать (прозрачный перехват трафика будет выполняться узловым агентом Istio CNI).
• Вместо него Istio внедрит контейнер с именем istio-validation, который проверяет, успешно ли заданы правила iptables для прозрачного перехвата трафика.

#Состояние гонки и меры по его устранению

DaemonSet Istio CNI устанавливает сетевой плагин CNI на каждом узле. Однако существует временной разрыв между моментом, когда pod DaemonSet назначается на узел, и моментом, когда плагин CNI установлен и готов к использованию. Существует вероятность, что в течение этого временного промежутка запустится pod приложения, а kubelet не будет знать о плагине Istio CNI. В результате pod приложения поднимется без перенаправления трафика Istio и обойдет sidecar Istio.

Чтобы устранить гонку между podом приложения и DaemonSet Istio CNI, в рамках внедрения sidecar добавляется init container istio-validation, который определяет, правильно ли настроено перенаправление трафика, и блокирует запуск podа, если это не так. DaemonSet CNI обнаружит и обработает любой pod, застрявший в таком состоянии; способ обработки podа зависит от конфигурации, описанной ниже. Эта мера по устранению проблемы включена по умолчанию и может быть отключена путем установки cni.values.repair.enabled в false.

apiVersion: asm.alauda.io/v1alpha1
kind: ServiceMesh
spec:
  componentConfig:
    - name: istioCni
      group: istio
      cni:
        values:
          repair:
            enabled: true
            repairPods: true
            deletePods: false
            labelPods: false

#См. также

Устранение неполадок плагина Istio CNI