Container version not starting
Closed this issue · 20 comments
Description
Unable to run the docker container
Server
Raspberry pi 3B running K3S
Client
Chrome on Android (works fine using the regular librespeed version)
Steps to reproduce
Following the regular librespeed docker instructions I have a working install, however it's slow because of the PHP. In switching over to this version I have just changed the image line in my kubernetes deployment yaml file to pull this version, however the container doesn't pull and start.
Expected behaviour
Container should pull and run.
This is my deployment yaml:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: librespeed-deployment
labels:
app: librespeed
spec:
replicas: 1
selector:
matchLabels:
app: librespeed
template:
metadata:
labels:
app: librespeed
spec:
containers:
- name: librespeed
image: mickkael/librespeed-go
ports:
- containerPort: 80
resources:
requests:
memory: 800Mi
cpu: 2000m
limits:
memory: 800Mi
cpu: 2000m
priorityClassName: high-priority
---
kind: Service
apiVersion: v1
metadata:
name: librespeed-service
spec:
type: NodePort
selector:
app: librespeed
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30009
And this is the output I get when checking events:
10m Normal Scheduled pod/librespeed-deployment-768fd648b9-mt65r Successfully assigned prod/librespeed-deployment-768fd648b9-mt65r to k3s-node1 9m53s Normal Pulled pod/librespeed-deployment-768fd648b9-mt65r Successfully pulled image "mickkael/librespeed-go" 9m52s Normal Created pod/librespeed-deployment-768fd648b9-mt65r Created container librespeed 9m52s Normal Started pod/librespeed-deployment-768fd648b9-mt65r Started container librespeed 9m3s Normal Pulling pod/librespeed-deployment-768fd648b9-mt65r Pulling image "mickkael/librespeed-go" 34s Warning BackOff pod/librespeed-deployment-768fd648b9-mt65r Back-off restarting failed container
Any ideas what I might be doing wrong?
Hi,
Try to remove the resources request, and keep limit only
Request is just for reserving resources on the node, no? The limit will remain the upper limit of available resources regardless of whether there is a request or not.
I gave it a try anyway and still no change I'm afraid. The previous pod attempt terminated and the image pulled again, but it fails to start.
I have the container running very well on k3s 1.17 / 1.18 for a long time, on rpi 3 and 4.
What do you have in the logs ?
please share the output of
kubectl describe deployment librespeed-deployment
kubectl logs librespeed-deployment-768fd648b9-mt65r
Sure here they are: (note I changed the deployment name)
Name: librespeed-go-deployment
Namespace: prod
CreationTimestamp: Tue, 10 Nov 2020 23:56:36 +0000
Labels: app=librespeed-go
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=librespeed-go
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=librespeed-go
Containers:
librespeed-go:
Image: mickkael/librespeed-go
Port: 80/TCP
Host Port: 0/TCP
Limits:
cpu: 1
memory: 300Mi
Requests:
cpu: 1
memory: 300Mi
Environment: <none>
Mounts: <none>
Volumes: <none>
Priority Class Name: high-priority
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available False MinimumReplicasUnavailable
OldReplicaSets: <none>
NewReplicaSet: librespeed-go-deployment-5786fc74cc (1/1 replicas created)
Events: <none>
Standard_init_linux.go:211: exec user process caused "exec format error"
That appears to give a hint. I wasn't aware of that command.
Note though just for awareness that all other pods and deployments that I attempt to start do so without issue.
A bit of research shows this can sometimes happen when the image architecture is wrong?
I added ":arm64" to the image to pull and it made no change unfortunately.
this my guess as well, and why I asked for pod logs. I have compiled the image for arm64 (latest and arm64 are the same image), and you are probably using arm32/v6 with the 32 bits version of Raspbian on your rpi3b.
I personally use Ubuntu 64b on Raspberry, and it gives much better results:
https://ubuntu.com/download/raspberry-pi
I can try to compile an arm32 version of the container in the next few days.
Ooooh man that explains it. It never clicked that raspberry OS is 32 bit. I never realised that.
If you're happy and willing to compile a 32 bit version that would be incredibly awesome of you.
Can you try mickkael/librespeed-go:arm ?
I'm not too familiar with how Docker Hub works but I notice the "OS/arch" field for the new arm version still says "arm64". Is that a functional difference or just a metadata field?
What about this one
mickkael/librespeed-go:armv6
built from https://github.com/mickkael/speedtest-go/blob/master/Dockerfile_arm
If it works, I'll work on a multi arch image
kaniko is not good for cross platform, I'll install docker and build with it
mickkael/librespeed-go:arm32v6 ?
Success! Nice job mate, started properly and did a full saturation of throughput on a raspberry pi 3B.
Nice work!
Can you close the issue ?
I'll build a multiarch image soon
Will do. Thanks for the effort.
multiarch image available:
mickkael/librespeed-go:latest
arm
arm64
amd64