Подскажите плз, что лучше использовать для алертинга об ошибках в логах? По компонентам: на куберах запущен EFK стэк, мониторинг - пром и графана. Как я понял, промовские экспротеры ES и Fluentd предоставляют только внутренние метрики самих ES и Fluentd, при этом логов они не предоставляют, т.е. в alertmanager ошибки отследить не получиться. Остается ElastAlert и без вариантов?

Eugene

щас он вроде уже кубадм юзает

совет дня: не используйте kube_proxy_mode: ipvs и kubeadm: enabled в кубспрее с версиями кубера ниже 1.13.2 если не хотите проблем с работой DNS внутри кластера)

Vadim

Подскажите плз, что лучше использовать для алертинга об ошибках в логах? По компонентам: на куберах запущен EFK стэк, мониторинг - пром и графана. Как я понял, промовские экспротеры ES и Fluentd предоставляют только внутренние метрики самих ES и Fluentd, при этом логов они не предоставляют, т.е. в alertmanager ошибки отследить не получиться. Остается ElastAlert и без вариантов?

сайдкары с кастомными метриками на сервис

Andrey

совет дня: не используйте kube_proxy_mode: ipvs и kubeadm: enabled в кубспрее с версиями кубера ниже 1.13.2 если не хотите проблем с работой DNS внутри кластера)

Дык ты это, разобрался бы в причинах проблем. А то так неинтересно

Artem

сайдкары с кастомными метриками на сервис

пошел гуглить… спасибо!

Eugene

Дык ты это, разобрался бы в причинах проблем. А то так неинтересно

есть баг в кубере, связанный с ipvs, в разных конфигурациях он по-разному проявляется, в моем конфиге это приводит к тому, что ни кубднс ни корднс не могут резолвить некоторые имена, у кого-то вообще сеть может не подняться, у кого-то кубпрокси ломается, глубже пока не знаю, буду разбираться, но совет может кому-то сэкономить кучу времени, если у него беда с днс и нет возможности использовать гугловские публичные адреса. Полностью это пофиксили от 1.13.2 и выше. В остальных версиях это может проявляться из коробки прямо сразу после установки кубспреем начиная с версий 2.6 и заканчивая 2.8.3. Чтобы отловить такой баг, который завязан сразу на столько условий мне нужно много времени.

Rainbow

Жизнь без cni прекрасна 😁

Pavel

есть баг в кубере, связанный с ipvs, в разных конфигурациях он по-разному проявляется, в моем конфиге это приводит к тому, что ни кубднс ни корднс не могут резолвить некоторые имена, у кого-то вообще сеть может не подняться, у кого-то кубпрокси ломается, глубже пока не знаю, буду разбираться, но совет может кому-то сэкономить кучу времени, если у него беда с днс и нет возможности использовать гугловские публичные адреса. Полностью это пофиксили от 1.13.2 и выше. В остальных версиях это может проявляться из коробки прямо сразу после установки кубспреем начиная с версий 2.6 и заканчивая 2.8.3. Чтобы отловить такой баг, который завязан сразу на столько условий мне нужно много времени.

Мне кажется это давняя тема, уже несколько раз здесь обсуждалась даже

Pavel

Есть несколько issue не гитхабе, вроде все закрыты

Pavel

Но надо обновляться, это да)

Eugene

Есть несколько issue не гитхабе, вроде все закрыты

ага закрыты после таких сложных решений как Well, I switched the cluster back to the default (iptables) mode, appears to be pretty stable since then...

Eugene

Мне кажется это давняя тема, уже несколько раз здесь обсуждалась даже

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

Pavel

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

Тут у многих проблемы были, можно просто в поиске глянуть.

Eugene

Тут у многих проблемы были, можно просто в поиске глянуть.

Я смотрел, на похожие вопросы ответов либо совсем не было, либо они никак не наводили на мысли об ipvs

Pavel

UDP в кубенях - это боль https://github.com/kubernetes/kubernetes/issues/71514

Ну вот, например

Andrey

Ну вот, например

Решаемо

Eugene

Ну вот, например

