Подскажите по nginx-ingress. Мне нужно сделать сайт доступным только с определённых ip. Нашёл только аннотацию: ingress.kubernetes.io/whitelist-source-range. Но там, как я понял, указывается диапазон. Как прописать определённые адреса?

Несколько аннотаций с cidrами попробуйте

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

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

Спасибо.

Можнр еще SubPath использовать для указания на файл

https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath

А где-то можно почитать, что в этом темплейте значат, например, такие конструкции: $cfg := .Cfg ?

https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/

Ребят, кто helm использует, а как там разруливать доступ к нескольким кластерам? Например есть у меня minikube локальный и кубы в проде/стейджинге. helm init вроде как работает с текущим контекстом, как разрулить?

хм нашел --kube-context делает вроде бы, что нужно

А можно сделать как нибудь у пода qos=guaranteed без установки cpu limit?

Ну или разрешить роду реюзать цпу если на ноде много лишнего

Поду *

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

А могу я параметр для конкретного ингресса передать? Например, у меня в шаблоне есть {{ if $check }} И мне нужно, чтобы это добавилось только для определённого хоста.

вмысле для конкретного ингресс-контроллера?

или для контретного правила ing?

или для контретного правила ing?

Да. Для правила.

ммм

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

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

у меня где-то в дальних планах есть задача написать 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 нет проверок никаких?

ERROR: S client not available

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 правильно, или как затычку в коде для галки)