Добрый день, а etcd у всех матюкается на heartbeat, что не может за 100ms получить ответ? Вчера попробовал увеличить интервал на одном из, он после этого не захотел вставать в кластер обратно, да и сам кластер загрустил, пришлось вернуть.Кто как лечил медленный etcd? У меня 3.1.5 сейчас кластер всего из трех и нагрузка не сказать чтобы большая, единственное диски неторопливые

etcd должен быть 3.2.15 , там кучу всего чинили

Спасибо попробую, там апгрейд без боли?

Но это прямо очень рискнуть, а есть предположения почему ей нужно при объеме бд в 20 метров такие излишества?) Может в 3.3 или где-то они уже поработали над оптимизацией?)

На 3.2.11 если в while-sleep-5sec вызывать kubectl get cs , то с большой вероятностью можно поймать 503 от API, типа я развалилось.

Так как ssd у меня под etcd не предвидится заход с другой стороны) ингресс контроллер периодически релоадит конфиг и при этом опрашивает api сервер про endpoint ы и если ему апи в этот момент не отвечает так как ему в свою очередь не отвечает etcd нгинкс со спокойной совестью выставляет бэкенд в 404, он правда относительно быстро восстанавливается, но сам факт, можно как-то изменить его поведение? Чтобы если не получил ответа к примеру оставил старые бэкенды?

Нужно смотреть как работает ингрес контроллер и поправить код, мы так для траефика делали

просвятите как при Load Balancer сохраняется Client IP

Кажется единственный способ сохранить ClientIP это иметь на Load Balancer ssl-терминатор и какой-нибудь http reverse-proxy

ингресс фактически

просвятите как при Load Balancer сохраняется Client IP

обычно так https://en.wikipedia.org/wiki/X-Forwarded-For

Ещё можно оставлять клиентский адрес в заголовках IP, тогда для конечного сервера не будет разницы за LB он или нет. Но это требует особой настройки сети.

обычно так https://en.wikipedia.org/wiki/X-Forwarded-For

Ну это уже http, значит на LB должен быть ssl-терминатор, и сразу же полезет вопрос как из kebernetes с каким-нибудь kube-lego доставать ssl-сертификаты. Я просто в качестве LB поставил linux с iptables с форвардингом портов, и соответсвенно имею что все запросы у меня идут от LB.

Ещё можно оставлять клиентский адрес в заголовках IP, тогда для конечного сервера не будет разницы за LB он или нет. Но это требует особой настройки сети.

вот это интересно как сделать своими руками

Ну это уже http, значит на LB должен быть ssl-терминатор, и сразу же полезет вопрос как из kebernetes с каким-нибудь kube-lego доставать ssl-сертификаты. Я просто в качестве LB поставил linux с iptables с форвардингом портов, и соответсвенно имею что все запросы у меня идут от LB.

это сложный вопрос, тут не подскажу

вот это интересно как сделать своими руками

зависит от окружения. В облаке типа AWS это может даже сделать не получится. В своей сети можно попробовать ipvs - он так умеет

но это не тривиально, надо документацию читать

чет по ipvs мало информации и по этой фиче в частности

чет по ipvs мало информации и по этой фиче в частности

вот один из вариантов

http://www.linuxvirtualserver.org/VS-DRouting.html

Direct Routing не вариант

"Piranha has been replaced in RHEL7 with HAProxy and keepalived"

Direct Routing не вариант

почему? Если веб сервер видит в source IP адрес клиента, он туда обратно и пошлёт, а это и есть direct routing

если вам надо, чтоб весь траффик ходил через LB, ставьте его как default gateway на web сервере

вот то что мне надо https://serverfault.com/questions/867864/how-to-forward-clients-ip-address-to-nginx-from-haproxy-in-tcp-mode

то есть моя задача научить ingress понимать send-proxy

а оно есть из коробки https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/examples/proxy-protocol/nginx-configmap.yaml

супер

не пойму только нужно ли что-то делать если proxy-protocol нужно протащить через несколько firewall

вот то что мне надо https://serverfault.com/questions/867864/how-to-forward-clients-ip-address-to-nginx-from-haproxy-in-tcp-mode

круто, спасибо, что поделились.

не пойму только нужно ли что-то делать если proxy-protocol нужно протащить через несколько firewall

Судя по документации, в промежуточных узлах ничего делать не надо

https://github.com/kubernetes/ingress-nginx/issues/909

Еще раз подыму вопрос. Кто какой техникой пользуется для выстраивания зависимостей старта контейнеров

ну типо вначале база, потом один сервис, потом другой

Я сейчас с кубером вообще не работаю, но в свое время просто пришли к тому, что нужно писать так, чтобы приложение свободно работало и без базы/других сервисов, просто возвращало бы негативный readiness check и постоянно опрашивало днс на предмет появления сервиса.

если дождаться просто порядка выката то покатят тупые варианты с getent ahostsv4 или nc на порт.

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

а как кто добавляет healthz на легаси, например postgesql

Tcp port или cli command

Еще раз подыму вопрос. Кто какой техникой пользуется для выстраивания зависимостей старта контейнеров

Как уже писали nc на порт в entry point, но чтобы например юзать официальный контейнер и не пересобирать свой для каждой новой версии вордпресса или чего там можно это делать в инит контейнере или сайдкаре

