Возился с переносом наработок по 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 и стало ясно чего не хватает.
Для решения проблемы достаточно разрешить входящие соединения с диапазона 169.254.7.127/32
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-kubelet-healthprobes spec: podSelector: {} policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 169.254.7.127/32
В GKE та же network policy не вызвала проблемы. Посмотрим что будет при миграции в AKS (Azure Kubernetes Service).
Комментариев нет:
Отправить комментарий