можно проверять статус ресурсов через которые менеджит релиз: kubectl -n <namespace> get all -l 'release=<helm_release>'

Если вы живёте без Хелм, лучше оставайтесь вдали от него. Ищите по тегу # helmговно

можно проверять статус ресурсов через которые менеджит релиз: kubectl -n <namespace> get all -l 'release=<helm_release>'

К сожалению all на самом деле не everything :)

Если вы живёте без Хелм, лучше оставайтесь вдали от него. Ищите по тегу # helmговно

есть тулза для генерации однотипных yaml ресурсов кубера?

К сожалению all на самом деле не everything :)

к сожалению да, вопрос был об "один из имаджей не задеплоился (с)"

есть тулза для генерации однотипных yaml ресурсов кубера?

Ваш envsubst прекрасная тулза :)

у меня дофига nginx+статика image. делать копипаст deployment/service/ingress уже надоело. Там разница только в image строке и path ingress

хотя тот же envsubst решает

Да, туплю.

у меня похожая ситуация, не понимаю в чем проблема генерить deployment,service,ingress файлики

у меня похожая ситуация, не понимаю в чем проблема генерить deployment,service,ingress файлики

генерить не проблема, нужен шаблон. Решается через дополнительный template.yml

впрочем ладно, я перестал слушать на моменте envsubst | kubectl apply - для выката приложений привет canary апгредам

cat static.yml | NAME=some-name envsubst | kubectl apply -f -

впрочем ладно, я перестал слушать на моменте envsubst | kubectl apply - для выката приложений привет canary апгредам

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

envsubst это начало, я жду когда там появится ... | awk | ...

а лучше ... | awk | yq | ..

У меня сотни строк на jsonnet (через ksonnet) , для сложных штук самое оно.

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

У меня нет сложных штук в плане devops, кроме этого полно других дел...

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

Задача генерации структурированных файлов классическими тулзами решена только в m4 и то с натяжкой )

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

Его нет в обычных дистрах вроде

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

Строки задолбали и сдерживают прогресс

JSON вместо строк уже предлагали

Давно

Json pipe и тп

(╯°□°）╯︵ ┻━┻

Я же говорю, что я за. А смайл схоронил

Хе... У нас пришли к генерации конфигов для всякого при помощи go, темплейтов и json с параметрами...

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

я так понимаю, в карму вы совсем не верите? :)

День добрый. Кто работал с rancher можете помочь? https://toster.ru/q/563328

я так понимаю, в карму вы совсем не верите? :)

Со стороны PowerShell выглядит как удачная технология страдающая от предвзятого отношения и вообще инерции мышления. Надо попробовать изнутри, чтобы понять так ли это

ЗАДАЧА: "Видеть" содежимое каталога "www" в "kubernet-docker"-контейнере и на host-системе: под "host-системой" понимается "железный" сервер на fedor-e 28. Что имеем? Делается по "нативной" инструкции: "Configure a Pod to Use a PersistentVolume for Storage": https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ PersistentVolume и PersistentVolumeClaim и Pod устанавливаются без проблем. путь хост-системы: /var/www/html путь Pod-a: /usr/share/nginx/html Но вот "хоть убей": когда "кладём" файл в хост-систему: echo "Hello World!" > /var/www/html/index.html на Pod-е его не видно: ls -la /usr/share/nginx/html result -> empty и наоборот: когда "кладём" файл в Pod: echo "Hello World!" > /usr/share/nginx/html/index12345.html на хост-системe его не видно: ls -la /var/www/html/ index.html ПРОСЬБА: "пнуть" в правильном направлении: Как "приготовить" PersistentVolume, PersistentVolumeClaim, Так чтобы папки и для host-системы и для Pod-а были "те же", т.е., после "выключения/удаления" Pod-а папки и файлы, созданные на Pod-е сохранялись на хост системe?

Со стороны PowerShell выглядит как удачная технология страдающая от предвзятого отношения и вообще инерции мышления. Надо попробовать изнутри, чтобы понять так ли это

а где можно прочитать про "удачная тенология"? ткните пальцем пожалуйста

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

