Речь про managed кластера.
Что вообще рекомендуется предпринимать на этот счёт сразу после развёртывания очередного k8s-кластера и добавления пустых нод (например в моём случае Ubuntu LTS) на него?
Разумеется, грамотно настроенный мониторинг мне в помощь, но что делать, пока его нет?
Постоянно бегать по /var/log/*, dmesg, syslog etc. - не комильфо, поэтому интересует, есть ли какая-то best practice, как настроить OOM дабы максимально оперативно предотвращать hang.
Больше всего упоминаний нашёл про nohang, ну вроде чё-то делает, мониторит и т.д.
Healthcheck на liveness probах
Благодарю, но поясни, пожалуйста. health checks performed by the kubelet: - Startup Probe - Liveness Probe - Readiness Probe Это вроде только к контейнерам относится? Напрвь мысль, плз :)
Я дописал eBPF exporter и мы начали использовать его в deckhouse. Можно взять себе на вооружение приём. Без оверхеда мониторим OOM'ы. cgroup'ные и глобальные. https://github.com/cloudflare/ebpf_exporter/pull/102 https://github.com/deckhouse/deckhouse/tree/main/modules/340-monitoring-kubernetes/templates/ebpf-exporter
А чтобы предотвращать зависания нод, когда ядро не хочет делать OOM. Просто посмотри на это чудо инженерной мысли! https://github.com/deckhouse/deckhouse/blob/main/modules/040-node-manager/templates/early-oom/daemonset.yaml#L61-L65
Что будет, когда кубелет его преодолеет? Или crontab? Или containerd?
Я чёт не видел что бы crontab много памяти занимал, как и сам демон containerd.
Неуверенно сказал. Не поверю тебе.
а если отправлять i вместо f - можно высвободить чуть больше памяти!
Если отправить b - можно вообще все память освободить)) а вот что такое i, чот даже не слышал о таком, гуггульну
Это просто гениально
Обсуждают сегодня