Kubernetes allow container to exit without pod restart
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
add a comment |
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
add a comment |
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
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
docker
asked Nov 15 '18 at 16:15
Luke VincentLuke Vincent
5461725
5461725
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
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
add a comment |
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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