Случайным образом отваливаются пробы в GKE после установки Cilium и Istio Ambient

 Устанавливал в GKE (Google Kubernetes Engine) кластер Cilium с Istio в режиме ambient и столкнулся со случайными ошибками readiness/liveness проб. Версия GKE 1.34.3, Cilium 1.18.4 и Istio 1.26.3 - не самые свежайшие версии, но работают в других окружениях.

Факты таковы:

• из десятка подов которые разворачиваются в тестовом окружении один или несколько не проходит readiness/liveness пробу
• внутри пода и с соседнего пода можно запросить нужный URL который используют пробы
• если вручную удалить этот под, то он начинает работать нормально
• автоматический рестарт из-за liveness не исправляет ситуацию

Я уже сталкивался с "отвалившимися" пробами после включения Istio Ambient, но тогда пробы не работали в 100% случаев, а здесь это происходит случайным образом. Исправление удалением пода намекает на проблемы связанные с работой CNI.

Не проходят пробы после включения Istio Ambient

 Возился с переносом наработок по Istio Ambient из GKE (Google Kubernetes Engine) в EKS (Elastic Kubernetes Service) и столкнулся с "отваливающимися" проверками готовности подов в Knative сервисах после включения пространства имён в ambient mesh.

Новый под стартует, но через 30 секунд у него отваливается readiness check без каких либо сообщений в логе пода. Проверил логи ztunnel, но ничего интересного не увидел. Для верности почитал Platform-Specific Prerequisites для EKS но описанный там случай не подходил для моего кластера.

Попробовал искать в сообщениях об ошибках в Istio, но ничего подходящего не нашлось. Потом вспомнил про kubernetes network policy которая есть в этом неймспейсе и после её удаления проверки стали проходить нормально.

Стал искать целенаправленно и натнулся на раздел Ambient, health probes, and Kubernetes NetworkPolicy в документации Istio Ambient и стало ясно чего не хватает.

Ошибки при установке Istio в GKE

 Если вы ставите Istio в ambient режиме в GKE (Google Kubernetes Engine) кластер и не прочли Platform-Specific Prerequisites, то при установке CNI node agent вы столкнётесь с двумя ошибками.

Первая не даст установить Helm релиз (в событиях будет ошибка):

LAST SEEN   TYPE      REASON                    OBJECT                           MESSAGE
3s          Warning   FailedCreate              daemonset/istio-cni-node         Error creating: insufficient quota to match these scopes: [{PriorityClass In [system-node-critical system-cluster-critical]}]

Это связано с тем что по-умолчанию разрешает использовать priorityClassName: system-node-critical только в пространстве имён "kube-system". Чтобы разрешить использовать его в "istio-system" нужно создать ResourceQuota в соответствующем пространстве имён

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

Вторая проблема проявляется как постоянный перезапуск пода istio-cni и в логах будет подсказка как это чинить:

2025-08-15T14:03:48.272826Z     info    controllers     starting        controller=repair pods
2025-08-15T14:03:48.357825Z     info    cni-agent       initialization complete, watching node CNI dir
2025-08-15T14:03:48.358220Z     error   cni-agent       failed file copy of /opt/cni/bin/istio-cni to /host/opt/cni/bin: open /host/opt/cni/bin/istio-cni.tmp.2135482355: read-only file system
2025-08-15T14:03:48.358243Z     warn    hint: some Kubernetes environments require customization of the CNI directory. Ensure you properly set global.platform=<name> during installation
2025-08-15T14:03:48.358311Z     error   cni-agent       installer failed: copy binaries: open /host/opt/cni/bin/istio-cni.tmp.2135482355: read-only file system
2025-08-15T14:03:48.369141Z     info    cni-agent       terminating, but parent DS istio-cni-node is still present, this is an upgrade, leaving plugin in place
2025-08-15T14:03:48.369180Z     info    cni-agent       Ambient node agent shutting down - is upgrade shutdown? true

Для исправления достаточно задать --set global.platform=gke при установке Helm релиза.