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

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

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

Агент узла Istio CNI требуется в режиме ambient плоскости данных.

Этот документ сосредоточен на использовании агента узла Istio CNI как опциональной части режима sidecar плоскости данных.

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

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

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

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

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

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

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

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

Сначала установите сервисный 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
        # Расширенная конфигурация
        values:
          logLevel: info
          cniBinDir: ""
          cniConfDir: /etc/cni/net.d
          cniConfFileName: ""
          cniNetnsDir:
          excludeNamespaces:
            - istio-system
            - kube-system
          chained: true
          provider: default

#Проверка

# При необходимости измените часть -nkube-system, если агент Istio CNI установлен в другом namespace:
kubectl -nkube-system get po -lk8s-app=istio-cni-node

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

По умолчанию 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 в подах произойдут следующие изменения:

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

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

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

Чтобы смягчить состояние гонки между подом приложения и DaemonSet Istio CNI, в рамках внедрения sidecar добавляется init контейнер istio-validation, который проверяет, правильно ли настроено перенаправление трафика, и блокирует запуск пода, если это не так. DaemonSet CNI обнаружит и обработает любой под, застрявший в таком состоянии; способ обработки пода зависит от конфигурации, описанной ниже. Эта мера включена по умолчанию и может быть отключена установкой 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

#См. также

Troubleshooting the Istio CNI plugin