Încheierea Kubernetes cu Wireguard

Am un scenariu cu multe noduri diferite. Unele au IPv4 public, altele au IPv6, altele sunt dual stack. Așa că am creat o rețea wireguard (10.11.12.0/24), astfel încât orice peer să poată ajunge la oricare altul din interiorul unei rețele private în ceea ce privește stiva IP și locație. Aș dori să construiesc un Kubernetes prin aceste rețele wireguard.

Am construit un mic cluster de testare...

nod public ip wireguard ip
vm1 192.168.10.10 10.11.12.10
vm2 192.168.10.11 10.11.12.11
vm3 192.168.10.12 10.11.12.12
...

... în locul meu de joacă local cu kubeadm 1.23.5 bazat pe docker.io (implicit Debian):

vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
vm01> kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-rbac.yml
vm01> kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
...
toate nodurile> kubeadm join 10.11.12.10:6443 --token ... --discovery-token-ca-cert-hash sha256:...
...
vm01> helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

Când mă uit de la vm1 la vm2 prin tcpdump -n gazdă 192.168.10.11, pot vedea numai traficul prin pachetele UDP wireguard. Amenda...

Apoi am definit o implementare simplă, un serviciu, un ClusterIP, un Ingress și este implementat

---
apiVersion: apps/v1
fel: Desfăşurare
metadate:
  nume: kubernetes-tutorial-deployment
specificație:
  replici: 2
  selector:
    matchLabels:
      aplicație: kubernetes-tutorial-deployment
  șablon:
    metadate:
      etichete:
        aplicație: kubernetes-tutorial-deployment
    specificație:
      containere:
      - nume: kubernetes-tutorial-application
        imagine: auth0blog/kubernetes-tutorial
        porturi:
          - containerPort: 3000
---
apiVersion: v1
fel: Serviciu
metadate:
  nume: kubernetes-tutorial-cluster-ip
specificație:
  porturi:
  - port: 80
    protocol: TCP
    targetPort: 3000
  selector:
    aplicație: kubernetes-tutorial-deployment
  tip: ClusterIP
---
apiVersion: networking.k8s.io/v1
fel: Intrare
metadate:
  nume: kubernetes-tutorial-ingress
specificație:
  ingressClassName: nginx
  reguli:
  - gazdă: test.example.com
    http:
      trasee:
      - cale: /
        pathType: Prefix
        backend:
          serviciu:
            nume: kubernetes-tutorial-cluster-ip
            port:
              număr: 80

Când verific cu browserul, primesc răspuns. Dar...

