CoreOS Kubernetes, как контролировать процессы узла?

Известно, что процесс фланелда на некоторых наших узлах Kubernetes Crash вызывает странное поведение. Я хотел бы настроить мониторинг/оповещение, чтобы убедиться, что мы получаем уведомление, когда/если flanneld падает. Мы запускаем CoreOS в качестве нашей базовой ОС для запуска Kubernetes.CoreOS Kubernetes, как контролировать процессы узла?

Одно из проектных решений с CoreOS (как я понимаю) заключается в том, что на базовой ОС должно быть минимальное программное обеспечение, и все должно работать в Pod/container.

Итак, имея в виду, я хотел бы запустить Pod/container для мониторинга списка процессов хоста, чтобы гарантировать, что всегда выполняется процесс с именем «flanneld» и отправляет предупреждение, если оно не бегать.

Однако, из-за того, что любой Pod/контейнер имеет собственное пространство имен процессов, кажется, что я не могу запустить контейнер, который имеет доступ к списку/дереву процессов хоста. Я попытался запустить контейнер с "privileged: true", но не повезло.

Есть ли способ запустить контейнер на Кубернете, который имеет доступ к списку/дереву хоста?

В качестве альтернативы, есть ли лучший способ сделать то, что я пытаюсь сделать? Предпочтительно, не устанавливая программное обеспечение непосредственно в системе CoreOS, а используя контейнер/под.

источник

2016-09-23 srkiNZ84

Один из способов, который я нашел, заключается в том, чтобы монтировать хосты/proc на контейнере, например. «-v/proc:/hostproc», а затем периодически просматривает все номера процессов, перечисленные в/hostproc, и проверяет, существует ли (например) «фланель».

источник

2016-09-23 10:14:43 srkiNZ84

Это, кажется, довольно распространенный подход (например, https://github.com/bhuisgen/docker-zabbix-coreos, https://stackoverflow.com/questions/29281350/how-do-i- enable-snmp-on-coreos) – srkiNZ84

Почему бы не использовать систему самостоятельно и убедитесь, что при запуске или перезагрузке фланелевого процесса (службы) вы получаете электронную почту, инициированное веб-приложение или какое-либо другое событие?

Вы можете легко создавать всплывающие окна для системных блоков в вашем облако-config, как вы часто делаете с настройкой фланеля по умолчанию, чтобы увеличить стандартный файл службы по умолчанию, как вы сочтете нужным.

- name: flanneld.service 
    command: start 
    drop-ins: 
    - name: 01-somedropin.conf 
    content: | 
    [Service] 
    ExecStartPre=-/usr/bin/somecommand

источник

2016-09-23 10:34:31

Да, это имело бы смысл. Я предполагаю, что я просто пытался избежать модификации Host OS (CoreOS) вообще, по причинам, которые меня волнуют, изменения будут «протерты» на обновлении CoreOS и, как правило, должны поддерживаться, версироваться и т. Д. На самом деле хотелось, чтобы решение было запущено в Pod/container поверх хоста, чтобы сделать все, чтобы все, что нам нужно беспокоиться об управлении версиями, - это изображение Docker. – srkiNZ84

Всякий раз, когда вы каким-либо образом протираете систему или даже просматриваете ее с нуля, ваша облачная конфигурация будет перезапущена (CoreOS перезапускает облачную конфигурацию при каждом запуске системы), поэтому вам не нужно беспокоиться о том, что она очищается от системы, если вы добавили ее с помощью cloud-config. Я предполагаю, что вы используете cloud-config, который вы все равно должны держать в управлении версиями, поэтому никаких проблем здесь нет. –

Спасибо за это! Не знал о «облачной конфигурации» функции CoreOS, может быть, именно то, что мы делаем :-) – srkiNZ84

CoreOS Kubernetes, как контролировать процессы узла?

ответ

Смежные вопросы