Oleg
minikube v0.28.0
Oleg
а, походу в 0.28.1 поправили vboxsf Host Mounting fixed
Oleg
да, починилось, сори за беспокойство
Olexander
добрый вечер, подскажите пожалуйста, я могу создать кластер из убунту, мак и виндо машин?
Olexander
без виртуалок
Andor
что?
Olexander
у меня три бука, три ос, хочу один кубернейт кластер
Andor
ну поставь везде линуксы
Olexander
если вопрос некорректный подскажите пожалуйста, я нулячий
Olexander
не хочу линуксы, хочу что есть оставить
Stas
на сколько я слышал можно добавить виндовую машину как воркера, но мастера должны быть на линуксе
Olexander
на сколько я слышал можно добавить виндовую машину как воркера, но мастера должны быть на линуксе
а можно ссылку? мастер на убунте планировал сделать
Valerii
очевидно же что ингрес ресурс никак не поможет нам понять где ьам бэкенды и хелчеки с точки зрения гуглового балансировщика
При этом, когда выставлено
externalTrafficPolicy: Local
и healthcheck в консоли гугла фейлится, трафик через какое-то время таки приходит в приложение и я успешно отлавливаю клиентские IPшники :)
Andor
а что это за веб-морда?
Valerii
Вот этот зафейленный healthcheck очень хочется поправить как-то. Потому что это всего-лишь dev окружение, хрен бы с ним, а вот дальше такое пропускать не охота...
Andor
а, блин
Nik
Deployment.apps "sftp" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"sftp"}: selector does not match template labels
Nik
Вот блин - вполне валидно все, а k8s жалуется.
template:
metadata:
labels:
app: sftp
ЧЯДНТ?
Valerii
очевидно же что ингрес ресурс никак не поможет нам понять где ьам бэкенды и хелчеки с точки зрения гуглового балансировщика
Ну а тестирую на простом nginx'е:
server {
listen 80;
set_real_ip_from 0.0.0.0/0;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
location /health {
access_log off;
default_type text/plain;
return 200 'OK';
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
Stas
Вот этот зафейленный healthcheck очень хочется поправить как-то. Потому что это всего-лишь dev окружение, хрен бы с ним, а вот дальше такое пропускать не охота...
отвлечемся, а почему нужно использовать родной ингресс контроллер? это же дорого и гемморойно потом с сертификатами редиректами и прочим?
Stas
и судя по гуглингу скорому ам полтора миллиона проблем в том числе и с хелсчеками
Valerii
отвлечемся, а почему нужно использовать родной ингресс контроллер? это же дорого и гемморойно потом с сертификатами редиректами и прочим?
Дорого? С сертификатами никаких проблем не предвижу...ну т.е. я вполне себе использую letsencrypt и норм работает или вы о чём? С редиректами-то что? С http на https или насчёт rewrite'ов? Я в-общем только начинаю с K8s и GKE знакомиться, поэтому пробую поднять всё штатными средствами просто... Или у nginx ingress эта проблема отпадёт, т.к. там будет не NodePort, а ClusterIP у сервисов?
Stas
мы сделали так: задеплоили нджинкс ингресс демонсетом и высунули его наружу через сервис тип лб и включили local
Stas
задача пробросить айпишники в этом случае решается на уровне джинкса + на сколько я понимаю гугл на каждый ингресс ресурс создает балансировщик, внешний айпишник и рулы - все это стоит денег
Stas
в случае с джинксом - 1 айпи и один форвардинг рул. за правила ингрессов платить больше не нужно
Valerii
мы сделали так: задеплоили нджинкс ингресс демонсетом и высунули его наружу через сервис тип лб и включили local
Ну вот я так походу и сделаю уже.
Valerii
задача пробросить айпишники в этом случае решается на уровне джинкса + на сколько я понимаю гугл на каждый ингресс ресурс создает балансировщик, внешний айпишник и рулы - все это стоит денег
Ну да, вы правы. Для dev/staging окружения и одного ингресса хватит, наверное, а вот когда пойдёт prod + autoscaling всякий, то там насоздаётся этих ingress'ов и соответственно балансировщиков.... На AWS'е у меня сейчас autoscaling группа, в которую добавляются frontend ноды, на каждой из которых крутится локальный load balancer (haproxy). Но там эти локальные haproxy внешние aws lb не создают, конечно, а сервера добавляются в таргет группы автоскейлингом :)
Valerii
мы сделали так: задеплоили нджинкс ингресс демонсетом и высунули его наружу через сервис тип лб и включили local
Читаю вот доку: https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/installation.md Если я на фронте буду autoscaling использовать, то лучше Deployment или DaemonSet всё-таки? Хотелось бы на каждой фронтэнд ноде по одному nginx ingress'у иметь, ну и чтобы они динамически убивались/поднимались вместе с нодами.
Stas
вообще демонсет не нужен, но ьак как надо айпишники пробросить, а хелсчек мы не побороли пока, то стоит демонсет
Valerii
вообще демонсет не нужен, но ьак как надо айпишники пробросить, а хелсчек мы не побороли пока, то стоит демонсет
А в чём ваша проблема с healthcheck'ами? Тоже на GKE?
Dmytro
https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/
Andrey
никто не занимался скрещиванием ngrok и nginx-ingress-controller?
Andrey
о, нашёл
https://medium.com/@sppatel/automatic-generation-of-lets-encrypt-certificates-b15c664f3832
Andrey
надо ещё деплоймент с ngrok замутить, не вручную же его запускать всё время
Oleg
пытаюсь на 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
никто не борол?
Oleg
Какую ещё хостовую?
хочу чтобы postgres в minikube писал pgdata мне в локальную фаловую систему, а не в файловую систему minikube
Anonymous
хочу чтобы postgres в minikube писал pgdata мне в локальную фаловую систему, а не в файловую систему minikube
Я бы примаунтил хостовую директорию к директории постгресс
Oleg
Я так и сделал
Anonymous
И права на запись чтение есть?
Oleg
Так в этом и загвоздка, судя по докерфайлу постгре действует от имени пользователя 999:999, а у него прав не хватает
Anonymous
Дело в том. Что когда маунтится директория, она маунтится от рута, нужно изменять права что бы постгресс мог писать в нее. Т.к. постгресс, скорее всего запущен от юзера постгресс
Lex
хочу чтобы postgres в minikube писал pgdata мне в локальную фаловую систему, а не в файловую систему minikube
А зачем так? Используйте персистент вольем
Oleg
Дело в том. Что когда маунтится директория, она маунтится от рута, нужно изменять права что бы постгресс мог писать в нее. Т.к. постгресс, скорее всего запущен от юзера постгресс
Так у меня нет на хвостовой машине такого пользователя, securityContext не помог
Anonymous
Так в этом и загвоздка, судя по докерфайлу постгре действует от имени пользователя 999:999, а у него прав не хватает
Или проще всего. Запустить весь под от рута, всеравно для дева
Oleg
На крайний вариант можно докерфайл постреса переписать на рута, но хочется попроще вариант
Anonymous
Сча найду кусок
Anonymous
Так у меня нет на хвостовой машине такого пользователя, securityContext не помог
А как через контекст запускали?
Oleg
securityContext:
fsGroup: 1000
runAsUser: 0
Anonymous
securityContext:
fsGroup: 0
runAsUser: 0
Anonymous
попробуйте, должно покатить
Oleg
не, то же самое, "/home/olegsmetanin/urhome/pgdata/pg_wal": Permission denied
Oleg
и еще. я подключаю вольюм без pv прямо через hostPath
volumes:
- name: host-mount
hostPath:
path: {{ .Values.persistence.mountPath }}
Oleg
может повлиять?
Denis
Всем привет! Снова попытаюсь задать вопрос по 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, то все работает нормально
Sergey
Anton
docker journald log driver -> jornalbeat -> graylog
хочется победить мультилайны наконец однозначно как то. сейчас приложения пишут в свои лог файлы, агенты эти логи парсят и отправляют. а хотелось бы писать в docker stdout\stderr.
но gelf юзать не хочется, вариант с journald выглядит адекватнее json, но хотелось бы прояснить как дела с мультилайном при такой схеме (на каком этапе их склейка происходит) и можно ли игнорить контейнеры по маске, например
Vitalii
Pavel
хочется победить мультилайны наконец однозначно как то. сейчас приложения пишут в свои лог файлы, агенты эти логи парсят и отправляют. а хотелось бы писать в docker stdout\stderr.
но gelf юзать не хочется, вариант с journald выглядит адекватнее json, но хотелось бы прояснить как дела с мультилайном при такой схеме (на каком этапе их склейка происходит) и можно ли игнорить контейнеры по маске, например
Мне кажется, что бороться с мультилайнами надо все-таки на уровне приложений. И, кстати, под капотом journald тот же json :)
Anton
Мне кажется, что бороться с мультилайнами надо все-таки на уровне приложений. И, кстати, под капотом journald тот же json :)
свои сервисы уже сейчас начинают писать однострочным json, который можно куда угодно лить, но это гемор с агентом. если агент сажать в под - он может потерять логи на старте или остановке. если сажать в daemonset на каждую машину - нужно как то шарить логи, через hostPath - опять какие то костыли.
да и с docker stdout\stderr нужно что то делать
Vitalii
блин, а как же длинные трейсы? =)
Приложения которые генерят длинные трэйсы отправляют их через gelf udp.
Journald вроде как умеет multiline. Непонятно только как docker работает в этой ситуации
Anton
Приложения которые генерят длинные трэйсы отправляют их через gelf udp.
Journald вроде как умеет multiline. Непонятно только как docker работает в этой ситуации
апп сам шлет udp пакет? при падении аппа это адекватно отрабатывает вообще?
Vitalii
апп сам шлет udp пакет? при падении аппа это адекватно отрабатывает вообще?
Апп сам шлёт с помощью log4j2.
А при падении нет большой разницы udp или stdout мне кажется
Anton
тут просто обидно будет если сообщение не долетит, не успеет отправится. в общем как то одного единообразного решения не получается
Vitalii
Оно также в stderr может не успеть я думаю
Oleg
Да. У меня подключается через pv
pvc из pinding не выходит для pv, который на hostPath. Есть пример рабочей конфы?
Anonymous
pvc из pinding не выходит для pv, который на hostPath. Есть пример рабочей конфы?
https://pastebin.com/GDSHdDs4
Andrey
Andrey
большинство проблем в докере/кубере/вм возникает изза отсутствия базовых знаний и текущих абстракций