Тип значений для value должен быть строго строкой, как оказалось)

теперь бери эти два файла: https://gist.github.com/Bregor/7079efc9b12e70e583e4847ed5ec7e91

и клади их в /etc/kubernetes/addons/ на мастере

в сервисе айпишник поменяй только

а в rc yaml на yml

:))

спасибо

уже меняю

чёт не подхватывается

попробую kubectl apply

kube-system kube-dns-v19-zcwxw 0/3 Pending 0 34s повисев так секунд 40 пропало из списка

гляну логи

а евенты ты больше не смотришь?

kube-system 1m 1m 3 kube-dns-v19-zcwxw Pod Warning FailedScheduling {default-scheduler } pod (kube-dns-v19-zcwxw) failed to fit in any node fit failure on node (10.91.119.199): MatchNodeSelector fit failure on node (10.91.119.197): MatchNodeSelector fit failure on node (10.91.119.198): MatchNodeSelector

я это и имел ввиду)

https://gist.github.com/Bregor/7079efc9b12e70e583e4847ed5ec7e91#file-dns-rc-yaml-L22-L23

можешь убрать эти строчки

а можешь лейбл на ноду повесить

kubectl label nodes 10.91.119.197 kube-role=master

если нода отвалится - DNS пропадёт?

если мастер-нода отвалится - все пропадет

fail-over 80lvl :)

failover пишется в одно слово

я люблю иногда разделять большие слова против правил :) чтобы сделать акцент на каких-то частях

вот реально, проскроллив то, что тут обсуждается, триджы подумаешь, а нужно ли тебе внедрять Kubernetes или лучше пока отложить эти планы... 😀

да да, давайте те кто в проде юзает давно - расскажите есть ли смысл

контейнеры нужны - тут я согласен, а вот именно облако...

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

сделать контейнеры достаточно просто, это не требует больших усилий, доставить (через Docker Hub) и запустить контейнеры (через systemd) тоже просто, а вот с Kubernetes (облако, когда серверы взаимодействуют друг с другом как единый организм) есть много вопросов

не проще же ли , например, просто пара внешних балансировщиков и несколько серверов, не в облаке?

ну мне пока кажется что кубернетес это не замена серверов/vps и всего такого, это именно оркестрация минимальных юнитов в роли которых выступают контейнеры (и они не постоянные единицы а что-то что может удаляться и создаваться без ограничений)

было бы интересно узнать , какие преимущества у Kubernetes против вот обычного подхода, когда балансировщик + несколько серверов + контейнеры через systemd-сервисы на каждом

да, я понимаю, но вообще, насколько эта оркестрация нужна?

мне , по идее, нужно просто запустить все контейнеры на всех серверах

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

например, неделю назад мой провайдер (гугль) полностью развалил сегмент в котором были инстансы в которых обслуживался продакшн то есть до этого я думал что моя система более-менее устойчива к форс-мажорам теперь понимаю что надо настраивать балансировку контейнеров между разными датацентрами и прописывать affinity соотвествующее поэтому стал к kubernetes присматривться как к решению данной проблемы без найма отдельной команды инженеров

но так как я это только начал делать - хз правильно иду или нет, и хотелось бы услышать мнение чуваков у которых в продакшне давно это запущено, на начальный вопрос :)

ну, я вижу это всё как: есть домен проекта, он прикручен к Route53, к которому прикручены 2 балансировщика и там на Route53 сделаны хелфчеки этих балансировщиков... а на каждом балансировщике - уже пути до всех серверов во всех дц

в итоге нам просто надо на всех серверах запустить контейнеры со статикой/кодом/базой , если сервер не отвечает или код ответа неверный - он автоматически перебрасывает запрос на другой сервер согласно весам

в итоге вроде как продвинутая оркестрация и не нужна

ну, может, я в чём-то ошибаюсь, Kubernetes мне в целом интересен, но больше "для галочки", я пока не понимаю, какую проблему он тут решает и в чём его фишка

вот в примере выше и без него всё вроде нормально

Kubernetes прекрасен по концепции, особенно, если мы возьмем большое микросервисное приложение. Без K8s или чего-то подобного никак. Это уровень абстракции, который позволяет связывать контейнеры, а также делать легкое горизонтальное масштабирование любого из звена.)

