Копия @ironcladlou @ bgrant0607

Какой вариант использования для перезапуска модулей без каких-либо изменений в спецификации?

Обратите внимание, что не будет никакого способа отменить изменение, если поды начали давать сбой при перезапуске.

Всякий раз, когда службы попадают в какое-то заклинившее или нежелательное состояние (соединения исчерпаны и теперь остановлены, плохое внутреннее состояние и т. Д.). Обычно это один из первых шагов по устранению неполадок, если служба плохо себя ведет.

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

Кроме того, непрерывный перезапуск без изменения спецификации перераспределяет модули по
кластер.

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

В среду, 2 сентября 2015 г., в 0:01, Sam Ghods [email protected] написал:

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

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

Клейтон Коулман | Ведущий инженер, OpenShift

@smarterclayton Это похоже на мой вариант 2, указанный выше? Хотя зачем менять ярлыки?

Re. клин: Вот для чего нужны датчики живучести.

Re. ребалансировка: см. # 12140

Если бы мы поддерживали это, я бы добавил к нему # 9043 - требуется тот же механизм.

Я полагаю, это больше подходит для ситуации, когда модуль жив и отвечает на проверки, но все еще требует перезапуска. Одним из примеров является служба с кешем в памяти или внутренним состоянием, которое повреждено и требует очистки.

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

Коррупция была бы всего лишь одной капсулой, которую можно было бы просто убить и заменить RC.

Другой случай, упомянутый в автономном режиме, - это перечитывание конфигурации. Это опасно делать неявно, потому что перезапуск по любой причине заставит контейнеры загрузить новую конфигурацию. Было бы лучше выполнить скользящее обновление, чтобы отправить новую ссылку на конфигурацию с версией (например, в env var) в модули. Это похоже на мотив № 1353.

@ bgrant0607 мы решили, что не хотим этого делать?

@gmarek Пока ничего. Слишком много всего уже происходит.

Можем ли мы установить отметку post v1.1 (или что-то в этом роде) для вещей, которые мы считаем важными, но нам не хватает людей, чтобы исправить их прямо сейчас?

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

Я фанат этой функции. Пример использования: легко обновите все модули, чтобы использовать недавно загруженный образ докера (с imagePullPolicy: Always ). В настоящее время я использую немного хитрое решение: скользящее обновление с тегом :latest в имени изображения или без него.

Другой вариант использования: обновление секретов.

Очень хотелось бы увидеть эту особенность. Мы запускаем нодовые приложения на кубернетах, и в настоящее время у нас есть определенные варианты использования, когда мы перезапускаем поды, чтобы очистить псевдокеширование приложений.

Вот что я сейчас делаю:

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

Это удаляет 10 модулей за раз и хорошо работает в настроенном контроллере репликации. Он не решает никаких проблем, таких как распределение модулей или сбой запуска новых модулей. При необходимости это быстрое решение.

Я действительно хотел бы иметь возможность выполнить непрерывный перезапуск.
Основная причина в том, что мы будем передавать переменные ENV в модули с помощью ConfigMap, а затем, если мы изменим конфигурацию, нам нужно перезапустить потребителей этой ConfigMap.

Да, очень много случаев, когда вы действительно хотите перезапустить под / контейнер без изменений внутри ...
Конфиги, кеширование, переподключение к внешним сервисам и т. Д. Очень надеюсь, что эта функция будет развита.

Небольшая работа (я использую развертывания и хочу изменить конфигурации без реальных изменений образа / модуля):

• создать configMap
• создать развертывание с переменной ENV (вы будете использовать ее как индикатор для своего развертывания) в любом контейнере
• обновить configMap
• развертывание обновлений (измените эту переменную ENV)

k8s увидит, что определение развертывания было изменено, и начнет процесс замены модулей.
PS:
если у кого-то есть лучшее решение, поделитесь, пожалуйста

Спасибо @paunin

