Open artushin opened 6 years ago
If quay.io supports multi-stage builds, I can try and work on reducing the layers needed. But right now I'm really busy with work stuff :/
Squashing worked alright (grep overlay /proc/mounts | wc -c
went down from 1870 to 358) and elasticsearch started. I don't actually know if the latest images have the same issue. I think it would depend on when you last built docker-jre.
I remember there was some issue with Alpine Linux containers and layers. Anyway, I can't find a way right now to squash this without overwriting automatically tagged images. Using your own is fine by me.
:heart_eyes: Thanks for providing the workaround, using docker-squash
could solve the problem. Another approach is updating the base image from alpine to new version (Alpine >= 3.6.2) or other linux distro as suggested by @AtzeDeVries in this issue.
just a warm reminder, if u want to keep using the same image version tag when deploying to k8s, make sure u have imagePullPolicy: Always
in the deployment .yaml file. Otherwise k8s will always keep using the old image. (i got stuck for two days! :persevere: )
I was having the same problem with the java.io.IOException: Mount Point not found
using the quay.io/pires/docker-elasticsearch-kubernetes:2.4.0 image (as of June 1, 2018) on Azure Kubernetes Service with https://github.com/pires/kubernetes-elasticsearch-cluster (for both es-master.yml and es-data.yml). Surprisingly, the exact same Kube specs worked on the first attempt on GKE and AWS (with KOPS). Also, notably, if I move to quay.io/pires/docker-elasticsearch-kubernetes:5.6.0, the configuration worked on all three providers equally.
To workaround the issue, as explained by @artushin in the original post, I followed these steps:
quay.io/pires/docker-elasticsearch-kubernetes:2.4.0
on my Linux VMdocker-squash
as described in https://github.com/goldmann/docker-squashdocker-squash 852fb8f4a5e1
, where 852fb8f4a5e1
is the Docker image ID of quay.io/pires/docker-elasticsearch-kubernetes:2.4.0
9c4ca802e8b9
) as myrepo/pires-docker-elasticsearch-kubernetes:2.4.0
es-master.yml
and es-data.yml
to refer to myrepo/pires-docker-elasticsearch-kubernetes:2.4.0
(everything else remains identical)es-master.yml
and es-data.yml
using kubectl apply -f
That worked on AKS. I'm still testing the same with GKE and AWS/KOPS, but I'm hopeful that a single kubespec will work across the three engines.
Super thanks to @artushin
@dearjadu It's still work really fine at Azure AKS? What is VM Size are you using?
@alexsandro-xpt Yes, it does. I was able to use the same "sqashed" image in both GKE and AKS. I'm using Standard_DS11_v2
on AKS (and n1-highmem-2
on GKE).
FYI, that image (2.4.0) is super old. I highly recommend the new 6.x versions.
Pod startup fails with the following:
Same issue as https://github.com/elastic/elasticsearch-docker/issues/44
Workaround for those of us on the pires images: Use https://github.com/goldmann/docker-squash to reduce the size of overlay in /proc/mounts then push your own image and use that.
😢