Kubernetes: What's the difference between helm uninstall, helm delete and kubectl delete

Ты поставил в кластер что-то через helm install. Потом решил, что это «что-то» больше не нужно. Логичный ход — удалить. Ты открываешь документацию, спрашиваешь у коллеги или у чатика — и получаешь в ответ три варианта: helm uninstall, helm delete и kubectl delete. И тихо зависаешь в раздумьях, какой из них правильный и не сломает ли это всё.

Давай разбираться, что к чему. Всё просто, если смотреть на это как на историю управления состоянием.

Helm delete — это призрак из прошлого

Первое, что нужно уяснить: в современном Helm (v3) команд helm delete как самостоятельной — не существует. Это просто псевдоним, альтернативное написание для helm uninstall.

Убедиться в этом можно, заглянув в справку:

$ helm delete --help
...
Usage:
  helm uninstall RELEASE_NAME [...] [flags]

То есть, когда ты пишешь helm delete my-release, система понимает это как helm uninstall my-release. Это одна и та же операция. Она делает главное: удаляет из кластера все ресурсы, которые были созданы конкретным релизом (тем самым my-release), и стирает запись об этом релизе из истории Helm (helm list его больше не покажет).

А что же kubectl delete?

Вот здесь начинается ключевое различие. Команда kubectl delete — это инструмент управления непосредственно объектами Kubernetes. Она ничего не знает о Helm, его релизах и истории.

Когда ты делаешь kubectl delete -n <namespace> deploy <deployment name>, ты удаляешь только конкретный объект Deployment (и порожденные им Pod’ы, благодаря механизму сборщика мусора). Однако для Helm этот релиз жив-здоров. Он по-прежнему числится в списке (helm list), и его «желаемое состояние» (описанное в чарте) остается прежним.

Что происходит потом? Scheduler Helm’а или ты сам в будущем можешь запустить helm upgrade или helm rollback для этого релиза. Helm увидит расхождение: «в моей истории должен быть deployment A, а в кластере его нет» — и попытается его воссоздать, вернув удалённое. Это может стать неожиданным сюрпризом.

Какой способ — правильный?

Правило простое и железобетонное: удаляй тем же инструментом, которым устанавливал.

Если приложение было развернуто через kubectl apply -f config.yaml, то для удаления используй kubectl delete -f config.yaml. Это чистая работа с манифестами.

Если же ты использовал helm install my-release ./my-chart, то правильный путь удаления — helm uninstall my-release. Helm сделает всю грязную работу: найдет все ресурсы, созданные этим релизом (Deployments, Services, ConfigMaps, Secrets — десятки или сотни объектов), и удалит их атомарной операцией. Это безопасно, предсказуемо и не оставляет следов.

Итог

helm delete и helm uninstall — одно и то же. Используй uninstall, это каноничное название в Helm 3.

kubectl delete — это операция на уровень ниже. Она удаляет ресурсы Kubernetes, но оставляет запись в Helm, что может привести к конфликтам в будущем.

Поэтому ответ на вопрос «что лучше» — helm uninstall. Это не просто удаление пода, это корректное завершение жизненного цикла релиза, за которым ты управлял через Helm. Не усложняй себе жизнь ручным удалением объектов, доверь это тому, кто их создавал.