chore: use transparent mode for Azure CNI #3958
Conversation
|
cc @vakalapa |
Codecov Report
|
|
|
||
| if o.KubernetesConfig.NetworkPlugin == NetworkPluginAzure { | ||
| if o.KubernetesConfig.NetworkMode == "" { | ||
| o.KubernetesConfig.NetworkMode = NetworkModeTransparent |
There was a problem hiding this comment.
sorry for a dumb question but what actually actions on network mode? I couldn't find it in my novice sluething. I just found this in cse.
if [[ "${NETWORK_POLICY}" == "calico" ]]; then
284 | sed -i 's#"mode":"bridge"#"mode":"transparent"#g' $CNI_CONFIG_DIR/10-azure.conflist
There was a problem hiding this comment.
is it this one?
There was a problem hiding this comment.
@weng271190436 has it right
Basically, the Azure CNI release artifact comes with a default static config, and we simply extract it, then sed replace "bridge" with "transparent" if the api model says to do so.
There was a problem hiding this comment.
Missed it by two lines and thought it was only calico that mattered. @matmerr planning on just having a transparent only conflist in cni 1.1.9. That means if someone explicity sets bridge mode it wouldn't work anymore. They'd have to know to fall back to 1.1.8.
In aks we control the cni url so we were planning on toggling that not using network mode.
|
|
||
| if o.KubernetesConfig.NetworkPlugin == NetworkPluginAzure { | ||
| if o.KubernetesConfig.NetworkMode == "" { | ||
| o.KubernetesConfig.NetworkMode = NetworkModeTransparent |
There was a problem hiding this comment.
is it this one?
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis, mboersma, weng271190436 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:
Approvers can indicate their approval by writing |
Reason for Change:
This PR changes the Azure CNI implementation to use "transparent" mode by default, rather than using a bridge interface. This change is due to an observed reduction in UDP edge cases, specifically intermittent high DNS lookup latency when the resolver is an IP address that sits in front of a distributed set of resolvers (DNAT). In the Kubernetes context, this is reproduced if there are more than one coredns pods in the cluster.
Fixes #3955
Issue Fixed:
Credit Where Due:
Does this change contain code from or inspired by another project?
If "Yes," did you notify that project's maintainers and provide attribution?
Requirements:
Notes: