Не проходят пробы после включения 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 и стало ясно чего не хватает.

Wildcard SSL сертификат

Понадобилось сгенерировать wildcard SSL сертификат и раскладывать его по пространствам имён в Kubernetes кластере. Этот сертификат будет использоваться в тестах которые выполняются для набора приложений на каждый запрос на слияние.

В cert-manager настроен ClusterIssuer LE с валидацией через DNS01. Выпуск wildcard сертификата у Let's Encrypt поддерживается только через DNS валидацию и протокол ACMEv2. В примере использован сервис Cloud DNS от Google Cloud Platform.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    email: certificates@example.com
    privateKeySecretRef:
      name: letsencrypt-production
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        cloudDNS:
          project: GCP_PROJECT_ID

Манифест для wildcard сертификата (сам сертификат и ключ будут созданы в пространстве имён cert-manager)

Ограничение доступа в контроллере ingress-nginx

Нередко возникает задача разрешить доступ к какому-либо приложению в Kubernetes кластере только для определённых подсетей. В случае с ingress-nginx (не путаем ingress-nginx и nginx-ingress) классический подход это использование аннотации nginx.ingress.kubernetes.io/whitelist-source-range

Например так

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: restricted-app
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8
spec:
  ingressClassName: nginx
  rules:
  - host: restricted-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 3000

У этого подхода есть несколько недостатков:

• аннотации нужно обновить в каждом приложении когда изменится список разрешённых подсетей
• в ingress-nginx контроллере могут найти уязвимость которая позволит обойти ограничение доступа

Грабли при обновлении ingress-nginx до 1.12.1

Вчера срочно обновлял ingress-nginx до 1.12.1 (версия чарта 4.12.1) после новости о критической уязвимости CVE-2025-1974 и наступил на грабли - релиз обновился, но все существующие ingress'ы потеряли привязку к IP адресу балансировщика.

Полез смотреть events в кластере, но там ничего криминального не нашлось. В логах ingress-nginx контроллера присутствовали ошибки вида

E0325 12:26:36.275715       7 store.go:938] annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

но сходу у меня не сложилась связь этих ошибок с отсутствием привязки к IP адресу. А вот когда попробовал пересоздать один из ingress'ов всё стало на свои места

Error: INSTALLATION FAILED: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

Во всех ингресах присутствовала аннотация nginx.ingress.kubernetes.io/configuration-snippet через которую делается тонкий тюнинг приложений и нет простого способа отказаться от использования этой опции.

Подключение к kubernetes кластерам в разных облаках

 Набросал себе инструкции для подключения к различным Kubernetes кластерам в GCP, AWS и Azure с установкой утилит для Debian 12.

GCP

Документация от GCP по установке google cloud sdk.

$ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
$ cat <<_EOF_ | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main
_EOF_
$ sudo apt-get update
$ sudo apt-get install google-cloud-sdk google-cloud-sdk-gke-gcloud-auth-plugin
$ gcloud auth login
$ gcloud container clusters get-credentials <cluster> --region <region> --project <project>

Чтобы не путаться в сортах Nginx ingress

Нужно помнить что в мире Kubernetes есть два варианта nginx ingress, которые можно спутать:

• ingress-nginx (аннотации)
  
• nginx-ingress (аннотации)

В самом кластере их можно опознать по контроллеру в ingressclass:

• k8s.io/ingress-nginx - это ingress-nginx
• nginx.org/ingress-controller - это nginx-ingress
  

Что нужно помнить про 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, но при этом ресурс создаётся.

Bitnami Sealed Secrets

Чтобы управлять Kubernetes секретами в духе GitOps нужно их шифровать перед фиксацией в Git и расшифровывать на стороне Kubernetes. Для CI я раньше использовал Mozilla SOPS, а для Kubernetes решил попробовать Bitnami Sealed Secrets.

В Sealed Secrets используется ассиметричная криптография и расшифровать секреты без доступа к приватному ключу не получится - можно коммитить даже в публичный репозитарий, хотя я бы не рекомендовал так делать.

Spinnaker - день второй

Второй день изучения Spinnaker (почитать про первый день можно тут). На сегодня в планах построить минимальную инфраструктуру вокруг Spinnaker и задеплоить приложение в отдельный GKE кластер.

Spinnaker у меня крутится в VirtualBox, поэтому нужно создать ключ для IAM сервис аккаунта, который будет использоваться для доступа в GCS, GCR и Pub/Sub. Для подключения к GKE я сгенерировал отдельный kubeconfig.

При составлении пайплайна для Spinnaker я пользовался репозитарием spinnaker-for-gcp. Сам туториал у меня не завелся из-за недоступности управления IAM в Cloud Playground.

Первые впечатления от 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 на всех окружениях".