rollback roll back a release to a previous revision

эмм. при чём здесь roolback? разверните вашу мысль

history смотришь и откатываешь к релизу

эмм. при чём здесь roolback? разверните вашу мысль

Что такое в вашем понимании "остановить"? Я не вижу таких опций

вот и я не вижу, поэтому и спрашиваю

потому что действия делает к8с, а не хелм

вот и я не вижу, поэтому и спрашиваю

это не суслик, откуда это понятие взялось у вас?

хелм сделал патч, дальше к8с работает

потому что действия делает к8с, а не хелм

+1

остановить - это просто. удалить ресурсы связанные с релизом, из кубера

я пробовал helm delete, но после него нельзя делать helm upgrade

helm delete --help helm delete --purge

я пробовал helm delete, но после него нельзя делать helm upgrade

helm upgrade --install

хм. может помочь, спасибо

из удалённого (но не пурженного) релиза можно получить json с values

вообще purge это крайние случаи. удалять не нужно. ведь даже failed первый релиз можно обновить с helm upgrade --install --force

и развернуть с ним новый релиз ?

Да, заменил kubedns на coredns (по памяти)

А в каком окружении работали не скажете? Версия кубера, докера, оси?

helm upgrade --install

не. UPGRADE FAILED: has no deployed releases

в смысле не помогало? kubedns выжирал весь проц на ноде или что происходило?

Ресурсы на ноде kube-dns особо не потребляет, более того, на Ubuntu 16 я такой проблемы не наблюдал, на Ubuntu 18 начала стрелять, нода та же самая.

не. UPGRADE FAILED: has no deployed releases

helm ls -a посмотри релиз в каком статусе

deleted, конечно же

вроде —install —force сработал

мне просто надо, чтоб upgrade из удалённого релиза values взял

вероятно там будет ответ или он был во время доклада с анонсом

Вопрос то очень актуальный. Интересно почему не вынесли сразу его.

мда, похоже, не берёт

так а 'helm get values <release_name>' не подходит?

да подходит, просто тогда надо будет эти values сохранять куда-то перед переустановкой

задача вроде простая, а инструментов нет

надо остановить релиз, и поднять новую версию с одной изменённой переменной

а остальные при этом взять из старого

если б останавливать релиз не надо было, я бы просто сделал upgrade —reuse-values —set var=value

upgrade —install —force —reuse-values не берёт values из удалённого релиза

А в каком окружении работали не скажете? Версия кубера, докера, оси?

Centos docker 17.12 Kuber GitVersion:"v1.9.4"

можно ли сделать имя пода фиксированным? (если deployment)

надо остановить релиз, и поднять новую версию с одной изменённой переменной

можно делать scale=0

после наката апгрейда скейлить вверх

helm scale? нет такой команды

kubectl =)

это тогда надо знать содержимое чарта

А нужен ли helm?

для многокомпонетного релиза - да

иначе я запарюсь пайплайны для выката делать

это тогда надо знать содержимое чарта

ок, через --set выставлять replicas=0

что я все за вас думаю то

да вы думаете не за меня, а за мной. Такой вариант тоже не подходит, потому что там не только deployment-ы

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

Ребятки, кто-нибудь пробововал NodePort для нод на AWS?

Вопрос то очень актуальный. Интересно почему не вынесли сразу его.

Я например не смотрел анонс, может там был ответ )

остановился на # пробуем helm upgrade --tls --dry-run --reuse-values --set var=newvalue release package # сохраняем текущий номер ревизии helm history --tls -o yaml --max 1 release | grep revision: | awk '{print $2}' > currentreleaserevision # сохраняем текущую конфигурацию helm get values --tls release > currentreleasevalues.yaml # удаляем helm delete --tls --no-hooks release # ставим новую версию со старой конфигурацией, с подмешанной новой переменной helm upgrade --tls --wait --install --force --values currentreleasevalues.yaml --set var=newvalue release) package # если свались, делаем откат helm rollback --tls --wait --no-hooks release `cat currentreleaserevision`

Ресурсы на ноде kube-dns особо не потребляет, более того, на Ubuntu 16 я такой проблемы не наблюдал, на Ubuntu 18 начала стрелять, нода та же самая.

о как, интересно

в смысле не помогало? kubedns выжирал весь проц на ноде или что происходило?

Кубе днс сами себя не резолвили, добавление ещё 2х под не помогло.

это на 18.04?

centos

ага, т.е. тут 2 разных случая смешано в чате

я не уверен что kube-dns должен уметь себя резолвить, зачем это может быть нужно?

я не уверен что kube-dns должен уметь себя резолвить, зачем это может быть нужно?

пода кубе-днс состоит из 3 контейнеров, один из контейнеров делает лайвнесс пробу другого и если не видит - ресетит поду.

https://sweetcode.io/a-first-look-at-the-helm-3-plan/ немного есть тут

Было говно, стало говно с мочей, ну что за

простите, эмоции

пода кубе-днс состоит из 3 контейнеров, один из контейнеров делает лайвнесс пробу другого и если не видит - ресетит поду.

а можно поподробнее? там 3 контейнера, dnsmasq должен ходит локально в kube-dns на локалхост:порт, третий контейнер nanny которая из оба чекает опять же на локалхосте https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/kube-dns/kube-dns.yaml.base#L202

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

>Our work on Helm Lua is still very much in its proof-of-concept stage, but we’re looking at a syntax that would be at once familiar and flexible ахахаххаха

ну хоть тиллер вырезали

да ладно же, я обеими руками за Lua

в нжинксе тоже Lua, не нужно плодить сущности

