Pull to refresh

Comments 18

Примечание: Вот почему вам нужно как минимум два узла - потому что неправильно иметь кластер, в котором один узел одновременно выполняет функции мастера и воркера.

очень спорно. Если очень хочется, то можно и так.

@DeepFakescovery+1

Согласен, что очень спорная фраза про два узла: например Red Hat CodeReady Containers это будет прямо у вас компьютере/ноутбуке кластер openshift без дополнительных worker. Главное, чтобы ресурсов хватало.

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-кейсы часто игнорируются?

должен, но если он рестартанулся по любой причине - упс, кранты.

Вот это да. Спасибо, что предупредили

Only those users with full accounts are able to leave comments. Log in, please.