и залезают по самые помидоры с правами администратора

Ну и за пределы этого постгреса они никуда не уйдут, не?

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

я условно про кибану. конечно же не она

Или суперпользователь в postgress даёт какие-то дополнительные привелегии кроме как владением root базой данных?

я например

извращенцы

не, я просто пытаюсь понять, если сервис единственный и ходит в базу postgres, нужна ли ему там отдельная база и юзер там, если никто кроме него её никогда использовать не будет

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

извращенцы

схерали

ну мониторинг и бэкап разве что

мониторинг вообще обычно везде ходит. а защищают его х*й пойми как всегда

Привет всем. пытаюсь деплоить с гитлаба так - kubectl create secret -n "$NAMESPACE_NAME" docker-registry gitlab-registry —docker-server="$CI_REGISTRY" —docker-username="$REGISTRY_DEPLOY_LOGIN" —docker-password="$REGISTRY_DEPLOY_TOKEN" —docker-email="$GITLAB_USER_EMAIL" -o yaml —dry-run | kubectl replace -n "$NAMESPACE_NAME" —force -f - imagePullSecrets: - name: gitlab-registry но не всегда почему то срабатывает, то есть иногда Secrets не принимает, точнее как будто он неправильный... в чем косяк ?

никто не вкурсе что может быть ???

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

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

извращенцы

всяко лучше чем go template

всяко лучше чем go template

😈

Ребята привет! А как вы генерите манифесты на build агенте? sed'ом?

Reclaim policy : Delete я правильно понял что pv удаляется при удалении pvc ?

И еще момент, как скоро шедулер перекинет под с мертвой ноды на живую?

Где почитать об этом?

Ребята привет! А как вы генерите манифесты на build агенте? sed'ом?

Sed - самое плохое. Template engine какой-нибудь. Gomplate чтоб одним бинарником. Ну ли jinja, Python вроде есть везде

Reclaim policy : Delete я правильно понял что pv удаляется при удалении pvc ?

да

Sed - самое плохое. Template engine какой-нибудь. Gomplate чтоб одним бинарником. Ну ли jinja, Python вроде есть везде

может поделишься какой-нибудь практикой? Если не сложно.

И еще момент, как скоро шедулер перекинет под с мертвой ноды на живую?

никогда

никогда

Хммм, а вот это грустно

А что произойдет тогда?

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

https://github.com/kvaps/kube-fencing

Ребята привет! А как вы генерите манифесты на build агенте? sed'ом?

k8s-handle, хотя уже неслабо припекает от ямлов и jinja в одном флаконе :D

https://github.com/kvaps/kube-fencing

О, крутая штука

может поделишься какой-нибудь практикой? Если не сложно.

есть миллион способов kustomize qbec/ksonnet ansible k8s terraform ensubst sed <очередная самодельная тулза от крупной компании> <очередная самодельная тулза от молодой компании>

Спасибо за советы

есть миллион способов kustomize qbec/ksonnet ansible k8s terraform ensubst sed <очередная самодельная тулза от крупной компании> <очередная самодельная тулза от молодой компании>

jinja еще

sed и башево-энвсабстовая шаблонизация это реально грустно, лучше не надо

может поделишься какой-нибудь практикой? Если не сложно.

Ну вот глянь репо https://github.com/IgoNsk/php-k8s/ Это с доклада про PHP в Kube, там на Junja2. Слайды доклада там же

https://github.com/kvaps/kube-fencing

>The next fencing agetns are included: опечатка, кстати => agetns :-)

>The next fencing agetns are included: опечатка, кстати => agetns :-)

fixed

https://github.com/kvaps/kube-fencing

Полезная тулза

Спасибо!

Я правильно понимаю что в таком случае лучше окружение в statefulset запихивать

Elastic, Redis

(хотя они априори стейтфулсеты)

Ну в StatefulSet имеет смысл запихивать то что имеет стейт)

Ну в StatefulSet имеет смысл запихивать то что имеет стейт)

Резонно

Всем привет Можете помочь ответом на вопрос. Почему при переключении контекста в кубе, с default на мой, kubectl на любой запрос возвращает The connection to the server localhost:8080 was refused – did you specify the right host or port?

кубконфига нет

~/.kube/config есть. kubectl cluster-info показывает все правильно

при этом контейнер API сервера запущен

~/.kube/config есть. kubectl cluster-info показывает все правильно

делайте kubectl --kubeconfig /etc/kubernetes/admin.conf <command>

Если сработает значит конфиг неправильный

)

Страно. Со стандартным конфигом заработал, но если переключить в дефолтный контекс и указать ему ~/.kube# kubectl --kubeconfig config get po No resources found. То тоже все работает

Народ, всем привет! Продолжаю ж̶р̶а̶т̶ь̶ ̶к̶а̶к̶т̶у̶с̶ настраивать пром-оператора через хельм. на этот раз столкнулся с тем, что нужно заменить селектор, по которому оператор находит сервисмониторы. в шаблоне это выглядит так: {{- if .Values.prometheus.prometheusSpec.serviceMonitorSelector }} serviceMonitorSelector: {{ toYaml .Values.prometheus.prometheusSpec.serviceMonitorSelector | indent 4 }} {{ else if .Values.prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues }} serviceMonitorSelector: matchLabels: release: {{ .Release.Name | quote }} {{ else }} serviceMonitorSelector: {} {{- end }} {{- if .Values.prometheus.prometheusSpec.serviceMonitorNamespaceSelector }} то есть, селетор работает по release: {{ .Release.Name | quote }} Решил я, что хочу, чтобы мой селектор работал по правилу matchLabels: monitoring: {{ prom1 | quote }} как мне это записать в мой custom-values.yaml?

попробовал так (в разных вариациях): prometheus: prometheusSpec: serviceMonitorsSelector: monitoring: "prom1"не выходит

Я в nodeSelector пишу без кавычек. Может убрать на удачу? )

Ну и проверить полный путь до свойства prometheus: prometheusSpec: serviceMonitorsSelector: - возможно оно длинее

Я в nodeSelector пишу без кавычек. Может убрать на удачу? )

пробовал. говорю же, в разных вариациях)

в деплоймент это рендерится как spec.serviceMonitorSelector.matchLabels

Ну ты не потому пути идешь явно. Ты правишь свойства Proma, а это свойство оператора

точно! спасибо!

но тогда почему это живет в шаблоне чарта прома?

не оператора, а именно helm.templates.prometheus.prometheus.yaml

Я вообще обычно values.yaml смотрю и разгребаю структуру поднимаясь выше нужного свойства. У PromOp она конечно непростая.

Ну ты не потому пути идешь явно. Ты правишь свойства Proma, а это свойство оператора

подставил оператору. ничего не поменялось)

Нельзя просто взять и отпараметризовать Chart.jpg

нашел тут немного инфы https://github.com/coreos/prometheus-operator/issues/1359#issuecomment-394820646 попробовал так же сделать. результат прежний.

Или суперпользователь в postgress даёт какие-то дополнительные привелегии кроме как владением root базой данных?

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

Коллеги, поясните за pv и pvc пожалуйста. pv на уровне кластера создаётся, а pvc на уровне namespace?

Коллеги, поясните за pv и pvc пожалуйста. pv на уровне кластера создаётся, а pvc на уровне namespace?

PVC это запрос (claim) на хранилище

PV = persistent volume

Вопрос о том, можно ли pv создавать с привязкой к неймспейсу или эта сушность уникальна на весь кластер

можно

Ок спс

можно

или нет

можно

вообще-то нельзя

сек

да, что-то затупил. pvc делятся по нэймспэйсам

pv нет

Ага, внесли ясность