Плюс разные другие плюшки

то есть если проблем со связыванием и масштабированием нет (все сервисы запускаются на всех серверах), то k8s не нужен?

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

то есть если на сервере А сервисом XYZ занят порт 1234, то и на всех других серверах никто этот порт не займёт

а можешь лейбл на ноду повесить

Не работает почему-то, на какое-то время появляется kube-dns-v19, весит секунд 30-40 в ожидании чуда и показывая 2/3, потом пропадает. При этом kubectl get ev возвращает ничего по сути: kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod Normal Scheduled {default-scheduler } Successfully assigned kube-dns-v19-y82n0 to 10.91.119.197 kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{kubedns} Normal Started {kubelet 10.91.119.197} Started container with docker id 73a3ad486923 kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{dnsmasq} Normal Started {kubelet 10.91.119.197} Started container with docker id 02ac5f624dbe kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{healthz} Normal Started {kubelet 10.91.119.197} Started container with docker id 7f38358d77f2 kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{dnsmasq} Normal Killing {kubelet 10.91.119.197} Killing container with docker id 02ac5f624dbe: Need to kill pod. kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{healthz} Normal Killing {kubelet 10.91.119.197} Killing container with docker id 7f38358d77f2: Need to kill pod. kube-system 2m 2m 1 kube-dns-v19-y82n0 Pod spec.containers{kubedns} Normal Killing

то есть если проблем со связыванием и масштабированием нет (все сервисы запускаются на всех серверах), то k8s не нужен?

А что ты будешь делать, когда упрешься в ресурсы?)

заменю материнские платы на двухсокетные с процессорами 2699v4

ну или ещё серверов докупить - и в балансировщике добавить записей

то есть на каждый сервер будет идти меньше трафика

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

У нас есть сервис, который очень тяжелый, по сути - один сервис = один сервер. Таких серверов 100+ и между ними балансируется трафик в зависимости от текущей нагрузки. Но это очень специфичный сервис. :)

но на каждом будут запущены все контейнеры

ну, просто, что значит запустить контейнер - это выделить ему оперативку

и как бы всё

если на него трафик не идёт - ресурсов процессора он не ест

а оперативки можно поставить много

Вот пример описание доступных ресурсов для контейнера: resources: # keep request = limit to keep this container in guaranteed class limits: cpu: 10m memory: 50Mi requests: cpu: 10m # Note that this container shouldn't really need 50Mi of memory. The # limits are set higher than expected pending investigation on #29688. # The extra memory was stolen from the kubedns container to keep the # net memory requested by the pod constant. memory: 50Mi

так эти ограничения можно ставить прямо в .service-файле

для этого k8s не нужен

systemd поддерживает все ограничения

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

но можно просто на всех серверах запускать всё

и тогда сэкономим силы на установку и поддержку k8s

а в качестве платы - придётся потерять немного оперативки

то есть даже если контейнер не нужен - он там будет висеть, отнимать какую-то память

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

у модулей памяти 32Гб хорошее соотношение $/Gb, значит, получится 32*24=768Gb на сервер

этого ведь должно хватить даже если все сервисы запустить

ну, а с балансировщика управляем трафиком на серверы

в общем, мне нравится Kubernetes, но с позиции Keep It Simple, мне кажется, что было бы проще все сервисы запускать на всех нодах (а слабые ноды вообще убрать ), а трафиком управлять с балансировщика... хотелось бы услышать какие-то аргументы, почему я не прав и передумать, но я их пока не слышу...

Вот нашёл наконец-то FAQ :) http://kubernetes.io/docs/user-guide/application-troubleshooting/

http://www.kubernetes.live/

Разворачиваю приложение. Возникла ошибка при деплое ingress: The Service "nginx-controller" is invalid. spec.ports[0].nodePort: Invalid value: 80: provided port is not in the valid range Максим, а ты не указывал service-node-port-range для apiserver?

А зачем тебе nodePort?

Ещё и такой низкий?

Ingress, nginx, проксирование доменов на поды)

Включая переадресацию на Https )

так а nodePort зачем?