У меня есть локальный кластер Kubernetes, работающий с k3s, и я хочу получить доступ к файловой системе остановленного Pod. Pod происходит от CronJob, и я хочу подробнее разобраться, почему это задание не удалось.
Для «обычной» установки Kubernetes я бы попытался получить доступ к файловой системе через docker cli. Однако с k3s docker ps на автомате возвращает пустой список. Насколько я понимаю, k3s использует containerd, но я не мог понять, как проверять контейнеры "containerd". Мой гугл-фу соскучился по мне. : /
Я не уверен, почему вы хотите войти в файловую систему, чтобы проверить, почему Job не смогли.
Когда вы создаете job он автоматически создает pod. Пример на основе официальные документы.
$ sudo k3s kubectl apply -f https://k8s.io/examples/controllers/job.yaml
job.batch/pi created
Тем временем он создал под (тем временем я создал псевдоним kk = "sudo k3s kubectl")
$ kk get pods
NAME READY STATUS RESTARTS AGE
pi-796ng 0/1 Completed 0 55s
$ kk get jobs
NAME COMPLETIONS DURATION AGE
pi 1/1 7s 30s
1. Чтобы проверить, что происходит внутри модуля, вы можете проверить это
$ sudo k3s kubectl logs <pod_name> -c <container_name>
$ kk logs pi-796ng -c pi
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647...
2. Опишите пакет / опишите работу
$ sudo k3s kubectl describe pod <pod_name>
$ sudo k3s kubectl describe job <job_name>
Если они в разных namespace затем default вам нужно добавить -n <namespace> флаг для запроса
3. Kubernetes события
Выполнить команду
$ sudo k3s kubectl get events
Он покажет вам все события из вашего Kubernetes кластер.
Многие факторы устранения неполадок также могут зависеть от вашего Job спец. Например .spec.activeDeadlineSeconds или .spec.backoffLimit. Больше информации Вот.