ЗАДАЧА: "Видеть" содежимое каталога "www" в "kubernet-docker"-контейнере и на host-системе: под "host-системой" понимается "железный" сервер на fedor-e 28. Что имеем? Делается по "нативной" инструкции: "Configure a Pod to Use a PersistentVolume for Storage": https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ PersistentVolume и PersistentVolumeClaim и Pod устанавливаются без проблем. путь хост-системы: /var/www/html путь Pod-a: /usr/share/nginx/html Но вот "хоть убей": когда "кладём" файл в хост-систему: echo "Hello World!" > /var/www/html/index.html на Pod-е его не видно: ls -la /usr/share/nginx/html result -> empty и наоборот: когда "кладём" файл в Pod: echo "Hello World!" > /usr/share/nginx/html/index12345.html на хост-системe его не видно: ls -la /var/www/html/ index.html ПРОСЬБА: "пнуть" в правильном направлении: Как "приготовить" PersistentVolume, PersistentVolumeClaim, Так чтобы папки и для host-системы и для Pod-а были "те же", т.е., после "выключения/удаления" Pod-а папки и файлы, созданные на Pod-е сохранялись на хост системe?

"Магия", оказалась в том,что на "хост-системе" файл кладётся: echo "Hello World!" > /var/www/html/index.html только после команды: minikube ssh

"Магия", оказалась в том,что на "хост-системе" файл кладётся: echo "Hello World!" > /var/www/html/index.html только после команды: minikube ssh

После команды minikube ssh создаётся файл: echo "Hello World!" > /var/www/html/index.html через "minikube ssh" его видно: ls -la /var/www/html/index.html -rw-r--r-- 1 root root 30 Sep 17 07:34 /var/www/html/index.html В Pod-e, его тоже видно (Pod при-mount-ен к /usr/share/nginx/html/): ls -la /usr/share/nginx/html/ -rw-r--r-- 1 root root 30 Sep 17 07:34 /usr/share/nginx/html/index.html Вопрос: Как увидеть на хост-системе (на железном сервере) вновь созданный файл: "/var/www/html/index.html" т.е. как увидеть этот файл вне "minikube ssh"?

А может кто в двух словах сказать, что будет с кублетами за натом? Они у меня давно работают, только штуки вроде kubectl logs не работаю. Куда копать?

После команды minikube ssh создаётся файл: echo "Hello World!" > /var/www/html/index.html через "minikube ssh" его видно: ls -la /var/www/html/index.html -rw-r--r-- 1 root root 30 Sep 17 07:34 /var/www/html/index.html В Pod-e, его тоже видно (Pod при-mount-ен к /usr/share/nginx/html/): ls -la /usr/share/nginx/html/ -rw-r--r-- 1 root root 30 Sep 17 07:34 /usr/share/nginx/html/index.html Вопрос: Как увидеть на хост-системе (на железном сервере) вновь созданный файл: "/var/www/html/index.html" т.е. как увидеть этот файл вне "minikube ssh"?

у тебя куб в вмке

у тебя куб в вмке

да, в virtualboxe: sudo minikube start --vm-driver virtualbox --v 1 файл из Poda вытаскивается вот так: sudo kubectl exec -it nginx -- cat /usr/share/nginx/html/index2.html > /tmp/index2.html хотелось бы понять: почему: ls -la /var/www/html (на железе) и ssh minikube > ls -la /var/www/html почему - это "разные" каталоги?

они будут одинаковые только если примонтировать через volumes: - name: name hostPath: /var/www/html

да, в virtualboxe: sudo minikube start --vm-driver virtualbox --v 1 файл из Poda вытаскивается вот так: sudo kubectl exec -it nginx -- cat /usr/share/nginx/html/index2.html > /tmp/index2.html хотелось бы понять: почему: ls -la /var/www/html (на железе) и ssh minikube > ls -la /var/www/html почему - это "разные" каталоги?

потому что у тебя куб в вмке.

они будут одинаковые только если примонтировать через volumes: - name: name hostPath: /var/www/html

Спасибо огромное: хорошего дня!!!!

/report

потому что у тебя куб в вмке.

Спасибо, Андрей, пробую с name:name

persistentVolumeClaim тут не причем. Просто spec: volumes: - name: html hostPath: /var/www/html containers: volumeMounts: - name: html mountPath: /var/www/html

