Need a CURL binary availble inside kubernetes pod
I would like to sh myself inside a kubernetes pod and execute a CURL command. Unfortunatly I can't find anywhere a working image with curl availble (and compatible with kubernetes)...
- I tried some docker images with Alpine and CURL but each time it ended with crashLoopBackOff. I guess it means the container exited because the docker image exits after executing itself...
- I also tried using the image of alpine and ubuntu alone but each time it also ended with crashloopBackOff.
- I manage to exec in a few images but it never had CURL installed and neither APT-GET or APK were working.
To exec into a container I'm doing a simple kubectl exec -it POD_ID /bin/bash
Does someone knows of a minimal docker image that contains a CURL binary and wont crash in kubernetes ?
PS: This is for testing purpose so it does not need to be rock solid or anything
Thx
UPDATE 1
This is the yaml I use to deploy all potential image :
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: SOME_IMAGE:latest
resources:
requests:
cpu: 0.1
memory: 200
I don't think that its broken because it works on certain image.
docker curl kubernetes alpine
add a comment |
I would like to sh myself inside a kubernetes pod and execute a CURL command. Unfortunatly I can't find anywhere a working image with curl availble (and compatible with kubernetes)...
- I tried some docker images with Alpine and CURL but each time it ended with crashLoopBackOff. I guess it means the container exited because the docker image exits after executing itself...
- I also tried using the image of alpine and ubuntu alone but each time it also ended with crashloopBackOff.
- I manage to exec in a few images but it never had CURL installed and neither APT-GET or APK were working.
To exec into a container I'm doing a simple kubectl exec -it POD_ID /bin/bash
Does someone knows of a minimal docker image that contains a CURL binary and wont crash in kubernetes ?
PS: This is for testing purpose so it does not need to be rock solid or anything
Thx
UPDATE 1
This is the yaml I use to deploy all potential image :
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: SOME_IMAGE:latest
resources:
requests:
cpu: 0.1
memory: 200
I don't think that its broken because it works on certain image.
docker curl kubernetes alpine
You are gettingcrashLoopBackOff
because of some reason. Can you share yaml file that you have tried?
– Emruz Hossain
Nov 13 '18 at 17:39
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
You’re probably looking forkubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get thecrashLoopBackOff
state.
– David Maze
Nov 13 '18 at 17:48
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51
add a comment |
I would like to sh myself inside a kubernetes pod and execute a CURL command. Unfortunatly I can't find anywhere a working image with curl availble (and compatible with kubernetes)...
- I tried some docker images with Alpine and CURL but each time it ended with crashLoopBackOff. I guess it means the container exited because the docker image exits after executing itself...
- I also tried using the image of alpine and ubuntu alone but each time it also ended with crashloopBackOff.
- I manage to exec in a few images but it never had CURL installed and neither APT-GET or APK were working.
To exec into a container I'm doing a simple kubectl exec -it POD_ID /bin/bash
Does someone knows of a minimal docker image that contains a CURL binary and wont crash in kubernetes ?
PS: This is for testing purpose so it does not need to be rock solid or anything
Thx
UPDATE 1
This is the yaml I use to deploy all potential image :
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: SOME_IMAGE:latest
resources:
requests:
cpu: 0.1
memory: 200
I don't think that its broken because it works on certain image.
docker curl kubernetes alpine
I would like to sh myself inside a kubernetes pod and execute a CURL command. Unfortunatly I can't find anywhere a working image with curl availble (and compatible with kubernetes)...
- I tried some docker images with Alpine and CURL but each time it ended with crashLoopBackOff. I guess it means the container exited because the docker image exits after executing itself...
- I also tried using the image of alpine and ubuntu alone but each time it also ended with crashloopBackOff.
- I manage to exec in a few images but it never had CURL installed and neither APT-GET or APK were working.
To exec into a container I'm doing a simple kubectl exec -it POD_ID /bin/bash
Does someone knows of a minimal docker image that contains a CURL binary and wont crash in kubernetes ?
PS: This is for testing purpose so it does not need to be rock solid or anything
Thx
UPDATE 1
This is the yaml I use to deploy all potential image :
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: SOME_IMAGE:latest
resources:
requests:
cpu: 0.1
memory: 200
I don't think that its broken because it works on certain image.
docker curl kubernetes alpine
docker curl kubernetes alpine
edited Nov 14 '18 at 12:19
Doctor
asked Nov 13 '18 at 17:27
DoctorDoctor
8681126
8681126
You are gettingcrashLoopBackOff
because of some reason. Can you share yaml file that you have tried?
– Emruz Hossain
Nov 13 '18 at 17:39
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
You’re probably looking forkubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get thecrashLoopBackOff
state.
– David Maze
Nov 13 '18 at 17:48
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51
add a comment |
You are gettingcrashLoopBackOff
because of some reason. Can you share yaml file that you have tried?
– Emruz Hossain
Nov 13 '18 at 17:39
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
You’re probably looking forkubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get thecrashLoopBackOff
state.
– David Maze
Nov 13 '18 at 17:48
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51
You are getting
crashLoopBackOff
because of some reason. Can you share yaml file that you have tried?– Emruz Hossain
Nov 13 '18 at 17:39
You are getting
crashLoopBackOff
because of some reason. Can you share yaml file that you have tried?– Emruz Hossain
Nov 13 '18 at 17:39
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
You’re probably looking for
kubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get the crashLoopBackOff
state.– David Maze
Nov 13 '18 at 17:48
You’re probably looking for
kubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get the crashLoopBackOff
state.– David Maze
Nov 13 '18 at 17:48
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51
add a comment |
4 Answers
4
active
oldest
votes
You getting CrashLoopBackOff
because container completes after starting as it does not have any task to process. Easy workaround is to run a command in the container to keep it running indefinitely. So that you can exec into the container and run curl.
Here, is modified yaml to do this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: scrapinghub/httpbin:latest
command:
- sleep
- "3600"
resources:
requests:
cpu: 0.1
memory: 200
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
add a comment |
You can skip the manifest and use kubectl run
to spin up one of these pods on demand.
i.e.
kubectl run curl -it --rm --image=tutum/curl -- sh
This would create a deployment named curl
from the tutum/curl
image and give you an interactive (-it
) shell inside it. When you exit, the deployment will be deleted (--rm
).
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something likesleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.
– switchboard.op
Nov 15 '18 at 16:21
add a comment |
You can use this image nightfury1204/alpine-curl
I created above image for my own testing purpose.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: curl
labels:
name: curl
spec:
serviceName: "curl"
selector:
matchLabels:
app: curl
replicas: 1
template:
metadata:
labels:
app: curl
spec:
containers:
- name: curl
image: nightfury1204/alpine-curl
command:
- "sh"
- "-c"
- >
while true; do
sleep 3600;
done
To exec into the pod use this kubectl exec -it curl-0 sh
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
add a comment |
Use byrnedo/alpine-curl
image from https://hub.docker.com/r/byrnedo/alpine-curl/.
Also it's not neccessary to have latest
tag in the deployment. It works without it, just
containers:
- name: blue-website
image: byrnedo/alpine-curl
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image withtutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image likebyrnedo/alpine-curl
or usetutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world
– Anna Slastnikova
Nov 15 '18 at 14:36
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%2f53286519%2fneed-a-curl-binary-availble-inside-kubernetes-pod%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
You getting CrashLoopBackOff
because container completes after starting as it does not have any task to process. Easy workaround is to run a command in the container to keep it running indefinitely. So that you can exec into the container and run curl.
Here, is modified yaml to do this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: scrapinghub/httpbin:latest
command:
- sleep
- "3600"
resources:
requests:
cpu: 0.1
memory: 200
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
add a comment |
You getting CrashLoopBackOff
because container completes after starting as it does not have any task to process. Easy workaround is to run a command in the container to keep it running indefinitely. So that you can exec into the container and run curl.
Here, is modified yaml to do this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: scrapinghub/httpbin:latest
command:
- sleep
- "3600"
resources:
requests:
cpu: 0.1
memory: 200
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
add a comment |
You getting CrashLoopBackOff
because container completes after starting as it does not have any task to process. Easy workaround is to run a command in the container to keep it running indefinitely. So that you can exec into the container and run curl.
Here, is modified yaml to do this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: scrapinghub/httpbin:latest
command:
- sleep
- "3600"
resources:
requests:
cpu: 0.1
memory: 200
You getting CrashLoopBackOff
because container completes after starting as it does not have any task to process. Easy workaround is to run a command in the container to keep it running indefinitely. So that you can exec into the container and run curl.
Here, is modified yaml to do this:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: blue
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
name: blue
spec:
containers:
- name: blue-website
image: scrapinghub/httpbin:latest
command:
- sleep
- "3600"
resources:
requests:
cpu: 0.1
memory: 200
answered Nov 13 '18 at 18:39
Emruz HossainEmruz Hossain
1,084210
1,084210
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
add a comment |
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
Thx for your answer. It works ! Httpbin has indeed a curl binary availble and the .yaml works. Though I would point out that httpbin seems to be working without using the "command" key. I guess it means that httpbin doesn't exits by itself.
– Doctor
Nov 14 '18 at 8:31
add a comment |
You can skip the manifest and use kubectl run
to spin up one of these pods on demand.
i.e.
kubectl run curl -it --rm --image=tutum/curl -- sh
This would create a deployment named curl
from the tutum/curl
image and give you an interactive (-it
) shell inside it. When you exit, the deployment will be deleted (--rm
).
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something likesleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.
– switchboard.op
Nov 15 '18 at 16:21
add a comment |
You can skip the manifest and use kubectl run
to spin up one of these pods on demand.
i.e.
kubectl run curl -it --rm --image=tutum/curl -- sh
This would create a deployment named curl
from the tutum/curl
image and give you an interactive (-it
) shell inside it. When you exit, the deployment will be deleted (--rm
).
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something likesleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.
– switchboard.op
Nov 15 '18 at 16:21
add a comment |
You can skip the manifest and use kubectl run
to spin up one of these pods on demand.
i.e.
kubectl run curl -it --rm --image=tutum/curl -- sh
This would create a deployment named curl
from the tutum/curl
image and give you an interactive (-it
) shell inside it. When you exit, the deployment will be deleted (--rm
).
You can skip the manifest and use kubectl run
to spin up one of these pods on demand.
i.e.
kubectl run curl -it --rm --image=tutum/curl -- sh
This would create a deployment named curl
from the tutum/curl
image and give you an interactive (-it
) shell inside it. When you exit, the deployment will be deleted (--rm
).
answered Nov 13 '18 at 20:14
switchboard.opswitchboard.op
1017
1017
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something likesleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.
– switchboard.op
Nov 15 '18 at 16:21
add a comment |
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something likesleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.
– switchboard.op
Nov 15 '18 at 16:21
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
Thx for your answer. It works well ! I would prefer having a .yaml though :-)
– Doctor
Nov 14 '18 at 8:22
1
1
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something like
sleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.– switchboard.op
Nov 15 '18 at 16:21
Understood. I prefer spinning stuff like this up on demand because with a yaml manifest you usually have to do something like
sleep 3000
to make sure the process doesn't just end right away. Seems hacky to me and the container might exit when you are in the middle of something. Plus then you don't have pods hanging around when you're not actively using them, but to each their own.– switchboard.op
Nov 15 '18 at 16:21
add a comment |
You can use this image nightfury1204/alpine-curl
I created above image for my own testing purpose.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: curl
labels:
name: curl
spec:
serviceName: "curl"
selector:
matchLabels:
app: curl
replicas: 1
template:
metadata:
labels:
app: curl
spec:
containers:
- name: curl
image: nightfury1204/alpine-curl
command:
- "sh"
- "-c"
- >
while true; do
sleep 3600;
done
To exec into the pod use this kubectl exec -it curl-0 sh
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
add a comment |
You can use this image nightfury1204/alpine-curl
I created above image for my own testing purpose.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: curl
labels:
name: curl
spec:
serviceName: "curl"
selector:
matchLabels:
app: curl
replicas: 1
template:
metadata:
labels:
app: curl
spec:
containers:
- name: curl
image: nightfury1204/alpine-curl
command:
- "sh"
- "-c"
- >
while true; do
sleep 3600;
done
To exec into the pod use this kubectl exec -it curl-0 sh
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
add a comment |
You can use this image nightfury1204/alpine-curl
I created above image for my own testing purpose.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: curl
labels:
name: curl
spec:
serviceName: "curl"
selector:
matchLabels:
app: curl
replicas: 1
template:
metadata:
labels:
app: curl
spec:
containers:
- name: curl
image: nightfury1204/alpine-curl
command:
- "sh"
- "-c"
- >
while true; do
sleep 3600;
done
To exec into the pod use this kubectl exec -it curl-0 sh
You can use this image nightfury1204/alpine-curl
I created above image for my own testing purpose.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: curl
labels:
name: curl
spec:
serviceName: "curl"
selector:
matchLabels:
app: curl
replicas: 1
template:
metadata:
labels:
app: curl
spec:
containers:
- name: curl
image: nightfury1204/alpine-curl
command:
- "sh"
- "-c"
- >
while true; do
sleep 3600;
done
To exec into the pod use this kubectl exec -it curl-0 sh
answered Nov 13 '18 at 18:32
nightfury1204nightfury1204
1,57148
1,57148
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
add a comment |
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
Thx for your answer. Unfortunatly deploying this .yaml is not creating any pods resulting in the command line not working.
– Doctor
Nov 14 '18 at 8:24
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
This works like a potluck.
– Teoman shipahi
Jan 2 at 20:03
add a comment |
Use byrnedo/alpine-curl
image from https://hub.docker.com/r/byrnedo/alpine-curl/.
Also it's not neccessary to have latest
tag in the deployment. It works without it, just
containers:
- name: blue-website
image: byrnedo/alpine-curl
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image withtutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image likebyrnedo/alpine-curl
or usetutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world
– Anna Slastnikova
Nov 15 '18 at 14:36
add a comment |
Use byrnedo/alpine-curl
image from https://hub.docker.com/r/byrnedo/alpine-curl/.
Also it's not neccessary to have latest
tag in the deployment. It works without it, just
containers:
- name: blue-website
image: byrnedo/alpine-curl
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image withtutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image likebyrnedo/alpine-curl
or usetutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world
– Anna Slastnikova
Nov 15 '18 at 14:36
add a comment |
Use byrnedo/alpine-curl
image from https://hub.docker.com/r/byrnedo/alpine-curl/.
Also it's not neccessary to have latest
tag in the deployment. It works without it, just
containers:
- name: blue-website
image: byrnedo/alpine-curl
Use byrnedo/alpine-curl
image from https://hub.docker.com/r/byrnedo/alpine-curl/.
Also it's not neccessary to have latest
tag in the deployment. It works without it, just
containers:
- name: blue-website
image: byrnedo/alpine-curl
answered Nov 14 '18 at 21:19
Anna SlastnikovaAnna Slastnikova
492
492
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image withtutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image likebyrnedo/alpine-curl
or usetutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world
– Anna Slastnikova
Nov 15 '18 at 14:36
add a comment |
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image withtutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image likebyrnedo/alpine-curl
or usetutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world
– Anna Slastnikova
Nov 15 '18 at 14:36
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Its not working. I get crashLoopbackOff. Its probably because the entrypoint exits at one point resulting in the container crashing.
– Doctor
Nov 15 '18 at 12:30
Yeah, I see. Then just replace the docker image with
tutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image like byrnedo/alpine-curl
or use tutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world– Anna Slastnikova
Nov 15 '18 at 14:36
Yeah, I see. Then just replace the docker image with
tutum/curl
as suggested by switchboard.op above. Yeah the reason is that there is no running process in a container so pod just stops and therefore you have crashLoopbackOff. Either you have sleep command in the deployment spec along with some simple image like byrnedo/alpine-curl
or use tutum/curl
which is a server listnening on port 80 and it's got curl installed hub.docker.com/r/tutum/hello-world– Anna Slastnikova
Nov 15 '18 at 14:36
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%2f53286519%2fneed-a-curl-binary-availble-inside-kubernetes-pod%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
You are getting
crashLoopBackOff
because of some reason. Can you share yaml file that you have tried?– Emruz Hossain
Nov 13 '18 at 17:39
@EmruzHossain I updated my question :-)
– Doctor
Nov 13 '18 at 17:43
You’re probably looking for
kubectl run
. Kubernetes’s general model isn’t to have idle pods sitting around waiting for users to exec into them; if a container starts up, has nothing to do, and immediately exits, you’ll get thecrashLoopBackOff
state.– David Maze
Nov 13 '18 at 17:48
@DavidMaze Yeah that what I though too...
– Doctor
Nov 13 '18 at 17:51