-
Notifications
You must be signed in to change notification settings - Fork 109
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
Usage of IPs returned by InstancesV2().InstanceMetadata()
, and interaction with --node-ip
#61
Comments
Anyone have insight into these issues? |
If kubelet is configured to use Also note that Node IPs are either internal or external. This is not synonymous with private and public. Internal means used for intra-cluster communication, and can (often) be public IPs. For example when IPv6 is used, some CCMs always classify these as Internal. |
Thanks for hopping in @olemarkus Yes, I definitely get the private/public vs internal/external distinctions, but it is good to have them clearly here on this issue. So to summarize. Setting When you wrote "list of eligible IPs", how does kubernetes decide, from that list, "this is the one I will use for internal comms, which is the one listed when I do |
Assuming an external CCM is used, then no, setting "List of eligible IPs" is whatever is returned by the |
Sure, totally got that. When it gets returned, how does kubernetes decide which IP to use? Is it first in the list? |
Also, is it this annotation, which is alpha? Or some other? |
The first entry is the primary node IP, yes. And yes, that is the correct annotation. |
When I pass |
Hmm, while we are at it, is there any way for a user to provide an external IP as well? Or is the |
It will certainly be validated. Kubelet also uses the argument for what IPs to listen to on the kubelet server. Using an external IP probably works. But keep in mind that the control plane and a few pods typically need to reach the kubelet API. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I am trying to clarify several related issues.
First, if an external CCM returns multiple addresses of one type (e.g. 2
InternalIP
or 2ExternalIP
), which ones become "the" IPs used for the node resource? Some comments in #56 imply that it is sorted order, i.e. first one of a given type, but is that actually so? Is it documented anywhere?Second, the description in #56, and the code comment here say that, essentially,
--node-ip
is an override. So if I provide--node-ip
, then whether that IP appears inInstanceMetadata()
's response or not, that will be the node's address.How does it determine if
--node-ip
is public or private? The description in kubelet reference does not say which one it is, or how it determines.Finally, the code implies that it does not actually use
--node-ip
unless it also appears inInstanceMetadata()
.It only would use
--node-ip
address if it also matches one provided by the CCM.I have not tried that quite yet, as I am not sure I am understanding it correctly.
The text was updated successfully, but these errors were encountered: