hi all! посоветуйте, пожалуйста, как увеличить размер pv и привязанного к нему pvc, если provisioner в их storageclass является host-path ?

мб есть какая-то конкретная литература на эту тему?

шо за провижионер с hostpath? =)

я, мб, нублю (: - дело для меня новое, мб, неправильно вопрос задал.

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"gitlab-storage-config","namespace":""},"provisioner":"kubernetes.io/host-path","reclaimPolicy":"Retain"} creationTimestamp: 2018-08-17T05:16:04Z name: gitlab-storage-config resourceVersion: "5859522" selfLink: /apis/storage.k8s.io/v1/storageclasses/gitlab-storage-config uid: a3b87c04-a1dc-11e8-ae43-1c6f6581d4b0 provisioner: kubernetes.io/host-path reclaimPolicy: Retain volumeBindingMode: Immediate

вот такой у меня storageclass, делал тестовое все, для gitlab-a

к нему привязан pv к pv обращается pvc. Все это на локальном сервере устроено. Хочется без лишних страданий научиться изменять размер pv и pvc.

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

читал. там, как мне кажется, ключевое - Although the feature is enabled by default, a cluster admin must opt-in to allow users to resize their volumes. Kubernetes v1.11 ships with volume expansion support for the following in-tree volume plugins: AWS-EBS, GCE-PD, Azure Disk, Azure File, Glusterfs, Cinder, Portworx, and Ceph RBD.

попробовал у себя, на тестовом pvc, получил - error: persistentvolumeclaims "local-claim-1" could not be patched: persistentvolumeclaims "local-claim-1" is forbidden: volume plugin does not support resize

мне кажется, для host-path цифры в pvc не особо важны

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

но хочется уверенности (:

проверь. выдели 8G, зайди в контейнер, посмотри, сколько доступно

скорее всего будет доступно всё, а не 8G

а, интересно, как выражается переполнение ресурса? это где-то видно?

ок, попробую, спасибо за совет.

еще уточнение - то есть выделить именно в pv? а в pvc должен остаться больший размер, который был изначально?

Доброе утро, господа. Кто-нибудь юзал pharos?

pharos.sh

нормальный у них такой в прайсе свитч usd <—> eur просто значок валюты около цифры меняется ?

Зачем такое вообще нужно

Затем же зачем и kubeadm

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

Храните сессии юзеров в общем хранилище уже

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

сохраняй сессии в монгу/редис/другое хранилище и не привызявай бекенд к сессии.

нормальный у них такой в прайсе свитч usd <—> eur просто значок валюты около цифры меняется ?

много у кого так.

бэкэнд - сторонне приложение. если в севрисе один под все ок, если больше - беда..

Бывает, что всё-таки нужно привязать юзера и бэкенд. Sessionaffinity для этого, если я правильно понимаю

спс пошел читать

спс пошел читать

https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/README/ предположу что ingress-nginx используешь

угу

тут есть нюансы как всегда, если куки нет, я так понимаю ingress ее воткнет

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

какраз по куке прилаги и отваливается.. т.е. через nginx.ingress.kubernetes.io/affinity + nginx.ingress.kubernetes.io/session-cookie-name пробросится кука в сервис, а описании сервиса sessionAffinity: по той же куке?

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

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#custom-nginx-upstream-hashing

«И если поменяют как всегда не тот диск в рейде, не страшно.» уж сколько дисков поменяли, ни разу такого не было

+1

какраз по куке прилаги и отваливается.. т.е. через nginx.ingress.kubernetes.io/affinity + nginx.ingress.kubernetes.io/session-cookie-name пробросится кука в сервис, а описании сервиса sessionAffinity: по той же куке?

не понял вопроса

Всем привет, в доках написано что кубер 1.8\1.9 поддерживает версию 17.03.х. Это последняя актуальная версия или документация просто не обновлялась?

это последняя, что прошла валидацию

у них там движуха в сторону валидации версии docker api, ведь версии docker поддерживают несколько версий api обычно и можно фиксироваться на api version, а не использовать старшую доступную, как сейчас. но это в планах только как я понял

работает и на 18.06, сам запускал, проблема пока не ловил

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

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

всетаки если commit sha уехал, это уже совсем не тоже самое, что было раньше. так что все правильно

Я readme поменял, он перезапускает deployment. Там docker build мгновенно проходит, потому что кэш, но tag меняется и deployment отрабатывает. Думаю потом сделать проверку, что docker image отличается хоть чем-то кроме tag

Я readme поменял, он перезапускает deployment. Там docker build мгновенно проходит, потому что кэш, но tag меняется и deployment отрабатывает. Думаю потом сделать проверку, что docker image отличается хоть чем-то кроме tag

Что поделать, readme часть кода же

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

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

ты можешь в чартах описать зависимость и тогда один чарт потянет все что ему нужно. но ты не можешь сказать "запусти под после запуска базы". зато можешь entrypoint или init container намутить, который будет тыкать в service дб. как только оно начнет что то возвращать - завершать инит с успехом и запускать твой апп

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

initContainers с wait’ом на базу?

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

Нет. Никакого "умного" деплоя Helm не умеет.

ок, спасибо!

в каком то смысле ваш апп будет дожидаться появления зависимостей, если например падает при недоступности бд. он же будет перезапускаться =)

