-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
feat: allow pod IPs even for non-hostNetwork pods #3174
base: master
Are you sure you want to change the base?
Conversation
Welcome @peterhoneder! |
It looks like external-dns is, in emulating kOps dns-controller, is assuming the pod IP is the same as a singular internal node IP. The Both the node's internal IPs case and pod's IP case are useful. In some networking configurations, non-host pods' internal IPs are inaccessible, yet the node internal IPs are. There is also a difference for dual-stack nodes supporting a cluster with a single-stack pod network. |
the proposed PR currently does not change that behavior, but yes the existing implementation of the non kops compatible code path would only use NodeIPs from host network pods |
I have a vague recollection of pods created in the early minutes of a new cluster having odd IP addresses, but I can't find anything like that in e2e tests. In the tests I've looked over, Whether or not non-host-network pods are included can be controlled by whether non-host-network pods have the annotation. There's a good question of whether it should use /lgtm |
I think I remember what it was: before the CNI comes up, the As previously noted, this was broken before and remains broken after the PR. The fix would be to follow from the pod to the node for pods that are host-networking. Fixing external-dns to correctly implement kOps requirements is behind #2051. |
Hi! my change does not affect the behavior for host-networking. It only allows an additional behavior for non host-networking pods, where the PodIP is correctly populated, and must be used instead of the host IP. The typical use case would be with a CNI like calico, where e.g. publicly routable IPv4 addresses are assigned to the pod. |
To be clear, I was not asking this PR to fix the handling of kOps requirements. It does not make things worse. |
ok, thanks, perfect 😄 just wanted to make sure we have the same understanding 👍 |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
@@ -254,7 +254,7 @@ func TestPodSource(t *testing.T) { | |||
"", | |||
[]*endpoint.Endpoint{ | |||
{DNSName: "a.foo.example.org", Targets: endpoint.Targets{"54.10.11.1"}, RecordType: endpoint.RecordTypeA}, | |||
{DNSName: "internal.a.foo.example.org", Targets: endpoint.Targets{"10.0.1.1"}, RecordType: endpoint.RecordTypeA}, | |||
{DNSName: "internal.a.foo.example.org", Targets: endpoint.Targets{"10.0.1.1", "100.0.1.2"}, RecordType: endpoint.RecordTypeA}, |
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.
The test name seems to be wrong.
And I wonder if you can increase test cases.
@peterhoneder Do you think you can rebase this PR and takes into account review comment from @szuecs ? |
yes, I will do that |
but only for the internalHostnameAnnotationKey which doesn't use the node's IP anyway tests validate this for annotations with: - mixing pods in the host network with others that are not - multiple comma separated annotations per Pod - explicitly set targets - IPv4 and IPv6
44fd810
to
1b9c3bd
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I rebased the PR and added more tests and more explicit comments on why the tests are there that way. I tested the scenarios described in the commit message. Regarding the comments further up in the thread especially from @johngmyers I think this points to valid use cases that might be interesting. In our setup we are basically using the internal hostname annotation for pods where calico CNI provides addresses and later announces those over BGP. Those addresses are public addresses due to the nature of the workload. In those cases having the regular hostname annotation work similarly in cases where the pod is not in the host network would be beneficial, but due to the constraints described above this sounds to me more like a task for a future PR. |
/ok-to-test |
/lgtm |
source/pod.go
Outdated
// accept annotations that point to the node's external IP (or IPv6 NodeInternalIP) only for pods using the host network | ||
if pod.Spec.HostNetwork { |
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.
Wdyt about removing this condition to cover all cases described in #3468 (comment) ?
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 can include that change in here, will do so later today.
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.
@mloiseleur please check, I added the changes and also some more docs updates.
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.
It's lgtm at first glance. I asked @gregorycuellar to also check, if possible.
- incorporated changes from PR kubernetes-sigs#3468 to allow for arbitrary annotations to be used no matter the hostNetwork property's value - updated docs to make clear how the annotations are used for pods
@gregorycuellar : This PR has been improved to include use case of #3468. Wdyt ? Anything missing ? |
@mloiseleur It look good to me, I think it's ok |
/lgtm |
is there an update on this? |
Hi! any updates on this? |
1 similar comment
Hi! any updates on this? |
I don't think DNS is a good choice for this use case. They should rather create a service type loadbalancer. Maybe calico can build a svc type loadbalancer if they see value in supporting it. In general I would rather delete pod dns name functionality than invest more into it. |
Let me explain the use case: there are services which cannot be put behind a service. E.g. if you have multiple connections which need to end up on the same replica but originate from different source IPs. E.g. if they are based on DNS round robin, a k8s service would not help. It would only help if a service would be created for each pod separately. The patch works very well in production and seems to be used by multiple people who even created multiple PRs for this. |
Hello All, I am a user of external DNS, and I manage, design and operate enterprise container platform. I will like to clarify some assumptions from this thread, and state that any POD IP can be reached for external communication if they are routed to the network. That is what we use for our enterprise deployment, routed pod IPs, where SNAT is not used and all communication between/to a pod can be allowed if the security policy allows it. It is my understanding that using this check for hostNetwork=False, and assuming that those pods should be ignored is also wrong |
I believe that use case is indeed not the only one. Pod IPs can be routable, and allowing it to have a dns name can be relevant for many different scenarios |
but only for the internalHostnameAnnotationKey which doesn't use the node's IP anyway
Description
Pod IPs and node IPs can be used for hostname annotations on pods.
The existing implementation worked this way:
I would like to change the implementation to cover a case, where Pod IPs can be exposed as names, but with pods where hostNetwork == false. This is a typical use case with CNI plugins like Calico CNI, where pod IPs are exposed as BGP routes directly to the ToR router/switch. So there is basically no service in front of the pod and the pod is directly exposed to the outside world of the cluster, most commonly with an internet-routable public IP, but could also be a private IP that is justed routed internally. The usefulness of this change addresses both those cases.
Since the pod's IP is already used for the internal hostname annotation, there is no need to actually limit this behavor to pods with nodeNetwork: true.
I can add public documentation for this, since the whole pod annotation part is not publicly documented yet, it might be a topic for a separate PR though.
There is no github issue for this yet.
Checklist