Комментарии 18
а как скрыть посты из ленты с тэгом Блог компании OTUS ?
Примечание: Вот почему вам нужно как минимум два узла - потому что неправильно иметь кластер, в котором один узел одновременно выполняет функции мастера и воркера.
очень спорно. Если очень хочется, то можно и так.
Согласен, что очень спорная фраза про два узла: например Red Hat CodeReady Containers это будет прямо у вас компьютере/ноутбуке кластер openshift без дополнительных worker. Главное, чтобы ресурсов хватало.
А вообще если нужно high availability (ради которого часто и затевают пляски с кубером), то нод наоборот должно быть хотя бы 3 - один мастер и два воркера.
А вообще если нужно high availability (ради которого часто и затевают пляски с кубером), то нод наоборот должно быть хотя бы 3 - один мастер и два воркера.
и мы только что получили не отказоустойчивый контрол плейн кубернетеса. Тогда уж минимальная HA конфа - 3 мастера + 2 воркера (ну, или просто 3 мастера, они же - 3 воркера, если не разделять узлы по ролям).
Рабочая нагрузка обычно вполне может пережить кратковременную потерю контрол плейна, поэтому одна нода (если мы уж экономим) вполне допустима. При наличии бэкапов )
Искренне убеждён - бекапы как раз не нужны. Зачастую проще переналить кластер и нагрузку, при помощи плейбуков/терраформа и манифестов в гите, чем разбираться, что там внутри сломалось. Если же мы были достаточно упорные и смелые, чтобы засунуть в кубернетес стейтфул - тут, да, без бекапов уже никак.
Касательно "мастер отъехал - приклад работает"... знаете, с одной стороны Вы правы. Приложению внутри контейнера обычно до лампочки, что там в кубере происходит. Но в реальной жизни при отказе мастера штормит будь здоров. Ну, такой пример приведу. Нам же приложение нужно не абстрактно в вакууме? Нам нужно туда трафик доставлять как-то снаружи. Пускай это будет ингресс. А ингресс контроллер постоянно перечитывает свою конфигурацию из апи сервера. А он у нас лёг. А если вообще ингресс сложится - он не перезапустится, потому что мастера-то у нас отъехали. Вот и получается - если делать хорошо, то контролплейн тоже резервировать надо...
Трафик должен приходить на keepalived. Тогда не страшно будет выпадение мастер ноды из кластера.
никто так не делает, а keepalived должен сдохнуть ) по разным причинам, но это не лучшее решение для фейловера.
Интересны подробности, я совсем недавно узнал про метод с keepalived и он кажется очень хорошим, было бы интересно узнать почему это не так
потому что pacemaker умеет в кворум, а keepalived в случае двух узлов - хряс-пополам и оба мастера. Плюс keepalived требует VRRP, а он может быть заблокирован и все такое.
Ну, то что так никто не делает -- это, конечно, совсем не правда (https://github.com/kubernetes/kubeadm/blob/main/docs/ha-considerations.md#keepalived-and-haproxy), а против разлома пополам у keepalived вроде как настраивается приоритет каждой ноды, но за pacemaker спасибо, изучим чо это такое )
а против разлома пополам у keepalived вроде как настраивается приоритет каждой ноды
чем это поможет? опять обменяем отказоустойчивость непонятно на что?
это, конечно, совсем не правда (https://github.com/kubernetes/kubeadm/blob/main/docs/ha-considerations.md#keepalived-and-haproxy)
надо писать, что не "совсем не правда", а "не совсем (не) правда". Еще раз - я видел МНОГО ситуаций, когда VRRP заблокирован (облака, мак антиспуф, вмварь и все такое) - и поделом. Если же у Вас облако, то там есть полноценный FIP (floating ip) и задача - правильно им воспользоваться. Или воспользоваться внешним NLB/ALB. Если не облако, а просто виртуалки или баре метал - надо думать, но варианты есть. И я уверен, что практически ЛЮБОЙ другой вариант кроме keepalived/vrrp будет лучше. Ну, и та статья попросту устарела.
Оставьте VRRP роутерам и прочим сетевым штукам... не нужно его тащить в 21м веке.
Эмм, а разве ингресс при отсутствии коннекта до апи сервера не будет держать последнюю полученную конфигурацию? Или теоретически должен, но на практике такие edge-кейсы часто игнорируются? Ну и складывание ингресса в течение maintaince window на мастере выглядит маловероятным, но у вас тут явно побольше опыта, так что готов поверить на слово. Но в целом мне тут кажется - если делать хорошо, но инфра совсем маленькая, то лучше без кубера, либо брать managed решение у провайдеров, которые нормальный контрол плейн бесплатно дают (тот же digital ocean).
Насчет бэкапов согласен - в общем то хранение полного набора манифестов в репе я тоже как некоторый бэкап рассматриваю.
Но в целом мне тут кажется - если делать хорошо, но инфра совсем маленькая, то лучше без кубера, либо брать managed решение у провайдеров, которые нормальный контрол плейн бесплатно дают (тот же digital ocean).
к сожалению, "нормальный контрол плейн" - это не про Digital Ocean. Пруфы:
кто бы мог подумать - control plane у них был НЕ ОТКАЗОУСТОЙЧИВЫЙ, ЛОЛ. И либо плати еще денег, либо заказывай узлы на "про" плане.
И постоянно таймауты вида:
$ flux get all -A
NAMESPACE NAME READY MESSAGE REVISION SUSPENDED
flux-system gitrepository/flux-system True Fetched revision: main/2a29c4b82541d89e9fe1f42832d7ac6b04458e8b main/2a29c4b82541d89e9fe1f42832d7ac6b04458e8b False
NAMESPACE NAME READY MESSAGE REVISION SUSPENDED
flux-system helmrepository/hashicorp True Fetched revision: 77a05bde477ba03cd06c17ed2e528707c0880ee2 77a05bde477ba03cd06c17ed2e528707c0880ee2 False
flux-system helmrepository/ingress-nginx True Fetched revision: 0adf7e010498f3849f214cf3ff8aef347be087d5 0adf7e010498f3849f214cf3ff8aef347be087d5 False
flux-system helmrepository/istio True Fetched revision: b6cf9b2d57f0d3317cf080055cf79aa427175a49 b6cf9b2d57f0d3317cf080055cf79aa427175a49 False
flux-system helmrepository/jetstack True Fetched revision: f35ae09270eee331991e2257317cc58ebded3597 f35ae09270eee331991e2257317cc58ebded3597 False
flux-system helmrepository/metrics-server True Fetched revision: 9592e73435d317885082719af55387c63f959690 9592e73435d317885082719af55387c63f959690 False
flux-system helmrepository/minio True Fetched revision: baf796a7aaa7a5f6cc1783cf851a4e0fab059293 baf796a7aaa7a5f6cc1783cf851a4e0fab059293 False
flux-system helmrepository/scylla True Fetched revision: e25e22a1e6de6e2f85b2c7c1e5d76ce524d3436c e25e22a1e6de6e2f85b2c7c1e5d76ce524d3436c False
NAMESPACE NAME READY MESSAGE REVISION SUSPENDED
flux-system helmchart/flux-system-cert-manager True Fetched revision: v1.7.1 v1.7.1 False
flux-system helmchart/flux-system-ingress-nginx True Fetched revision: 4.0.16 4.0.16 False
flux-system helmchart/flux-system-metrics-server True Fetched revision: 3.7.0 3.7.0 False
flux-system helmchart/flux-system-minio-operator True Fetched revision: 4.3.7 4.3.7 False
flux-system helmchart/flux-system-scylla True Fetched revision: v1.7.1 v1.7.1 False
flux-system helmchart/flux-system-scylla-manager True Fetched revision: v1.7.1 v1.7.1 False
flux-system helmchart/flux-system-scylla-operator True Fetched revision: v1.7.1 v1.7.1 False
flux-system helmchart/flux-system-vault True Fetched revision: 0.19.0 0.19.0 False
I0205 10:04:10.678744 85888 request.go:665] Waited for 1.016862346s due to client-side throttling, not priority and fairness, request: GET:https://4cd588f6-0e4d-45bb-a5c5-473057f3dd25.k8s.ondigitalocean.com/apis/notification.toolkit.fluxcd.io/v1beta1?timeout=32s
NAMESPACE NAME READY MESSAGE REVISION SUSPENDED
flux-system helmrelease/cert-manager True Release reconciliation succeeded v1.7.1 False
flux-system helmrelease/ingress-nginx True Release reconciliation succeeded 4.0.16 False
flux-system helmrelease/metrics-server True Release reconciliation succeeded 3.7.0 False
flux-system helmrelease/minio-operator False upgrade retries exhausted 4.3.6 False
flux-system helmrelease/scylla True Release reconciliation succeeded v1.7.1 False
flux-system helmrelease/scylla-manager False upgrade retries exhausted v1.7.0 False
flux-system helmrelease/scylla-operator True Release reconciliation succeeded v1.7.1 False
flux-system helmrelease/vault True Release reconciliation succeeded 0.19.0 False
NAMESPACE NAME READY MESSAGE REVISION SUSPENDED
flux-system kustomization/flux-system Unknown reconciliation in progress main/2a29c4b82541d89e9fe1f42832d7ac6b04458e8b False
flux-system kustomization/knative-operator True Applied revision: main/63331701bab830e41c44994308ddc01aa6dee5aa main/63331701bab830e41c44994308ddc01aa6dee5aa False
мда... менеджед такой менеджед... после этого реально подумаешь - не накатить ли https://habr.com/ru/company/flant/blog/569840/
разве ингресс при отсутствии коннекта до апи сервера не будет держать последнюю полученную конфигурацию? Или теоретически должен, но на практике такие edge-кейсы часто игнорируются?
должен, но если он рестартанулся по любой причине - упс, кранты.
Just-in-Time Kubernetes: Руководство начинающим для понимания основных концепций Kubernetes