search

kubernetes-retired / cluster-api-bootstrap-provider-kubeadm

LEGACY REPO. NEW CODE IS https://github.com/kubernetes-sigs/cluster-api/tree/master/bootstrap/kubeadm
Apache License 2.0
62 stars 67 forks source link

There is no default CRI socket #203

Closed akutz closed 4 years ago

akutz commented 4 years ago

/kind bug

What steps did you take and what happened: In CAPA v1alpha1 the containerd socket was selected if no other CRI socket was specified. This is planned for CAPV 0.4.2 (v1alpha1) as well. However, in the new Kubeadm Bootstrapper there is no longer a default CRI socket. CRI auto-detection did not land until Kubernetes 1.14, which means the Kubeadm Bootstrapper generates bootstrap data that will cause Kubernetes 1.13-based machine images to fail unless a CRI socket is explicitly selected.

This was fixed in CAPV v1alpha2 so that containerd is the default socket, and there are plans to do the same for CAPA.

What did you expect to happen: Since the CAPI image builder creates machine images based on containerd, it makes since for this bootstrap provider to default to the containerd socket if no other CRI socket is selected.

Anything else you would like to add: I believe this should be treated as a regression from CAPA and CAPV v1alpha1.

detiber commented 4 years ago

@akutz I worry a bit here that we may be optimizing for v1.13 here vs optimizing for v1.14+, especially as we near the end of support for upstream v1.13 with the release of v1.16.

That said, I do think this highlights a certain class of regressions that were introduced in v1alpha2 compared to v1alpha1, which is that the bootstrapping provider no longer has direct communication with the infrastructure provider in order to set defaults that are infrastructure provider specific. This affects not just the provider examples needing to explicitly set the cri runtime (in the case of v1.13 clusters), but also needing to specify cloud provider arguments (for all deployed k8s versions). This is something that we should start addressing in the v1alpha3 cycle, since this will likely require API and component contract changes.

In the meantime, I think the approach taking by CAPV for specifying the CRI configuration in the examples is likely the right approach for v1alpha2 and should also be followed for other providers that have a need to support k8s v1.13 and also default to containerd as the CRI runtime.

detiber commented 4 years ago

/priority important-soon /milestone Next

chuckha commented 4 years ago

@akutz do you still need this for 1.13 support in v1alpha2?

akutz commented 4 years ago

Closing for #131. When a defaults mechanism is provided, it will solve this issue.