опять запускаешь что то, что непонятно как конфигурируется и неизвестно какое состояние имеет

Почему непонятно и неизвестно?

Ваще если конфиг никогда во время жизни приложения не меняется, то конфигмапы ок

Почему непонятно и неизвестно?

потому что конфиг это внешняя сущность получается. не ясно состояние конфига, он зависит от времени запуска или от момента перечитывания конфига. я хз как такие динамические варианты с конфигурированием ПО решаются. железный вариант - изменился конфиг - ты или ролллинг апдейт сделал, или форсил релод приложения. и ты видишь в состоянии аппа какой у него конфиг

Ваще если конфиг никогда во время жизни приложения не меняется, то конфигмапы ок

Именно, если приложение поддерживает динамическую конфигурацию и фактически запрашивает значения и во время работы по определенной бизнес логике, то etcd/consul/zookeper вполне ок.

Конфигмап выглядит куда лучше. Хотя я пока и не до конца понимаю

Я вот не понял, если у тебя всё запскается через ansible, и ты в нём максимально используешь enventory, то почему бы тебе не генерить на лету yaml файл из темплейта посредством envsubst и транслировать его напрямую в kubectl create/apply -f - ? Зачем ещё конфигматы городить?

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

потому что конфиг это внешняя сущность получается. не ясно состояние конфига, он зависит от времени запуска или от момента перечитывания конфига. я хз как такие динамические варианты с конфигурированием ПО решаются. железный вариант - изменился конфиг - ты или ролллинг апдейт сделал, или форсил релод приложения. и ты видишь в состоянии аппа какой у него конфиг

В нашем случае конфиг статический и меняется сильно редко. Дергаем при старте из сервиса и сохраняем внутри контейнера.

А чем не нравится текущий подход, ну не считая, что это велосипед?

Я вот не понял, если у тебя всё запскается через ansible, и ты в нём максимально используешь enventory, то почему бы тебе не генерить на лету yaml файл из темплейта посредством envsubst и транслировать его напрямую в kubectl create/apply -f - ? Зачем ещё конфигматы городить?

У меня ансибль только для дева/стейджа. Локально в офисе для бареметал. В AWS там ансибля нет.

Резюмирую: "env legacy, потому что в нашем случае конфиг статический"

У меня ансибль только для дева/стейджа. Локально в офисе для бареметал. В AWS там ансибля нет.

но какой-то CD же есть?

А чем не нравится текущий подход, ну не считая, что это велосипед?

Да я не говорил, что он мне не нравится. Смущает - да.

но какой-то CD же есть?

Есть

А что смущает?

на нём можно тоже самое сделать

В проде пока нет куба. Строю в деве и хочу сделать более-менее правильно.

А что смущает?

Безопасность (относительная простота доступа к конфигам).

Ладно. Спасибо всем за дискуссию. Довольно не мало вариантов накидали. Буду думать и читать. :)

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

2 или 3

Я подниму снова вопрос, т.к. он затерялся немного в предыдущей дискуссии. И так, каким образом размещать бд сервиса в кубернетес: в одном поде с сервисом, в разных подах, за кубами (т.е. непосредственно на сервере)?

В одном сете одназначно хранить не стоит

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

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

Ребят, на сколько я знаю, кол-во серверов etcd изменить не выйдет, верно? Хотелось бы добавить мастеров в других локациях… А переносить текущие, тоже не очень весело

Ребят, на сколько я знаю, кол-во серверов etcd изменить не выйдет, верно? Хотелось бы добавить мастеров в других локациях… А переносить текущие, тоже не очень весело

с чего это не выйдет?

по документации etcd добавляешь ноды

etcd разве умеет в мультимастер?

только вот зачем их в другие локации уносить?

что значит добавить мастеров?

etcd разве умеет в мультимастер?

лидер всегда один

лидер всегда один

так и я о том

что значит добавить мастеров?

вангую, что мастер-ноды совмещены с etcd-нодами

только вот зачем их в другие локации уносить?

Затем что после недавнего падения hetzner пришлось ручками consul’у говорить кто там главный. Ибо большая часть кластера оказалась там.

вангую, что мастер-ноды совмещены с etcd-нодами

Да, kubespray ем разворачивал. Правда там пока ничего особо нет и крутится в тестовом режиме, но накатывать заново - тоже время

Да, kubespray ем разворачивал. Правда там пока ничего особо нет и крутится в тестовом режиме, но накатывать заново - тоже время

он не очень-то бережно с etcd обращается. в мастер недавно кучу фиксов слили насчет этого. имеет смысл обновиться.

Спасибо за инфу. Ну dev обновил, с ним всё ок было.

Вообще, лично я планирую уходить от kubespray в сторону своего ансибловелосипеда. Кубспрей тот еще черный ящик, особенно при обновлениях, имхо.

сейчас через kubeadm кластер весьма просто разворачивается, зачем какой-то kuberspray?

Это раньше приходилось городить плэйбуки которые раскидывают бинари, конфиги, все эти дела.

И еще момент, никто не извращался так: нужно поднять еще один кластер монги, есть мысль добавить worker ноды и на них не через куб поставить монгу. Профит - легко подключить к мониторингу, минусы …?

kubeadm уже умеет мультимастер поднимать?

kubeadm уже умеет мультимастер поднимать?

пол года назад когда я смотрел это было в бэтке

сейчас через kubeadm кластер весьма просто разворачивается, зачем какой-то kuberspray?

+ за kubespray - поддержка coreos

если не ошибаюсь

kubeadm уже умеет мультимастер поднимать?

https://kubernetes.io/docs/setup/independent/high-availability/

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

тут его не любят, пиши в группу докера)

