Агент узла Istio CNI используется для настройки перенаправления трафика для подов в mesh. Он запускается как DaemonSet на каждом узле с повышенными правами. Агент узла Istio CNI может использоваться в двух режимах плоскости данных Istio.
Для режима sidecar плоскости данных агент узла Istio CNI является необязательным. Он устраняет необходимость запуска привилегированных init контейнеров в каждом поде mesh, заменяя эту модель одним привилегированным подом агента узла на каждом узле Kubernetes.
Агент узла Istio CNI обязателен в режиме ambient плоскости данных.
Этот документ сосредоточен на использовании агента узла Istio CNI как опциональной части режима sidecar плоскости данных.
Если вы создаёте сервисный mesh в кластере OpenShift, Istio CNI включён по умолчанию, поэтому вам не нужно выполнять шаги из этого документа.
NET_ADMIN
и NET_RAW
в бизнес-нагрузках)KIND
)Сначала установите сервисный mesh как обычно. После установки временно не добавляйте сервисы (то есть не внедряйте Sidecar). Затем выполните следующие шаги для установки и настройки Istio CNI.
В большинстве сред базовый кластер Istio с включённым компонентом istioCni можно установить с помощью следующих команд:
kube-system
.При использовании OpenShift или Multus CNI:
false
.multus
.info
)/opt/cni/bin
)/etc/cni/net.d
)/var/run/netns
, в minikube/docker/других может быть /var/run/docker/netns
)true
) или как отдельные файлы в каталоге конфигурации (значение false
).default
и multus
. (По умолчанию: default
)Убедитесь, что все поды агента узла CNI находятся в состоянии Running перед переходом к следующему шагу.
По умолчанию Istio использует webhook для внедрения контейнера istio-init
для прозрачного перехвата трафика.
Чтобы использовать Istio CNI вместо контейнера istio-init
, необходимо изменить ресурс ServiceMesh следующим образом:
istio-init
. (По умолчанию: false
)multus
, если используется Multus CNI. (По умолчанию: default
)После установки и настройки используйте обычный процесс внедрения сервиса без дополнительных изменений.
После установки и правильной настройки компонента Istio CNI в подах произойдут следующие изменения:
istio-init
больше не будет присутствовать (прозрачный перехват трафика будет осуществляться агентом узла Istio CNI).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
.
true
)true
)false
)cni.istio.io/uninitialized=true
. Пользователю необходимо вручную решить проблему. (По умолчанию: false
)Приоритет конфигурации: repairPods
> deletePods
> labelPods
. Таким образом, будет использовано первое поле со значением true
с более высоким приоритетом.
Например, чтобы активировать deletePods
, недостаточно установить true
для deletePods
, необходимо также установить false
для repairPods
.