Kubernetes allow container to exit without pod restart












0















A fairly common setup I see for docker is to have a container spin up perform a task and then exit.
This is something I do quite often with docker-compose where I have a node container that performs a build process and doesn't need to stay up once the static files have been built.
In these cases if I look at the docker-compose ps output, while my other containers are up and exposed on a port, the node containers state will be "Exit 0".
Although otherwise dormant if I need to access this container it's available to be spun up.



What's a good practice for translating this setup to Kubernetes?



My initial approach was to place everything in one pod but the container exiting causes a CrashLoopBackOff and due to the pod restart policy the pod keeps restarting.
If I were to keep this setup I'd only want the pod to restart if one of the other containers were to fail. It already moves the build static files into a volume that is accessible by the other containers.



Should this container be moved into another pod that does not restart? Seems like this would unnecessarily complicate the deployment.










share|improve this question



























    0















    A fairly common setup I see for docker is to have a container spin up perform a task and then exit.
    This is something I do quite often with docker-compose where I have a node container that performs a build process and doesn't need to stay up once the static files have been built.
    In these cases if I look at the docker-compose ps output, while my other containers are up and exposed on a port, the node containers state will be "Exit 0".
    Although otherwise dormant if I need to access this container it's available to be spun up.



    What's a good practice for translating this setup to Kubernetes?



    My initial approach was to place everything in one pod but the container exiting causes a CrashLoopBackOff and due to the pod restart policy the pod keeps restarting.
    If I were to keep this setup I'd only want the pod to restart if one of the other containers were to fail. It already moves the build static files into a volume that is accessible by the other containers.



    Should this container be moved into another pod that does not restart? Seems like this would unnecessarily complicate the deployment.










    share|improve this question

























      0












      0








      0








      A fairly common setup I see for docker is to have a container spin up perform a task and then exit.
      This is something I do quite often with docker-compose where I have a node container that performs a build process and doesn't need to stay up once the static files have been built.
      In these cases if I look at the docker-compose ps output, while my other containers are up and exposed on a port, the node containers state will be "Exit 0".
      Although otherwise dormant if I need to access this container it's available to be spun up.



      What's a good practice for translating this setup to Kubernetes?



      My initial approach was to place everything in one pod but the container exiting causes a CrashLoopBackOff and due to the pod restart policy the pod keeps restarting.
      If I were to keep this setup I'd only want the pod to restart if one of the other containers were to fail. It already moves the build static files into a volume that is accessible by the other containers.



      Should this container be moved into another pod that does not restart? Seems like this would unnecessarily complicate the deployment.










      share|improve this question














      A fairly common setup I see for docker is to have a container spin up perform a task and then exit.
      This is something I do quite often with docker-compose where I have a node container that performs a build process and doesn't need to stay up once the static files have been built.
      In these cases if I look at the docker-compose ps output, while my other containers are up and exposed on a port, the node containers state will be "Exit 0".
      Although otherwise dormant if I need to access this container it's available to be spun up.



      What's a good practice for translating this setup to Kubernetes?



      My initial approach was to place everything in one pod but the container exiting causes a CrashLoopBackOff and due to the pod restart policy the pod keeps restarting.
      If I were to keep this setup I'd only want the pod to restart if one of the other containers were to fail. It already moves the build static files into a volume that is accessible by the other containers.



      Should this container be moved into another pod that does not restart? Seems like this would unnecessarily complicate the deployment.







      docker kubernetes docker-compose containers devops






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 15 '18 at 16:15









      Luke VincentLuke Vincent

      5461725




      5461725
























          2 Answers
          2






          active

          oldest

          votes


















          4















          a node container that performs a build process and doesn't need to stay up once the static files have been built




          That sounds like exactly the definition of an init container: "They always run to completion. Each one must run successfully before the next one is started."



          In your Deployment spec, in the Pod template part, you'd have a separate initContainers: section that contains the separate build-only container. It has the exact same format as the containers: section that contains the main application, but runs first, to completion, once. You may need to create a volume within the context of the Pod to share contents with the main container, but this can be something like an emptyDir: type pod with no actual persistent storage.



          If you really are "building" something in the sense of running a tool like Webpack that mostly generates static files, it's better still to move this process into a Dockerfile, so that you can run the unmodified image without doing still more building at deploy time.






          share|improve this answer
























          • Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

            – Luke Vincent
            Nov 16 '18 at 10:17





















          5














          Generally, to prevent POD from restating use restartPolicy: Never (more on Restart Policy).



          Also, for the thing which you want to run "to completion" use k8s component called Job (more on Job):



          apiVersion: batch/v1
          kind: Job
          metadata:
          name: <job_name>
          spec:
          template:
          spec:
          containers:
          <...>


          To run Job till the first success (which is exit code 0) set restartPolicy: OnFailure.






          share|improve this answer
























          • Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

            – Luke Vincent
            Nov 15 '18 at 17:58











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323637%2fkubernetes-allow-container-to-exit-without-pod-restart%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4















          a node container that performs a build process and doesn't need to stay up once the static files have been built




          That sounds like exactly the definition of an init container: "They always run to completion. Each one must run successfully before the next one is started."



          In your Deployment spec, in the Pod template part, you'd have a separate initContainers: section that contains the separate build-only container. It has the exact same format as the containers: section that contains the main application, but runs first, to completion, once. You may need to create a volume within the context of the Pod to share contents with the main container, but this can be something like an emptyDir: type pod with no actual persistent storage.



          If you really are "building" something in the sense of running a tool like Webpack that mostly generates static files, it's better still to move this process into a Dockerfile, so that you can run the unmodified image without doing still more building at deploy time.






          share|improve this answer
























          • Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

            – Luke Vincent
            Nov 16 '18 at 10:17


















          4















          a node container that performs a build process and doesn't need to stay up once the static files have been built




          That sounds like exactly the definition of an init container: "They always run to completion. Each one must run successfully before the next one is started."



          In your Deployment spec, in the Pod template part, you'd have a separate initContainers: section that contains the separate build-only container. It has the exact same format as the containers: section that contains the main application, but runs first, to completion, once. You may need to create a volume within the context of the Pod to share contents with the main container, but this can be something like an emptyDir: type pod with no actual persistent storage.



          If you really are "building" something in the sense of running a tool like Webpack that mostly generates static files, it's better still to move this process into a Dockerfile, so that you can run the unmodified image without doing still more building at deploy time.






          share|improve this answer
























          • Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

            – Luke Vincent
            Nov 16 '18 at 10:17
















          4












          4








          4








          a node container that performs a build process and doesn't need to stay up once the static files have been built




          That sounds like exactly the definition of an init container: "They always run to completion. Each one must run successfully before the next one is started."



          In your Deployment spec, in the Pod template part, you'd have a separate initContainers: section that contains the separate build-only container. It has the exact same format as the containers: section that contains the main application, but runs first, to completion, once. You may need to create a volume within the context of the Pod to share contents with the main container, but this can be something like an emptyDir: type pod with no actual persistent storage.



          If you really are "building" something in the sense of running a tool like Webpack that mostly generates static files, it's better still to move this process into a Dockerfile, so that you can run the unmodified image without doing still more building at deploy time.






          share|improve this answer














          a node container that performs a build process and doesn't need to stay up once the static files have been built




          That sounds like exactly the definition of an init container: "They always run to completion. Each one must run successfully before the next one is started."



          In your Deployment spec, in the Pod template part, you'd have a separate initContainers: section that contains the separate build-only container. It has the exact same format as the containers: section that contains the main application, but runs first, to completion, once. You may need to create a volume within the context of the Pod to share contents with the main container, but this can be something like an emptyDir: type pod with no actual persistent storage.



          If you really are "building" something in the sense of running a tool like Webpack that mostly generates static files, it's better still to move this process into a Dockerfile, so that you can run the unmodified image without doing still more building at deploy time.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 15 '18 at 20:44









          David MazeDavid Maze

          15.1k31429




          15.1k31429













          • Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

            – Luke Vincent
            Nov 16 '18 at 10:17





















          • Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

            – Luke Vincent
            Nov 16 '18 at 10:17



















          Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

          – Luke Vincent
          Nov 16 '18 at 10:17







          Ah thanks. I'll make this the accepted as it seems more defined for exactly what I need and I think it makes the yaml configs slightly more succinct. In regards to your last part you're right and this is actually what I'm doing although I didn't describe it like that in my op. The 'build' process it does is just move some already built static files to make them available via a volume like you explained.

          – Luke Vincent
          Nov 16 '18 at 10:17















          5














          Generally, to prevent POD from restating use restartPolicy: Never (more on Restart Policy).



          Also, for the thing which you want to run "to completion" use k8s component called Job (more on Job):



          apiVersion: batch/v1
          kind: Job
          metadata:
          name: <job_name>
          spec:
          template:
          spec:
          containers:
          <...>


          To run Job till the first success (which is exit code 0) set restartPolicy: OnFailure.






          share|improve this answer
























          • Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

            – Luke Vincent
            Nov 15 '18 at 17:58
















          5














          Generally, to prevent POD from restating use restartPolicy: Never (more on Restart Policy).



          Also, for the thing which you want to run "to completion" use k8s component called Job (more on Job):



          apiVersion: batch/v1
          kind: Job
          metadata:
          name: <job_name>
          spec:
          template:
          spec:
          containers:
          <...>


          To run Job till the first success (which is exit code 0) set restartPolicy: OnFailure.






          share|improve this answer
























          • Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

            – Luke Vincent
            Nov 15 '18 at 17:58














          5












          5








          5







          Generally, to prevent POD from restating use restartPolicy: Never (more on Restart Policy).



          Also, for the thing which you want to run "to completion" use k8s component called Job (more on Job):



          apiVersion: batch/v1
          kind: Job
          metadata:
          name: <job_name>
          spec:
          template:
          spec:
          containers:
          <...>


          To run Job till the first success (which is exit code 0) set restartPolicy: OnFailure.






          share|improve this answer













          Generally, to prevent POD from restating use restartPolicy: Never (more on Restart Policy).



          Also, for the thing which you want to run "to completion" use k8s component called Job (more on Job):



          apiVersion: batch/v1
          kind: Job
          metadata:
          name: <job_name>
          spec:
          template:
          spec:
          containers:
          <...>


          To run Job till the first success (which is exit code 0) set restartPolicy: OnFailure.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 15 '18 at 16:48









          WindyFieldsWindyFields

          1,5001715




          1,5001715













          • Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

            – Luke Vincent
            Nov 15 '18 at 17:58



















          • Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

            – Luke Vincent
            Nov 15 '18 at 17:58

















          Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

          – Luke Vincent
          Nov 15 '18 at 17:58





          Ok thank you. I initially tried a restart policy of "OnFailure" but this was in a Deployment which is a higher level api for ReplicaSet which only allows "Always" as a restart policy. I've achieved what I wanted with that container isolated in a job.

          – Luke Vincent
          Nov 15 '18 at 17:58


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53323637%2fkubernetes-allow-container-to-exit-without-pod-restart%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown