Не записывать трассировку стека из kubelet
У меня что-то не так с моей нодой Kubernetes, но ее сложно отлаживать, потому что я получаю страницы и страницы трассировки стека, например
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/client-go/tools/cache.(*Reflector).Run(0xc000040f
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: created by k8s.io/kubernetes/pkg/kubelet/config.newSourceApiserverFromLW
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: goroutine 244 [select]:
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.contextForChannel.func
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: created by k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.contextForC
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: goroutine 205 [sync.Cond.Wait]:
Nov 13 10:55:51 corona kubelet[29656]: runtime.goparkunlock(...)
Nov 13 10:55:51 corona kubelet[29656]: /usr/local/go/src/runtime/proc.go:312
Nov 13 10:55:51 corona kubelet[29656]: sync.runtime_notifyListWait(0xc000b140c8, 0x1)
Nov 13 10:55:51 corona kubelet[29656]: /usr/local/go/src/runtime/sema.go:513 +0xf8
Nov 13 10:55:51 corona kubelet[29656]: sync.(*Cond).Wait(0xc000b140b8)
Nov 13 10:55:51 corona kubelet[29656]: /usr/local/go/src/sync/cond.go:56 +0x9d
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/client-go/tools/cache.(*DeltaFIFO).Pop(0xc000b140
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/client-go/tools/cache.(*controller).processLoop(0
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0xc
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0xc000def
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil(0xc000defe
Nov 13 10:55:51 corona kubelet[29656]: /workspace/anago-v1.19.4-rc.0.51+5f1e5cafd33a88/src/k8s.io/kubernetes/_ou
Nov 13 10:55:51 corona kubelet[29656]: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.Until(...)
. Я попытался добавить -v = 0 к команде kubelet в файле модуля systemd, но он все еще извергается. Я посмотрел на /var/lib/kubelet/config.yaml , и там написано ведение журнала: {} . Я не уверен, можно ли что-нибудь добавить туда, чтобы было тише.
Есть ли способ сказать kubelet пропустить трассировку стека? Сообщения об ошибках перед трассировкой полезны, но их трудно найти в шуме.
Трассировка стека происходит из кода в kubelet, вызывающего panic , подпрограмму Golang, которая выгружает трассировку стека из всех потоков и завершает программу с неудачным кодом выхода.
Нет другого способа избежать трассировки стека, кроме как не вызывать panic в коде. Обычно паника указывает на то, что программа перешла в непредвиденное состояние, и трассировка стека поможет программистам отладить проблему.
В этом случае, по крайней мере, некоторые паники происходят из-за известных ошибок. Программа была запущена с неверной конфигурацией. Невозможно сократить или избежать вывода трассировки стека. Вероятно, код кублета следует исправить, чтобы он выходил чисто с ошибкой, а не паниковал в тех случаях, когда проблема ясна.
С точки зрения оператора, единственное, что можно сделать, это найти самую первую строку паники. , который обычно содержит удобочитаемое сообщение об ошибке, и посмотрите, можно ли исправить это.
Сначала проверьте, нет ли файлов конфигурации или переменных среды, которые используются для запуска kubelet.
Лучший способ проверить:
1. проверьте процесс kubelet (например, ps -ef | grep kubelet), чтобы увидеть все аргументы
2. если kubelet использует динамическую конфигурацию, проверьте ConfigMap kubelet-config-1.18 в системе Kube, чтобы узнать, указан ли cgroupDriver по вашему желанию.
3. если вы запустите kubelet с помощью systemd , то вы можете использовать следующий метод для просмотра журналов kubelet:
# journalctl -u kubelet
См .: журналы компонентов системы .
См. пример, как сузить область журналов: management-logs-kubernetes .
Ошибка не удалось запустить Kubelet: неправильная конфигурация: драйвер cgroup kubelet: «cgroupfs» отличается от драйвера cgroup docker: «systemd» происходит из-за драйвера Cgroup, используемого в Kubelet. Либо Kubelet, либо Docker должны работать с использованием драйвера Systemd или Cgroupfs. Рекомендуется Systemd.
Проверьте файл рабочих узлов /var/lib/kubelet/kubeadm-flags.env и в KUBELET_KUBEADM_ARGS , если у вас есть - cgroup- драйвер = cgroupfs флаг. Изменил его на systemd , и kubelet снова начнет работать.
Взгляните: kubelete-cgroupfs-driver , kubelet-cgroupfs .
См. также: kubelet-runtime-panic .