Приветствую всех. Есть докер образ, который должен открывать много udp портов. Возможно ли в k8s через сервис сделать доступ к этому множеству портов (диапазон) что бы не описывать вручную?

Господа, подскажите пожалуйста! Слышал такую точку зрения что хранить данные в кубернетесе/докере опасно, так как не смотря на все Persistent хранилища он все-равно может их (данные) потерять. Насколько оправданы такие опасения?

уже обсуждали в этом чате и там были какие-то грабли с этим

apiVersion: v1 data: tls.crt: "..." tls.key: "..." kind: Secret metadata: name: sslcerts namespace: default type: Opaque --- apiVersion: extensions/v1beta1 kind: Ingress metadata: name: dev-ingress annotations: kubernetes.io/ingress.global-static-ip-name: 'dev-ingress-ip' spec: tls: - secretName: sslcerts backend: serviceName: 'nginx-app' servicePort: 80 rules: - host: skghmrcx.dev.example.com http: paths: - path: '/gw/poi/api/*' backend: serviceName: 'gateway-poi' servicePort: 80 - path: '/gw/erty/api/*' backend: serviceName: 'gateway-erty' servicePort: 80 - path: '/api/v4/*' backend: serviceName: 'payment-api' servicePort: 80 - path: '/demo/*' backend: serviceName: 'demo-app' servicePort: 80 - path: '/pqkhy/*' backend: serviceName: 'pqkhy-app' servicePort: 80 - path: '/*' backend: serviceName: 'skghmrcx-app' servicePort: 80 - host: pzeu.dev.example.com http: paths: - path: '/powuitnb/api/*' backend: serviceName: 'powuitnb-app' servicePort: 80 - path: '/powuitnb/*' backend: serviceName: 'powuitnb-app' servicePort: 80 - path: '/*' backend: serviceName: 'pzeu-app' servicePort: 80 - host: oqyrtd.dev.example.com http: paths: - path: '/gw/poi/web/*' backend: serviceName: 'gateway-poi' servicePort: 80 - path: '/gw/erty/web/*' backend: serviceName: 'gateway-erty' servicePort: 80 - path: '/*' backend: serviceName: 'example-app' servicePort: 80 - host: dev.example.com http: paths: - path: '/*' backend: serviceName: 'www-app' servicePort: 80 - host: www.dev.example.com http: paths: - path: '/*' backend: serviceName: 'www-app' servicePort: 80 - host: ep.dev.example.com http: paths: - path: '/api/v1/*' backend: serviceName: 'ri-adapter-app' servicePort: 80

А как он их потеряет?

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

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

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

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

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

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

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

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

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

а что это за веб-морда?

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

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

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

мы сделали так: задеплоили нджинкс ингресс демонсетом и высунули его наружу через сервис тип лб и включили local

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

мы сделали так: задеплоили нджинкс ингресс демонсетом и высунули его наружу через сервис тип лб и включили local

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

у меня три бука, три ос, хочу один кубернейт кластер

Только линукс

пытаюсь на minikube запустить postgres, который будет pgdata писать на хостовую машину. Получаю fixing permissions on existing directory /home/olegsmetanin/urhome/pgdata ... ok initdb: could not create directory "/home/olegsmetanin/urhome/pgdata/pg_wal": Permission denied никто не борол?

Какую ещё хостовую?

хочу чтобы postgres в minikube писал pgdata мне в локальную фаловую систему, а не в файловую систему minikube

хочу чтобы postgres в minikube писал pgdata мне в локальную фаловую систему, а не в файловую систему minikube

А зачем так? Используйте персистент вольем

Дело в том. Что когда маунтится директория, она маунтится от рута, нужно изменять права что бы постгресс мог писать в нее. Т.к. постгресс, скорее всего запущен от юзера постгресс

Так в этом и загвоздка, судя по докерфайлу постгре действует от имени пользователя 999:999, а у него прав не хватает

Так у меня нет на хвостовой машине такого пользователя, securityContext не помог

может повлиять?

Всем привет! Снова попытаюсь задать вопрос по Helm. Использую свой репозиторий с чартами на базе S3 ( https://github.com/hypnoglow/helm-s3) Проблема следующая: Есть devel релиз app-0.1.1-dev+30. На стадии CI пушится в репозиторий новый чарт с именем "app-0.1.1-dev+31. Далее делаю следующие шаги в CI на стадии деплоя: kubectl exec -it helm-deploy-0 -n deploy -- helm repo update kubectl exec -it helm-deploy-0 -n deploy -- helm s3 reindex repo kubectl exec -it helm-deploy-0 -n deploy -- helm upgrade --install --namespace develop dev-app -f /values/dev-app.yaml myrepo/app --devel --recreate-pods Делаю helm ls и вижу что текущая версия чарта app-0.1.1-dev+30, но по факту как я понимаю должна быть app-0.1.1-dev+31. Или я чего то не понимаю, или это нормальная работа helm?

Вообщем коллеги, опытным путем выяснил что подобная проблема будет встречатся с названиями app-0.1.1-dev+31 и т.д. Если используем именование app-0.1.1-dev.31, то все работает нормально

хочется победить мультилайны наконец однозначно как то. сейчас приложения пишут в свои лог файлы, агенты эти логи парсят и отправляют. а хотелось бы писать в docker stdout\stderr. но gelf юзать не хочется, вариант с journald выглядит адекватнее json, но хотелось бы прояснить как дела с мультилайном при такой схеме (на каком этапе их склейка происходит) и можно ли игнорить контейнеры по маске, например

хочется победить мультилайны наконец однозначно как то. сейчас приложения пишут в свои лог файлы, агенты эти логи парсят и отправляют. а хотелось бы писать в docker stdout\stderr. но gelf юзать не хочется, вариант с journald выглядит адекватнее json, но хотелось бы прояснить как дела с мультилайном при такой схеме (на каком этапе их склейка происходит) и можно ли игнорить контейнеры по маске, например

У нас мультилайны вроде как не работают

Мне кажется, что бороться с мультилайнами надо все-таки на уровне приложений. И, кстати, под капотом journald тот же json :)

блин, а как же длинные трейсы? =)

Приложения которые генерят длинные трэйсы отправляют их через gelf udp. Journald вроде как умеет multiline. Непонятно только как docker работает в этой ситуации

апп сам шлет udp пакет? при падении аппа это адекватно отрабатывает вообще?

Да. У меня подключается через pv

pvc из pinding не выходит для pv, который на hostPath. Есть пример рабочей конфы?

Так у меня нет на хвостовой машине такого пользователя, securityContext не помог