Remove sessionAffinity ClientIP from services

[ejweber]

Which issue(s) this PR fixes:

Issue #7399

What this PR does / why we need it:

Remove sessionAffinity: ClientIP from Longhorn services. See #7399 for justification.

Special notes for your reviewer:

We could optionally introduce a Helm variable that controls the value of sessionAffinity for the Longhorn services that previously used sessionAffinity: ClientIP. If we did this, I would argue for making None the default, with the option to change back to ClientIP if desired. However:

1. I cannot identify any situation in which we should be using sessionAffinity: ClientIP,
2. More Helm variables makes Longhorn deployment more difficult to understand.

I'm curious whether reviewers agree.

[innobead]

LGTM.

Agreed that there is no need for having a variable to customize this property since the session affinity should be determined by the server side instead of the client side. There is no session concept in our API server.

note: The default value of sessionAffinity is None.

[ejweber]

note: The default value of sessionAffinity is None.

Good catch on "" vs None. Updated the description.

[PhanLe1010]

LGTM

Agree that we should remove the setting completely!

Quick question. Assume that we have sessionAffinity: ClientIP set. In the first time the client connects to the backend service it is routed to manager pod with IP-1. Then manager pod with IP-1 crash, restarted, and get a new IP-2. When client connect to backend service for the 2nd time, will Kubernetes network control plane route the client to a new IP different than the IP-1 assume no manager pod has IP-1 anymore?

[ejweber]

Quick question. Assume that we have sessionAffinity: ClientIP set. In the first time the client connects to the backend service it is routed to pod with IP-1. Then pod with IP-1 crash, restarted, and get new IP-2. When client connect to backend service for the 2nd time, will Kubernetes network control plane route the client to a new IP different than the IP-1 assume no manager pod has IP-1 anymore?

I think yes, though I am interested enough to test it.

From #7399 (comment):

---

The chain that handles load balancing (KUBE-SVC-NQL64TY2T3FWFXFQ) has two kinds of rules:

• The first set of rules are for packets from source IPs that have already been balanced in the last configured number of seconds (10800). If, for example, the source IP is in the KUBE-SEP-W3Y4QUAIHX5U3K5C list, we jump to the KUBE-SEP-W3Y4QUAIHX5U3K5C chain.
• The second set of rules are for packets from source IPs that have not already been balanced. Probabilities are used to ensure we have an equal chance to jump to any related chain (e.g. KUBE-SEP-W3Y4QUAIHX5U3K5C).

---

The event you described should cause kube-proxy to remove the list of source IPs that previously balanced to the old destination IP and the rule that would check that list (e.g. KUBE-SEP-W3Y4QUAIHX5U3K5C). The source IP is obviously not in any of the other, still existing, lists, so we would eventually fall down to the set of rules that does the load balancing and DNAT to a different IP address.

In other words, I don't think sessionAffinity: ClientIP is likely to be the cause of any previously strange connectivity behavior we may have observed.

[innobead]

@mergify backport v1.6.x v1.5.x v1.4.x

[mergify]

backport v1.6.x v1.5.x v1.4.x

✅ Backports have been created

• #7764 Remove sessionAffinity ClientIP from services (backport #7748) has been created for branch v1.6.x
• #7765 Remove sessionAffinity ClientIP from services (backport #7748) has been created for branch v1.5.x
• #7766 Remove sessionAffinity ClientIP from services (backport #7748) has been created for branch v1.4.x