подключаешься из пода?

kubectl describe podName покажи

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

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

@devops_ru больше народу

каким образом я могу монтировать pv на nfs в множество подов в разных неймспейсах?

@vizdrag ты тоже не понял, как оказался в чате про криптовалюту?

каким образом я могу монтировать pv на nfs в множество подов в разных неймспейсах?

PV не привязаны к namespace. Привязаны claims (PVC)

@vizdrag ты тоже не понял, как оказался в чате про криптовалюту?

я думаю эти пидлы сменили подход с "постить хуйню(да простят меня админы)" на "а давайте добавлять в свои каналы

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

каким образом я могу монтировать pv на nfs в множество подов в разных неймспейсах?

разные неймспейсы я не пробовал, а так pvc шарят

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

pod-pvc-pv

т.е нужно создавать одинаковые pv под каждый неймспейс? через storage class нельзя сделать?

я не знакомился с ранчером так что хз как он там устроен как я разумею надо шарить не pv а pvc которые будут на pv ссылаться

запутали?

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

нуда, точняк

apiVersion: v1 kind: PersistentVolume metadata: name: pv01 spec: capacity: storage: 5Mi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: any mountOptions: - hard - nfsvers=4.1 - intr nfs: path: /mnt/nginx server: <ip.addr> --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 5Mi volumeName: pv01 storageClassName: any --- apiVersion: apps/v1 kind: Deployment metadata: name: nfs-web spec: replicas: 3 selector: role: web-frontend template: metadata: labels: role: web-frontend spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 volumeMounts: # name must match the volume name below - name: pv01 mountPath: "/usr/share/nginx/html" volumes: - name: pv01 persistentVolumeClaim: claimName: myclaim

а никто случаем не владеет инфой по best-practices HELM+K8S+DAPP+Gitlab?

надо у фланта спросить?

надо у фланта спросить?

в открытом доступе только теорию нашёл, сам их ci flow искал)

в открытом доступе только теорию нашёл, сам их ci flow искал)

мы вообще кубер с видосов Столярова начинали изучать?

да, там всё красиво и толково, но теория в большинстве

ну, еще бы на конференции бы все тех подробности гибкой проды рассказывали, ага:)

"смарите все как надо много бабла рубить"

в вики такое - "Пример .gitlab-ci.yml (#TODO)" ))

Но и без этого инфы там хватает, читал?

ты про dapp?

да, http://flant.github.io/dapp/

а, эту то всю доку шерстил, ага

а в итоге вышло - билд даппом - деплой кубером

по джобам

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

так а dapp kube deploy ?

не, тогда уж хельм

надо бы отредактировать

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

таки да, у тебя вводных не так уж и много)

?

в принципе, хельм стоит над кубером, а кубер над образами, скорее там надо искать в dapp практики, типа а как еше можно лучше сделать

думаю вопрос всё же ближе к gitlab и лучше там спросить?

apiVersion: v1 kind: PersistentVolume metadata: name: pv01 spec: capacity: storage: 5Mi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: any mountOptions: - hard - nfsvers=4.1 - intr nfs: path: /mnt/nginx server: <ip.addr> --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 5Mi volumeName: pv01 storageClassName: any --- apiVersion: apps/v1 kind: Deployment metadata: name: nfs-web spec: replicas: 3 selector: role: web-frontend template: metadata: labels: role: web-frontend spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 volumeMounts: # name must match the volume name below - name: pv01 mountPath: "/usr/share/nginx/html" volumes: - name: pv01 persistentVolumeClaim: claimName: myclaim

ReadWriteOnce то почему если нфс?

разве dapp деплоит не через helm чарты?

В этом наверное и проблема с шарингом pv с другими подами. PV живёт вне неймспейса pvc в неймспейсе. PV нужно тогда описать как ReadWriteMany в случае нфс чтобы другие pvc тоже могли его цеплять. Всё это как я понимаю должно работать в теории, сам с нфс в кубере не работал

разве dapp деплоит не через helm чарты?

dapp деплоит helm чарты)

dapp деплоит helm чарты)

не через tiller?

а это не helm?

тиллер это хелмовский демон в к8с

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

демон не в смысле daemonset, а в смысле часть хелма

