Когда что-то ломается в k8s, нельзя просто взять, посмотреть логи и найти проблему. Сначала вы ничего не понимаете, потом пьёте кофе, потом уходите на созвон, затем до вечера копаетесь с проблемой, и только на следующий день приходите к идее, которая оказывается шагом в правильном направлении.
Вот несколько советов, которые помогут облегчить процесс поиска 👉
Не откладывайте сбор логов и событий
Они могут быть затерты, если не настроено сохранение в долгосрочное хранилище. Если проблема плавающая, лучше сразу сохранить себе kubectl logs, kubectl get events, kubectl describe pod и так далее, чтобы потом спокойно разбираться, даже если сервис уже перезапустился и стабильно работает.
Не забывайте отключать под от продового трафика, если начинаете копошиться в нем через kubectl exec, чтобы случайно не поломать все клиентам
Оно, конечно, работает только в ограниченном количестве случаев, когда у вас, например, php и можно на ходу поправить код. Сделать это можно, только очень осторожно, через редактирование endpoints. Это сущность в k8s, которая указывает service, по каким адресам доступны поды. Операция относительно безвредная, потому что трафик перестанет идти на под, который будем препарировать. Потом просто удалите под и deployment его пересоздаст. Это вмешательство во внутреннюю логику k8s и может сломать вам сервис. You have been warned.
Если вы еще не используете в сервисах динамически настраиваемые feature flags, обязательно разберитесь.
Это экономит много времени в итоге и позволяет с большей уверенностью выкатывать изменения в прод, зная, что их легко очень быстро выключить без нового деплоя. Это не значит, что код надо писать абы как, потому что фича флаги все порешают).
Не уверены? Киньте детали всех ошибок и вывод всех команд в chatgpt и попросите разрулить (научитесь писать хорошие промпты)
Только учтите предварительно, что нужно будет вычистить все детали: ссылки на образы, названия env переменных, публичные IP адреса, user_id из логов, и так далее, если по ним можно понять, какая компания и какой сервис это. Все, что вы отправите в интернет, будет использовано против вас.
Больше советов и полезных материалов (а также фоток кота и историй о релокации) – в канале «Kubernetes и кот Лихачева».
Вот несколько советов, которые помогут облегчить процесс поиска 👉
Не откладывайте сбор логов и событий
Они могут быть затерты, если не настроено сохранение в долгосрочное хранилище. Если проблема плавающая, лучше сразу сохранить себе kubectl logs, kubectl get events, kubectl describe pod и так далее, чтобы потом спокойно разбираться, даже если сервис уже перезапустился и стабильно работает.
Не забывайте отключать под от продового трафика, если начинаете копошиться в нем через kubectl exec, чтобы случайно не поломать все клиентам
Оно, конечно, работает только в ограниченном количестве случаев, когда у вас, например, php и можно на ходу поправить код. Сделать это можно, только очень осторожно, через редактирование endpoints. Это сущность в k8s, которая указывает service, по каким адресам доступны поды. Операция относительно безвредная, потому что трафик перестанет идти на под, который будем препарировать. Потом просто удалите под и deployment его пересоздаст. Это вмешательство во внутреннюю логику k8s и может сломать вам сервис. You have been warned.
Если вы еще не используете в сервисах динамически настраиваемые feature flags, обязательно разберитесь.
Это экономит много времени в итоге и позволяет с большей уверенностью выкатывать изменения в прод, зная, что их легко очень быстро выключить без нового деплоя. Это не значит, что код надо писать абы как, потому что фича флаги все порешают).
Не уверены? Киньте детали всех ошибок и вывод всех команд в chatgpt и попросите разрулить (научитесь писать хорошие промпты)
Только учтите предварительно, что нужно будет вычистить все детали: ссылки на образы, названия env переменных, публичные IP адреса, user_id из логов, и так далее, если по ним можно понять, какая компания и какой сервис это. Все, что вы отправите в интернет, будет использовано против вас.
Больше советов и полезных материалов (а также фоток кота и историй о релокации) – в канале «Kubernetes и кот Лихачева».
