-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calico CNI installation fails with cridocker v0.3.12 #345
Comments
This is because #311 switched cri-dockerd from using the deprecated 'Binds' API to the new 'Mounts' API, which does not create missing directories by default: bf1a9b9 To preserve backward-compatible behavior, we need to set |
Isn't https://github.com/Mirantis/cri-dockerd/blob/v0.3.12/libdocker/helpers.go#L224 |
Shoot, I missed that we're setting that in the diff. @anfechtung could you please let us know what Engine version you are using? |
I am assuming by Engine you mean the docker runtime:
|
|
|
We might be downgrading the API version to <= v1.41 in somewhere? |
Do you have any potential workarounds? Or a planned fix? I am trying to determine if it makes sense to go down the rabbit hole of pre-creating all of the needed directories. |
Someone has to figure out exactly what's going over the wire and whether the issue is on the client or server side. I don't think there are any workarounds outside of pre-creating the directories on the host. |
#346 ought to solve this; would you mind testing a build off of master? That being said, I think we should keep this issue open until we have a regression test. |
Is there a deb package built from master, or would I need to build from master? Currently we are using the deb package to install. |
You would need to build from master; there are instructions and it is as trivial as a |
I compiled from master, and dropped the new binary on my cluster. I am still getting the same error. I tried setting the log level for the cri-docker service to debug, but it didn't produce anything useful. |
After reading through the docker documentation, and the go docker libraries (Mount and Volume), I think this is simply the expected behavior when using docker mounts. |
It looks like some more digging will have to be done to determine where the fault lies; however, this is not the intended behavior. Kubernetes requires implicit directory creation as it was based on the Engine Binds API, which had this default behavior. We specifically added a new option to the Mounts API to enable implicit directory creation in v23, so if it doesn't work, there is a bug either in the daemon, or in cri-dockerd. |
I have the same problem with Promtail Pod. It tries to bind the path at /run/promtail but it can't. Normally, it should be created on the container's initial. Nodes using cri-dockerd 0.3.11 are working normally Pod Event
cri-dockerd version
Docker Information
|
Is there any minimal reproducer that does not depend on Calico? Can't repro the issue with the following yaml ---
apiVersion: v1
kind: Pod
metadata:
name: bind
spec:
volumes:
- name: mnt
hostPath:
path: /tmp/non-existent
containers:
- name: busybox
image: busybox
args: ["sleep", "infinity"]
volumeMounts:
- name: mnt
mountPath: /mnt (cri-dockerd v0.3.12, Docker v26.0.1, Kubernetes v1.30.0) |
Not sure what may have changed, but this same error does not occur in v0.3.13. |
@anfechtung v0.3.13 has the problematic change #311 reverted. |
Still can't repro the issue with calico. I wonder if the issue might have been already fixed in a recent version of Docker?
Used minikube v1.33 (Kubernetes v1.30.0, Docker v26.0.1, cri-dockerd v0.3.12, according to |
Bad Docker versions: <= v24.0.9, <= v25.0.3 Seems fixed in moby/moby@v25.0.3...v25.0.4 |
I was able to reproduce the error and fix. I followed the calico quickstart steps using minikube. This was all done using FailureUsing minikube v1.31.1, calico fails due to the missing mount
WorkingAfter upgrading my minikube version to v1.33.0, calico is successful
SolutionWe should document that
|
Expected Behavior
Prior to v0.3.12 we were able to successfully install calico cni provider using the tigera operator to a baremetal kubeadm managed kubernetes cluster.
Actual Behavior
When updating our process to use cri-docker v0.3.12 we see bind errors during calico deployment.
Initially the tigera-operator fails to deploy.
After manually creating the folder
/var/lib/calico
on the controller node, the tigera operator pod deploys, but calico cni pods fail withSteps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: