Я создал на Go инструмент для Kubernetes с открытым исходным кодом

В мире, где ИИ умеет якобы все, я потратил уикенд на создание утилиты командной строки для Kubernetes. На Go. С нуля. И сделал бы это снова.

Почему?

Ложь, с которой все началось

Если вы работали с Kubernetes дольше недели, наверняка запускали эту команду:

kubectl get all -n my-namespace

И, вероятно, думали, что она возвращает… все ресурсы.

Но это не так.

Команда kubectl get all возвращает, возможно, 8 типов ресурсов. В вашем пространстве имен (namespace) может быть 140 ресурсов 30 разных видов — Deployments, Secrets, ConfigMaps, Ingresses, CRD из ArgoCD, cert-manager, external-secrets, Prometheus … и ничего из этого не отображается.

Еще в 2019 году Ахмет Балкан — инженер, создавший kubectx, krew и половину плагинов для kubectl, которыми вы наверняка пользуетесь, — открыто указал на это: «kubectl get all» на самом деле не получает все типы ресурсов».

                                                                   …

ketall решил часть проблемы

Для решения этой проблемы появился инструмент под названием ketall. Он выводит список всех типов ресурсов, известных Kubernetes, включая CRD. Я пользовался им в течение многих лет.

Но со временем начал постоянно сталкиваться с ограничениями.

ketall отвечает на вопрос: «Что существует?»

Но во время реальных инцидентов, которые всегда случаются в 2 часа ночи, в пространстве имен, которое я не создавал, с 200 ресурсами, о которых я никогда не слышал, мне требовалось нечто большее, чем просто список.

Мне нужно было знать:

• Что выглядит осиротевшим? — ConfigMaps и Secrets, оставшиеся от удаленных развертываний.
• Что застряло? — Ресурсы с финализаторами, блокирующими удаление пространства имен.
• Кто чем владеет? — Цепочка Deployment → ReplicaSet → Pod
• Что управляется GitOps? — Это ресурс ArgoCD или кто-то применил его вручную с помощью kubectl apply?
• Что можно безопасно трогать? — Прежде чем что-либо удалить, нужно понять, на что вообще есть ссылки.

Плоский список из 200 ресурсов не дает вам этого контекста.

Поэтому я создал kubectl-inventory

kubectl inventory -n production

Namespace: production   Context: prod-cluster
─────────────────────────────────────────────────────────────

Workloads
  Deployment   12
  StatefulSet   3
  ReplicaSet   12
  Pod          47

Networking
  Service        15
  Ingress         6
  NetworkPolicy   0  ⚠  No network policies defined!

Configuration
  ConfigMap  23  (suspicious: 8 ⚠)
  Secret     31  (suspicious: 5 ⚠)

argoproj.io
  Application    48
  AppProject      1

Stuck Resources
  None  ✓

Total resources: 147
Duration: 7.2s

За 7 секунд я узнаю:

• все, что существует, сгруппированное по API-группам;
• что выглядит заброшенным;
• что блокирует удаление;
• что управляется через ArgoCD/Helm/Flux;
• на что стоит обратить внимание, прежде чем что-либо трогать.

Я также добавил команду explain:

kubectl inventory explain secret/old-api-key -n production

secret/old-api-key
─────────────────────────────────────────────────────────────

Classification
  Status:     SUSPICIOUS
  Reasons:
    • no ownerReferences
    • no known GitOps/controller metadata detected
    • not referenced by any Pod, Deployment, or Ingress
    • age: 184 days
    • created/managed by: kubectl-create

Теперь я знаю: этот Secret, вероятно, можно безопасно исследовать. Он старый, на него нет ссылок, и он был создан вручную.

Почему Go?

Когда я решил создать этот инструмент, у меня был выбор: Python, Rust или Go.

Я выбрал Go по трем причинам:

1. Это язык Kubernetes. kubectl, Helm, k9s, Argo CD, Prometheus — все написано на Go. Официальная клиентская библиотека Kubernetes (client-go) написана на Go. Если создавать инструменты для Kubernetes, Go — путь наименьшего сопротивления.
2. Единый бинарный дистрибутив. Никакой среды выполнения, никаких зависимостей. Собрал один раз — скопировал и вставил куда угодно. Пользователи запускают kubectl inventory без установки Python или Node.
3. Это достаточно быстрый язык. Мой инструмент выполняет десятки одновременных API-вызовов. Горутины и каналы Go сделали эту задачу тривиальной. Полное сканирование пространства имен завершается менее чем за 8 секунд.

Буду честен: я никогда не работал с Go до того, как начал этот проект полгода назад.

Как я учил Go

Я не поглощал тоннами туториалы. У меня была конкретная цель: создать работающий плагин для kubectl, который сканирует пространство имен и классифицирует ресурсы.

Для изучения базовых тем — горутин, каналов, интерфейсов, шаблонов обработки ошибок — я использовал курсы по Go от Educative. Интерактивная среда помогла, поскольку позволила сразу же тестировать код без переключения контекста.

Но настоящее обучение началось, когда я начал интегрироваться с client-go. Вот тогда я понял идиомы Go:

• почему интерфейсы важны (различие между динамическим и типизированным клиентом);
• почему обработка ошибок явная (вызовы API Kubernetes могут завершиться сбоем десятками разных способов);
• почему каналы полезны (одновременные вызовы List для 200 типов ресурсов).

Если вы DevOps-инженер и собираетесь выучить Go, мой совет: выберите инструмент, который вы хотели бы иметь, и создайте его.

Заключение

Kubernetes-инструмент в 2026 году? Серьезно?

Да. Потому что проблема по-прежнему актуальна.

Команда kubectl get all по-прежнему не выдает всех ресурсов. В пространствах имен по-прежнему скапливаются осиротевшие ресурсы. Финализаторы по-прежнему блокируют удаление. Инженеры по-прежнему запускают 15 команд, чтобы разобраться в пространстве имен, которое они не создавали.

ИИ не решил эту проблему чудесным образом. Он помог мне быстрее создать решение. Но решение все равно должно было появиться.

Если вы инженер DevOps и думаете о создании инструментов: делайте это. Экосистема достаточно зрелая, чтобы вы могли выпустить что-то полезное за уикенд. Go легко освоить. client-go хорошо документирован. И везде все еще есть пробелы.

Найдите проблему, которая вас раздражает. Создайте решение. Опубликуйте его в открытом доступе.

Где-то есть человек, который запускает те же 15 команд kubectl, что и вы.

---

Читайте также:

• Построение комплексных конвейеров сборки вокруг Kubernetes
• Базовые команды при работе с узлами K8s
• K8s: топология подов

Читайте нас в Telegram, VK и Дзен

---

Перевод статьи Neil Shah: I Built an Open-Source Kubernetes Tool Using GO