ovn lb select the local chassis's backend prefer

[changluyi]

Pull Request

• Make sure you have followed Kube-OVN Code Style.

What type of this PR

Examples of user facing changes:

• Features
• Bug fixes
• Docs
• Tests

ovn 实现原理。

OVN 这部分代码修改原理：

实现原理是获取到vip backend的 chassis ， 新增加流表入下：

is_chassis_resident("nginx-6f55f97f94-8kvlx.default") , 其中 nginx-6f55f97f94-8kvlx.default 是某个vip 的backend下的任意一个lsp，backends=10.16.0.3:80 表示这个lb 在这个chassis下的所有backendip: port 。

  table=13(ls_in_lb           ), priority=140  , match=(ct.new && ip4.dst == 1.1.1.1 && tcp.dst == 80 && is_chassis_resident("nginx-6f55f97f94-8kvlx.default")), action=(ct_lb_mark(backends=10.16.0.3:80; hash_fields="ip_src");)
  table=13(ls_in_lb           ), priority=140  , match=(ct.new && ip4.dst == 1.1.1.1 && tcp.dst == 80 && is_chassis_resident("nginx-6f55f97f94-zlr4p.default")), action=(ct_lb_mark(backends=10.16.0.2:80; hash_fields="ip_src");)

如果hit不到以上流表，就会走原来的ovn lb 规则。

该功能需要配置Load_balancer的 两个字段
option:prefer_local_backend

option:prefer_local_backend=true

ip_port_mappings

"10.16.0.10"="nginx-6f55f97f94-m4bxx.default:10.16.0.4", "10.16.0.2"="nginx-6f55f97f94-zlr4p.default:10.16.0.4", "10.16.0.3"="nginx-6f55f97f94-8kvlx.default:10.16.0.4", "10.16.0.5"="nginx-6f55f97f94-ns9th.default:10.16.0.4"

kube-ovn 增加场景

场景1：switchlbRules 支持 OVN LB 优先走本地 backend

使用方法：

kube-ovn-controller 开启开关 --enable-ovn-lb-prefer-local = true

用例：

kind: SwitchLBRule
metadata:
  name:  cjh-slr-nginx
spec:
  vip: 1.1.1.1
  sessionAffinity: ClientIP
  namespace: default
  selector:
    - app:nginx
  ports:
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                      - nginx
              topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx-container
        image: nginx:alpine
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

场景2: ovn lb 模式下支持 internalTrafficPolicy: Local , 真正实现发送本地 backend

使用方法：

kube-ovn-controller 开启开关 --enable-ovn-lb-prefer-local = true

用例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:alpine
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  internalTrafficPolicy: Local
  type: ClusterIP

场景3：underlay 模式下 和 metallb 一起使用， 该场景主要是为了metallb 模式下支持某个underlay subnet提供外部地址池的vip， vip的后端pod同样在该子网下， 并保证clientIP 不被改变。

流量走向：

使用方法：

1. kube-ovn-controller 开启开关 --enable-ovn-lb-prefer-local = true
2. subnet.spec.enableExternalLBAddress = true
3. subnet.spec.excludeIps 添加外部地址池的地址段。
4. service 配置 externalTrafficPolicy:Local

Which issue(s) this PR fixes

Fixes #(issue-number)

[coveralls]

Pull Request Test Coverage Report for Build 13255351680

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 446 (0.0%) changed or added relevant lines in 8 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.2%) to 22.115%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/controller/config.go	0	2	0.0%
pkg/controller/init.go	0	5	0.0%
pkg/ovs/ovn-nb-load_balancer.go	0	32	0.0%
pkg/controller/endpoint.go	0	36	0.0%
pkg/controller/service.go	0	40	0.0%
pkg/daemon/controller.go	0	45	0.0%
pkg/ovs/ovs-ofctl.go	0	117	0.0%
pkg/daemon/controller_linux.go	0	169	0.0%

Files with Coverage Reduction	New Missed Lines	%
pkg/controller/init.go	1	0.0%
pkg/ovs/ovn-nb-bfd.go	2	61.61%

Totals
Change from base Build 13236788436:	-0.2%
Covered Lines:	10376
Relevant Lines:	46919

---

💛 - Coveralls

[zhangzujian]

The following occasional failure need to be fixed:

  [FAILED] Code Location: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:417
  Expected
      <string>: kube-ovn-control-plane
  to equal
      <string>: kube-ovn-worker
  In [It] at: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:358 @ 02/06/25 02:45:06.75

[changluyi]

The following occasional failure need to be fixed:

  [FAILED] Code Location: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:417
  Expected
      <string>: kube-ovn-control-plane
  to equal
      <string>: kube-ovn-worker
  In [It] at: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:358 @ 02/06/25 02:45:06.75

I tested in my local env and github CI flow, but not find this error

[zbb88888]

matallb 也可以使用 kube-ovn unerlay subnet 中 exclude 中的 ip：metallb 使用 br-provider 网桥么， 这样 metallb 可以将流量转到 kube-ovn underlay subnet pod 内， 这样子使用吗？

[changluyi]

matallb 也可以使用 kube-ovn unerlay subnet 中 exclude 中的 ip：metallb 使用 br-provider 网桥么， 这样 metallb 可以将流量转到 kube-ovn underlay subnet pod 内， 这样子使用吗？

是的

[changluyi]

The following occasional failure need to be fixed:

  [FAILED] Code Location: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:417
  Expected
      <string>: kube-ovn-control-plane
  to equal
      <string>: kube-ovn-worker
  In [It] at: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:358 @ 02/06/25 02:45:06.75

It should be a problem with the l2servicestatus field of metallb. It seems that the status.node of this field is not necessarily the node where the vip is located. It is probably a metallb bug.

[zhangzujian]

The following occasional failure need to be fixed:

  [FAILED] Code Location: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:417
  Expected
      <string>: kube-ovn-control-plane
  to equal
      <string>: kube-ovn-worker
  In [It] at: /home/zhang/kube-ovn/test/e2e/metallb/e2e_test.go:358 @ 02/06/25 02:45:06.75

It should be a problem with the l2servicestatus field of metallb. It seems that the status.node of this field is not necessarily the node where the vip is located. It is probably a metallb bug.

If the l2servicestatus field may be incorrect, we should not use it in our e2e tests.