Всем првиет! Подскажите в k8s service можно задать диапозон портов?

Что поделать, readme часть кода же

смотреть, что по факту image не поменялся. Там же есть sha256. Может он, ещё не читал. 100% можно детектить, что у контейнера отличаются только меткой.

там же собирается по слоям, у слоя md5 свой или ещё какой хэш. Хэши последних слоёв равны - не поменялся.

docker pull же не перекачивает слои, если они одинаковые у разных тегов одного image

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

"слои" и "образы" это "многие ко многим"

да не, docker pull же ничего не качает, если контент не менялся

docker pull ничего не качает, deployment не должен обновлятся.

если тег поменялся, то обновится, даже если не качал ничего

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

и не пушит так же

или я прям совсем сейчас себе шаблон порву, если не так.

порвёшь

выкачиваться может и не будет, но тегаться будет

docker pull some:label1 docker tag -t some:label2 some:label1 docker push some:label2

docker pull some:label2 ничего не качнет

docker build ничего не пересобёрет

потому что нельзя "скачать тег"

можно "узнать sha слоёв по тегу и скачать их"

Я могу путать понятия, с другой стороны. Если работает some:label1 а дальше docker pull some:label2 ничего нового не выкачивает то deployment не нужно запускать, ничего не поменялось.

docker pull*

потому что нельзя "скачать тег"

кроме слоев есть еще манифест, в нем хранятся теги. Меняются теги - меняется хэш манифеста

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

Ставлю миникуб)

Винда просто умерла )

кроме слоев есть еще манифест, в нем хранятся теги. Меняются теги - меняется хэш манифеста

ты про манифесты кубера?

ты про манифесты кубера?

https://docs.docker.com/registry/spec/manifest-v2-2/

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

У меня есть 2 тега 027cb8a34f212354af11dfc548d339e3a7ddf063 dcddfdc066d02ac80341de3e044918d49df5622c Они собраны на 100% одинаково. docker build просто берёт все их кеша слоёв. Есть же способ это задетектить, чтобы не перезапускать deployment просто так. Я про это начал говорить, в теме не разбирался пока, руки не доходят.

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

это не теги, это хеши

docker build -t service:dcddfdc066d02ac80341de3e044918d49df5622c .

это теги

$CI_COMMIT_SHA

И тут косяк только один, левые комиты заставляют deployment обновиться, хотя не нужно.

а это проблема?

Ну, нам уже пол года пофиг. А вообще безполезное действие

Я написал, что это если с этим нет проблем, то наоборот круто. Это тест, что приложение не валится от рандомных перезапусков =)

думаю этим должен CI заниматься, а не докер и не кубер

И тут косяк только один, левые комиты заставляют deployment обновиться, хотя не нужно.

образы тегируются git коммитами (хешами) в том месте, где идет deploy сервиса в k8s по триггеру, можно выдирать метку образа, через git смотреть что поменялось, и принимать решение. деплоить или нет

думаю этим должен CI заниматься, а не докер и не кубер

+1

общепринята практика делать [ci skip] в хедлайне коммита, например

образы тегируются git коммитами (хешами) в том месте, где идет deploy сервиса в k8s по триггеру, можно выдирать метку образа, через git смотреть что поменялось, и принимать решение. деплоить или нет

Я думаю, что можно опираться докеровское сравнение слоёв, потому что он уже это умеет. Пока не дошел ещё.

точнее CD

Зачем мне думать, что поменялось, если это знает докер.