@paunin Это именно тот случай, когда он нам нужен сейчас - мы должны изменить значения ConfigMap, которые очень важны для служб и должны быть развернуты в контейнерах в течение нескольких минут или нескольких часов. Если в это время не произойдет развертывание, все контейнеры выйдут из строя одновременно, и у нас будет частичное время простоя не менее нескольких секунд.

from (вроде как # 9043): однострочный подход RESTART_ - это переменная среды, для которой установлена ​​временная метка ISO:

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(обратите внимание, что по какой-то причине переменные среды, начинающиеся с _ кажется, просто исчезают, а числовые env value s вызывают ошибки, они должны быть строками)

@paunin @rcoup Сейчас мы делаем что-то очень похожее, у нас есть env var, буквально называемая "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT".

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

какой прогресс в этом?

Мне кажется, что это добавление - ненужное раздувание CLI API. Этого можно легко добиться, обновив значения переменных среды развертывания, как предлагает @paunin .

Мы также хотели бы видеть это для развертываний, например, kubectl restart deployment some-api

Kubernetes может перезапускать поды по разным причинам, но администратору кластера не разрешено.
Я понимаю моральную позицию, согласно которой `` выключи и снова включи '' может быть нежелательным способом работы ... но я также думаю, что это должно быть нормально, если те люди, которые хотят, перезапустить развертывание, не прибегая к диапазону менее аппетитных трюков вроде:

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

«Нет-нет, я ничего не перезапускаю, просто исправляю опечатку в этом ярлыке здесь» 😛

Эта функция будет полезна в паре с kubectl apply : apply будет обновлять конфигурации, включая контроллеры репликации, но поды не будут перезапущены.

Итак, нам нужен способ перезапуска этих стручков сине-зеленым способом.

@DmitryRomanenko, а как насчет перехода с ReplicationControllers на Deployments? Это позволит вам запускать обновления ReplicaSets (преемника ReplicationController).

@kargakis это невозможно: развертывания обновляют только наборы реплик и поды.
С помощью kubectl apply мы также обновляем ConfigMaps, Services и т. Д.

@DmitryRomanenko, если проблема: «Я хочу перезапустить модули при обновлении ConfigMap / Secret», то возможное решение состоит в том, чтобы иметь версии для вашей ConfigMap и Secrets и сделать эту версию частью вашей спецификации развертывания. Таким образом, с kubectl apply ing спецификация развертывания изменяется, и поды воссоздаются.
В других ситуациях я не понимаю, почему Pods необходимо перезапускать (я имею в виду обновление Service / Ingress / и т. Д.).

@tyranron , спасибо! Как лучше всего установить версию ConfigMap s? Должен ли я создать новую карту конфигурации с другим именем для нового развертывания?

@DmitryRomanenko , а почему бы и нет? Но в этом случае стоит позаботиться об удалении старых. С другой стороны, это может быть полезно для отката. Но в большинстве случаев достаточно указать версию с помощью ярлыков.

Я действительно считаю, что лучшим решением здесь может быть какой-нибудь наблюдатель или средство проверки хеш-суммы для объекта configmap . Это должно вызвать перезапуск связанных объектов / модулей (все, что использует configmap , secret ). Не уверен, что это что-то доступное в архитектуре k8s хотя ...

Я также думаю, что лучше иметь управление от объекта configmap|secret чтобы запускать перезапуск при изменении или нет.

@tyranron ,

Таким образом, с применением kubectl спецификация развертывания изменяется, и поды воссоздаются.

Могли бы вы объяснить? Должен ли я просто использовать kubectl apply -f new_config.yml с обновленными развертываниями, и эти развертывания будут перезапускаться по очереди?

@DmitryRomanenko Ага , именно так.

@DmitryRomanenko с применением новых спецификаций вы обновляете Развертывание , а при обновлении Развертывания запускается перезапуск, если его спецификация была изменена.

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

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Предотвратить автоматическое закрытие проблем с помощью комментария /lifecycle frozen .

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или @fejta .
/ жизненный цикл устаревший

Небольшое изменение в решении @rcoup : убедитесь, что date оценивается в оболочке:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/ remove-жизненный цикл устаревший
/ жизненный цикл заморожен

Некоторое время я использовал режим Swarm, который считается менее гибким, чем Kubernetes, я могу перезапускать служебные задачи (читай: модули развертывания), просто выполняя принудительное обновление (без изменений в спецификациях), как в docker service update --force <service-name> . Я ожидал, что Kubernetes тоже сделает это.
Что касается конфигурационных карт и секретов, swarm не позволяет вам редактировать их, вместо этого вам нужно вращать их. Вы делаете это, создавая новые карты конфигурации / секреты, обновляя спецификацию службы, чтобы использовать новые, а затем удаляя старые. Я вижу, что это обычно то, что рекомендуется выше, путем создания версий ваших configmaps / secerts и обновления развертываний, которые их используют. Честно говоря, такое вращение - одна из основных причин, по которой я ушел из роя! Очень неудобно иметь локальную копию, обновлять, затем создавать новые ресурсы и, наконец, обновлять зависимые ресурсы. Добавьте к этому секреты в swarm не могут быть прочитаны из api, вы должны смонтировать их внутри любого контейнера (или exec внутри контейнера, который их использует), затем cat их файлы.
Кстати, я некоторое время использовал openshift и считаю, что он автоматически перезапускает поды при изменении env / configmap / secret? Но я исправлюсь.

приложение должно следить за изменениями файловой системы, как уже упоминалось, вы можете использовать контрольные суммы в configmap / secret и принудительно перезапускать таким образом

но если вы вообще не хотите менять конфигурацию, а просто выполняете скользящий перезапуск с произвольной паузой, то работу выполняет простой конвейер (он спит 30 секунд между завершенными модулями)

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

обратите внимание, что если вы нажмете ctrl + c, будет непросто перезапустить с того места, где вы остановились

@ so0k , альтернативная команда:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

Прошло два с половиной года, а люди все еще создают новые обходные пути, с фиктивными переменными env, фиктивными метками, боковыми картами ConfigMap и Secret watcher, масштабированием до нуля и прямыми сценариями оболочки для скользящего обновления, чтобы имитировать возможность запуска скользящего обновления. Неужели администраторы кластеров по-прежнему не должны делать этого честно, без уловок?

27081 # 33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

Еще один трюк - запустить:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

а потом:

kubectl set image deployment/my-deployment mycontainer=myimage

На самом деле он будет запускать скользящее обновление, но убедитесь, что у вас также установлен imagePullPolicy: «Always».

Еще одна хитрость, которую я обнаружил, когда вам не нужно изменять имя изображения, - это изменить значение поля, которое будет запускать скользящее обновление, например terminationGracePeriodSeconds. Вы можете сделать это с помощью kubectl edit deployment your_deployment или kubectl apply -f your_deployment.yaml или с помощью такого патча:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@ so0k @KIVagant удаление модулей означает простои, даже если запущено несколько экземпляров. Когда кто-то запускает один модуль с strategy.rollingUpdate.maxUnavailable = 0 при обычном развертывании сначала создается новый модуль, а затем завершается существующий. Уловка kubectl patch deployment вызывает такое поведение, а удаление модулей - нет. Я бы действительно хотел, чтобы не-взломанный способ запускал это поведение по требованию.

Например, при запуске образов с сайта hub.docker.com один и тот же тег может быть исправлен для обновлений безопасности. Я действительно хотел бы «извлечь последние образы» и выполнить непрерывное обновление для любого устаревшего образа.

Развертывание обновлений ConfigMap / Secret - # 22368
Более простой выпуск новых изображений - # 1697.
Постоянные обновления на месте - № 9043.

Перезапуск при сборке образов: https://github.com/GoogleCloudPlatform/freshpod
Презентация на саммите Helm трюка с использованием шаблонной аннотации для запуска развертывания развертывания: https://www.youtube.com/watch?v=dSw0w1x96ak

@ bgrant0607 Я думаю, что важный вариант использования, который не покрывается другими билетами, - это следующий: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

@ghodss написал:
Я полагаю, это больше подходит для ситуации, когда модуль жив и отвечает на проверки, но все еще требует перезапуска. Одним из примеров является служба с кешем в памяти или внутренним состоянием, которое повреждено и требует очистки.

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

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

У меня есть аналогичный однострочник, основанный на подходе, описанном @rcoup и @paunin , но он должен работать в более общем случае. Он полагается на вывод JSON и использует jq для анализа. У меня это загружено в мой bashrc как функция, поэтому я могу вызывать его где угодно

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

Это позволяет мне просто сказать: kubectl-restart my-deployment-name и он «обновит» переменную RESTART_ env в первом контейнере до текущей отметки времени. Я далек от эксперта по jq, поэтому может быть лучший способ сделать это, но в основном он удаляет старую переменную RESTART_ env из вывода (если она существует), а затем добавляет ее туда с Текущее время.

Мне действительно кажется очень странным, что нет собственного способа сделать это ... Конечно, комната, полная инженеров, согласятся, что возможность «выключить и снова включить» - это то, что мы хотели бы иметь.

Это хороший прием и все такое, но у него есть большой недостаток. При следующем развертывании с использованием kubectl apply -f этот компонент будет перезапущен, если он имеет переменную окружения RESTART_xxx, даже если больше ничего не изменится. Другими словами, он вызывает ложный перезапуск при следующем развертывании, если он когда-либо был перезапущен между последним развертыванием и этим развертыванием. Не идеально ...

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

Я написал функцию bash для выполнения стратегии «развертывание патчей terminationGracePeriodSeconds » @whereisaaron, цитируемой в его комментарии выше (источник: https://stackoverflow.com/a/40368520/90442).

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

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

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

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro Была ли у вас RESTART_xxx env var в конфигурации, которую вы применили, или нет? Если нет, то я ожидаю, что apply будет игнорировать лишнюю переменную env в живом состоянии.

cc @apelisse

@gjcarneiro Да, проблема со скриптом @mattdodge в том, что он использует apply, поэтому изменение будет сохранено в аннотации lastApplied. Сценарий можно исправить с помощью патча или другого метода обновления развертывания.

Хотелось бы иметь эту функцию. Это кажется очень простым и необходимым.

Никакого прогресса тут ни по # 22368, не вздох :-(

Может ли кто-нибудь порекомендовать быстрое и грязное решение для перезапуска DaemonSet после обновления смонтированного ConfigMap (имя все еще идентично)?

@alcohol , проверьте это https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

Спасибо за совет :-)

Openshift имеет концепцию триггеров развертывания, которые запускают развертывание при изменении образа, веб-перехватчика или изменения конфигурации. Было бы очень хорошо иметь в Kubernetes. А также, конечно, ручное развертывание.

Кроме того, у репозитория Docker есть история, поэтому нет причин, по которым откат не может работать - pod, созданный из .spec.template может использовать формат image-tag:@digest при извлечении изображений для контейнеров. При откате будет использоваться идентификатор дайджеста предыдущего развертывания.

Не уверен, правильно ли я понимаю. На всякий случай это кому-нибудь поможет.

Кажется, что если вы обновляете значение метки в модуле> шаблон> метаданные, то скользящее обновление происходит после того, как вы kubectl apply -f file.yaml

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

Конечно, недостатком является то, что в следующий раз, когда вы захотите выполнить развертывание, вы сделаете kubectl apply -f some.yaml , верно? Обычно, если в some.yaml ничего не меняется, ничего не перезапускается, и это одна из самых приятных особенностей Kubernetes.

Но представьте, что произойдет после того, как вы измените метку для перезапуска развертывания. При следующем обычном развертывании программного обеспечения вы выполняете kubectl apply -f some.yaml как обычно, но поскольку файл yaml не содержит такой же метки, развертывание будет без необходимости перезапущено.

@gjcarneiro Если вы не apply , когда вы вносите изменения, то kubectl.kubernetes.io/last-applied-configuration аннотацию не будет обновляться, так что следующий apply не будет причиной другой перезагрузки.

Я настоятельно рекомендую добавить в kubectl команду непрерывного перезапуска, но пока что я использую следующее (на основе решений, приведенных выше):

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

Параметризуйте это и добавьте как функцию в свой .bashrc, и это хорошее временное решение.

Ах, круто, я этого не знала, спасибо!

Мне не нужен псевдоним bash, в моей компании мы сделали мой собственный веб-интерфейс для управления Kubernetes с использованием Python + aiohttp, и он уже использует патч. Я думал об открытии исходного кода, просто поленился ...

Похоже, люди повторяют те же обходные решения в этой теме - пожалуйста, прочтите всю цепочку перед тем, как публиковать здесь

@joelittlejohn Я запустил ваш макрос, и он

@Macmee Это зависит от конфигурации вашего развертывания. Приведенная выше команда просто изменяет развертывание. Затем модули обновляются в соответствии с развертыванием strategy определенным вашим развертыванием. Это похоже на любое другое изменение развертывания.

Единственный способ одновременной замены всех модулей - это если это позволяет ваш .spec.strategy.rollingUpdate.maxUnavailable .

Нам тоже нужна эта функция. Один из вариантов использования также на нашей стороне заключается в том, что мы используем spring-cloud-config-server, поддерживаемый и scm, для нашего приложения с весенней загрузкой. Когда мы меняем свойство конфигурации, необходимо перезапустить приложение spring -boot, чтобы иметь возможность получить новое изменение конфигурации, поэтому нам также нужен такой триггер плавного перезапуска без необходимости повторного развертывания.

@japzio Как предложил Хелм , контрольная сумма configmap в аннотациях - хороший способ справиться с этим случаем.

Были ли какие-нибудь обновления по этому поводу? Мы тоже хотим иметь эту функцию. @ bgrant0607 @nikhiljindal

@ bholagabbar-mt Каков ваш вариант использования?

cc @ kow3ns @janetkuo

@ bgrant0607 @ kow3ns @janetkuo Варианты использования наших систем разнообразны.

1. Обновление секретов - я уверен, вы понимаете, что есть много компаний, таких как моя, которые построили свои собственные абстракции над кубернетами. У нас есть собственная система управления контейнерами, управляемая кубернетами. Таким образом, комментарий к

2. Это немного сложно, но общая цель, как кто-то предположил, состоит в том, чтобы исправить ненормальное поведение. У нас есть 4-5 тяжелых Java-приложений, работающих на платформе Play. Мы сталкиваемся с ситуацией, когда потребление памяти нашими модулями Java линейно возрастает, а затем перезапускаются модули при достижении предела памяти. Это задокументированная проблема Java с проблемой переполнения стека и связанной с ней проблемой Kubernetes . Последовательный перезапуск всех модулей в течение 3-4 часов сбросит потребление памяти и позволит нашим приложениям работать плавно без скачков.

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

@ bholagabbar-mt просто измените переменную среды, и она запустит скользящее развертывание:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn Это прекрасно. Мы интегрировали это изменение в наши системы сегодня, и оно работает нормально. Благодаря тонну!

cc @huzhengchuan

Другой вариант использования для этого: из-за проблемы с безопасностью в containerd я хотел бы перезапустить все модули. https://seclists.org/oss-sec/2019/q1/119 Либо кластер полностью выключается, либо выполняется непрерывный перезапуск. Команда перезапуска будет иметь огромное значение!

обновление , обходной путь:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh вы лучшие практики. добавить annotation:{creatTime: 12312312} в ранчо!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

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

cc @monopole @apelisse

~ Два ~ Три с половиной года спустя, а люди все еще создают новые обходные пути, с фиктивными переменными env, фиктивными метками, фиктивными аннотациями , боковыми тележками ConfigMap и Secret Watcher, масштабированием до нуля и прямыми сценариями оболочки с скользящим обновлением для моделирования возможности запускает непрерывное обновление. Неужели администраторы кластеров по-прежнему не должны делать этого честно, без уловок?

Последовательные обновления по-прежнему являются довольно популярным занятием для чего-то, что, по-видимому, не имеет варианта использования 😄

долгосрочная проблема (примечание для себя)

1. Я не вижу способа сделать это, не позволяя императивной логике перетекать в декларативный API, тем самым нарушая наше соглашение о декларативности API и реализации императивного поведения в контроллерах, а также вводя несовместимость с большинством практик CI / CD.
2. Я мог бы представить себе API-интерфейс и контроллер RollingRestart, где создание ресурса RollingRestart заставило контроллер перезапустить модули 1 на 1 посредством выселения (таким образом, соблюдая бюджеты сбоев), но такой контроллер мог бы быть реализован как CRD (т.е. я понимаю, почему мы должны сделать это в дереве).
3. Декларативный подход, например добавление аннотации lastRestartedAt = TIMESTAMP, мне не кажется хакерским.
4. Если кто-то хочет предложить декларативный дизайн и вклад для реализации этой функции (в виде дерева или иным образом), рассмотрите возможность создания KEP PR для репозитория улучшений . Если можно разработать декларативную, встроенную реализацию, я был бы рад просмотреть / проверить API-интерфейсы рабочих нагрузок. Если предлагается контроллер CRD, такой как [2], мы могли бы спонсировать его в SIG Apps в качестве расширения, спонсируемого сообществом.

Декларативный подход, например добавление аннотации lastRestartedAt = TIMESTAMP, мне не кажется хакерским.

Это не взлом, просто для этого должна быть сокращенная командная строка.

Кто-нибудь может создать плагин krew, который отправляет патч. kubectl restart-deployment <deployment_name> ?

kubectl rollout restart который исправляет развертывание / daemonset / statefulset, чтобы запустить новое «развертывание»?

Это соответствует подходу @ kow3ns (3) и имеет некоторый смысл, поскольку затем вы можете посмотреть / приостановить / возобновить развертывание, которое вы только что начали, с помощью других команд kubectl rollout .

@whereisaaron Я посмотрю, смогу ли я отправить патч для этого (каламбур не предназначен)

Для развертывания новых секретов и конфигурационных карт моя рекомендация по-прежнему №22368: создавать новые. Это дает средства как для управления развертыванием, так и для отката назад. Нам просто нужно закончить сборку мусора старых объектов:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

Тем не менее, документирование и / или поддержка (в kustomize, kubectl или плагине kubectl) рекомендуемого способа выполнения непрерывного перезапуска с существующим API является разумным.

cc @monopole

Что касается новых образов, CI / CD или контроллера, который разрешает теги для переваривания: # 1697.

Перемещение недовольных подов должно было выполняться деспланировщиком (https://github.com/kubernetes-incubator/descheduler) или чем-то в этом роде, которое могло бы использовать статус контейнера, основные метрики и даже пользовательские метрики:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

Также официальная документация по обработке секретов и configmap: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

Скользящий перезапуск очень нужен. 1 пример: мы получаем все секреты SSM от AWS. Если мы изменим какой-то секрет из SSM, мы хотели бы выполнить непрерывный перезапуск, чтобы модули теперь получали последнюю версию при загрузке. Также иногда возникают проблемы с приложениями, требующие непрерывного перезапуска, пока фактическое исправление не появится в производстве.

Хорошо, kubectl rollout restart объединено!

Приятно слышать это спустя почти 4 года, спасибо!

Я считаю, что объединенный PR поддерживает только развертывание, это правильно?

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

@apelisse есть ли способ сделать это через sdk или просто kubectl?

@ e-nikolov Что такое SDK?

Я имел в виду клиент Go, который можно использовать для общения с кубернетами из программ Go.

Нет, вам придется заново реализовать (очень простую) логику, реализованную в kubectl.

Хорошо, перезапуск развертывания kubectl объединен!

В какой версии kubectl будет?

В какой версии kubectl он будет?

Kubernetes 1.15

Наш кластер GKE на "быстром" канале выпуска обновился до Kubernetes 1.16, и теперь kubectl rollout restart перестал работать:

kubectl rollout перезапустить развертывание myapp
ошибка: неизвестная команда "перезапустить развертывание myapp"

@nikhiljindal некоторое время назад спросил о

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

эй @dimileeh

Вы случайно не знаете, какую версию kubectl вы используете сейчас? а какой версией вы пользовались раньше? Мне бы хотелось узнать, произошла ли регрессия, но в то же время я был бы удивлен, если бы эта функция полностью исчезла.

Что касается GCS, и очень мало зная о вашем варианте использования, извините, если это не имеет смысла: я бы предположил, что модель gcs получает другое имя каждый раз, когда они модифицируются (возможно, суффикс с их хешем), и что имя будет включено в развертывание. Обновление развертывания для использования новых файлов автоматически запустит развертывание. Это дает вам возможность вернуться к предыдущему развертыванию / модели, лучше понять изменения, происходящие с моделями, и т. Д.

привет @apelisse , спасибо за ответ!

Когда я запускаю kubectl version из Google Cloud Terminal, я получаю следующее:

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

Когда я попытался обновить kubectl с помощью gcloud components update , он сказал, что я уже использую последние версии всех продуктов. Поэтому я думаю, что моя версия kubectl осталась прежней, в то время как кластер K8S обновился с 1.15 до 1.16.

В документации Kubenetes 1.17, 1.16 и 1.15 ничего не говорится о функции kubectl rollout restart . Так что мне интересно, мог ли ваш ценный вклад исчезнуть из 1.16?

Спасибо за ваше предложение по версии модели, это имеет смысл. Мы думали об этом, но потом, поскольку мы переобучаем наши модели каждый день, мы подумали, что начнем накапливать слишком много моделей (а они довольно тяжелые). Конечно, мы могли бы использовать какой-нибудь скрипт для очистки старых версий через некоторое время, но пока мы решили сохранить его простым, полагаясь на kubectl rollout restart и не заботясь о версиях моделей :)

Я могу увидеть здесь документы:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

Ах, спасибо, я тут искал:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

Большое спасибо за ссылку, я обязательно буду обновлять ее!

Вт, 19 декабря 2019 г., 12:40 Дмитрий Лихацов [email protected]
написал:

Ах, спасибо, я тут искал:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFMVREXWK3TUL52HS4DFMVREXWWK3TUL52HS4DFMVREXWWWK3TUL52HS4DFMVREX
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (я буду выбирать соответствующие ветки после объединения).

@dimileeh Кажется, я понял, что не так с вашей версией kubectl, мы будем над этим работать.

Да, у нас также есть вариант повторного запуска модуля без изменения кода после обновления configmap. Это необходимо для обновления модели машинного обучения без повторного развертывания службы.

@anuragtr с последними версиями, которые вы можете запустить

kubectl rollout restart deploy NAME

Я использовал для этого специальную команду [1], рад, что теперь она есть в стандартном kubectl! Спасибо

[1] https://github.com/mauri870/kubectl-renew

@anuragtr с последними версиями, которые вы можете запустить

kubectl rollout restart deploy NAME

@countrogue