Envolviendo Kubernetes con Wireguard

2024-6-23 • tag-icon

Tengo un escenario con muchos nodos diferentes. Algunos tienen IPv4 público, otros tienen IPv6 y otros son de doble pila. Así que creé una red Wireguard (10.11.12.0/24), para que cualquier par pueda comunicarse con cualquier otro dentro de una red privada con respecto a la pila de IP y la ubicación. Me gustaría construir un Kubernetes sobre estas redes de protección de cables.

He creado un pequeño grupo de pruebas...

node   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
...

... en mi patio de juegos local con kubeadm 1.23.5 basado en docker.io (valor predeterminado de 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
...
all nodes> 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

Cuando miro de vm1 a vm2 a través de tcpdump -n host 192.168.10.11, solo puedo ver el tráfico a través de paquetes UDP de Wireguard. Bien...

Luego definí una implementación simple, un servicio, una IP de clúster, un ingreso y se implementó.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubernetes-tutorial-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: kubernetes-tutorial-deployment
  template:
    metadata:
      labels:
        app: kubernetes-tutorial-deployment
    spec:
      containers:
      - name: kubernetes-tutorial-application
        image: auth0blog/kubernetes-tutorial
        ports:
          - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-tutorial-cluster-ip
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 3000
  selector:
    app: kubernetes-tutorial-deployment
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetes-tutorial-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: test.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes-tutorial-cluster-ip
            port:
              number: 80

Cuando consulto con el navegador, obtengo respuesta. Pero...

La respuesta es muy lenta (puedo confirmar mediante un simple curl, el servicio tarda entre 10 y 20 segundos en responder a una sola solicitud; eso es extrañamente lento para una implementación tan simple).

Cuando miro a través de tcpdump veo tráfico fuera de la red Wireguard, lo cual es mucho más extraño.

18:39:18.341836 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 128
18:39:18.344382 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 176
18:39:18.344563 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:18.344571 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:18.344572 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:18.344573 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:18.344711 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 128
18:39:20.566833 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 592
18:39:20.567003 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 96
18:39:20.570978 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 128
18:39:20.571309 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:20.572538 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 176
18:39:20.572566 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 592
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:20.572764 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:23.540401 ARP, Request who-has 192.168.10.11 tell 192.168.10.10, length 28
18:39:23.540646 ARP, Reply 192.168.10.11 is-at 7a:1d:d9:fc:fa:eb, length 28
18:39:23.608703 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [S], seq 3011291899, win 64860, options [mss 1410,sackOK,TS val 2531657982 ecr 0,nop,wscale 7], length 0
18:39:23.609071 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [S.], seq 1444377380, ack 3011291900, win 64308, options [mss 1410,sackOK,TS val 2546470618 ecr 2531657982,nop,wscale 7], length 0
18:39:23.609112 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [.], ack 1, win 507, options [nop,nop,TS val 2531657983 ecr 2546470618], length 0
18:39:23.609140 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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 748
18:39:23.609370 IP 192.168.10.11.59205 > 192.168.10.10.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.20.4.2.3000 > 10.20.0.5.55222: Flags [.], ack 749, win 501, options [nop,nop,TS val 2546470618 ecr 2531657983], length 0
18:39:23.610441 IP 192.168.10.11.36593 > 192.168.10.10.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 1
IP 10.20.4.2.59046 > 10.20.0.3.53: 18849+ A? test.example.com.cluster.local. (48)
18:39:23.611567 IP 192.168.10.10.39789 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 1
IP 10.20.4.2.34442 > 10.20.0.3.53: 49768+ A? test.example.com.sol.system. (45)
18:39:25.329861 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 208
18:39:25.330138 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:25.613106 IP 192.168.10.10.52981 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 1
IP 10.20.4.2.59146 > 10.20.0.3.53: 49768+ A? test.example.com.sol.system. (45)
18:39:27.021478 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 224
18:39:27.021876 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:27.614533 IP 192.168.10.10.48157 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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, length 128
18:39:28.503146 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 256
18:39:28.503158 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:28.503159 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:28.503161 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 1452
18:39:28.503162 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:28.503453 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:28.627012 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 128
18:39:28.627292 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 128
18:39:28.627636 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:29.615282 IP 192.168.10.10.52590 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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, length 192
18:39:29.877722 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 128
18:39:30.898243 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 592
18:39:30.898330 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 96
18:39:30.902126 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 128
18:39:30.902362 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:30.903556 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 176
18:39:30.903696 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 592
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:30.904023 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96
18:39:31.617136 IP 192.168.10.10.38253 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 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, flags [I] (0x08), overlay 0, instance 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 2531657983], length 113
18:39:31.619911 IP 192.168.10.10.42274 > 192.168.10.11.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.20.0.5.55222 > 10.20.4.2.3000: Flags [.], ack 114, win 507, options [nop,nop,TS val 2531665993 ecr 2546478629], length 0
18:39:33.434382 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 128
18:39:33.434488 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 96
18:39:33.434537 IP 192.168.10.10.59120 > 192.168.10.11.59120: UDP, length 128
18:39:33.434860 IP 192.168.10.11.59120 > 192.168.10.10.59120: UDP, length 96

¿Cuál es la posible razón por la cual la respuesta es tan lenta en una red LAN? ¿Se debe a un enrutamiento incorrecto a IP "públicas" en lugar de utilizar la IP Wireguard? ¿Es posible configurar Kubernetes para utilizar la dirección Wireguard para el puerto 8472?

Respuesta1

Ok, encontré la solución.

Probé la instalación del clúster sin Wireguard. Y en ese caso la aplicación auth0blog/kubernetes-tutorialtambién se bloquea durante varios segundos. Así que cambié a un servicio http nginx simple y eso responde en el tiempo esperado.
El puerto 8472 lo utiliza franela. Hay problemas en Github (de 2018...) que muestran que utiliza de forma predeterminada la interfaz de red externa. Debe configurarse para utilizar la interfaz Wireguard. Verhttps://github.com/rancher/rancher/issues/15133yhttps://github.com/rancher/rancher/issues/14721#issuecomment-417913067

Entonces, en realidad esto es más o menos un duplicado dehttps://stackoverflow.com/questions/66449289/hay-alguna-manera-de-vincular-k3s-flannel-a-otra-interfaz

Y como soy nuevo en Kubernetes, me preguntaba cómo cambiar ese valor en los comandos que recibí (ver pregunta). La documentación solo habla sobre los parámetros pero no dice cómo ni dónde configurarlos. Miré a mi alrededor y encontréhttps://stackoverflow.com/questions/47845739/configuring-flannel-to-use-a-non-default-interface-in-kubernetes

Allí puede ver que la solución es descargar flannel.yml y agregar el parámetro --iface=wg_k8sa ese archivo en la ubicación correcta. En la versión actual (2022) está en la línea 200+.

Respuesta1

información relacionada