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

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

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

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

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

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

#Окружения, в которых необходимо использовать 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