за imagePullPolicy большое спасибо а зачем устанавливаете в окружение REDEPLOY_VARIABLE?

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

Понятно. Хочу уточнить нюанс: если imagePullPolicy установлен в always — это ведь не значит, что кубер будет сам периодически перевыкачивать latest, да? Это значит, что после kubectl image set deployments/deployment-name container-name=my-registry/docker-namespace/docker-repository, он выкачеет новый latest, так ведь?

Это значит, что даже есть такой образ уже есть на машине, он всё равно проверит наличие более свежего

Да, но когда?

Хм. Я запускал до сих пор деплоймент посредством kubectl image set...

да, kubectl set image менят поле image в деплойменте, по этому он и перезапускается. Точно так же его можно менять через kubectl edit интерактивно, через kubectl patch ... через kubectl apply -f ... и ещё не знаю сколько способов, но суть у них одна, внесение изменений в дейплоймент.

нет, если изменений небыло то не запустит

как в мане написано kubectl set env RESOURCE/NAME KEY_1=VAL_1

Если цель только перевыложить latest - лучше так

Перестаньте использовать latest и всё будет ок

У меня, например, для ветки stage используется такой способ для выкатки на тестирование автоматически. только там не :latest, а :stage, но суть та же.

Ну в смысле вешай там теги и катай на стейжинг автомагически

технически версию можно в аннотации сунуть

если я правильно понял вопрос - с любой сетью должны видеть по FQDN пода (в которой есть имя headless сервиса)

админы, шо за?

Да решил уточнить. Просто странно. В моем кластере этого не происходит

или в аннотациях чего?

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

а точно есть headless service и вы пишите правильно хостнейм? И что значит "видеть"? Пинговаться поды не будут но по телнету можно зайти на заэкспозженный порт по FQDN и порту

Хостнейм точно пишу правильно. Ну покрайней мере hostname -f на самом поде врать не будет. Видеть, имеется в виду взаимодействовать и обмениватся информацией к примеру. У меня обычный сервис по типу ClusterIP. Причем попробовал на нашем тестовом кластере это все дело развернуть, который деплоил не я. Там все завелось. Но какой сетевой плагин я не знаю.

host <service dns name> В контейнере делали?

cri-o емнип независимый проект

то-то он в kubernetes-incubator/cri-o обитает

кстати, если количество нод динамически не меняется то можно вот такой скрипт юзать (я для монги юзаю) ## ## Generate statefulset peer hostnames in the form $(statefulset name)-$(ordinal) ## and from host names and knowing service name generate pod dns names. ## I.e. for replicas=3 pod hostnames will be: ## $(statefulset name)-0 ## $(statefulset name)-1 ## $(statefulset name)-2 ## and pod dns names will be: ## $(statefulset name)-0.$(service name).$(namespace name).svc.cluster.local ## $(statefulset name)-1.$(service name).$(namespace name).svc.cluster.local ## $(statefulset name)-2.$(service name).$(namespace name).svc.cluster.local ## ## Links: ## https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-identity ## https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantee ## https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#srv-records ## function get_peers() { local stateful_set_name=${1:?} local service_name=${2:?} local replicas=${3:?} local my_dns_name=${4:?} local namespace_name=${5:?} local peers_dns_names="" for i in $(seq 0 $(($replicas - 1))); do local peers_dns_name="$stateful_set_name-$i.$service_name.$namespace_name.svc.cluster.local" if [[ "$peers_dns_name" != "$my_dns_name" ]]; then peers_dns_names="$peers_dns_names $peers_dns_name" fi done echo "$peers_dns_names" }

Было дело. Если есть желание почитать про то, как его полили говном, можно проскролить чуть выше