daemon: Add --derive-masquerade-ip-addr-from-device opt

[brb]

The new option is used to specify a device which globally scoped IP addr
should be used for BPF-based masquerading.

This is a workaround for an environment which uses ECMP for outgoing
traffic and it has a dedicated device which IP addr should be used for
the masquerading. The workaround is relevant until
#17158 has been resolved (thus,
we hide the flag).

[brb]

test-gke

[christarazi]

LGTM, minor comments

[christarazi]

If this is supposed to be "hidden" for now, does it make sense to mark this as "minor release change"? I'd expect release-note/misc?

[pchaigno]

LGTM but not sure I understand the motivation:

This is a workaround for an environment which uses ECMP for outgoing traffic and it has a dedicated device which IP addr should be used for the masquerading. The workaround is relevant until #17158 has been resolved (thus, we hide the flag).

#17158 describes a case where a device as multiple global scope IP addresses. This new flag still won't address that since we're only selecting the first global scope IP address of the passed device. What am I missing?

Also, what's the link with ECMP? Do you mean egress traffic from pods can egress the node on multiple native devices, but it should always be SNATed to the same IP address?

[brb]

#17158 describes a case where a device as multiple global scope IP addresses. This new flag still won't address that since we're only selecting the first global scope IP address of the passed device. What am I missing?

Also, what's the link with ECMP? Do you mean egress traffic from pods can egress the node on multiple native devices, but it should always be SNATed to the same IP address?

The configuration I'm talking about is eth0 and eth1 with local scope IP addrs used for outgoing traffic, and then dummy0 which globally scoped IP addr should be used as src IP addr for the traffic. With #17158, the bpf_fib_lookup will determine the src IP addr based on the route which will be the IP addr of the dummy0.

[brb]

test-net-next

[maintainer-s-little-helper]

Job 'Cilium-PR-K8s-1.16-net-next' has 1 failure but they might be new flake since it also hit 1 known flake: #17060 (94.00)

[brb]

test-net-next

[brb]

test-net-next

[maintainer-s-little-helper]

Job 'Cilium-PR-K8s-1.16-net-next' failed and has not been observed before, so may be related to your PR:

Click to show.

Test Name

K8sKafkaPolicyTest Kafka Policy Tests KafkaPolicies

Failure Output

FAIL: DNS entry of kafka-service is not ready after timeout

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.16-net-next so I can create a new GitHub issue to track it.

[brb]

CI hit:

• CI: RedirectSuite.TestAddVisibilityRedirects #17414
• k8s-1.13-net-next CI: DNS entry is not ready after timeout #14598

Considering that this is the fix for the customer and it got ACK-ed by the reviewers, marking as ready-to-merge.