Решил схемку нарисовать, т.к. все равно коллегам объяснять еще.

инженерам ещё стоит качать навык "уметь продать решение", а не плакать, что их не слушают

Стоп, а етсд как-то отдельно резервировать для НА надо?

предлагаю етцд убрать из схемы :)

не, он важен, т.к. по умолчанию api-server стучится в 127.0.0.1:2379, то есть если etcd умрет, умрет и связанный с ним api-server

Hi. helm install --name postgres-cluster Chart.yaml --namespace database выдает Error: gzip: invalid header. не подскажете, в чем проблема?

а в аписервер нельзя сказать что "вот тебе список адресов где должен быть етцд"?

а в аписервер нельзя сказать что "вот тебе список адресов где должен быть етцд"?

ну у тебя и так будет весело, когда два из трёх умрут

звучит как кластер consul

угу, но падение одного переживет, так что все же чуть-чуть лучше

ну в схеме "подключаемся в локалхост" один упавший етцд = один упавший аписервер, а в том случае все аписервера на месте будут

да они одинаковые

haproxy поэтому и используют в k8s, что нет чего-то вроде агента consul на каждом хосте

толку с них не будет - etcd развален

чо такое "агент консул"?

https://learn.hashicorp.com/assets/images/vault-ref-arch-2.png

это ничего не объясняет

может не прав, не юзал консул никогда

два етцд живы, один сдох, все аписервера знают про всех и все живы

хмм, да, я совсем запутался. У нас disaster recovery и без локалхоста работал

Я описываю кейс stacked control plane как деплоит kubeadm по дефолту, он настраисает каждый api-server стучаться в локальный etcd

вот, теперь все правильно

А можно в этой схеме заменить haproxy на LVS?

хотя в кейсе с external etcd nodes, по умолчанию туда заносятся все endpoints https://kubernetes.io/docs/setup/independent/high-availability/#set-up-the-first-control-plane-node

да

Это keepalived

ну понятно, хелсчеки в keepalived, балансировка в ipvs

По какому принципу перебор идёт? Первый доступный?

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

Полагаю, потому kubeadm и настраивает api-server смотреть в локальный etcd, ибовсе равно запись не завершится пока не запишется хотябы на 2 из 3х etcd нод

Ребят, привет. Подскажите пожалуйста с чем может быть связано. Участились случаи когда кубер убивает поды с такими причинами: The node was low on resource: ephemeral-storage. и в messages: must evict pod(s) to reclaim ephe meral-storage На всех разделах свободно более 70% (порядка 60-80 gb), с инодами все нормально. Подскажите в какую сторону копать? Рантайм - крио 🙁

Ребят, привет. Подскажите пожалуйста с чем может быть связано. Участились случаи когда кубер убивает поды с такими причинами: The node was low on resource: ephemeral-storage. и в messages: must evict pod(s) to reclaim ephe meral-storage На всех разделах свободно более 70% (порядка 60-80 gb), с инодами все нормально. Подскажите в какую сторону копать? Рантайм - крио 🙁

А нет, там 10% и 15% для imagefs

не лишний ли тут keepalived ? Понятно зачем он нужен, но схема, когда у тебя на каждой ноде есть haproxy или envoy, которые знают про все apiserver-a - не сказал бы, что сильно менее надежна. Особенно учитывая, что keepalived могу и потерять друг друга и будут два VIP в сети

держи конфиг: frontend k8s-api bind 0.0.0.0:8443 bind 127.0.0.1:8443 mode tcp option tcplog default_backend k8s-api backend k8s-api mode tcp option tcplog option tcp-check balance roundrobin default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100 server k8s-api-1 192.168.0.147:6443 check server k8s-api-2 192.168.0.148:6443 check server k8s-api-3 192.168.0.149:6443 checkпри этом обращаться к api-server нужно будет через порт 8443, а не на 6443