а я что-то говорил о хостнейм? :) На определенном пороге (около 20 под запущено) увидел что под с кубе-днс начала рестартовать часто. Полез в логи, dnsmaq выдавал Maximum number of concurrent DNS queries reached (max: 150) В этот момент sidecar ругался что dnsmasq не отвечает, поєтому ему страшно и он ресетит сервис

увеличение этого порога с 150 до 300 не помогло

в нжинксе тоже Lua, не нужно плодить сущности

мало ли где Lua есть, только вот решение "для редактирования yaml теперь вот вам язык программирования" как минимум странное

Кубе днс сами себя не резолвили, добавление ещё 2х под не помогло.

не резолвили это обычно про днс же

мало ли где Lua есть, только вот решение "для редактирования yaml теперь вот вам язык программирования" как минимум странное

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

рабочего какого-то решения данной проблемы не увидел, обновлять кубер не хотелось, увидел что один из вариантов - замена на коре-днс. и типа на него кубер перешел в новых версиях (или переходит?)

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

это аргумент "ачотаково, все так делают"?

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

нет, это аргумент о стандартизации

не резолвили это обычно про днс же

сорри, не правильно выразился. Он не получал ответа от сервиса

сорри, не правильно выразился. Он не получал ответа от сервиса

обычно это сообщение про 150 запросов не приводит к рестарту (по крайней мере из моих наблюдений), а вот низкие цпу лимиты - да (т.к. не отвечает kube-dns контейнер за таймаут)

цпу лимиты были дефолтные

если не помогает убрать или поднять лимиты - нужно увеличивать количество реплик. Но прежде стоит посмотреть на логки dnsmasq и ndots у подов

первое решение которое сделал - увеличил колличество под с кубе-днс до 3х

они достаточно низкие, если у вас приложения не кешируют днс на какое-то время а фигачат кучу днс запросов - нужно увличить

падений стало меньше, но падали поочереди все поды с кубе-днс ;)

например, у соседнй команды было пхп приложение которое на каждую страницу ходило до 400 раз в мемкеш по днс

они там наебались...

да, учту при дальнейших вопросах

обычно это сообщение про 150 запросов не приводит к рестарту (по крайней мере из моих наблюдений), а вот низкие цпу лимиты - да (т.к. не отвечает kube-dns контейнер за таймаут)

у меня сейчас в кластере две ноды - одна с ub18, вторая - ub16. kube-dns раскидал два пода на эти ноды. на ub16 - всё работает без рестартов, на ub18 под растартуется через 3-5 минут с тем же сообщением

да, учту при дальнейших вопросах

еще вот на секцию Pod’s DNS Config посмотрите тут https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods

если вкратце, то по дефолту обычно стоит ndots:5 и на каждый днс резолв летит вместо одного запроса пачка вида <dns>.svc.local, т.е. все внешние ресурсы сначала внутри кластера

плюс еще летят всегда ipv4 и ipv6 резолвы

все это можно увидеть в логах dnsmasq если их включить

т.е. на один днс резолв от приложения выходит до 10 (по моим прикидкам) днс запросов

у меня сейчас в кластере две ноды - одна с ub18, вторая - ub16. kube-dns раскидал два пода на эти ноды. на ub16 - всё работает без рестартов, на ub18 под растартуется через 3-5 минут с тем же сообщением

интересно а cpu quota usage одинаковый? и еще я бы попробовал поды с ноды с у18 переместит на у16 а с той на у18, может просто больше днс запросов генерят поды на этой ноде а днс запросы сервис роутит на ближайший под - т.е. на это же ноде

Да, видел, как вариант снижения нагрузки - прописывание полного адреса сервиса вплодь до точки на конце. Не помогло, но на всякий пожарный теперь делаю так

интересно а cpu quota usage одинаковый? и еще я бы попробовал поды с ноды с у18 переместит на у16 а с той на у18, может просто больше днс запросов генерят поды на этой ноде а днс запросы сервис роутит на ближайший под - т.е. на это же ноде

да, квота одинаковая - ноды по железу одинаковые, а вот на ноде с ub16 как раз подов больше работающих, а на ub18 только сервисные

квота одинаковая но вот сколько из квоты использовано одним подом и сколько другим?

по логам получается сначала dnsmasq отваливается I0725 15:08:54.586875 1 nanny.go:116] dnsmasq[18]: using nameserver 127.0.0.1#10053 for domain cluster.local I0725 15:08:54.586885 1 nanny.go:116] dnsmasq[18]: using nameserver 127.0.0.53#53 I0725 15:08:54.586893 1 nanny.go:116] dnsmasq[18]: read /etc/hosts - 7 addresses I0725 15:12:48.143322 1 nanny.go:116] dnsmasq[18]: Maximum number of concurrent DNS queries reached (max: 150) I0725 15:12:58.154825 1 nanny.go:116] dnsmasq[18]: Maximum number of concurrent DNS queries reached (max: 150)

я бы еще пробовал все-таки включить логи dnsmasq посмотреть что там приходит то

Да, видел, как вариант снижения нагрузки - прописывание полного адреса сервиса вплодь до точки на конце. Не помогло, но на всякий пожарный теперь делаю так

либо настроить ndots в каждом таком dns intensive поде (или вообще во всех)

потом sidecar перестает метрики получать I0725 15:08:59.144350 1 dnsprobe.go:75] Starting dnsProbe {Label:kubedns Server:127.0.0.1:10053 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:1} I0725 15:08:59.144397 1 dnsprobe.go:75] Starting dnsProbe {Label:dnsmasq Server:127.0.0.1:53 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:1} W0725 15:12:51.207223 1 server.go:64] Error getting metrics from dnsmasq: read udp 127.0.0.1:39414->127.0.0.1:53: i/o timeout W0725 15:13:05.150423 1 server.go:64] Error getting metrics from dnsmasq: read udp 127.0.0.1:44531->127.0.0.1:53: i/o timeout