Răspunsul este foarte lent (pot confirma printr-o simplă curl, este nevoie de 10-20 de secunde pentru ca serviciul să răspundă la o singură solicitare - asta este ciudat lent pentru o implementare atât de simplă.

Când mă uit prin tcpdump, văd trafic în afara rețelei wireguard, ceea ce este mult mai ciudat.

18:39:18.341836 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:18.344382 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 176
18:39:18.344563 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:18.344571 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:18.344572 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:18.344573 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 592
18:39:20.567003 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 96
18:39:20.570978 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 128
18:39:20.571309 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:20.572538 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 176
18:39:20.572566 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 592
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:23.540401 ARP, Solicitați cine-are 192.168.10.11 spuneți 192.168.10.10, lungime 28
18:39:23.540646 ARP, Răspuns 192.168.10.11 is-at 7a:1d:d9:fc:fa:eb, lungime 28
18:39:23.608703 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: steaguri [S], seq 3011291899, win 64860, opțiuni [mss 1410,sackOK,TS val 2531657982 ecr],wscale 07p,wscale 07p
18:39:23.609071 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Steaguri [S.], seq 1444377380, ack 3011291900, win 64308, opțiuni [mss 1410,sackOK,TS val 70wrp2546, TS val 70wrp27546, TS val 7092546]
18:39:23.609112 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: steaguri [.], ack 1, win 507, opțiuni [nop,nop,TS val 2531657983 ecr 2546470618], lungime 0
18:39:23.609140 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [P.], seq 1:749, ack 1, win 507, options [nop,nop,TS val 2531657983 ecr 2546470618], length 2546470618]
18:39:23.609370 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: steaguri [.], ack 749, win 501, opțiuni [nop,nop,TS val 2546470618 ecr 2531657983], lungime 0
18:39:23.610441 IP 192.168.10.11.36593 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.33592 > 10.20.0.2.53: 53349+ A? test.example.com.default.svc.cluster.local. (60)
18:39:23.610713 IP 192.168.10.10.58646 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.2.53 > 10.20.4.2.33592: 53349 NXDomain*- 0/1/0 (153)
18:39:23.611018 IP 192.168.10.11.32846 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.40077 > 10.20.0.2.53: 57710+ A? test.example.com.svc.cluster.local. (52)
18:39:23.611134 IP 192.168.10.10.41066 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.2.53 > 10.20.4.2.40077: 57710 NXDomain*- 0/1/0 (145)
18:39:23.611427 IP 192.168.10.11.51546 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.59046 > 10.20.0.3.53: 18849+ A? test.exemplu.com.cluster.local. (48)
18:39:23.611567 IP 192.168.10.10.39789 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.3.53 > 10.20.4.2.59046: 18849 NXDomain*- 0/1/0 (141)
18:39:23.611831 IP 192.168.10.11.50067 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.34442 > 10.20.0.3.53: 49768+ A? test.exemplu.com.sistem.sol. (45)
18:39:25.329861 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 208
18:39:25.330138 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:25.613106 IP 192.168.10.10.52981 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.3.53 > 10.20.4.2.34442: 49768 ServFail- 0/0/0 (45)
18:39:25.613542 IP 192.168.10.11.33388 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.59146 > 10.20.0.3.53: 49768+ A? test.exemplu.com.sistem.sol. (45)
18:39:27.021478 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 224
18:39:27.021876 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:27.614533 IP 192.168.10.10.48157 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.3.53 > 10.20.4.2.59146: 49768 ServFail- 0/0/0 (45)
18:39:27.614906 IP 192.168.10.11.52721 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.33596 > 10.20.0.3.53: 32196+ A? test.example.com. (34)
18:39:28.500696 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:28.503146 ​​IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 256
18:39:28.503158 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:28.503159 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:28.503161 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 1452
18:39:28.503162 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:28.627012 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:28.627292 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 128
18:39:28.627636 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:29.615282 IP 192.168.10.10.52590 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.3.53 > 10.20.4.2.33596: 32196 ServFail- 0/0/0 (34)
18:39:29.615672 IP 192.168.10.11.37175 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.50957 > 10.20.0.3.53: 32196+ A? test.example.com. (34)
18:39:29.877400 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 192
18:39:29.877722 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 592
18:39:30.898330 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 96
18:39:30.902126 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 128
18:39:30.902362 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:30.903556 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 176
18:39:30.903696 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 592
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96
18:39:31.617136 IP 192.168.10.10.38253 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.3.53 > 10.20.4.2.50957: 32196 ServFail- 0/0/0 (34)
18:39:31.619778 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [P.], seq 1:114, ack 749, win 501, options [nop,nop,TS val 2546478629 ecr 25316573], length 9183
18:39:31.619911 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, steaguri [I] (0x08), suprapunere 0, instanță 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: steaguri [.], ack 114, win 507, opțiuni [nop,nop,TS val 2531665993 ecr 2546478629], lungime 0
18:39:33.434382 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 128
18:39:33.434488 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 96
18:39:33.434537 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, lungime 128
18:39:33.434860 ​​IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, lungime 96

Care este motivul posibil, pentru care răspunsul este atât de lent într-o rețea LAN.Este din cauza direcționării greșite către IP-uri „publice” în loc de a utiliza IP-ul wireguard? Este posibil să configurați Kubernetes să utilizeze adresa wireguard pentru portul 8472?

Ok, am gasit solutia.

1. Am testat instalarea clusterului fără Wireguard. Și în acest caz aplicația auth0blog/kubernetes-tutorial de asemenea, se blochează mai multe secunde. Așa că am trecut la un serviciu http nginx simplu și care răspunde într-un timp așteptat.
2. Portul 8472 este folosit de flanel. Există probleme pe Github (din 2018...) care arată că folosește implicit interfața de rețea externă. Trebuie configurat pentru a utiliza interfața wireguard. Vedea https://github.com/rancher/rancher/issues/15133 și https://github.com/rancher/rancher/issues/14721#issuecomment-417913067

Deci - de fapt, acesta este mai mult sau mai puțin un duplicat al https://stackoverflow.com/questions/66449289/is-there-any-way-to-bind-k3s-flannel-to-another-interface

Și pentru că sunt nou în Kubernetes, m-am întrebat cum să schimb acea valoare în comenzile date (vezi întrebarea).Documentația vorbește doar despre parametri, dar nu spune cum și unde să o setați. M-am uitat în jur și am găsit https://stackoverflow.com/questions/47845739/configuring-flannel-to-use-a-non-default-interface-in-kubernetes

Acolo puteți vedea că soluția este să descărcați flannel.yml și să adăugați parametrul --iface=wg_k8s la acel fișier în locația corectă. În versiunea actuală (2022) este în linia 200+.