k8s-triage-robot
commented
1 year ago The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-ci-robot
/kind bug
What steps did you take and what happened: Hello out there. has anyone played around with the PreferredAPIServerCIDR parmeter in the VsphereMachineTemplate Network Stanza? (https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api-provider-vsphere/infrastructure.cluster.x-k8s.io/VSphereMachineTemplate/v1beta1@v1.5.1)
it says its a string, however when i try simple "10.0.0.0/8" or the IP of my API endpoint (10.0.0.1/32) i get this error (which made me think that it was perhaps deprecated - however, looking at the link above, it seems that v1.5.1 is the latest of the Spec.) The "use-case" - i want to have two NIC on my TKG worker and control plan VMs that are from two different networks. The "issue' - when i use the stanza below and TKG spins up the cluster, the configuration gets garbled, sometimes the /etc/Kubernetes generated configs have IPs and URLS to eth0 IP and some to eth1 IP (the network that i dont want to be included in the kube-system stuff or the host setup - will pass via multus later on) What i see - while i can fix up the configuration in /etc/Kubernetes and sort the Urls, during the process of TKG (1.6.0 and greater) the X509 certs are being setup with a SAN inside, and the SAN is the IP of the second NIC - so then when we do fix /etc/kubernetes files, the cert doesnt match (not allowed in the SAN)) - this would mean "redoing" the whole PKI chain to accomodate the configuration fix. What i am "hoping" is that this PreferredAPIServerCIDR is intended so that in the case of "two or more NICs" -- during the Cluster rollout, the kubeadmCP and other components know "which" network they are to bind and build off of. however, it doesnt seem to work :disappointed: (tanzu v0.25.0, v0.25.4 and even trying with TKG2.1 and seem to have this issue).. in the "older days" we were able to fake out Calico however, the configuration to bind Calico is locked out and this now seems a bit more than just CNI setup, rather the K8s binding at the key needs to have this "PrefferedAPIServiceCIDR" (again - im guessing at what i think the intention of the parameter was)... Looking into the code base a bit its not clear "why' the K8s parser would throw the error out. oops - i should mention that this same issue occurs whether im using Antrea or Calico and really seems like when you boot the initial setup, if the target Machine has two NICs, the starting containers are not clear 'which one" to use and thus end up with a split / non-functional k8s configuration - so we dont get "as far" as CNI. Looking even deeper -it would seem that there are test cases that use this a parameter so it seems like it "should work" - https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/main/pkg/util/machines_test.go any thoughts?
What did you expect to happen:
I expected that using a Parameter that is defined in the Spec would "work" (parse) and that this would resolve the collision of setting up the K8s service on the target MachineDeployments
Anything else you would like to add:
Environment:
kubectl version): 1.23.8-vmware/etc/os-release): photon 3