так

Было: env: - name: KUBECTL value: '/usr/local/bin/kubectl -—kubeconfig=/etc/kubernetes/kubeconfig.yml' - name: ADDON_CHECK_INTERVAL_SEC value: 10 Стало: env: - name: KUBECTL value: '/usr/local/bin/kubectl -—kubeconfig=/etc/kubernetes/kubeconfig.yml' - name: ADDON_CHECK_INTERVAL_SEC value: '10'

Тип значений для 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 - это ведь разбираться с тем, на каких серверах что запущено и как

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

ERROR: S client not available

и тогда сэкономим силы на установку и поддержку 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 зачем?

Для nginx-ingress-controller: + https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx ports: - containerPort: 80 - containerPort: 443 # we expose 8080 to access nginx stats in url /nginx-status # this is optional - containerPort: 8080 volumeMounts: - mountPath: /etc/nginx-ssl/dhparam name: dhparam-secret args: - /nginx-ingress-controller - --default-backend-service=ingress-controller/default-http-backend

а не, это фрагмент из RC nginx-ingress-lb

apiVersion: v1 kind: Service metadata: name: nginx-controller namespace: ingress-controller labels: k8s-app: nginx-ingress-lb spec: selector: k8s-app: nginx-ingress-lb ports: - name: http port: 80 targetPort: 80 nodePort: 80 protocol: TCP - name: https port: 443 targetPort: 443 nodePort: 443 protocol: TCP type: NodePort

Вот это сам конфиг сервиса

Который уже переадресует на RC nginx-ingress-lb

А есть ещё альтернативы, как обеспечить HTTPS + dhparam, форвард HTTP->HTTPS, роут разных URI на отдельный поды (/assets/*, /api/search/* и т.д.)?

если у тебя bare metal и ты хочешь экспозиться наружу, то это боль

я это решил "железным" nginx'ом, смотрящим в kube-dns

upstream kube-preview-app { server preview.apps.svc.kubernetes.local:8081; } server { server_name preview.amplifr.com; ... location / { ... proxy_pass http://kube-preview-app; } }

preview.apps.svc.kubernetes.local:8081 - это обычный сервис

всмысле ClusterIP

а вот так

у нас через ingress прописано

но nginx тоже неплохой вариант

надо будет подумать на него переехать ли

я только не знаю, как ты его будешь ставить на кореос