Requires tweaking existing method signature to allow specifying whether or not IPv6 addresses should be return URL-safe.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Use same kubelet-preferred-address-types setting as RKE2 to improve reliability of the egress selector when using a HTTP proxy. Also, use BindAddressOrLoopback to ensure that the correct supervisor address is used when --bind-address is set.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
The control-plane context handles requests outside the cluster and
should not be sent to the proxy.
In agent mode, we don't watch pods and just direct-dial any request for
a non-node address, which is the original behavior.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Watching pods appears to be the most reliable way to ensure that the
proxy routes and authorizes connections.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
This is required to make the websocket tunnel server functional on
etcd-only nodes, and will save some code on the RKE2 side once pulled
through.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Closing idle connections isn't guaranteed to close out a pooled connection to a
loadbalancer endpoint that has been removed. Instead, ensure that requests used
to wait for the apiserver to become ready aren't reused.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Several types contained redundant references to ControlRuntime data. Switch to consistently accessing this via config.Runtime instead.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
* Regular CLI framework for encrypt commands
* New secrets-encryption feature
* New integration test
* fixes for flaky integration test CI
* Fix to bootstrap on restart of existing nodes
* Consolidate event recorder
Signed-off-by: Derek Nola <derek.nola@suse.com>
Since we now start the server's agent sooner and in the background, we
may need to wait longer than 30 seconds for the apiserver to become
ready on downstream projects such as RKE2.
Since this essentially just serves as an analogue for the server's
apiReady channel, there's little danger in setting it to something
relatively high.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Works around issue with Job controller not tracking job pods that
are in CrashloopBackoff during upgrade from 1.21 to 1.22.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Also honor node-ip when adding the node address to the SAN list, instead
of hardcoding the autodetected IP address.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Required to support apiextensions.v1 as v1beta1 has been deleted. Also
update helm-controller and dynamiclistener to track wrangler versions.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Updated the logic to handle if extra args are passed with existing hyphens in the arg. The test was updated to add the additional case of having pre-existing hyphens. The method name was also refactored based on previous feedback.
* Move cloud-controller-manager into an embedded executor
* Import K3s cloud provider and clean up imports
Signed-off-by: Chris Kim <oats87g@gmail.com>
* Changed cloud-controller-manager user name in ccm.yaml
Signed-off-by: dereknola <derek.nola@suse.com>
* Changed RBAC name in server.go
Signed-off-by: dereknola <derek.nola@suse.com>
* Changed "k3s" string prefix to version.Program to prevent static hardcoding
Signed-off-by: dereknola <derek.nola@suse.com>
* Changed user in ccm.yaml to k3s-cloud-controller-manager
Signed-off-by: dereknola <derek.nola@suse.com>
Problem:
Only the client CA is passed to the kube-controller-manager and
therefore CSRs with the signer name "kubernetes.io/kubelet-serving" are
signed with the client CA. Serving certificates must be signed with the
server CA otherwise e.g. "kubectl logs" fails with the error message
"x509: certificate signed by unknown authority".
Solution:
Instead of providing only one CA via the kube-controller-manager
parameter "--cluster-signing-cert-file", the corresponding CA for every
signer is set with the parameters
"--cluster-signing-kube-apiserver-client-cert-file",
"--cluster-signing-kubelet-client-cert-file",
"--cluster-signing-kubelet-serving-cert-file", and
"--cluster-signing-legacy-unknown-cert-file".
Signed-off-by: Siegfried Weber <mail@siegfriedweber.net>
The kube-apiserver cert should have the same SANs in the same order,
excluding the extra user-configured SANs since this will only be used
in-cluster.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>