Deployment on k3s not working (containerd runtime)

[IuriGarcia]

Hi everyone!

So, i was trying to deploy it with the k3d as an alternative to minikube.
k3d uses that docker image rancher/k3s:v1.17.3-k3s1.

when i deploy it, that just happen

NAME                                           READY   STATUS             RESTARTS   AGE
wicked-wicked-kong-adapter-5db56c5bb8-c44k8    0/1     Init:0/2           0          168m
wicked-wicked-portal-55dcbdf8c8-k7n57          0/1     Init:0/1           0          168m
wicked-wicked-auth-5f6bbd8cb-6x42s             0/1     Init:0/1           0          168m
wicked-wicked-mailer-78c5c46d8b-k72jj          0/1     Init:0/1           0          168m
wicked-wicked-redis-58b8bcc8d9-sgbq2           1/1     Running            0          168m
wicked-wicked-kong-database-8467566f9d-cstcf   1/1     Running            0          168m
wicked-wicked-kong-5bb6c8f45c-qhc7f            1/1     Running            0          168m
wicked-wicked-api-7bdb967dc7-vzjtp             0/1     CrashLoopBackOff   37         168m

the only logs that i can get is
Error from server (BadRequest): container "wicked-wicked-portal" in pod "wicked-wicked-portal-55dcbdf8c8-k7n57" is waiting to start: PodInitializing

in the ones with Init:0, and

Running as root.
Do not use this script in non-dockerized environments.
Detected non-Linux runtime Linux, or /.dockerenv is not present.
Use 'node bin/api' or 'npm start'.'

in the wicked-api pod. Still can't find out the problem.
So, if you guys could please help me out, already thankfull

[DonMartin76]

OK, so k3s apparently behaves different than minikube or Docker; I will have a look what happens if the API does not find .dockerenv in the / folder. Must admit I have never tried it out, so more than interested in seeing what is happening here.

You tried to deploy using the Helm chart, right?

Are you using k3s with the default containerd container runtime, or did you use the --docker option? Would you mind trying that and see whether that makes any difference? The error message comes from a check in the docker-start.sh script which is supposed to prevent somebody calling that script where they're not supposed to.

[DonMartin76]

I have checked in an attempted fix for this (see above). You can try this out with the latest helm chart by overriding the image.tag value with next, i.e. like this --set image.tag=next. Give me a shout out if that works. Or not.

[IuriGarcia]

ok! i will try it later, see you soon!

[IuriGarcia]

I was using k3d to local testing just like that

k3d create -n wicked \                                   
  --enable-registry \
  --publish 8080:32080 \
  --server-arg "--no-deploy=traefik" \
  --server-arg "--no-deploy=servicelb"

k3d by default uses docker as far as i know. The latest helm chart just fixed it! all running just fine!
I can not even put in words how thankful i am, really, D.Martin!

[DonMartin76]

Lands in 1.0.0-rc.14