error: cannot expose a {extensions DaemonSet} - кругом враги, походу ds нельзя заекспозить культуро :(

Пробую kubernetes+traefik. При создании deployment+service+ingress вида whoami1 при доступе по PathPrefixStrip:/whoami1 не могу достучаться к сервису. При создании доп реплик запросы приходят через раз. При использовании имени вида whoami все норм. Сталкивался кто-то с этим?

Вопрос в том как работает helm upgrade и не должно ли для того что бы он так все обновил у него быть куча файликов на всех?

upgrade пихает кучу ваших отрендеренных yaml в сторону tiller, кто то из них ищет указанный релиз и ресурсы патчатся. понятно что helm нужен чарт вашего приложения и все зависимости. история\инфа о релизе лежат в tiller, если я правильно понимаю

а если ты два контейнера сливаешь в один под, то у них будет общая Ы

Что, серьёзно? А если у меня один контейнер с nginx, а второй с php-fpm в одном поде, как мне статику отдавать? Как мне обратиться к файлам, которые в соседнем контейнере?

Что, серьёзно? А если у меня один контейнер с nginx, а второй с php-fpm в одном поде, как мне статику отдавать? Как мне обратиться к файлам, которые в соседнем контейнере?

Нет. Ошибси)

Эх, а было бы круто. Как с сетью!

Что, серьёзно? А если у меня один контейнер с nginx, а второй с php-fpm в одном поде, как мне статику отдавать? Как мне обратиться к файлам, которые в соседнем контейнере?

я делаю один образ исходников с nginx+php-fpm и запускаю в поде из него два контейнера с разными command'ами

cat Deployment.yaml | sed s/\$\$EXTERNAL_IP/1.2.3.4/ | kubectl create -f -

Ещё есть envsubst.

я делаю один образ исходников с nginx+php-fpm и запускаю в поде из него два контейнера с разными command'ами

Интересная идея.

spec: containers: - image: образ:latest name: php-fpm command: ["/usr/sbin/php-fpm7.0"] args: ["--nodaemonize", "--force-stderr"] - image: образ:latest name: nginx command: ["/usr/sbin/nginx"] args: ["-g", "daemon off;"]

Что, серьёзно? А если у меня один контейнер с nginx, а второй с php-fpm в одном поде, как мне статику отдавать? Как мне обратиться к файлам, которые в соседнем контейнере?

По идее можно так: https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

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

в случае со статикой нет смысла.

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

не очень понятно, если честно, зачем держать "единый образ". собирайте просто два образа из одного сорс-репозитория, один для кода, другой для статики, и стартуйте их отдельно. этой статике не обязательно лежать рядом с php-fpm же.

у меня статика и код в одной репе и довольно сильно перемешана чтоб разделять ее на разные образы

я для mediawiki делал образы для nginx и fpm с одинаковым кодом. Там php и статика вперемешку в исходниках (как и в большинстве легаси php приложений наверно)

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

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

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

никакого дублирования

spec: containers: - image: образ:latest name: php-fpm command: ["/usr/sbin/php-fpm7.0"] args: ["--nodaemonize", "--force-stderr"] - image: образ:latest name: nginx command: ["/usr/sbin/nginx"] args: ["-g", "daemon off;"]

ну а я про что??

Наконец это произошло! Мы нормально оформили свой проект на гитхабе, который пилили для себя внутри команды. https://github.com/smpio/kubernator

Кто то здесь уже интересовался, поэтому разрешите попиарить

Вчера жаловался, что кубеспрей криво деплоит калику, на самом деле всё дело в провайдере, не разворачивайте кубернетес на диджитал оушене

Наконец это произошло! Мы нормально оформили свой проект на гитхабе, который пилили для себя внутри команды. https://github.com/smpio/kubernator

а контроль версий манифестов как осуществляется?

а контроль версий манифестов как осуществляется?

resourceVersion?

при попытке сохранить манифест, который уже был изменен api server определяет конфликт. мы в этом случае показываем diff. там на гифках это показано

я скорее про историю изменений

у нас всё в репозитории например, и я очень ругаюсь если в кластер лазят руками через kubectl edit

тут такого нет. это скорее как альтернатива kubectl edit, а не helm

да, в этом плане у всех разный workflow

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

а для сохранения истории делаю каждый день дамп

всех манифестов

Ребятушки! У меня выше была проблема с k8s on OpenStack, и мне помогли её благополучно решить, хочу оставить подробную инструкцию, для потомков. Где лучше это сделать?

Ребятушки! У меня выше была проблема с k8s on OpenStack, и мне помогли её благополучно решить, хочу оставить подробную инструкцию, для потомков. Где лучше это сделать?

https://github.com/kubernetes/community/tree/master/sig-openstack

https://github.com/kubernetes/community/tree/master/sig-openstack

