Продолжение истории с Cilium в GKE

Какое-то время назад я писал про отваливающиеся пробы у подов в GKE кластере после установки Cilium. Тогда пришлось сделать шаг назад и удалить Cilium из кластера чтобы не блокировать команды разработки.

Отладку продолжил в изолированном кластере и в итоге получилось решить изначальную проблему с отваливающимися пробами. Около двух недель как Cilium снова управляет сетью в GKE, но периодически приходится решать мелкие проблемы.

Из свежего - несколько часов разбирался почему некоторые поды определённых демонсетов становятся "not ready" спустя несколько часов после создания. Интриги добавляло что это происходило ночью и один из них смог сам починиться и продолжить работу. Эта проблема отличалась от той, с которой я разбирался в отдельном кластере, т.к. там поды не проходили проверки сразу после создания. В итоге причина снова была в Cilium.

В процессе отладки пришёл к нескольким умозаключениям:

1. Похоже что разработчики рассчитывают что ставить Cilium будут через утилиту cilium. Это удобно для интерактивной установки, но плохо подходит для инфраструктуры как код.
2. Параметры для Helm пришлось доставать из исходников утилиты cilium параллельно листая issues на Github. Quickstart для GKE не содержит ничего полезного а вся магия происходит в утилите Cilium которая настраивает параметры чарта. Для AKS и EKS документация заметно лучше.
3. Нужно настраивать под селектор в cilium оператора чтобы он перезапускал какие-либо unmanaged поды кроме kube-dns (cilium #39844).

Большая часть проблем вытекает из невозможности создать GKE кластер без каких-либо CNI плагинов (во всяком случае я пока не нашёл способа это сделать). В итоге часть подов у которых настроен "агрессивный" tolerations запускаются раньше чем Cilium закончит настройку ноды (нода становится Ready из-за родного GKE CNI) и они становятся unmanaged с точки зрения Cilium. Такие поды могут работать до тех пор пока Cilium не назначит такой же IP другому поду.

Конфигурация Helm чарта Cilium для совместимости с Istio Ambient для GKE выглядит примерно так:

gke:
  # gke.enabled=true will enable more options under the hood (see https://docs.cilium.io/en/stable/network/concepts/routing/#id8)
  # - ipam: kubernetes
  # - routing-mode: native
  # - enable-endpoint-routes: true
  enabled: true
  disableDefaultSnat: true

# See https://docs.cilium.io/en/stable/installation/k8s-install-helm/
nodeinit:
  enabled: true
  reconfigureKubelet: true
  removeCbrBridge: true

ipam:
  mode: kubernetes

ipv4NativeRoutingCIDR: "10.17.0.0/16"

socketLB:
  hostNamespaceOnly: true # https://docs.cilium.io/en/latest/network/servicemesh/istio/#cilium-configuration

cni:
  binPath: /home/kubernetes/bin # https://github.com/cilium/cilium/issues/35336
  exclusive: false # https://docs.cilium.io/en/latest/network/servicemesh/istio/#cilium-configuration

agentNotReadyTaintKey: "startup-taint.cluster-autoscaler.kubernetes.io/cilium-not-ready"

operator:
  replicas: 1
  # TODO: Newer versions support operator.unmanagedPodWatcher.selector
  extraArgs:
    - --pod-restart-selector=

Перезапуск unmanaged подов Cilium оператором можно поискать в логах по фразе "Restarting unmanaged pod". Там нашлись не только знакомые поды с "агрессивным" tolerations, но и поды обычных деплойментов у которых tolerations вовсе не задан. Следовательно есть ещё какая-то причина почему они становятся unmanaged, но пока на неё никто не пожаловался.