Это жёсткая практика, проверенная на нескольких кластерах схожей конфигурации. Кворум не ломается, т.к. кластер etcd отлично работает на двух нодах и не развалится до момента смерти второй из трёх нод. В случае беспокойства, кластер отлично восстанавливается даже на других ip адресах просто из дампа etcd. И да, это тоже опробовано не единожды. Возможно позже сделаю статью и на эту тему.
>>Так же не совсем ясно, что будет после того, как на всех мастерах выполнится... Возможно вы невнимательно читали, или я недостаточно подробно описал. Данная процедура производится только на перемещаемой ноде. Состояние кластера etcd хранится в самом кластере. Настройка --initial-cluster, равно как и --initial-cluster-state используется только в момент инициализации ноды и присоединению к кластеру (согласно документации). На дальнейший рестарт ноды etcd это не влияет.
Настройки calico не влияют, т.к. cni система на ноде инициализируется заново. Т.е. нода прохдит через продедуру удаления из кластера и добавления в него. Штатная процедура для kubeadm.
Про маршрутизацию в статье указано: "Дальше тушим ноду, меняем адреса на гипервизоре или железке, поднимаем, проверяем наличие сетевой связности нод."
В реальности переносилось именно в другую подсеть, в другой vlan. И часть времени кластер был размазан между двумя подсетями.
Дамп в configmap? Возможно автор никогда не делал подобного или никогда не сталкивался с кубером.
Ограничение configmap по размеру в 1мб со стороны etcd, ибо объект будет создаваться в виде записи в этой бд. И сама идея хранить одну бд внутри другой - это что то с чем то.
job по восстановлению дампа без привязки к реальному месту хранения данных?
Оно восстановит, но себе под ноги и на время жизни пода.
Придётся подгонять под себя, патчить (в моём случае некоторые метрики отдавали по метке 'instance' ip ноды вместо имени, а в коде используется имя ноды). Некоторых метрик нет в куберовском мониторинге, придётся что то выдумывать.
Также потребуется патчинг файлов (это как минимум):
Патчим разделы с запросами, попутно проверяем что запросы отдают нормальные данные на вашем prometheus.
Дальше собираем фронт через:
git clone https://github.com/openshift/console
cd console/frontend
yarn install
yarn run build
И подсовываем в кастомный образ console например так (Dockerfile):
FROM quay.io/openshift/origin-console:4.16
COPY ./dist /opt/bridge/static
WORKDIR /
USER 1001
CMD [ "/opt/bridge/bin/bridge", "--public-dir=/opt/bridge/static" ]
В моём случае мониторинг (его значительная часть) заработал. Но не отрабатывает проваливание в подробности метрики по нажатию на любой из графиков мониторинга, показывает пустую страницу. Если кто-то сумел это победить - прошу подсказать решение.
Пользуясь случаем, хочу спросить совета у клавиатурных знатоков:
Хочу найти FullSize тихую! (одно из ключевых условий) клавиатуру с ANSI раскладкой. В идеале беспроводную со своим донглом, не bluetooth. По тишине ориентируюсь на родную ноутбучную клаву от Lenovo x220.
Это жёсткая практика, проверенная на нескольких кластерах схожей конфигурации.
Кворум не ломается, т.к. кластер etcd отлично работает на двух нодах и не развалится до момента смерти второй из трёх нод. В случае беспокойства, кластер отлично восстанавливается даже на других ip адресах просто из дампа etcd. И да, это тоже опробовано не единожды. Возможно позже сделаю статью и на эту тему.
>>Так же не совсем ясно, что будет после того, как на всех мастерах выполнится...
Возможно вы невнимательно читали, или я недостаточно подробно описал. Данная процедура производится только на перемещаемой ноде. Состояние кластера etcd хранится в самом кластере. Настройка --initial-cluster, равно как и --initial-cluster-state используется только в момент инициализации ноды и присоединению к кластеру (согласно документации). На дальнейший рестарт ноды etcd это не влияет.
Настройки calico не влияют, т.к. cni система на ноде инициализируется заново. Т.е. нода прохдит через продедуру удаления из кластера и добавления в него. Штатная процедура для kubeadm.
Про маршрутизацию в статье указано: "Дальше тушим ноду, меняем адреса на гипервизоре или железке, поднимаем, проверяем наличие сетевой связности нод."
В реальности переносилось именно в другую подсеть, в другой vlan. И часть времени кластер был размазан между двумя подсетями.
Перечитайте, пожалуйста, третий абзац статьи. Краткий план работ описан.
Плюс, если человек вообще лезет в данную область, он как правило знает зачем ему это нужно. Пененос кластера достаточно редкое явление.
Как быть с авторизацией по ключам?
Например для прямого чтения баз etcd у k8s?
Очень странная инструкция.
Дамп в configmap? Возможно автор никогда не делал подобного или никогда не сталкивался с кубером.
Ограничение configmap по размеру в 1мб со стороны etcd, ибо объект будет создаваться в виде записи в этой бд. И сама идея хранить одну бд внутри другой - это что то с чем то.
job по восстановлению дампа без привязки к реальному месту хранения данных?
Оно восстановит, но себе под ноги и на время жизни пода.
Т.е. статья - образец как делать не надо.
Пожалуй отвечу сам, возможно кто-то пойдёт по моему пути и тоже упрётся.
Я решил в какой то мере подключение обычного prometheus к этой консоли.
Вопрос с подключением к prometheus решается опциями в запуске:
Дальше придётся подключать кастомные метрики относительно ванильной инсталляции стека kube-prometheus-stack
Статья в помощь: https://engineering.cloudflight.io/running-the-openshift-console-in-plain-kubernetes
Метрики для создания, которые используются в openshift:
https://github.com/openshift/cluster-monitoring-operator/blob/master/assets/cluster-monitoring-operator/prometheus-rule.yaml
Придётся подгонять под себя, патчить (в моём случае некоторые метрики отдавали по метке 'instance' ip ноды вместо имени, а в коде используется имя ноды). Некоторых метрик нет в куберовском мониторинге, придётся что то выдумывать.
Также потребуется патчинг файлов (это как минимум):
https://github.com/openshift/console/blob/master/frontend/packages/console-app/src/components/nodes/NodesPage.tsx
https://github.com/openshift/console/blob/master/frontend/packages/console-app/src/components/nodes/node-dashboard/queries.ts
Патчим разделы с запросами, попутно проверяем что запросы отдают нормальные данные на вашем prometheus.
Дальше собираем фронт через:
И подсовываем в кастомный образ console например так (Dockerfile):
В моём случае мониторинг (его значительная часть) заработал. Но не отрабатывает проваливание в подробности метрики по нажатию на любой из графиков мониторинга, показывает пустую страницу. Если кто-то сумел это победить - прошу подсказать решение.
А у вас получилось прикрутить сюда мониторинг от prometheus? Ибо в этой конфигурации штатно не показываются данные по cpu/mem подов и нод.
Пользуясь случаем, хочу спросить совета у клавиатурных знатоков:
Хочу найти FullSize тихую! (одно из ключевых условий) клавиатуру с ANSI раскладкой. В идеале беспроводную со своим донглом, не bluetooth. По тишине ориентируюсь на родную ноутбучную клаву от Lenovo x220.
Хорошо бы чтобы и по цене адекватно было.
Такое в природе существует?