Подтвердить что ты не робот

Перезапустите контейнер в модуле

У меня есть стручок test-1495806908-xn5jn с 2 контейнерами. Я хотел бы перезапустить одну из них под названием container-test. Можно ли перезапустить один контейнер внутри контейнера и как? Если нет, то как мне перезапустить модуль?

Модуль был создан с использованием deployment.yaml с:

kubectl create -f deployment.yaml
4b9b3361

Ответ 1

Можно ли перезапустить один контейнер

Не через kubectl, хотя в зависимости от настройки вашего кластера вы можете "обмануть" и docker kill the-sha-goes-here, из-за чего кубелет перезапустит контейнер с ошибкой (предположив, конечно, политику перезагрузки для Pod говорит, что это то, что он должен делать)

как перезагрузить pod

Это зависит от того, как был создан Pod, но на основе имени Pod, которое вы указали, он, похоже, находится под надзором ReplicaSet, поэтому вы можете просто kubectl delete pod test-1495806908-xn5jn, а кубернетес создаст новый на своем месте ( новый Pod будет иметь другое имя, поэтому не ожидайте, что kubectl get pods снова вернет test-1495806908-xn5jn)

Ответ 2

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

Выполнение kubectl exec POD_NAME -c CONTAINER_NAME /sbin/killall5 работало на меня.

(Я изменил команду с reboot на /sbin/killall5 на основе приведенных ниже рекомендаций.)

Ответ 3

И pod, и container эфемерны, попробуйте использовать следующую команду, чтобы остановить определенный контейнер, и кластер k8s перезапустит новый контейнер.

kubectl exec -it [POD_NAME] -c [CONTAINER_NAME] -- /bin/sh -c "kill 1"

Это отправит сигнал SIGTERM процессу 1, который является основным процессом, выполняющимся в контейнере. Все остальные процессы будут дочерними по отношению к процессу 1 и будут завершены после завершения процесса 1. Смотрите страницу убийства для других сигналов, которые вы можете отправить.

Ответ 4

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

Поскольку у вас есть настройка deployment, которая использует replica set. Вы можете удалить pod с помощью kubectl delete pod test-1495806908-xn5jn, и кубернеты будут управлять созданием нового контейнера с двумя контейнерами без простоя. Попытка вручную перезапустить отдельные контейнеры в контейнерах сводит на нет все преимущества кубернетов.

Ответ 5

Убивание процесса, указанного в файле Dockerfile CMD/ENTRYPOINT работает для меня. (Контейнер перезапускается автоматически)

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

Ответ 6

Мы используем довольно удобную командную строку для принудительного повторного развертывания свежих изображений на модуле интеграции.
Мы заметили, что наши альпийские контейнеры запускают свою "поддерживающую" команду на PID 5. Поэтому, отправляя сигнал SIGTERM контейнер падает. imagePullPolicy устанавливается на Always, когда кубелет перетягивает последнее изображение, когда оно возвращает контейнер.

kubectl exec -i [pod name] -c [container-name] -- kill -15 5

Ответ 7

Возникла проблема в coredns, я удалил такой модуль

kubectl delete pod -n=kube-system coredns-fb8b8dccf-8ggcf

Его модуль перезапустится автоматически.

Ответ 8

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

Поэтому я предлагаю следующее решение: перезапустите:

  • 1) Установите масштаб на ноль:

     kubectl scale deployment <<name>> --replicas=0 -n service 
    

    Приведенная выше команда завершит все ваши модули с именем <<name>>

  • 2) Чтобы снова запустить модуль, установите для реплик более 0

    kubectl scale deployment <<name>> --replicas=2 -n service
    

    Приведенная выше команда снова запустит ваши модули с 2 репликами.

Ответ 9

kubectl exec -it POD_NAME -c CONTAINER_NAME bash - then kill 1

Предполагается, что контейнер запускается с правами root, что не рекомендуется.

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