🛠 Кейс из жизни: почему пайплайн деплоя может "висеть" на step'е helm install

Недавно заметил, что пайплайн деплоя зависает на шаге helm install. Логи — тишина. Время ожидания — в никуда. Проблема оказалась интересной и довольно редкой: зависание происходило из-за недоступности webhook'а Kubernetes admission controller'а, а не из-за самого Helm.

Что происходило под капотом:

Helm создаёт ресурсы через kubectl apply, но в кластере был установлен ValidatingWebhookConfiguration, который ожидал ответ от стороннего admission webhook'а. А тот лежал — под был удалён, сервис не восстановился, ingress не поднялся… В итоге API-сервер ждал ответа, который никогда не придёт, и не возвращал ошибку Helm'у.

Решение:

▫️Проверить список webhook'ов:

  kubectl get validatingwebhookconfigurations
  

▫️Найти подозрительный и посмотреть, куда он указывает.
▫️Если сервис не работает и не критичен — удалить/отключить webhook.
▫️Альтернатива: установить timeout'ы на webhook'и, чтобы не зависало вечно:

  timeoutSeconds: 5
  

📌 Совет: если helm install висит без логов — не всегда виноват Helm. Иногда виноваты "умные" валидаторы, которые сломались.

Подпишись 👉@devopslib