Я не в курсе прокидывает ли minikube примонтированные папки на host систему, если нет, то это отдельно пробросить с vm на хост нужно.

docker - vm - host вы понимаете, что там такая схема? Выше конфиг под слой docker - vm

https://github.com/kubernetes/minikube/blob/master/docs/host_folder_mount.md

minikube mount

на vm - host

docker - vm - host вы понимаете, что там такая схема? Выше конфиг под слой docker - vm

Да, на "чистом" docker-e просто: при монтировании -> файлы, что - на железе, что в doсker-контейнере - те же (bind), видны "одинаково". в minikube, оказывается для расшаривания хост-директорий и minikube-related, необходим дополнительный "танец с бубном" в виде: minikube mount ~/mount-dir:/mount-9p ожидалось: что задачу "minikube mount ~/mount-dir:/mount-9p" возможно решить в рамках yaml-конфига. Или всё же, указанный вами конфиг рабочий (для Pod-a)? -> spec: volumes: - name: html hostPath: /var/www/html containers: volumeMounts: - name: html mountPath: /var/www/html

У вас 3 уровня. Нужно 2 «моста» сделать

От докера к vm и от vm на хост.

minikube запускает кластер в virtualbox

minikube запускает кластер в virtualbox

да, этот шаг понятен

minikube запускает кластер в virtualbox

Вопрос -> как "3 уровня и 2 моста" реализовать в рамках yaml конфига?

Вопрос -> как "3 уровня и 2 моста" реализовать в рамках yaml конфига?

Никак. В конфиге прямой mount. А перед деплоем писать minikube mount

Вообще это странно, не стоит так делать. У каждого разработчика своё окружение, сломаете

А как сделать в ingress динамический url, который прокидывается на сервис?

Вообще это странно, не стоит так делать. У каждого разработчика своё окружение, сломаете

Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?

Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?

Имеется ввиду не все директри, а к, примеру:

А как сделать в ingress динамический url, который прокидывается на сервис?

Что значит динамический? Там path и весь хвост уходит на сервис. Как location у nginx

Так, как же правильно? Для случая "директории-хост-машины-и-Pod-a—те-же"?

"железо": /mnt/sdd1/kubernetes/storage "Pod(s)": /usr/share/nginx/html

я поднимаю kubeless и каждый ендпойнт маппится на определенный сервис (->деплоймент ->под). Допустим, пишем обычный CRUD через kubeless. Как сделать GET по id? Но пока что-то не понял, как сделать динамический ingress, который будет мапить его с сервисом. Мб как-то иначе можно это сделать?

Замапить / на kubeless

А, либо просто внешний сделать ingress типа http:/..../mymodel - сервис list get http:/.../mymodel/ - сервис detail get а там уже получать и парсить оставшуюся часть

Там же у kubeless свой ingress?

там как-то через kube proxy это делается, но я не совсем пока освоился с ним

мне проще пока описать свой ингрес

Это базовая вещь которую должны были решить. Точно есть в доке

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

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

devopstoolkit

https://leanpub.com/the-devops-2-toolkit

там как-то через kube proxy это делается, но я не совсем пока освоился с ним

kubeless ingress там есть (сам только собираюсь пробовать kubeless). Т.е. каждую функцию нужно забиндить на url

kubeless ingress create route1 --function get-python

да, я видел это

https://leanpub.com/the-devops-2-toolkit

Спасибо.

но я ещё использую serverless фреймворк для удобной конфигурации функций. А вот там с ингрессом тоже пока не разобрался. Поэтому exposить ендпойнты решил через обычный ingress конфиг)

чота посмотрел три разных оператора для монги и кажется все херовые какие-то

может есть готовые не херовые?

.

Нормально ли, у меня кластер на бареметал, если я диапазон nodeport сменю начиная с 80 порта, чтобы ingress nginx работал на 80 порту? Или есть более нормальный вариант?

Нормально ли, у меня кластер на бареметал, если я диапазон nodeport сменю начиная с 80 порта, чтобы ingress nginx работал на 80 порту? Или есть более нормальный вариант?

есть. controller.hostNetwork=true

и controller.daemonset.useHostPort

есть. controller.hostNetwork=true

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

потому что контроллер в 1 экземпляре