Update kube-router to 2.1.x

[ncopa]

Description

Update to kube router 2.1.

Fixes #3814

Testing the IPv6 is done in separate PR. #3954

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[twz123]

NB: The diff of generic-kuberouter.yaml between v1.6.1 and v2.1.0:

diff --git a/daemonset/generic-kuberouter.yaml b/daemonset/generic-kuberouter.yaml
index 8d812848..0179d35c 100644
--- a/daemonset/generic-kuberouter.yaml
+++ b/daemonset/generic-kuberouter.yaml
@@ -60,6 +60,10 @@ spec:
           valueFrom:
             fieldRef:
               fieldPath: spec.nodeName
+        - name: POD_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.name
         - name: KUBE_ROUTER_CNI_CONF_FILE
           value: /etc/cni/net.d/10-kuberouter.conflist
         livenessProbe:
@@ -98,13 +102,19 @@ spec:
             TMP=/etc/cni/net.d/.tmp-kuberouter-cfg;
             cp /etc/kube-router/cni-conf.json ${TMP};
             mv ${TMP} /etc/cni/net.d/10-kuberouter.conflist;
-          fi
+          fi;
+          if [ -x /usr/local/bin/cni-install ]; then
+            /usr/local/bin/cni-install;
+          fi;
         volumeMounts:
         - mountPath: /etc/cni/net.d
           name: cni-conf-dir
         - mountPath: /etc/kube-router
           name: kube-router-cfg
+        - name: host-opt
+          mountPath: /opt
       hostNetwork: true
+      hostPID: true
       tolerations:
       - effect: NoSchedule
         operator: Exists
@@ -126,6 +136,9 @@ spec:
         hostPath:
           path: /run/xtables.lock
           type: FileOrCreate
+      - name: host-opt
+        hostPath:
+          path: /opt
 
 ---
 apiVersion: v1
@@ -169,7 +182,29 @@ rules:
       - get
       - list
       - watch
-
+  - apiGroups:
+      - "coordination.k8s.io"
+    resources:
+      - leases
+    verbs:
+      - get
+      - create
+      - update
+  - apiGroups:
+      - ""
+    resources:
+      - services/status
+    verbs:
+      - update
+  - apiGroups:
+      - "discovery.k8s.io"
+    resources:
+      - endpointslices
+    verbs:
+      - get
+      - list
+      - watch
+      
 ---
 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1

The cni-install and /opt mounting is related to the CNI binary installation, which the official kube-router image is capable of. K0s has its own CNI installation image, so it's fine to leave that out.

[twz123]

This is necessary due to some upstream fixes to hairpinning. I do know that we are testing hairpinning in the inttests, bit from the fix's description it sounds as it has been broken before?

With this fix, kube-router now passes the Kubernetes end-to-end conformance test for hairpinning traffic.

🤔

[twz123]

This (and the RBAC change) has been introduced in afdf553f add loadbalancer address allocator.

This adds a simple controller that will watch for services of type LoadBalancer and try to allocated addresses from the specified IPv4 and/or IPv6 ranges. It's assumed that kube-router (or another network controller) will announce the addresses.

As the controller uses leases for leader election and updates the service status new RBAC permissions are required.

Is that something that we need to be aware of?

[jnummelin]

Partially yes. I mean we do provide extraArgs via which user can enable LB feature. Thus IMO we should have these in place.