Christian Schlotter
Christian Schlotter
Maybe gets resolved or partially resolved in #2061
capv pushes arm64 + amd64 today as multi-arch already. But it slightly drifts from how it is done in core CAPI so aligning could help getting to a single tooling...
/assign @killianmuldoon For updating here and linking what work we already want to do
Got this on my list to check but got distracted for something else. /assign
All green since https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/pull/2983 + cherry-picks got merged 🎉 /close
Yeah, we've been unsure if we actually need this in CAPV, so more of a placeholder to not forget about it and think it through once.
When manually adding the line `127.0.0.1 kubernetes` to the hosts file, the next issue we hit is #684
Possible workaround: use a hand-crafted hosts file and mount it via a hostPath volume instead of relying on `hostAliases`. Regarding: > > pod.spec.hostAliases are not expected to work on hostNetwork...
Workaround for now: instead of hostAliases: * create a file (e.g. `/etc/kubernetes/manifests/kube-vip.yaml`) with the following content: ``` 127.0.0.1 localhost kubernetes ``` * Add the following to the static pod manifest:...
Workaround: * use `super-admin.conf` during `kubeadm init`. * revert the static pod back to `admin.conf` after successful `kubeadm init` (which causes a recreation of the kube-vip pod) Example solution (only...