为什么我从泊坞窗映像中获取CrashLoopBackOff并且日志没有说出什么问题？ [英] Why am I getting CrashLoopBackOff from my docker image and the logs don't say what is wrong?
问题描述
我使用此 Dockerfile 用Docker创建了一个映像，并将其推送到docker-hub。
I created an image with Docker using this Dockerfile and I pushed it to docker-hub.
FROM gcc AS builder
RUN mkdir -p /opt
COPY ./generate-tpch-dbgen.sh /opt/generate-tpch-dbgen.sh
WORKDIR /opt
RUN chmod +x /opt/generate-tpch-dbgen.sh
ENTRYPOINT ["/bin/sh","/opt/generate-tpch-dbgen.sh"]
，这是我在其中运行的 generate-tpch-dbgen.sh 脚本
and this is the generate-tpch-dbgen.sh script that I am running inside the image.
#!/bin/sh
# download
git clone https://github.com/electrum/tpch-dbgen.git
# replace variables
cd tpch-dbgen
sed -i '/CC =/c\CC=gcc' makefile.suite
sed -i '/DATABASE=/c\DATABASE=INFORMIX' makefile.suite
sed -i '/MACHINE =/c\MACHINE=LINUX' makefile.suite
sed -i '/WORKLOAD =/c\WORKLOAD=TPCH' makefile.suite
# compile
make -f makefile.suite
# run the tpch-dbgen to generate data with database factor of 0.1GB
mkdir data && cd data
cp ../dbgen . && cp ../dists.dss .
./dbgen -f -s 0.1
ls -l
# create the datarate.txt file
mkdir -p /tmp
echo "1000000000" > /tmp/datarate.txt
然后，我使用Kubernetes（minikube）从部署对象创建一个pod。我希望此图像可用并且不终止，因为我将共享由脚本<$ c $生成的该图像中的目录 / opt / tpch-dbgen / data c> /opt/generate-tpch-dbgen.sh 。
Then I am creating a pod from a deployment object using Kubernetes (minikube). I want this image to be available and not terminate because I will share the directory /opt/tpch-dbgen/data from this image that is generated by the script /opt/generate-tpch-dbgen.sh.
apiVersion: apps/v1
kind: Deployment
metadata:
name: tpch-dbgen-deployment
spec:
replicas: 1
selector:
matchLabels:
component: tpch-dbgen
template:
metadata:
labels:
component: tpch-dbgen
spec:
containers:
- name: tpch-dbgen
image: felipeogutierrez/tpch-dbgen
imagePullPolicy: Always
我正在获取<窗格上的code> CrashLoopBackOff 错误。但是日志显示我的文件在那里，我看不到任何其他相关的错误可以修复。我想我的部署文件有问题，但是日志没有给我任何提示，或者我不知道在哪里看。我的部署有什么问题？
I am getting the CrashLoopBackOff error on the pod. But the log says that my files are there and I cannot see any other relevant error to fix. I suppose that there is a problem with my deployment file, but the logs don't give any hint to me, or I don't know where to look. What is wrong with my deployment?
felipe@cow-11:~/workspace-scala/explore-flink$ kubectl get pods
NAME READY STATUS RESTARTS AGE
tpch-dbgen-deployment-57587d8748-gd4xs 0/1 CrashLoopBackOff 6 7m34s
felipe@cow-11:~/workspace-scala/explore-flink$ kubectl describe pods tpch-dbgen-deployment-57587d8748-gd4xs
Name: tpch-dbgen-deployment-57587d8748-gd4xs
Namespace: default
Priority: 0
Node: minikube/192.168.99.100
Start Time: Wed, 23 Sep 2020 09:38:11 +0200
Labels: component=tpch-dbgen
pod-template-hash=57587d8748
Annotations: <none>
Status: Running
IP: 172.17.0.3
IPs:
IP: 172.17.0.3
Controlled By: ReplicaSet/tpch-dbgen-deployment-57587d8748
Containers:
tpch-dbgen:
Container ID: docker://3ddf1b5306707f4ba60a35f08306f1a621a744e5ce08c7e5806594ba80865fba
Image: felipeogutierrez/tpch-dbgen
Image ID: docker-pullable://felipeogutierrez/tpch-dbgen@sha256:079c7f009a8cb93830cb11ff71bdba122795b7c8750e65f308dc43174252f71a
Port: <none>
Host Port: <none>
Command:
/bin/sh
-c
Args:
ls ; pwd ; ./generate-tpch-dbgen.sh ; ls
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 23 Sep 2020 09:45:10 +0200
Finished: Wed, 23 Sep 2020 09:45:20 +0200
Ready: False
Restart Count: 6
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-7snfd (ro)
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-7snfd:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-7snfd
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7m43s default-scheduler Successfully assigned default/tpch-dbgen-deployment-57587d8748-gd4xs to minikube
Normal Pulled 7m40s kubelet, minikube Successfully pulled image "felipeogutierrez/tpch-dbgen" in 1.732811715s
Normal Pulled 7m24s kubelet, minikube Successfully pulled image "felipeogutierrez/tpch-dbgen" in 1.522490498s
Normal Pulled 6m58s kubelet, minikube Successfully pulled image "felipeogutierrez/tpch-dbgen" in 1.570829385s
Normal Created 6m23s (x4 over 7m40s) kubelet, minikube Created container tpch-dbgen
Normal Pulled 6m23s kubelet, minikube Successfully pulled image "felipeogutierrez/tpch-dbgen" in 3.077114721s
Normal Started 6m22s (x4 over 7m40s) kubelet, minikube Started container tpch-dbgen
Normal Pulling 5m23s (x5 over 7m42s) kubelet, minikube Pulling image "felipeogutierrez/tpch-dbgen"
Normal Pulled 5m21s kubelet, minikube Successfully pulled image "felipeogutierrez/tpch-dbgen" in 1.834155671s
Warning BackOff 2m33s (x19 over 7m13s) kubelet, minikube Back-off restarting failed container
felipe@cow-11:~/workspace-scala/explore-flink$ kubectl logs tpch-dbgen-deployment-57587d8748-gd4xs
Cloning into 'tpch-dbgen'...
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o build.o build.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o driver.o driver.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o bm_utils.o bm_utils.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o rnd.o rnd.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o print.o print.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o load_stub.o load_stub.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o bcd2.o bcd2.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o speed_seed.o speed_seed.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o text.o text.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o permute.o permute.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o rng64.o rng64.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -O -o dbgen build.o driver.o bm_utils.o rnd.o print.o load_stub.o bcd2.o speed_seed.o text.o permute.o rng64.o -lm
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o qgen.o qgen.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -c -o varsub.o varsub.c
gcc -g -DDBNAME=\"dss\" -DLINUX -DINFORMIX -DTPCH -DRNG_TEST -D_FILE_OFFSET_BITS=64 -O -o qgen build.o bm_utils.o qgen.o rnd.o varsub.o text.o bcd2.o permute.o speed_seed.o rng64.o -lm
TPC-H Population Generator (Version 2.14.0)
Copyright Transaction Processing Performance Council 1994 - 2010
total 105448
-rw-r--r-- 1 root root 2426114 Sep 23 07:45 customer.tbl
-rwxr-xr-x 1 root root 116600 Sep 23 07:45 dbgen
-rw-r--r-- 1 root root 11815 Sep 23 07:45 dists.dss
-rw-r--r-- 1 root root 74246996 Sep 23 07:45 lineitem.tbl
-rw-r--r-- 1 root root 2224 Sep 23 07:45 nation.tbl
-rw-r--r-- 1 root root 16893122 Sep 23 07:45 orders.tbl
-rw-r--r-- 1 root root 2391090 Sep 23 07:45 part.tbl
-rw-r--r-- 1 root root 11728193 Sep 23 07:45 partsupp.tbl
-rw-r--r-- 1 root root 389 Sep 23 07:45 region.tbl
-rw-r--r-- 1 root root 139625 Sep 23 07:45 supplier.tbl
推荐答案
吊舱出口中的容器d的状态为 0 ，表示您容器中的命令已成功完成。您没有为容器指定任何 restartPolicy ，因此默认值为始终。由于您的容器已完成-由于其重启策略而将其重启（实际上，您甚至无法在使用部署时更改它-始终为始终。
The container in your pod exited with status 0 which means that the command in your container has successfully finished. You have not specified any restartPolicy for your container so the default is Always. Since your container finished - it will be restarted due to it's restart policy (actually you cannot even change that when using a deployment - it is always Always.
当您有一些长时间运行的进程并且要确保这些进程的所有实例都可以启动并且可以在需要时可以推广到新版本时，应使用部署。
The deployment should be used when you have some long running processes and you want to make sure that all instances of those processees are up and can be rolled out to new versions if needed.
对于执行某项操作然后退出的热门流程-您最好使用职位。
For one hit processes that do something and then quit - you might better use Jobs.
这篇关于为什么我从泊坞窗映像中获取CrashLoopBackOff并且日志没有说出什么问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
