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

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

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

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

Случайным образом отваливаются пробы в 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 в 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 релиза.

Что нужно помнить про Cloud IAM и Kubernetes RBAC в GKE

Чтобы разграничить права пользователей по namespace нужно использовать Kubernetes RBAC, т.к. Cloud IAM не позволяет гранулярно задать привилегии внутри namespace. Сделал простую роль для namespace (Role/RoleBinding) и кластерную роль для просмотра namespace, storageclass и прочих ресурсов, которые не имееют привязки к namespace.

процессе отладки возникла проблема что пользователь, который должен видеть список namespace и оперировать ресурсами в пространстве имён "abc-dev", смог создать ресурс в пространстве имён "xyz-dev". Если проверять через kubectl auth can-i create secret --as user@example.com --namespace xyz-dev то возвращает false, но при этом ресурс создаётся.

GCloud prompt

Много работаю с GCP и зачастую приходится иметь дело с несколькими проектами одновременно и переключаться между ними в течении дня. Случаются досадные ситуации когда команда была выполнена не в том проекте или не в том GKE кластере. Последнее особенно коварно, т.к. в корпоративной среде обычно один и тот же пользователь имеет доступ в разные кластера в разных проектах и переключение профиля gcloud не влияет на kubectl.

Первые впечатления от Backup for GKE

В рамках ликбеза потрогал немного Backup for GKE чтобы понять чем он отличается от привычного Velero. На данный момент времени он в preview и часть выводов может стать неактуальными в будущем.

Первое что бросается в глаза это его ценообразование - оно зависит не только от объема данных, которые попадают в бэкап, но и от количества подов, которые бэкапятся. Т.е. если у вас условно в среднем 30 подов в месяц, то вам нужно заплатить около 30$ за backup management, плюс стоимость хранения данных. В этом плане Velero выигрывает, т.к. там в основном стоимость только за хранение данных.

Далее его региональная доступность - сейчас он поддерживается только в некоторых регионах, но при этом создать бэкапить дает кластера и в неподдерживаемых регионах. Но вот восстановить бэкап в тот же кластер уже не получится - обязательно проверяйте список поддерживаемых регионов через gcloud beta container backup-restore locations list.

Задержка ответа DNS до 5 секунд или более в GKE

Изначально эта проблема попала ко мне с описанием "Нестабильная работа Solr на всех окружениях". В админке Drupal сайта тестирование настроек Solr в большинстве случаев завершалось с ошибкой, но сам поиск хоть и очень медленно, но работал.

Сперва выполнил пробный запрос к Solr из одного из контейнеров чтобы подтвердить наличие проблемы - с приличной задержкой, но запрос выполнился. Повторил запрос в цикле и получилось что время выполнения запроса "скачет" от 100 миллисекунд до 12 секунд. Чтобы исключить проблемы с DNS попробовал подключиться к Solr по IP, а не по FQDN - запрос выполняется быстро. Повторяю тест используя IP вместо FQDN в цикле и результат находится в пределах 100 - 150 миллисекунд. Выходит что проблема в DNS, но пока не ясно виноват kube-dns или вышестоящий DNS сервер к которому обращается kube-dns. Попробовал обращаться к другим доменам, например www.google.com - поведение аналогичное. Описание проблемы меняется с "Нестабильная работа Solr на всех окружениях" на "Нестабильная работа DNS в GKE на всех окружениях".