тут его не любят, пиши в группу докера)

скинь группу, плз)

скинь группу, плз)

В описании есть

В описании есть

спс

В описании есть

а она существует, та что в описании?

а она существует, та что в описании?

Ага

ого, я там забанен чтоли)) спасибо

пол года назад когда я смотрел это было в бэтке

С напильником.

Коллеги, добрый день. Есть такой архитектурный вопрос. Изучаю микросервисы, пытаюсь понять, как их правильно организовать. Стек простой: golang+cockroachdb. Итого у меня есть три варианта: 1) Контейнер приложения и контейнер базы лежат в одном поде внутри стейтфул-сета. 2) приложение и база в разных подах, база в стейтфул-сете, у базы отдельно есть балансировщик. 3) базу вообще вынести из кубов. Как организовать все кошерно/феншуйно?

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

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

edit или apply -f не канает?

Имеется в виду ситуация, когда deployment потребляет конфиг, конфиг меняется, а deployment (точнее, поды) нужно передёргивать руками

господа а что configmap чтобы обновить надо delete/create? более вменяемых способов нет?

рализовать в приложении перечитывание конфигов при их изменении

рализовать в приложении перечитывание конфигов при их изменении

или взять хельм

А хельм магический апи кубера использует?

кажется только обычный вариант 😆

Кто пользовался docker swarm? На каких юз кейсах он предпочтительнее чем Kubernetes?

Ни на каких. Говоря, т.к. имею его в проде. Наколенное поделие

что 12 факторов говорят про стораджа? :)

Хорошо накинул

а можно ли прикрутить s3 bucket как shared storage?

minio?

а можно ли прикрутить s3 bucket как shared storage?

крайне не рекомендуется

хотя извращенцы находились

а что посоветуете?

BMR?

если да - ceph или локальное хранилище если нет - используйте решение вашего провайдера (Amazon EBS/Google storage)

cпасибо

Warning FailedCreatePodSandBox 2m (x8 over 2m) kubelet, gke-crypto-ai-cluster-pool-1-f0f1c05e-v267 Failed create pod sandbox. Warning FailedSync 2m (x8 over 2m) kubelet, gke-crypto-ai-cluster-pool-1-f0f1c05e-v267 Error syncing pod Normal SandboxChanged 2m (x8 over 2m) kubelet, gke-crypto-ai-cluster-pool-1-f0f1c05e-v267 Pod sandbox changed, it will be killed and re-created. как это исправлять? все же нормально было, всего-то поменял ноды через админу GKE, раньше тоже менял и все было ок

Народ, странная ситуация: я только что обнаружил, что резолвинг dns не работает из подов. Проверил первым делом, что kube-dns запущен: kuber@kube-master:~$ kubectl get svc —namespace=kube-system | grep dns kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 19d Убедился, что запущен по всем нодам (их три): kuber@kube-master:~$ kubectl get pods —namespace=kube-system -l k8s-app=kube-dns | grep dns kube-dns-86f4d74b45-bzp88 3/3 Running 1 19d Запустил busybox, проверяю, получается вот что: kuber@kube-master:~$ kubectl exec -ti busybox — nslookup kubernetes.default Server: 10.96.0.10 Address 1: 10.96.0.10 nslookup: can't resolve 'kubernetes.default' Пока смотрю в сторону iptables. Но может есть другие соображения? Буду очень признателен за любую подсказку, давно бьюсь.

При этом я точно вижу, что 10.96.0.10 доступен с мастера, но не доступен с других нод. kube-master:~$ dig @10.96.0.10 google.com +short 64.233.162.102 ... kube-node2:~$ dig @10.96.0.10 google.com +short ; «» DiG 9.10.3-P4-Ubuntu «» @10.96.0.10 google.com +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached

iptables-save |grep *servicename* что выдает?

iptables-save |grep *servicename* что выдает?

ничего, ни на одной из нод-миньонов, ни по одному из сервисов

ни по одному из моих сервисов. может быть вопрос был о сервисе kube-dns?

у кого-нибудь XFF работает нормально в связке traefik ingress lb + metallb? или у меня весьма экзотическая инсталляция?)

kube-node2:~# iptables-save | grep kube-dns -A KUBE-SEP-IWJI6C47NUOQRVJI -s 192.168.221.203/32 -m comment —comment "kube-system/kube-dns:dns-tcp" -j KUBE-MARK-MASQ -A KUBE-SEP-IWJI6C47NUOQRVJI -p tcp -m comment —comment "kube-system/kube-dns:dns-tcp" -m tcp -j DNAT —to-destination 192.168.221.203:53 -A KUBE-SEP-WJKWNDNHZFTML3HV -s 192.168.221.203/32 -m comment —comment "kube-system/kube-dns:dns" -j KUBE-MARK-MASQ -A KUBE-SEP-WJKWNDNHZFTML3HV -p udp -m comment —comment "kube-system/kube-dns:dns" -m udp -j DNAT —to-destination 192.168.221.203:53 -A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.96.0.10/32 -p udp -m comment —comment "kube-system/kube-dns:dns cluster IP" -m udp —dport 53 -j KUBE-MARK-MASQ -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment —comment "kube-system/kube-dns:dns cluster IP" -m udp —dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU -A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.96.0.10/32 -p tcp -m comment —comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp —dport 53 -j KUBE-MARK-MASQ -A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment —comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp —dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 -A KUBE-SVC-ERIFXISQEP7F7OF4 -m comment —comment "kube-system/kube-dns:dns-tcp" -j KUBE-SEP-IWJI6C47NUOQRVJI -A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment —comment "kube-system/kube-dns:dns" -j KUBE-SEP-WJKWNDNHZFTML3HV