выдает неинформативные сообщения, аля “Kubernetes error.”

уже сны вижу с этими нодами)

насколько плохо деплоить образы в кластер напрямую через gitlab runner?

насколько плохо деплоить образы в кластер напрямую через gitlab runner?

абсолютно нормально)

абсолютно нормально)

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

абсолютно нормально)

я думаю через docker registry правильнее

я думаю через docker registry правильнее

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

ну да, правильно, нужно же команду послать

ну спасибо ребят, успокоили)

ну спасибо ребят, успокоили)

helm это как раз обертка вокруг обычного деплоя

ну если это можно так назвать ?

то есть ставить его в гитлаб раннер и деплоить через него?

Подскажите - можно ли ингрессу подсунуть регулярку для server name?

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

писать 80+ алиасов совсем дико как-то

на обычном nginx это делается без проблем, а вот на ингрессе непонятно

Я в своё время пофейлился с регулярками и ингрессом. Пришлось делать кастомный шаблон конфига

насколько плохо деплоить образы в кластер напрямую через gitlab runner?

А как ты делал иначе?

А как ты делал иначе?

Пытался настроить автоматическую интеграцию гитлаба и кубера

Я в своё время пофейлился с регулярками и ингрессом. Пришлось делать кастомный шаблон конфига

вроде как traefik умеет это делать, но хотелось бы избежать этого

доброе утро! я правильно понимаю, что в случае с nbd невозможно "заказать" нарезать новое блочное устройство? т.е. в качестве бэкенда для pvc с динамическим выделением ресурсов не подходит?

Как правильно делать, у меня кластер 3 мастера и 5 воркеров,на воркерах крутится веб прилодение. Где размещать правильно ингресс нджинкса, на каждом воркере или на мастерах? Нужно ли вообще чтото на мастерах ставить или не стоит?

по хорошему надо выделить 1+ воркер для ингресса, поставить на него метку, что-то типа role=ingress и запускать ингресс там

по хорошему надо выделить 1+ воркер для ингресса, поставить на него метку, что-то типа role=ingress и запускать ингресс там

Тогда входная точка в приложение будет всего один воркер?

не менее 1

у нас 2

т.е. пролейблить несколько нод

ну и ингресс контроллер запускать демонсетом

А если нода перестала существовать то на оьорудовании выше которое смотрит на адрес воркера тоже надо будет производить изменения?

да

Разве это правильно? В том плане что мастера их адреса и колво в основном стаичны, не выгодней ли разместить там?

В чем профит от размещения на 1+ ноде а не на всех?

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

можно и так,

up to you

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

Хмм..спасибо

доброе утро! я правильно понимаю, что в случае с nbd невозможно "заказать" нарезать новое блочное устройство? т.е. в качестве бэкенда для pvc с динамическим выделением ресурсов не подходит?

Привет, nbd - это просто протокол доставки блочного устройства, очень простой и не очень надежный. И насколько мне известно kubernetes не поддерживает его из коробки. Имхо iscsi - намного стабильнее.

Как в случае и с iscsi экспортируемое устройство должно быть уже создано на сервере.

В чем профит от размещения на 1+ ноде а не на всех?

У нас на этих нодах только ингресс, ну и filebeat с prometheus-node-exporter для логирования и мониторинга

У нас на этих нодах только ингресс, ну и filebeat с prometheus-node-exporter для логирования и мониторинга

Ты про мастера?

нет, про ноды с role=ingress

@kvaps но спомощью кастомного CSI можно их создавать получается

что я делаю не так, я создал деплоймент, создал сервис и теперь пытаюсь стучаться по NodePort и порту на этот сервис, но в браузере site cannot be reached

кластер через kubespray развернул

А у вас прямая видимость этого хоста есть?

Посмотрите на хосте вывод netstat -antp | grep LIST

всем привет

пытаюсь прикрутить цеф к кубу, имею следующую проблему: kubectl get pvc -n kubecloud NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE claim Pending fast 4m kubectl describe pvc -n kubecloud Name: claim Namespace: kubecloud StorageClass: fast Status: Pending Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 8s (x20 over 4m) persistentvolume-controller Failed to provision volume with StorageClass "fast": failed to create rbd image: executable file not found in $PATH, command output:

подскажите как посмотреть подробные логи, что не получается у него?

потому что в дефолтном kube-controller нету бинарника

можно подробней? я не понял, что где посмотреть?

ceph-common стоит на нодах?

да 12.2.8-1~bpo90+1

цеф установлен не в кубе, отдельно

у тебя в контейнере должен быть rbd,что бы маунтить волюмы

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

ссылку не дает вставить

интересно, в сиписке чатов ссылка есть а в чате нет)

цеф установлен не в кубе, отдельно

К тебя kubelet контейнеризирован? Дык прокинь библиотеки через bind mount

мне тут вроде подсказали я пропустил пунк про замену образа kube-controller-manager

еще не проверил, отпишусь

Не. Тебе провижен нужен контроллер заменять точно не надо

Провижен ты можешь натравить и на внешний цеф.

бинарь rbd нужен, а его нет в текущем image для kube-controller-manager, хотя у меня с 1.9.2 (еще на coreos в контейнерах) бинарник уже был

и сейчас есть в 1.11 (gcr.io/google-containers/hyperkube:v1.11.1)

бинарь rbd нужен, а его нет в текущем image для kube-controller-manager, хотя у меня с 1.9.2 (еще на coreos в контейнерах) бинарник уже был

Дык bind-mount за чем переделывать образ?

ну bind-mount - костыль

да, самое простое - биндить

где тут смайл с взорвавшимся мозгомм

ну bind-mount - костыль

Почему? И что такое костыль?)

я просто удивился что внутри образа нет rbd бинарника. Интересна версия k8s

Мне всегда интересно как люди определяют что костыль а что нет.)

у каждого свое понятие.Для кого-то это нормально,для кого-то "и тааак сойдет (с)"

Кстати офф тема от цефа это делать отдельный контейнер с провизингом

в общем помогло подменить образ

осталось понять как теперь этот волюм юзать

https://github.com/ceph/ceph-container/blob/master/examples/kubernetes/rbd-provisioner/README.md

Так что замена образа то же в какой-то мере костыль)

почему? я пробовал rbd-provisioner - отлично работает

почему? я пробовал rbd-provisioner - отлично работает

твои вкусы весьма спецефичны

а так мне просто не нравится держать части ceph в докере

любые части)