Tengo un pod test-1495806908-xn5jn con 2 contenedores. Me gustaría reiniciar uno de ellos llamado container-test. Es posible reiniciar un único contenedor dentro de una vaina y cómo? Si no, ¿cómo puedo reiniciar el pod?

La vaina fue creado usando una implementación.yaml con:

kubectl create -f deployment.yaml
InformationsquelleAutor s5s | 2017-09-08

8 Comentarios

  1. 71

    Es posible reiniciar un único contenedor

    No a través de kubectl, aunque, dependiendo de la configuración del clúster puede «engañar» y docker kill the-sha-goes-here, que hará que kubelet para reiniciar el «error» de contenedor (asumiendo, por supuesto, el reinicio de la política para el Pod dice que es lo que se debe hacer)

    ¿cómo puedo reiniciar el pod

    Que depende de cómo la Vaina fue creado, pero basado en la Vaina nombre proporcionado, parece estar bajo la supervisión de un conjunto réplica, por lo que sólo puede kubectl delete pod test-1495806908-xn5jn y kubernetes creará uno nuevo en su lugar (el nuevo Pod tendrá un nombre diferente, así que no esperes kubectl get pods para volver test-1495806908-xn5jn nunca más)

    • El valor predeterminado reinicie la política es siempre reiniciar
  2. 28

    Hay casos cuando desea reiniciar un contenedor específico en lugar de eliminar la vaina y dejar Kubernetes volver a crearla.

    Haciendo un kubectl exec POD_NAME -c CONTAINER_NAME reboot trabajó para mí.

    • No cada contenedor tiene reboot; he tenido más suerte con la ejecución de /sbin/killall5 lugar; que mata todos los procesos, y el contenedor de salida.
    • Y no cada contenedor tiene usuario root 😉
    • -1, porque… estás usando el efecto secundario de ‘reboot’ matar a todos los procesos y Kubernetes de recuperación de la misma. Se trata de hacer un montón de suposiciones: se ejecuta como root, la disponibilidad de los binarios en el recipiente, una restartPolicy que está habilitada, etc. También, este abarrota los registros acerca de una falla en el proceso, que no es lo ideal.
  3. 10

    Tanto la vaina y el contenedor se efímero, pruebe a utilizar el siguiente comando para detener el contenedor específico y la k8s clúster se reiniciará un nuevo contenedor.

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

    Esto va a enviar un SIGTERM señal de proceso 1, que es el principal proceso que se ejecuta en el contenedor. Todos los otros procesos serán hijos de proceso 1, y será cancelada después de que el proceso 1 se cierra. Ver el matar manual para otras señales que pueden enviar.

    • Traté de otras respuestas y este fue el único que trabajó para mí, me parece que es la más general.
    • ¿cómo puedo obtener el nombre del contenedor que se ejecuta dentro de un pod??
  4. 9

    Toda la razón para tener kubernetes es lo que logra que los recipientes para usted de modo que usted no tiene que preocuparse tanto de que el ciclo de vida de los contenedores en el pod.

    Ya que usted tiene un deployment de instalación que utiliza replica set. Usted puede eliminar el pod con kubectl delete pod test-1495806908-xn5jn y kubernetes va a gestionar la creación de un nuevo pod con el 2 contenedores sin ningún tiempo de inactividad. Tratando de reiniciar manualmente contenedores individuales en las vainas niega la totalidad de los beneficios de kubernetes.

    • He experimentado el tiempo de inactividad como mi terminación de la vaina del proceso se convirtió 0/1
    • Usted necesita tener cuidado de que indica «sin ningún tiempo de inactividad». Depende de su configuración exacta. Además de cero tiempo de inactividad tiene problemas por su propia cuenta.
    • Cuando elimino una vaina en mi implementación con sólo 1 réplica, yo siempre la experiencia tiempo de inactividad.
  5. 2

    Matar el proceso que se especifica en el Dockerfile del CMD /ENTRYPOINT funciona para mí. (El envase se reinicia automáticamente)

    Reiniciar no estaba permitido en mi contenedor, por lo que tuve que utilizar esta solución.

  6. 1

    Utilizamos un muy conveniente de la línea de comandos para forzar la re-despliegue de imágenes nuevas en la integración de la vaina.

    Nos dimos cuenta de que nuestro alpino contenedores se ejecutan todos sus «sostener» comando PID 5. Por lo tanto, el envío de un SIGTERM señal toma el recipiente de abajo. imagePullPolicy ser Always tiene la kubelet re-tire de la última imagen cuando se trae el contenedor de la espalda.

    kubectl exec -i [pod name] -c [container-name] -- kill -15 5
    
    • ¿qué -15 y 5 representan?
    • está escondido en la descripción anterior, pero en kill -15 5 estás ejecutando el comando kill para enviar la señal de «-15» para el proceso con el PID 5. Esta es la forma de decirle a un proceso que le gustaría para terminar (SIGTERM) y que se tome el tiempo para limpiar cualquier abrió los recursos (archivos temporales, la reversión db transacciones, cerca de las conexiones, lo que sea). Contrasta con -9 (SIGKILL), mata el proceso inmediatamente, no permitiendo que se limpie cualquier abrió los recursos.
  7. 1

    Hubo un problema en el coredns pod, he eliminado tales pod

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

    Su vaina se reiniciará automáticamente.

  8. 0

    Todas las respuestas anteriores han mencionado la eliminación de la vaina…pero si usted tiene muchas vainas del mismo servicio, a continuación, sería tedioso para eliminar cada uno de ellos….Por lo tanto propongo la siguiente solución:

    Reiniciar se necesitan dos pasos:
    1) establecer la escala a cero

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

    El comando anterior se terminará todas sus vainas con el nombre de << nombre >>

    2) Para iniciar el pod de nuevo, establece las réplicas a más de 0

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

    El comando anterior comenzará su vainas con 2 réplicas.

Dejar respuesta

Please enter your comment!
Please enter your name here