Кстати. Демонсет же деприкейтед уже. Кто как гарантирует размещение подов на каждой ноде?

Может кто-нибудь рассказать зачем нужен helm? Я уже прочитал что это типа пакетный менеджер для кубернетиса, посмотрел доку, поднял пару сервисов с помощью него, но пока не вижу его пользы, если я использую только свой софт на кубер кластере.

Может кто-нибудь рассказать зачем нужен helm? Я уже прочитал что это типа пакетный менеджер для кубернетиса, посмотрел доку, поднял пару сервисов с помощью него, но пока не вижу его пользы, если я использую только свой софт на кубер кластере.

Мне эта поделка тоже не по душе. Пока не увидел от нее плюсов

Ну много людей использует, видимо я что-то не понимаю :)

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

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

Разве с kubectl нельзя так? ?

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

Я не ожидаю от него ничего в принципе, поскольку не понимаю чем он мне может помочь. Вот у меня есть го-сервис, который катается деплоем, как он мне тут поможет?

Разве с kubectl нельзя так? ?

думаю можно и докер композом или вообще накидать sh скрипт с деплоем по машинам зачем вообще эти куберы докеры понапридумали

Я не ожидаю от него ничего в принципе, поскольку не понимаю чем он мне может помочь. Вот у меня есть го-сервис, который катается деплоем, как он мне тут поможет?

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

> Для всех популярных программ есть helm чарты. и примерно все из них надо будет допиливать руками, а для этого надо уметь в хельм для начала

> Для всех популярных программ есть helm чарты. и примерно все из них надо будет допиливать руками, а для этого надо уметь в хельм для начала

ни разу с таким не сталкивался. да, придётся отредактировать values

@azalio вощем юзай envsubst где тебе надо шаблонизировать манифесты и всё %)

думаю можно и докер композом или вообще накидать sh скрипт с деплоем по машинам зачем вообще эти куберы докеры понапридумали

Не надо утрировать. Я говорю о том что можно деплоиться по kubectl apply -f . При этом гораздо быстрее написать манифесты, чем чарты

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

Прям сейчас не катается, но скоро будет и я думаю как сделать правильно, поэтому и задумался о хельме, о котором много говорят.

@azalio вощем юзай envsubst где тебе надо шаблонизировать манифесты и всё %)

Так может вообще паппет? :)

может

но тогда с тасками

чтобы по команде

Не надо утрировать. Я говорю о том что можно деплоиться по kubectl apply -f . При этом гораздо быстрее написать манифесты, чем чарты

манифесты всё равно придётся писать разве что накидать потом Charts и values файлы и не заморачиваться с envsubst в будущем

но тогда с тасками

Таски? Гитлаб? Или что.

таски папета

Оу, для меня это новье

оно и есть

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

в том числе в разных неймспейсах или кластерах

плюс у него есть хуки post install, post update и т.п., он умеет рестартанут поды позле изменения конфигмапа или секрета и прочие мелкие плюшки которые kubectl apply не умеет

до сих пор не понимаю почему в кубере этого нет в коробке

в плане возможностей го темплейты явно на порядок выше envsubst

рестартануиь поды после изменения конфигмапа - это интересно

в плане возможностей го темплейты явно на порядок выше envsubst

они для текста, а не для структурированных данных (yaml) и это со всех сторон лезет

то же самое сели через ту же jinja делать

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

то же самое сели через ту же jinja делать

всё так но тут есть документация и куча примеров, а не велосипед васи пупкина

ну вот согласен, главное преимущество, что оно стандарт де-факто

угу

это как с паппетом или шефом - ну говно же что один что другой

но сука стандард и все пользуются

папет старее 4.0 говно :)

современный очень ок

я 4 не видел, на 3 закончил с ним общение и очень этому рад

но остадочек остался и новички его не хотят изучать

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

?

может хелм к 4 версии тоже уже и не говно будет

вангую что они на версионирование <yyyy>.<mm> перейдут скорее

есть еще ksonnet, он вроде бы выглядит поприятнее чем хелм (все-таки считай полноценный ЯП) но с ним я не ковыряся подробно и как по мне там слишком много магии тогда как хелм простой как табуретка

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

https://github.com/fkorotkov/k8s-kotlin-dsl вот ещё есть