потому что у тебя вписано чтобы этот таргет дропался?

кто отключает на nginx-ingress hsts, поднимите руку

зачем вы тащите несмешной контент куда попало?

создай в ~/.kube

кто отключает на nginx-ingress hsts, поднимите руку

Коллеги, такие 2 вопроса: На GKE, когда задаю в service (type:NodePort) externalTrafficPolicy: Local то на GLB backend начинает отображаться, как UNHEALTHY (красный) и если зайти в него там же в веб консоли, то написано 1 of 2 instances healthyПри этом deployment, на который указывает этот service всего 1. Вопрос 1: почему 1 of 2? Как только убираю externalTrafficPolicy: Local (т.е. оно становится дефолтным externalTrafficPolicy: Cluster), то backend сразу становится HEALTHY. Вопрос 2: как сделать backend HEALTHY с externalTrafficPolicy: Local? Deployment и Service такие: apiVersion: apps/v1 kind: Deployment metadata: name: example-app labels: app: example-app spec: replicas: 1 selector: matchLabels: app: example-app template: metadata: labels: app: example-app spec: nodeSelector: app: '1' containers: - image: registry.gitlab.example.com/example/example:latest imagePullPolicy: Always name: example-app readinessProbe: httpGet: path: /health port: 80 ports: - containerPort: 80 name: example-http env: - name: test value: '1' imagePullSecrets: - name: regcred --- apiVersion: v1 kind: Service metadata: name: example-app spec: externalTrafficPolicy: Local type: NodePort ports: - port: 80 targetPort: 80 protocol: TCP name: example-http selector: app: example-app

создать директорию и туда все сложить ?

да

а какая цель всего этогл упражнения? пробросить ип клиента или что?

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

оказывается в новой версии прометея нужно добавлять в spec jobLabel: k8s-app

Всем привет! Снова попытаюсь задать вопрос по 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?

По хорошему, Вам надо указывать что-то типа —values image.tag=app-0.1.1-dev+31 при апгрейде чарта

или imagepullpolicy=always

Причем тут это?) Image с нужным образом правильно скачивается)

Если Вы используете хелм, то накатывать свежую версию следует через helm upgrade

*при чём

Смотря в каких случаях https://ru.m.wiktionary.org/wiki/%D0%BF%D1%80%D0%B8%D1%87%D1%91%D0%BC

Да, пробросить IP внешнего клиента до приложения.

Значит что-то Вы делаете не так

ЗАчем Вы пишите новый чарт?

На стадии CI пушится в репозиторий новый чарт

К вопросу не имеет отношения, но объясню. Разработчик делает пуш с тегом. На стадит выше в пайплайне запускается сценарии на python с symver и вытягивает тег. Если тег новый он вставляет в чарт и добавляется этот тэг имейдж. И получается app-0-1.2. Если тег старый или пуш без тэга, то берется последниц тег, плюсуется к немут+1 и добовляем piplineID. Потом это дело пушим репу и переходим на стадию деплоя

потому что пока вы в chart.yaml версию самого чарта не бампните у вас автоматом по имени чарта или по апп версии ничего не бампнится

не уверен что туда думаю, но может попробовать плюсик на нижнее подчеркивание заменить?

не уверен что туда думаю, но может попробовать плюсик на нижнее подчеркивание заменить?

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

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

ну все правильно происходит же. нод порт открывает тебе на каждой ноде порт для сервиса, но ендпоинт (то есть сам под с сервисом) есть не на каждрй ноде кластера. При выключенной политике локал разрешена балансировка между нодами, т.е. куб прокси отправит траффик на тут ноду на которой под есть, но при этом будет снат. Так как политика включена, то гугловый балансер чекает наличие эндпоинта на нодах и те на которых его нет помечает как зафейливших хелсчек

покажи конфиг балансировщика

чтобы отрезать?

Приветствую всех. Есть докер образ, который должен открывать много 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

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

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

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