Comments 8
Спасибо, узнал что-то новое. Для меня пока тактика скроллить дескрайб до ивентов работает хорошо. Но и использование достаточно простое, деплоймент, под, секреты. Деплою частично через Хелм, а другую часть через Терраформ.
О, тогда describe ещё полезнее. Когда часть едет через Helm, часть через Terraform, легко получить два источника правды: в values одно, в tf state другое, а в Pod прилетело третье, ещё и после вебхуков, инжекторов и платформенных дефолтных настроек.
Я бы в таком раскладе смотрел describe как проверку реальности перед тем, как лезть глубже: какой образ реально запущен, какие метки и аннотации навесились, под каким service account всё стартует, какие переменные окружения, тома, пробы и кто владелец пода.
Events, это как быстрый вход в отладку, а верхняя часть describe помогает понять сразу: мы чиним реальную проблему или расхождение между Helm, Terraform и тем, что в итоге собрал наш кластер.
У меня все проще. Я деплою Coder (удаленное пользовательское окружение) через Хелм, а он уже создаёт поды через Терраформ, я всегда знаю через что какой под создан. Сервис аккаунт тоже один. Неймспейс как бы один, но в разных кластерах. Технически я владелец всех темплейтов и всех объектов. Пользователи могут только логиниться в свой под и творить там что захотят и смотреть метрики к графане (OOM, CPU, ...)
Крайне полезный материал, спасибо.
Еще бы узнать, почему с виду корректно работающие поды в ide помечаются восклицательным знаком )
Спасибо!
С IDE это кстати частая история. И восклицательный знак там далеко не всегда значит что под лежит. Часто это бывает когда что-то в статусе не идеально, например, был рестарт, Ready=False, старый warning event какой-нибудь, отвалилась проба, один контейнер из нескольких не готов или сама IDE чуть закешировала стейт.
Часто бывает, что под снаружи живой, и приложение отвечает, но Кубер уже оставил жёлтый флажок, мол тут был флап, рестарт или проба ругалась, и IDE просто подсвечивает этот шум как проблему.
Я бы проверил под через get и describe, и если в Ready, Restart Count, Last State и Events всё чисто, то скорее всего, это просто шум или IDE закешировала старый статус.
Хорошо бы перед тем как выкладывать статью посмотреть ее превью.
Есть подозрение, что при написании статьи использовался ИИ (даже уверен, что использовался бесплатный ИИ от Google, что доступен на странице поиска).
Я не против статей от ИИ, но когда она просто скопирована и вставлена без правок опечаток и проблем с форматированием, то считаю это как неуважение к читателям.
Таблицу тоже ИИ "сгенерил" или откуда-то скопировали не проверив ее содержимое?
ИИ действительно использовался, но не в том варианте, который вы предполагаете. И точно не бесплатный — возможности бесплатных моделей для подобных задач довольно ограничены.
Сам текст я писал вручную. После этого использовал ИИ как редактор, чтобы он помог исправить грамматические и пунктуационные ошибки, улучшить стилистику, разбить текст на более читаемые абзацы и привести оформление к единому виду. Это примерно то же самое, как использовать LanguageTool или Grammarly, только с более широкими возможностями.
Если где-то осталось кривое форматирование или ошибки в таблице, то это мой недосмотр, а не результат слепого копирования, так как через ИИ я прогонял не всю статью, а подозрительные для меня участки текста. За замечание спасибо.
Kubernetes хорошо показывает одну вещь: автоматизация не отменяет необходимость думать. Можно знать сотни команд, но без понимания того, как система принимает решения, легко потратить часы не туда. Именно такие инструменты и прокачивают инженерное мышление.
kubectl describe pod: как читать вывод, в котором Kubernetes уже написал причину