Коллеги, приветствую. Только изучаю kubernetes, строим production окружение, не взлетает prometheus. А именно - получаем server returned 401 Unathorized. Сначала думалось, что это RBAC, но все же выяснили, что проблема кроется в сертификате. Кластер разворачивали через kubespray. При попытке через curl обратиться к endpoint с сертификатом ca.pem получаем ошибку curl: (35) error reading X.509 key or certificate file: Error in parsing, но собрали cat ca.pem ca-key.pem в bundle и curl уже получает положительный ответ. Prometheus же не дает заменить ca.pem, в secret - т.к. постоянно пересоздает этот secret. В гуглениях предлагают "отключить" ServiceMonitor(чтобы secret больше не пересоздавался), но пока нет полного понимания - за что еще отвечает ServiceMonitor кроме пересоздания конфигураций и какие могут быть последствия. Кто сталкивался с чем-то подобным?

Посути надо изменить поведение ServiceMonitor'a(если конечно я правильно понял его задачу) чтобы он в secret ca.crt брал комбинацию файлов и все должно заработать

Никаких кастомных настроек не делалось, просто kubespray и далее prometheus через helm со stable ветки

а результат такой

Vladislav рекомендую развернуть все самостоятельно, что бы понять как компоненты k8s связанны между собой - https://github.com/kelseyhightower/kubernetes-the-hard-way . А уже потом автоматизировать процесс с помощью kubespray.

Всем привет. Никто не сталкивался с проблемой kube-dns/coredns. Если послать запрос на несуществующий домен, то dns перестает после этого нормально работать. Как я понимаю какой-то сервис k8s делает retry и флудит dns server

Всем привет. Никто не сталкивался с проблемой kube-dns/coredns. Если послать запрос на несуществующий домен, то dns перестает после этого нормально работать. Как я понимаю какой-то сервис k8s делает retry и флудит dns server

Перед ним же dnsmasq обычно, который сам резолвит все внешние адреса. Или вы несуществующий внутренний пробуете?

Перед ним же dnsmasq обычно, который сам резолвит все внешние адреса. Или вы несуществующий внутренний пробуете?

в случае kube-dns, да там dnsmasq. Несуществующий адрес это лишь быстрый способ воспроизвести это поведение. Флуд начинается как только dns не может отрезолвить имя. Проблему решает лишь рестарт dns

Проблема была в не существуюущем резолвере. Если текущий dns сервер не смог отрезолвить имя, то он отправит следующему (proxy в core-dns), а так как он не мог до него достучаться, то пробовал снова и снова. Это как я понял

Господа GKE-воды, я вот читаю https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer и пытаюсь понять, откуда в этом туториале возьмется Ingress Controller? Отдельно самому нужно впиливать?

Господа GKE-воды, я вот читаю https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer и пытаюсь понять, откуда в этом туториале возьмется Ingress Controller? Отдельно самому нужно впиливать?

ingress-controller в вашем случае предоставляется GKE

Просто я-то ингресс создал, но не совсем понятно - куда направлять траффик в ДНС? Service типа LoadBalancer (как в случае с nginx-ingress-controller) - нету, соответственно не могу привязать ДНС к этому LB. И еще, сервисы обязательно должны быть типа NodePort чтобы оно взлетело?

Всем привет! Кто настраивал limit-rps и limit-connection для nginx-ingress, подскажите, пожалуйста, как вы учитывали тот факт что несколько пользователей с одного могут заходить с одного ip?

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/annotations.md#rate-limiting этим штукам юзеры пофиг

per ip же

Hi folks

per ip же

Вот да, поэтому и спрашиваю. Например вы прикинули что один юзер делает не более X запросов в секунду и имеет не более Y одновременных соединений. Как вы скейлите эти X и Y для случая нескольких юзеров с одного IP?

с запасом =)

ребята я заблудился? как pvc находит pv ?

а то магия какая то

я ведь даже не указал имя pv а pvc нашел его

по требованиям, указанным в pvc, включая storage class

я не указывал класс

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

тогда он имеет право взять любой

ясненько ну спасибо

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#binding все есть в доках

с запасом =)

А вот с каким запасом? Может есть какой-нибудь подход чтобы определить?

ну эт такой ddos mitigation на коленке. это сложный диванно теоретический вопрос

потому что потом начинаются вопросы, как вот считать коннекты на всех веб серверах

тогда он имеет право взять любой

Любой свободный с default storage class.

В какой сторадж лучше всего писать базы данных? Где sla и скорости будут повыше?

в наиболее надежном и быстром?

что за навязчивая идея совать базы данных в кубер?

Вот да, поэтому и спрашиваю. Например вы прикинули что один юзер делает не более X запросов в секунду и имеет не более Y одновременных соединений. Как вы скейлите эти X и Y для случая нескольких юзеров с одного IP?

у nginx есть возможность лимитировать в рамках location, perip и perserver.

что за навязчивая идея совать базы данных в кубер?

А в чем проблема?

проблема в утилитах для этих самый баз данных, которые про кубер ничего не знают

а им нужно?

нередко бывает, что нужно

сходить в сторейж, что-то потрогать в файлах

дык это разве нельзя сделать в поде с привязанным volume?

а нафиг тогда вообще кубер, если всё будет друг к другу привязано?