使用sh命令时Kubernetes Pod的容器未运行 [英] Kubernetes Pod's containers not running when using sh commands
问题描述
Pod容器在运行sh命令(以及/bin/sh)之后，还没有准备好并且每次都停留在Waiting状态. 例如，在
Pod containers are not ready and stuck under Waiting state over and over every single time after they run sh commands (/bin/sh as well). As example all pod's containers seen at https://v1-17.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-with-data-from-multiple-configmaps they just go on "Complete" status after executing the sh command, or if I set "restartPolicy: Always" they have the "Waiting" state for the reason CrashLoopBackOff. (Containers work fine if I do not set any command on them. If I use the sh command within container, after creating them I can read using "kubectl logs" the env variable was set correctly.
预期的行为是使pod的容器在执行sh命令后运行.
The expected behaviour is to get pod's containers running after they execute the sh command.
我找不到有关此特定问题的参考，如果可能，我几乎不需要帮助，在此先非常感谢您！
I cannot find references regarding this particular problem and I need little help if possible, thank you very much in advance!
请不要理会我尝试了其他图像，无论哪种方式都会发生问题.
Please disregard I tried different images, the problem happens either way.
环境:qemu VM上的Kubernetes v 1.17.1
environment: Kubernetes v 1.17.1 on qemu VM
yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
data:
how: very
---
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: nginx
ports:
- containerPort: 88
command: [ "/bin/sh", "-c", "env" ]
env:
# Define the environment variable
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
name: special-config
# Specify the key associated with the value
key: how
restartPolicy: Always
描述广告连播:
kubectl describe pod dapi-test-pod
Name: dapi-test-pod
Namespace: default
Priority: 0
Node: kw1/10.1.10.31
Start Time: Thu, 21 May 2020 01:02:17 +0000
Labels: <none>
Annotations: cni.projectcalico.org/podIP: 192.168.159.83/32
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"dapi-test-pod","namespace":"default"},"spec":{"containers":[{"command...
Status: Running
IP: 192.168.159.83
IPs:
IP: 192.168.159.83
Containers:
test-container:
Container ID: docker://63040ec4d0a3e78639d831c26939f272b19f21574069c639c7bd4c89bb1328de
Image: nginx
Image ID: docker-pullable://nginx@sha256:30dfa439718a17baafefadf16c5e7c9d0a1cde97b4fd84f63b69e13513be7097
Port: 88/TCP
Host Port: 0/TCP
Command:
/bin/sh
-c
env
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Thu, 21 May 2020 01:13:21 +0000
Finished: Thu, 21 May 2020 01:13:21 +0000
Ready: False
Restart Count: 7
Environment:
SPECIAL_LEVEL_KEY: <set to the key 'how' of config map 'special-config'> Optional: false
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-zqbsw (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-zqbsw:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-zqbsw
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 13m default-scheduler Successfully assigned default/dapi-test-pod to kw1
Normal Pulling 12m (x4 over 13m) kubelet, kw1 Pulling image "nginx"
Normal Pulled 12m (x4 over 13m) kubelet, kw1 Successfully pulled image "nginx"
Normal Created 12m (x4 over 13m) kubelet, kw1 Created container test-container
Normal Started 12m (x4 over 13m) kubelet, kw1 Started container test-container
Warning BackOff 3m16s (x49 over 13m) kubelet, kw1 Back-off restarting failed container
推荐答案
之所以会发生这种情况，是因为您正在运行的容器中的进程已完成，并且该容器已关闭，因此kubernetes将pod标记为已完成.
This happens because the process in the container you are running has completed and the container shuts down, and so kubernetes marks the pod as completed.
如果在docker映像中作为CMD的一部分定义的命令，或者如果您已添加自己的命令，则该命令完成后容器将关闭.这就是为什么当您使用普通docker运行Ubuntu时，它先启动然后又直接关闭的原因.
If the command that is defined in the docker image as part of CMD, or if you've added your own command as you have done, then the container shuts down after the command completed. It's the same reason why when you run Ubuntu using plain docker, it starts up then shuts down directly afterwards.
要使Pod及其底层Docker容器继续运行，您需要启动一个将继续运行的进程.就您而言，运行env命令立即完成.
For pods, and their underlying docker container to continue running, you need to start a process that will continue running. In your case, running the env command completes right away.
如果您将Pod设置为始终重启，那么kubernetes将继续尝试重启它，直到达到它的退出阈值为止.
If you set the pod to restart Always, then kubernetes will keep trying to restart it until it's reached it's back off threshold.
像您正在运行的一次性命令对于实用程序类型的东西很有用. IE.做一件事然后摆脱吊舱.
One off commands like you're running are useful for utility type things. I.e. do one thing then get rid of the pod.
例如:
kubectl run tester --generator run-pod/v1 --image alpine --restart Never --rm -it -- /bin/sh -c env
要运行更长的时间，请启动一个继续运行的进程.
To run something longer, start a process that continues running.
例如:
kubectl run tester --generator run-pod/v1 --image alpine -- /bin/sh -c "sleep 30"
该命令将运行30秒，因此吊舱也将运行30秒.它还将使用默认的重启策略Always.因此，该过程完成30秒后，Kubernetes将Pod标记为已完成，然后重新启动它以再次执行相同的操作.
That command will run for 30 seconds, and so the pod will also run for 30 seconds. It will also use the default restart policy of Always. So after 30 seconds the process completes, Kubernetes marks the pod as complete, and then restarts it to do the same things again.
通常，pod会启动一个长时间运行的过程，例如Web服务器.为了让Kubernetes知道该Pod是否健康，因此可以执行它的高可用性魔术并在兑现后重启它，可以使用
Generally pods will start a long running process, like a web server. For Kubernetes to know if that pod is healthy, so it can do it's high availability magic and restart it if it cashes, it can use readiness and liveness probes.
这篇关于使用sh命令时Kubernetes Pod的容器未运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
