Показаны сообщения с ярлыком kubernetes. Показать все сообщения
Показаны сообщения с ярлыком kubernetes. Показать все сообщения

20 мая 2026

Отладка HTTP заголовков

В рамках активности по замене bitnami чартов дошли руки обновить oauth2-proxy. В процессе столкнулся с тем что перестала работать авторизация в одном из приложений для которого был использован alpha config.

Чтобы проверить какие HTTP заголовки oauth2-proxy передаёт на бэкенд после прохождения авторизации можно запустить "echo" сервис, который будет отображать всю информацию о запросе который к нему поступил.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: echo
          image: docker.io/mendhak/http-https-echo:31
          ports:
            - containerPort: 8080
          env:
            - name: HTTP_PORT
              value: "8080"
---
apiVersion: v1
kind: Service
metadata:
  name: echo
spec:
  selector:
    app: echo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

После применения манифеста остаётся заменить бэкенд на http://echo и посмотреть какие заголовки были переданы со стороны oauth2-proxy.

26 марта 2026

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

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

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

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

16 марта 2026

Ошибка "metadata.resourceVersion: Invalid value: 0: must be specified for an update" в Terraform после редактирования ресурса

После редактирования ресурса knativeserving в Kubernetis кластере через kubectl edit Terraform не может применить к нему изменения через gavinbunney/kubectl провайдер:

│ Resource: "operator.knative.dev/v1beta1, Resource=knativeservings", GroupVersionKind: "operator.knative.dev/v1beta1, Kind=KnativeServing"
│ Name: "knative-serving", Namespace: "knative-serving"
│ for: "/tmp/1389615405kubectl_manifest.yaml": error when patching "/tmp/1389615405kubectl_manifest.yaml": knativeservings.operator.knative.dev "knative-serving" is invalid: metadata.resourceVersion: Invalid value: 0: must be specified for an update
│ 
│   with kubectl_manifest.knative_serving,
│   on knative.tf line 163, in resource "kubectl_manifest" "knative_serving":
│  163: resource "kubectl_manifest" "knative_serving" {

Я пробовал использовать параметр force_conflicts = true, но это не даёт эффекта.

Исправляется ошибка удалением аннотации kubectl.kubernetes.io/last-applied-configuration с нужного ресурса.

kubectl -n knative-serving annotate knativeserving knative-serving kubectl.kubernetes.io/last-applied-configuration-

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

13 января 2026

Сделать дамп кучи и потоков для Java приложения

Сделать дамп кучи и потоков для Java приложения в Kubernetes

$ JVM_PID=1
$ JVM_POD=some-pod

$ kubectl exec $JVM_POD -- /bin/sh -c "jmap -dump:live,format=b,file=/tmp/heap-dump.hprof $JVM_PID; gzip /tmp/heap-dump.hprof"

$ kubectl cp $JVM_POD:/tmp/heap-dump.hprof.gz $PWD/heap-dump.hprof.gz

$ gunzip $PWD/heap-dump.hprof.gz

$ kubectl exec $JVM_POD -- rm /tmp/heap-dump.hprof.gz

Посмотреть состояние можно через VisualVM.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

24 декабря 2025

Добавить метку времени к событиям в Kubernetes

 Если по какой-то причине нет доступа в панель мониторинга Kubernetes кластера, но нужно знать в какое время происходит определённое событие, то есть простой способ сделать это

$ kubectl -n default get events -w | ts
Dec 24 09:39:13 LAST SEEN   TYPE     REASON              OBJECT                        MESSAGE
Dec 24 09:39:13 15s         Normal   Scheduled           pod/debug-658b996798-52g2g    Successfully assigned default/debug-658b996798-52g2g to aks-workerf1f9-29801352-vmss000003
Dec 24 09:39:13 14s         Normal   Pulling             pod/debug-658b996798-52g2g    Pulling image "nicolaka/netshoot"
Dec 24 09:39:13 14s         Normal   Pulled              pod/debug-658b996798-52g2g    Successfully pulled image "nicolaka/netshoot" in 237ms (237ms including waiting). Image size: 207893848 bytes.
Dec 24 09:39:13 14s         Normal   Created             pod/debug-658b996798-52g2g    Created container: netshoot
Dec 24 09:39:13 14s         Normal   Started             pod/debug-658b996798-52g2g    Started container netshoot
Dec 24 09:39:13 15s         Normal   SuccessfulCreate    replicaset/debug-658b996798   Created pod: debug-658b996798-52g2g
Dec 24 09:39:13 15s         Normal   ScalingReplicaSet   deployment/debug              Scaled up replica set debug-658b996798 from 0 to 1

Dec 24 09:39:26 0s          Normal   ScalingReplicaSet   deployment/debug              Scaled down replica set debug-658b996798 from 1 to 0
Dec 24 09:39:26 0s          Normal   Killing             pod/debug-658b996798-52g2g    Stopping container netshoot
Dec 24 09:39:26 0s          Normal   SuccessfulDelete    replicaset/debug-658b996798   Deleted pod: debug-658b996798-52g2g

Я раньше не знал про утилиту "ts" из пакета moreutils и узнал о ней из вопроса на stackoverlow. Забавно что больше откликов набрал другой вариант ответа на вопрос.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

12 декабря 2025

Distribution не работает через workload identity в Azure

 Довольно долго провозился с настройкой distribution в Azure через workload identity в AKS который не хотел работать.

Сама настройка простая:

  • аннотация на сервис аккаунт в кластере (azure.workload.identity/client-id)
  • метка на под (azure.workload.identity/use: "true")
  • настроить конфигурацию в distribution
    storage:
      azure:
        accountname: accountname
        container: containername
        credentials:
          type: default_credentials
    

Но в лог валится ошибка "403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature."

14 ноября 2025

Ingress-nginx уходит на покой

На днях в блоге Kubernetes появилась запись Ingress NGINX Retirement: What You Need to Know в которой сообщается что поддержка Ingress Nginx будет осуществляться до марта 2026 и далее не стоит ожидать каких-либо новых выпусков или исправлений.

To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX. Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available.

Другими словами, самое время начинать двигаться дальше и искать альтернативу. Жаль конечно, на мой взгляд это был один из самых популярных ингресс контроллеров, но отсутствие ресурсов на поддержку и "излишняя гибкость" сделали своё дело.


Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

21 августа 2025

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

17 июля 2025

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)

23 мая 2025

Ограничение доступа в контроллере 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 контроллере могут найти уязвимость которая позволит обойти ограничение доступа

26 марта 2025

Грабли при обновлении 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 через которую делается тонкий тюнинг приложений и нет простого способа отказаться от использования этой опции.

28 февраля 2025

Подключение к 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>

17 января 2025

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

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

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

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

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

17 декабря 2023

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

25 ноября 2022

Bitnami Sealed Secrets

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

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

13 ноября 2022

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

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

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

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

25 сентября 2022

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

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

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

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

03 июля 2021

Задержка ответа 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 на всех окружениях".