-
Notifications
You must be signed in to change notification settings - Fork 92
Avoid hard-coded values for API server address #288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
jip149
wants to merge
1
commit into
k3s-io:master
Choose a base branch
from
jip149:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You cannot assume that the in-cluster apiserver port is the same as the actual port on the host. For example, on both K3s and RKE2, the port for the in-cluster kubernetes service is 443, and that's what you'll see here if you look at the client config - but the apiserver is actually listening on 6443 on the server nodes.
You need to understand the difference between service ports, and service endpoints. Bootstrap charts need to access the local apiserver endpoint directly, as kube-proxy and the rest of the CNI cannot be relied on to be functional yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I understood that.
I tried the patch with minikube and k3s by using helm-controller outside the cluster. In that case it worked since the kube-config file is set with direct api endpoint and not the in-cluster service.
I forgot to try the in-cluster image. I suppose in that case the code will use the in-cluster service and fail.
I will try and report back.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, doing this the "right way" such that it will work in all possible environments is non-trivial, which is why I opted to just fix it the easy way in K3s.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn’t find a use-case where the helm controller can connect to the API but not the helm bootstrap chart pod.
If the helm controller is using the in-cluster api and has access to the custom resources, then the pod running the bootstrap chart will be able to connect as well to the in-cluster API.
If the helm controller is configured to connect to the in-cluster API and the in-cluster API is not available, then the helm controller will never see the custom resource and will never start any pod anyways.
So using the in-cluster API for bootstrap charts when helm controller is using in-cluster API shouldn’t be a problem?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
helm-controller runs embedded in the K3s and RKE2 supervisor process, and always talks to the local apiserver endpoint, not the in-cluster service endpoint.
Users can also deploy it as a daemonset that runs with host network on control-plane nodes, and point it to the local apiserver endpoint. This would be necessary if it was to be used for bootstrap charts on other Kubernetes distributions.
Running it against the in-cluster service endpoint will never work for bootstrap charts, as you cannot rely on the cluster network being up yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That use-case is not related to the PR, as host and port will be given by the supervisor process.
In that case, the PR works since bootstrap charts will re-use host and port of local api server endpoint given by the user.
The only case in which the PR will use in-cluster service endpoint for bootstrap charts is if helm-controller is using in-cluster service endpoint to get the custom resource.
Either network is up, helm-controller can get custom resources, and bootstrap charts will work using in-cluster api.
Or network is down, helm-controller can’t get custer resources, and no bootstrap charts will ever be started.
I’ll make more tests and report logs, but I still don’t see what I’ve missed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn’t find a failing use-case. See below for configuration I tested and logs.
Could you provide a way to make the PR fail? I have no problem updating the PR to use hard-coded values in specific situations, but I’d rather limit using 127.0.0.1 to situations where re-using host and port from the controller actually fail.
Test 1: embedded in k3s
Test 2: out of cluster
Test 3: in-cluster helm-controller using local api server endpoint
Test 4: in-cluster helm-controller using in-cluster api service
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made more tests, this time by disabling both flannel and kube-proxy.
This is now the behavior I described above. In-cluster api service cannot be reached, but the problem is not with the bootstrap chart, it’s just that helm-controller does not start (see logs below).
I still can’t find a situation where using a hard-coded value is better than connecting to host and port used by helm-controller.
Test 5: in-cluster helm-controller using in-cluster api service without kube-proxy
Test 6: in-cluster helm-controller using local api server endpoint without kube-proxy