Что реально никто не мониторит доступность апи кубера?))

Нафига? Кубе прометеус стек есть же. Никто же не добавляет себе в кластер единую точку отказа в виде хапркси

а какая у тебя единая точка отказа?, мастер?))

Датацентр

промашка, у меня несколько дц и нет единой точки отказа

Есть. Твой балансировщик на хапрокси

у меня несколько балансировщиков на хапрокси в разных ДЦ, и они между собой делять ip по которому и обращается всё к апи кубера, один балансировщик упал, этот ip забрал другой

и всё это в целом работает хорошо, но хочется ещё на всякий случай это мониторить), вот интересно кто как это делает

Вррп между ДЦ? Сурово

а если у тебя нет балансировщика в виде хапрокси или чего-то иного, то значит ты указал в апи ip мастера, который упав полождит всё, вот и единая точка отказа

Хм. У меня на каждом из узлов свой балансировщик. Упадет балансировщик - из кластера один только узел пропадет. Прометей Алерт пришлет.

о каком балансировщике речь?

что у тебя вписано в controlPlaneEndpoint ?

Ну конкретно у меня там nginx. Но это не важно. Главное, что их много.

я не про ингресс сейчас говорю, а ощущение что Вы о нём подумали

127.0.0.1:6443

ммм))), интересно), почему я о таком раньше не думал))

Потому что кубспреем ни разу кластер не ставил ))

ставил, это мой первый опыт) Потом начал стаивть кубадмином))

Ну вот. Он так делает

Мне надо сейчас с этой мыслью переспать)), в целом идея интересная))

Я мониторю в т.ч. тупо состояния подов. Если каво-чиво важное не Running или за N-времени много рестартов - алерт.

я все же предпочитаю давать имя и потом прописать его в hosts на 127.0.0.1 для воркеров . Так и конфиги получаются с нормальным адресом к которому можно обратится итд итп.

а такой ip не вызывает конфликтов?, в смысле к нему никто не обращается из под контейнера например, там ведь этот адрес будет восприниматься как локальный

kubelet на хосте работает все системные компоненты с hostNetwork: true ну надо разумеется в SAN сертификатов добавить 127.0.0.1

логично, развеял мои сомнения))

в kubeadm конфиге, и фазу сертов запустить

я про этот конфиг и мел ввиду, а фазу сертов это в смысле kubeadm certs renew all

нет, вроде там была kubeadm init phase certs apiserver

хм, будем пробовать)

а точно надо ? Там же вроде только X509v3 Subject Alternative Name: DNS:cicd-kub-control-01, DNS:kub-lb-api.ci-cd.loc, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.xxx.xxx.1, IP Address:10.xxx.xx.41 и вроде как само

К нему обращается только кубелет И кубпрокси, который запущен в режиме хостнетворк. Все обычные поды обращаются к апи через адрес куб-сервиса kubernetes.default

Мне команда говорит что серты есть и будут использованы старые, мне что сначала удалить старые?

по-русски плиз

Согласен

kubeadm certs renew может надо? или както так

ну я вообще так и хотел, но мне сказали нет

а ты SAN добавил?

конечно certSANs: - "127.0.0.1"

удали старые rm -fv /etc/kubernetes/pki/apiserver.* и попробуй но забэкапить надо конечно, на всякий

звучит страшно)), может всё таки просто команда перегенерации сертов?))

cert renew вроде просто существующие апдейтит, не уверен что оно SAN обновит

ладно, я попробую сначала его), оно точно ничего поломать не должно))

так удаление тож не поломает, тем более можно на всякий случай забэкапить

Доброго дня, а на мастерах у тебя тоже этот эндпойнт стоит?, я просто к чему это, получается у мастера этот адрес уже слушается апи самого мастера, то есть условно если я выключу мастер, а потом включу, она сам на себя же норм включится?. Вроде должен), иначе как кластеры с одним мастером запускаются)), но всё таки ответ интересен

Мастера общаются через etcd , если я правильно помню о чем речь. Поэтому делают на воркерах и на них же ставят балансировщики, если ты об это схеме

кластеры с одним мастером лучше не запускать, поверь на слово

Если у тебя всё на одном дедик, от того что ты там запустил 2 мастера у тебя надёжность не повысилась))

И мой вопрос был в другом

Ответ кроется в сущности static pod + etcd service discovery. Близкий аналог по логике работы связка consul + vault/stolon/patroni

etcd у меня внешний

Это тут без разницы. Я тебе про кишки, а не способ размещения

я вообще не понял к чему это

вот же

странно как я это просрал учитывая что даже даже через ответ написано)

>пятница

Я на мастере kubelet, cni натраваливаю на nginx/envoy локальный. Остальные компоненты - kube-sheduler, kube-controller-manager на kube-apiserver локальный. Порты развожу прост: Локальный прокси в апстримах которого все kube-apiservers, слушает 6444 kube-apiserver слушает 6444 Но ваще я думаю это не обязательно, мне прост автоматизацию так удобно было делать.

вот я так понял что нет смысла разводить порты, я слушаю хапроксю на том же что и реальный апи сервер, просто на мастерах у меня нет хапрокси

Да