The newControlPlane flag has been historically problematic, since
it implies that the function FetchInitConfigurationFromCluster
cannot handle the cases where a node is worker node but
we still want to fetch its NodeRegistrationOptions conditionally,
in cases such as "upgrade node" for workers.
To fix this issue, replace the flag newControlPlaneNode with
two new flags getNodeRegistration and getAPIEndpoint.
If getNodeRegistration is true, we fetch the NRO, and if
getAPIEndpoint is true, we fetch the API endpoint for
that node.
Additionally, rename skipComponentConfigs to getComponentConfigs
for consistency and flip its value accordingly everywhere.
When waiting for the kube-apiserver to report 'ok'
in the 'init' and 'join' phase 'wait-control-plane', a client
constructed from the 'admin.conf' is used. In the case of the
kube-apiserver, the discovery client is used so that
anonymous-auth works. But if 'admin.conf' is used as is,
it would point to the CPE and not the LAE.
Implement a new method WaitControlPlaneClient() for both
init.go and join.go that patches the 'Server' field in the
loaded v1.Config to point to the LAE, before constructing
a client set and using it in the kube-apiserver waiter.
Replace context.TODO() and poll timeout context propagation with direct
context.Background() calls to prevent timeout errors from masking actual
API errors. Affects discovery/file.go, phases/upgrade/health.go, and
util/apiclient/wait.go for consistent error reporting.
The semantics (sometimes it returns an error that is really just a
warning) are too confusing, and it turns out that we really only need
it in one place (platformCheckSupported()); after that we've already
figured out what IP families are supported, so we could just use
utiliptables.NewBestEffort() instead, knowing we want exactly what it
returns.
So we can just expand the semantics of the old NewDualStack() inline
in the one place we care, without hiding any of it behind a
too-complicated return value.
This change refactors the cloud-specific versions of the node lifecycle
and node IPAM controllers to use a context.Context for cancellation and
contextual logging, replacing the legacy stopCh pattern.
This is a follow-up to PR #133985, where these controllers were
separated out due to their use in the legacy Cloud Controller Manager
(CCM).
It is a known issue that the CCM's startup logic does not pass the
controller name via the context. This change proceeds with the
refactoring to unify the cancellation logic across controllers, while
acknowledging that contextual logs will be less detailed when these
controllers are run in the CCM.
Signed-off-by: Aditi Gupta <aditigpta@google.com>
