к поду что запускается на node1 цепляется imageID с нужным секретом, а к поду на node2 нет

Зайдите на ноду и дропните уже сохраненный имедж. Оно, бывает, тупит, если вы латест версию тянете

Зайдите на ноду и дропните уже сохраненный имедж. Оно, бывает, тупит, если вы латест версию тянете

не было ни одного. Помогло сделать docker login и docker pull [pause-image], после этого поехали другие автоматически

не было ни одного. Помогло сделать docker login и docker pull [pause-image], после этого поехали другие автоматически

Сраный докер :))

Ребята, подскажите самый человечный способ заставить поды DaemonSet'a перечитать configMap

скейлить до нуля и обратно

daemonset скейлить?

Я вот пока ничего, кроме удаления подов не придумал

daemonset скейлить?

меняешь ему nodeSelector, например

удалить поды по label

В общем без удаления пока никак, видимо

Ладно, всем спасибо

если приложение умное и умеет по сигналу перечитывать конфиг - зайти в каждый контейнер послать сигнал

ну или зайти внутрь каждого контейнера рестатртануть приложение что по сути равноценно удалению пода. а какие еще варианты?

Всем привет. Народ, подскажите, пожалуйста, кто как делает. Развернул себе мультимастер кластер (из 3 мастеров) на кубе, все на vps, кластер работает. Вопрос, кто как создает единую точку входа? Типа снаружи nginx как load balancer, а на его айпишник уже dns? Чет в голове не могу 2 + 2 сложить...

Вроде есть на это полиси

Всем привет. Народ, подскажите, пожалуйста, кто как делает. Развернул себе мультимастер кластер (из 3 мастеров) на кубе, все на vps, кластер работает. Вопрос, кто как создает единую точку входа? Типа снаружи nginx как load balancer, а на его айпишник уже dns? Чет в голове не могу 2 + 2 сложить...

Просто несколько А записей на все мастера

nginx ingress controller поставь

Такс, он у меня уже есть, походу я что то не докурил)

ну или зайти внутрь каждого контейнера рестатртануть приложение что по сути равноценно удалению пода. а какие еще варианты?

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

В общем, спасибо за наводку)

Коллеги, такие 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

Кстати, те, которые HEALTHY (т.е. с externalTrafficPolicy: Cluster) тоже 2 of 2 instances healthy пишут.

Купил я своим програмерам 3 одинаковых макбука. Два для работы и один запасной для командировок. Специфика нашего разработческого процесса требует установки и калибровки огромного количества разного софта и скриптов и занимает часов 12 на свежем компе. Алексею так хотелось скорее начать пользовать новую машинку, что сразу после окончания рабочего дня он засел за конфигурацию новой игрушки. Просидел он, видимо, всю ночь, его обнаружили спящим в кресле перед готовым к использованию ноутом. Ребята долго не думали, забрали компьютер и поставили перед ним "запасной" макбук, на экране которого светилось сообщение: "Форматирование диска окончено. Можно начать установку операционной системы", ну или примерно так. Когда Леша проснулся, сказать, что он удивился - ничего не сказать.

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

здрасти, я подскажите как в маке поправить кьюб конфиг из уже имеющегося ? немогу вообще найти у себя конфиг в $HOME или ~/.kube или в /etc/local/bin/ тратата kubectl config view Отвечает показывает пустышку

создай в ~/.kube

Кто стакливался с тем, что prometheus в кубере видит сервис, но рядом с endpoint стоит dropped?

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

это в /targets или в /service-discovery ?

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

а где это прописывают?!

вроде в /targets

это SD

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

в таргетс от не появляется из за того, что все таргеты dropped

ну конфиг смотри

релейбелинг с keep/drop

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

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

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

чтобы редиректа на https не было

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

Humor is an individual behaivor

создай в ~/.kube

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

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

А можно сразу с адресами эндпоинтов?

разрешаю :)

Парни, а кто-то уже пробовал использовать PodPreset в рамках AWS EKS ?

Коллеги, такие 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

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

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

да

да

cgfcb,j gjghj,e.

спасибо попробую

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

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

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

оказывается в новой версии прометея нужно добавлять в 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?

оказывается в новой версии прометея нужно добавлять в 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

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

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

или imagepullpolicy=always

Тут проблема Хелма

*при чём

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

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

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

Блин, а для кого я выше писал сообщение?) Что по вашему я еще использую)

*при чём

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

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

Я в курсе. В данном случае - как я сказал.

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

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

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

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

Артем, вы просто капитан очевидность! Если бы я делал все правильно, я бы не стал сюда писать)

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

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

Что? Не совсем понял, какой новый чарт?

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

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

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

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

а в какой момент вы бампите версию чарта в chart ямле?

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

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

Стэйджи в пайплане stages: - build - release - packaging - deploy На стадии packaging просиходит создание чарта. Версия, image tag и т.д. Потом делается пуш в репозитории и в конце helm s3 reindex. После этого этого начинается стадия deploy . Делаю helm repo search и вижу последняя версия app-0.1.1-dev+30 ? Дальше смотрю helm repo -l и вижу app-0.1.1-dev+31 и app-0.1.1-dev+30 есть. Вопрос почему он последней версией считает pp-0.1.1-dev+30 , а не app-0.1.1-dev+301 ? Есть подозрение что это бага плагина

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

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

Думаю врятли, нопопробовать конечно можно

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

Хэлм испульзует типизаю SemVer2 и там это доспускается

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

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

Я знаю. Но лэйблы то тут причем? Не совсем просто понимаю

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

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

Верное решение. Сейчас как раз хочу развернуть локально хэлм-репозитории и проверить это

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

То, что происходит правильно, т.е. так, как куб просили, я не сомневаюсь :) А как сделать так, как мне нужно-то? :) Т.е. чтобы пробросить трафик по доке для GKE с GLB на гугл ingress и далее, нужно для сервиса использовать NodePort + externalTrafficPolicy: Local..

ну он и пробрасывается на ту ноду на которой есть под

а на ту на которой нет не пробрасывается потому что она хелчек фейлит

или у тебя обе ноды в одной инстанс группе и она же бекенд?

Ноды в разных node-pools. Когда фейлится healthcheck, то красным в консоли весь бэкэнд горит. Не красиво. И разве в этом случае GLB не перестаёт роутить трафик туда и отдавать 500 клиенту?

Как сделать красиво-то? :)

да не может у тебя быть бэкенд хэлси если там эндпоинта нет

сделай демонсет - будет красиво

будет эндпоинт на каждой ноде

У меня есть ноды в кластере для других целей совсем, я не хочу, чтобы там app крутились вообще. Поэтому и разные node-pool'ы.

По сути разделение есть на app и db ноды.

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

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

Есть мысль сделать цикл и через helm это дело прогнать