Issue сделать?

у нас всё в репозитории например, и я очень ругаюсь если в кластер лазят руками через kubectl edit

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

Issue сделать?

Не знаю:) у них есть слак канал. Может это в доку стоит добавить

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

В нашем workflow это редко требуется и делается руками:) Если количество реплик запланировано меняется, то это комитится

Точно! Я ж в слаке уже есть у них! Спрошу там... Блин на англицком буду дольше писать )-: Ладно, заодно прогоню все еще раз — нет худа без добра.

Ну могу понять что не так делаю, пробую создать SteatefulSets, вроде всё прописал, но claim не выходит. persistent volumes создается и остается свободным, ничего не линкуется( Что у меня не так: https://pastebin.com/tV0bYipp ?

В общем в итоге не там пытался прописать volumes. JSON судя по всему будет удобнее в этом плане...

Блин, теперь другоая проблема( Эта зараза не хочет просто брать и создавать контейнер, и даже не понятно в чем дело(

describe поможет думаю

Да с этим разобрался, я там с сетями намудрил

Я вот сейчас думаю как бы мне динамическое хранилище сотворить....

@Visteras давно бы уже расшарили свой env, всем миром бы помогли

@Visteras давно бы уже расшарили свой env, всем миром бы помогли

издеваетесь да?)

издеваетесь да?)

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

shellinabox или другой web terminal emulator

Сейчас у меня есть два железных и чистых сервера только на которых я ставлю кубер в текущий момент) Хочу убедиться что все понял верно и проблем не будет)

А так я хочу еще разобраться с тем что бы запускать glusterfs или ceph или нечто подобное для того что бы можно было дублировать данные

у меня есть похожее окружение железные нодыпровижинтся через MAAS, и туда накатывается k8s все это обернуто в CI/CD чего и вам советую, для того чтобы цена передеплоя сводилась к минимуму

это из разряда - долго запрягаешь - быстро едешь

ceph не советую, большой входной порог

glusters через heketi

так я как раз и хочу сейчас разобраться как это с CI/CD подружить. Я хочу иметь возможность разворачивать этот кластер достаточно быстро, добавть к нему новые сервера в процессе его работы. Возможно выводить эти сервера. Плюс - еще хочу что бы часть данных между этими серверами дублировалась. Ну и деплой приложений в сам кластер само собой

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

да, примерно к этому и стремятся большинство местных обитателей CI/CD интегрируется с MAAS'ом который готовит чистый baremetal ноды разворачивать через kubespray добавлять - то же через него, есть возможность LCM и scale деплой приложения - helm chart storage сначала сделать на glusterfs

Хм.. не сталкивался с понятием MAAS

так же советую разрабатывать или держать в уме CI/CD таким образом, что между baremetal провижинингом и например amazon'ом(gke/azure/etc) не было большой разницы

Хм.. не сталкивался с понятием MAAS

https://maas.io/

более-менее внятная штука, а главное с внятным api

Стоп, глупый судя по всему вопрос, но зачем она вообще нужна?

Если кубер сам создает этот кластер ?

у вас есть N железных нод на них были проведены некие работы, поставлена ОС, пакеты, развернут кубер MAAS позволит развернуть на этих нодах чистую ОС что для возпроизведения результата

Последнее предложение не понятно, зачем там чистая ОС если там кубер?

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

тот же - это какой? если там контейнеры? в контейнер при сборке все собирается и вот вам окружение

кубер кто готовит?

на котором эти котейнеры крутятся?

В каком смысле готовит? Есть kubespray, оттуда оно должно разворачиваться вроде?

Там же ansible который это разворачивание и делает

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

ну да, а какие варианты вы предлагаете?

поднимать их виртуально через maas? а смысл если каждая новая железная нода будет требовать тот самый maas?

Эх... что-то всё же пошло не верно: TASK [kubernetes-apps/cluster_roles : Create kube system namespace] ************************************************************************************************************************************************************************* Thursday 23 November 2017 23:40:55 +0300 (0:00:00.421) 0:02:20.005 ***** FAILED - RETRYING: Create kube system namespace (4 retries left). FAILED - RETRYING: Create kube system namespace (3 retries left). FAILED - RETRYING: Create kube system namespace (2 retries left). FAILED - RETRYING: Create kube system namespace (1 retries left). fatal: [node1]: FAILED! => {"attempts": 4, "changed": false, "cmd": "/usr/local/bin/kubectl create -f /etc/kubernetes/kube-system-ns.yml", "failed": true, "msg": "[Errno 2] No such file or directory", "rc": 2}

maas позволит провижиить железые ноды с чистой ОС, и эти ноды можно скармливать kubespray

Эм.. а в чем преимущество по сравнению со скармливанием ему простых серверов без maas?

ничем