Lab 4.2 vish/stress pod CrashLoopBackOff

aristideboisseau

Hi there,

I started lab 4.2 trying to deploy the vish/stress image and it's not working.
I tried others stress images and the results is the same.

Any idea ?

Kind regards
Aristide

>

ubuntu@cp:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
hog-5f9cd5f666-6fb5h 0/1 CrashLoopBackOff 6 (50s ago) 6m28s

>

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 8m2s default-scheduler Successfully assigned default/hog-5f9cd5f666-6fb5h to worker1
Normal Pulled 8m1s kubelet Successfully pulled image "vish/stress" in 1.095s (1.095s including waiting). Image size: 1558791 bytes.
Normal Pulled 7m59s kubelet Successfully pulled image "vish/stress" in 1.142s (1.143s including waiting). Image size: 1558791 bytes.
Normal Pulled 7m45s kubelet Successfully pulled image "vish/stress" in 1.275s (1.275s including waiting). Image size: 1558791 bytes.
Normal Created 7m18s (x4 over 8m1s) kubelet Created container stress
Normal Started 7m18s (x4 over 8m1s) kubelet Started container stress
Normal Pulled 7m18s kubelet Successfully pulled image "vish/stress" in 1.102s (1.102s including waiting). Image size: 1558791 bytes.
Normal Pulling 6m37s (x5 over 8m2s) kubelet Pulling image "vish/stress"
Normal Pulled 6m36s kubelet Successfully pulled image "vish/stress" in 1.354s (1.354s including waiting). Image size: 1558791 bytes.
Warning BackOff 2m54s (x24 over 7m58s) kubelet Back-off restarting failed container stress in pod hog-5f9cd5f666-6fb5h_default(ffc3055e-ae90-426e-a834-675e1ef7f450)

chrispokorni

Hi @aristideboisseau,

Keep in mind that typically stress images are used for stress-testing purposes. They are pre-configured to put stress on system resources, such as CPU and Memory.
It seems your cluster successfully pulls the image from the repository.
Are there additional events related to your hog deployment? Shortly after the deployment was launched, run kubectl events to capture and display all recent cluster events.
What details can you extract from the container logs? Run kubectl logs hog-pod-name to capture container logs, or use the -p flag if needed to capture the last terminated container logs.
Running top on both your nodes, should show high consumers of CPU and Memory on each VM.
Describe both nodes, and ensure there are enough resources available on each VM. Assuming the VMs were provisioned with the 2 CPU cores, 8GB Memory, and 20GB+ disk space, the very first hog deployment should be successful.

Regards,
-Chris

aristideboisseau

Hi Chris,

I may found the answer of this issue.
I have created two k8 clusters with Multipass, one on a Mac M1 where the deployment is not working, and another one an intel Mac
where there is no issue running the fish/stress container within the associated deployment.

So I guess there is something there related to this problem.

Best regards,
Aristide

chrispokorni

Hi @aristideboisseau,

Ah yes, the M1 processor. This critical detail should have been mentioned from the very beginning.

In case you missed the fine-print for Apple Mac computers powered by an "M" processor, from now on you have to be extra careful when installing software packages, runtimes, and container images. They need to be compatible with the ARM architecture. A container image compatible with the AMD/Intel architecture may not run directly on ARM processors. Whether you can achieve this, I recommend reaching out for assistance in user groups and forums dedicated to supporting the Mac/ARM users community.

The vish/stress container image unfortunately was built for the AMD/Intel architecture - the reason it works on the older model. If selecting a different stress image, ensure it is for the ARM architecture to successfully run it on the newer model with the M1 processor.

Regards,
-Chris