а теперь попробуй связать вот эту беду с этой ошибкой: 1 aws_manager.go:153] Failed to regenerate ASG cache: RequestError: send request failed caused by: Post https://autoscaling.us-east-2.amazonaws.com/: dial tcp: i/o timeout F0402 13:04:29.059069 1 cloud_provider_builder.go:149] Failed to create AWS Manager: RequestError: send request failed caused by: Post https://autoscaling.us-east-2.amazonaws.com/: dial tcp: i/o timeout

Eugene

Ну вот, например

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

Михаил

было?

Михаил

Выкладывали новый сервис в kubernetes, сломали три шаблонизатора.

Dmitriy

Ребят, где можно почитать понятную информацию про то, как добавить еще 1 мастера в уже существующий сконфигурированный кластер (есть 3 мастера, нужно добавить еще 2)?

Rainbow

Ребят, где можно почитать понятную информацию про то, как добавить еще 1 мастера в уже существующий сконфигурированный кластер (есть 3 мастера, нужно добавить еще 2)?

kubeadm join ...?*

Dmitriy

kubeadm join ...?*

Это работает до того момента пока не произошел init с конфигом для kubeadm, т.е. если изначально кластер конфигурировать Если новые мастер ноды небыли там прописаны, то простым join уже не присоединить

Artem

Кто знает, Ingress Nginx позволяет TCP порты пробрасывать к сервисам? Или только http/https ?

Andor

А в документации что про это написано?

Rainbow

Это работает до того момента пока не произошел init с конфигом для kubeadm, т.е. если изначально кластер конфигурировать Если новые мастер ноды небыли там прописаны, то простым join уже не присоединить

т.е. --experimental-control-plane не работает?

Solyar

Кто знает, Ingress Nginx позволяет TCP порты пробрасывать к сервисам? Или только http/https ?

+

Solyar

port: targetPort:

Solyar

В ингрессе указывай

Solyar

либо я не понял вопроса)

Artem

либо я не понял вопроса)

есть сервис, который поднимает ТСП порт и ждет сетевые подключения. Можно ли его через Ингресс опубликовать наружу кластера?

Artem

или только через NodePort?

Andor

есть сервис, который поднимает ТСП порт и ждет сетевые подключения. Можно ли его через Ингресс опубликовать наружу кластера?

А в документации что про это сказано?

Artem

кластер на голом железе

Rainbow

есть сервис, который поднимает ТСП порт и ждет сетевые подключения. Можно ли его через Ингресс опубликовать наружу кластера?

можно, но не нужно. Хочется балансировки?

Artem

да

Andor

можно, но не нужно. Хочется балансировки?

Не спойлери

Rainbow

nginx поддерживает stream tcp https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md

Andor

Ну слыш

Artem

А в документации что про это сказано?

https://kubernetes.io/docs/concepts/services-networking/ingress/ в этой только про http пишут

Rainbow

Ну слыш

я пока в доках ingress не увидел, не знал что он умеет

Andor

Там более одной страницы документация

Rainbow

NodePort тоже если что балансит

Andrew

Смотрю вы тут ингрессы обсуждаете, прорекламирую тут статью... https://habr.com/ru/company/flant/blog/447180/ Может полезно будет :)

Dmitriy

т.е. --experimental-control-plane не работает?

Нет, команда просто висит и отваливается по таймауту (сертификаты с первой мастер ноды скопировал на текущий хост, который нужно подключить в кластер)

Artem

NodePort тоже если что балансит

но для того, чтобы было HA надо по-хорошему, еще внешний балансировщик поставить, который будет чекать этот порт на всех нодах кластера

Rainbow

Нет, команда просто висит и отваливается по таймауту (сертификаты с первой мастер ноды скопировал на текущий хост, который нужно подключить в кластер)

docker ps docker logs там будет видно почему

Rainbow

но для того, чтобы было HA надо по-хорошему, еще внешний балансировщик поставить, который будет чекать этот порт на всех нодах кластера

точно так же как nginx-ingress и не обязательно. Можно перекидывать публичный ip через bgp или ещё что