у меня где-то в дальних планах есть задача написать a/b тестирование

темплейт он сразу для контроллера

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

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

у тебя есть представление как раотает ингресс-контроллер?

извини что ворпсом на вопрос

таки образом ты не изменишь настройки для конкретного vhost

в контроллере есть ряд переменных передаваемых через annotations

по сути там есть легкий демон, который постоянно тыркается в апи и получает ing (можно установтиь что бы работал только на конкретный namespace)

у тебя есть представление как раотает ингресс-контроллер?

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

после счего смотрит есть ли изминения относительно текущего конфига nginx, если есть то сохдает нвый конфиг из tmpl и перезапускает nginx

Да. Но для этой переменной нужен обработчик) в контроллере

Да. Но для этой переменной нужен обработчик) в контроллере

Это контроллер нужно переписывать?)

да

. А есть какой-то способ получить в консоли содержимое секрета не в формате base64?

kubectl че-то там | jq еще че-то там | base64 -d ?

kubectl че-то там | jq еще че-то там | base64 -d ?

Да. Примерно так я и сделал)

kubectl че-то там | jq еще че-то там | base64 -d ?

бггг "kuberenetes на ощупь" (c)

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

как будто другие пермутации в терминале иначе делаются

kubectl тяп-ляп | jq коллега-что-то-подсказал-две-недели-назад | дальше не помню

да

А ведь я могу использовать имя хоста в темплейте?

{{ if $hostname == (или как там пишется условие равенства) }}

Думается что да

можно использовать уже существующие переменные

можно использовать уже существующие переменные

А что за язык, на котором темплейт?

go template

можно получить из секрета. надо сделать decode

если есть helm можно поставить stable/jenkins и посмотреть команду

либо в чарте его

eviction manager: no observation found for eviction signal allocatableNodeFs.available - так это гавно починить? на 1.7.2

под кюблетом нету тонны df процессов?

вроде нет

а в логах на тему NodeFs?

Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>}]} ExperimentalQOSReserved:map[]}

--eviction-hard?

его прямо в systemd поставить?

кто нибудь использует storage classes, dinamic provisioning?

я использую, на цеф

что интрересует?

как за местом следишь?

его прямо в systemd поставить?

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

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

и ещё вопрос. у меня провижионер отпадал, сейчас полсотни контейнеров в статусе terminating уже сутки висят, grace-period=0 не помогает

как за местом следишь?

цеф монитрится отдельно

то есть перед тем как сделать claim нет проверок никаких?

Could not get instant cpu stats: different number of cpus - вот еще...

застопал все kubelets, остановил докеры, убил докеры запустил, заработало....

а /var/lib/etcd нужно как то реплицировать отдельно, или оно вытянет с мастера по дискавери все?

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

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

угу - понял.. ну вот он "подсасывает".. а потом крашиться на всех нодах...

container "etcd" is unhealthy, it will be killed and re-created. Aug 02 19:31:40 kubelet[11626]: W0802 19:31:40.590748 11626 helpers.go:771] eviction manager: no observation found for eviction signal allocatableNodeFs.available

member "etcd-1" has previously registered with discovery service token But etcd could not find valid cluster configuration in the given data dir (/var/lib/etcd).

/var/lib/etcd/ - не пустой

volumeMounts: - mountPath: /etc/nginx/template name: template-volume volumes: - configMap: defaultMode: 420 name: nginx-template name: template-volume

Что-то не работает, хоть это и написано в документации. Error: exit status 1 2017/08/03 08:12:16 [emerg] 480#480: "map_hash_bucket_size" directive is duplicate in /tmp/nginx-cfg691280194:61 nginx: [emerg] "map_hash_bucket_size" directive is duplicate in /tmp/nginx-cfg691280194:61 nginx: configuration file /tmp/nginx-cfg691280194 test failed

map_hash_bucket_size" directive is duplicate in

Ошибка в темплейте

Создаётся очень много файлов в каталоге /tmp с именем /tmp/nginx-cfg В темплейте только одна такая директива.

nginx считает что не так

Да и в этих файлах тоже одна эта директива. Может, просто он пытается добавить все эти файлы...

нет только один

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

В общем случае тот же, что и liveness =)

Так а какой конкретно код?

Я пока кроме 503 ничего не придумала

Вроде, другого специального никакого нет.

положительным счтитается код 200

http ok

200, иначе куб пульнет туда трафик раньше, чем под войдет в рабочий режим

любой другой воспринимается как феил

200, иначе куб пульнет туда трафик раньше, чем под войдет в рабочий режим

с точностью до наоборот

В общем случае тот же, что и liveness =)

в теории: liveness - должна отвечать на вопрос "надо ли перезапускать под". т.е. не должна включать в себя внешние зависимости (скажем обращения к внешним базам данных и проч, т..к если внешняя зависимость сломалась, то перезапускать под вряд ли поможет). но должна включать максимум внутреннего кода: те же thread pools, те же локи, фильттры и проч что может сломаться. readiness - должна отвечать на вопрос "можно ли слать клиентский трафик на под", т.е. в теории может включать и внешние зависимости, если скажем подключение к ним проблемное (а с другго пода будет ОК возможно).

на практике все лепят один и тот же /version.txt какой-нибудь, который работает всегда, даже если основной код весь в дедлоках и не отвечает ни на что :)

в теории: liveness - должна отвечать на вопрос "надо ли перезапускать под". т.е. не должна включать в себя внешние зависимости (скажем обращения к внешним базам данных и проч, т..к если внешняя зависимость сломалась, то перезапускать под вряд ли поможет). но должна включать максимум внутреннего кода: те же thread pools, те же локи, фильттры и проч что может сломаться. readiness - должна отвечать на вопрос "можно ли слать клиентский трафик на под", т.е. в теории может включать и внешние зависимости, если скажем подключение к ним проблемное (а с другго пода будет ОК возможно).

Все ок, но ответ на другой вопрос))))

Это вопрос к тому, используешь ты liveness и readness правильно, или как затычку в коде для галки)

на практике обычно readness запускается раньше liveness =)

типо Админы площадки просили разработать ну мы и разработали

на практике обычно readness запускается раньше liveness =)

Это разные пробы, с разным назначением Let Eat Bee написал в чем разница

в теории: liveness - должна отвечать на вопрос "надо ли перезапускать под". т.е. не должна включать в себя внешние зависимости (скажем обращения к внешним базам данных и проч, т..к если внешняя зависимость сломалась, то перезапускать под вряд ли поможет). но должна включать максимум внутреннего кода: те же thread pools, те же локи, фильттры и проч что может сломаться. readiness - должна отвечать на вопрос "можно ли слать клиентский трафик на под", т.е. в теории может включать и внешние зависимости, если скажем подключение к ним проблемное (а с другго пода будет ОК возможно).

Читай и думай

Так а какой конкретно код?

Вопрос был про код, когда сервис НЕ ГОТОВ

на практике обычно readness запускается раньше liveness =)

На практике они запускаются одновременно)

Это разные пробы, с разным назначением Let Eat Bee написал в чем разница

ну что ты пристал?) я понимаю их различие =)