limit the scope of 169.254.169.252/32 to host

[zshihang]

What type of PR is this?

/kind bug

What this PR does / why we need it:

when a cluster has calico enabled, traffic from node would sometimes use 169.254.169.252 as source ip instead of node ip. we need to change the scope from global to host.

Special notes for your reviewer:

Does this PR introduce a user-facing change?

none

[zshihang]

/sig auth
/priority high
/triage accepted
/cc @mikedanese

[k8s-ci-robot]

@zshihang: The label(s) priority/high cannot be applied, because the repository doesn't have them.

In response to this:

/sig auth
/priority high
/triage accepted
/cc @mikedanese

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.

[zshihang]

/priority important-soon

[aojea]

What type of PR is this?

/kind bug

What this PR does / why we need it:

due to #95790, traffic from node would sometimes use 169.254.169.252 as source ip instead of node ip. we need to change the scope from global to host.

Special notes for your reviewer:

Does this PR introduce a user-facing change?

none

That pr you mention only uses a global unicast addresses from the loopback if there are no other global unicast addresses on the host.

169.254.0.0/24 is link local and should not be picked, do you have an occurrence? I find it weird

[aojea]

/cc

Kubelet should not take this ip, will take a look later, thanks for reporting

[zshihang]

seems #95790 is not relevant here. this happens in a cluster with calico enabled.

[aojea]

when a cluster has calico enabled, traffic from node would sometimes use 169.254.169.252 as source ip instead of node ip. we need to change the scope from global to host.

is UDP traffic? can you provide more details about the problem?

[zshihang]

it is the healthcheck traffic (TCP) initiated by kubelet, i.e. node -> pod.

if you tcpdump on ip of any pod that has health check configured, you would see something like this:

22:12:13.486826 IP 169.254.169.252.54256 > 10.16.0.10.8093: Flags [S], seq 2990051932, win 42600, options [mss 1420,sackOK,TS val 165524131 ecr 0,nop,wscale 7], length 0
22:12:13.486888 IP 169.254.169.252.54256 > 10.16.0.10.8093: Flags [.], ack 3839683330, win 333, options [nop,nop,TS val 165524132 ecr 2383257463], length 0

this only happens in cluster with calico enabled.

[aojea]

this only happens in cluster with calico enabled.

there was an issue with this exact problem, I'll try to find it, it was related to some iptables rules doing NAT IIIRC

[aojea]

I can't find it, but I think that was the same problem, check the iptables rules on the host, I don't know why but sometimes it SNATed the traffic with the link local address, on that issue it was created by the node-local-dns sidecar

[mikedanese]

/retest

[mikedanese]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikedanese, zshihang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster/gce/gci/OWNERS [mikedanese]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[zshihang]

/retest