Wireguard で Kubernetes をラッピングする

2024-6-23 • tag-icon

さまざまなノードが多数存在するシナリオがあります。パブリック IPv4 を持つものもあれば、IPv6 を持つものもあり、デュアルスタックのものもあります。そこで、Wireguard ネットワーク (10.11.12.0/24) を作成しました。これにより、IP スタックと場所に関係なく、どのピアもプライベートネットワーク内の他のピアにアクセスできるようになります。この Wireguard ネットワーク上に Kubernetes を構築したいと考えています。

小さなテストクラスターを構築しました...

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

... docker.io (Debian のデフォルト) に基づく kubeadm 1.23.5 を使用したローカルプレイグラウンドで:

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

経由で vm1 から vm2 を見るとtcpdump -n host 192.168.10.11、Wireguard UDP パケットを介したトラフィックのみが表示されます。問題ありません...

次に、シンプルなデプロイメント、サービス、ClusterIP、Ingressを定義してデプロイします。

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

ブラウザで確認すると、応答があります。しかし...

応答が非常に遅いです (単純な curl で確認できますが、サービスが 1 つの要求に応答するのに 10 ～ 20 秒かかります。これは、このような単純な展開では異常に遅いです)。

tcpdump で確認すると、Wireguard ネットワークの外部のトラフィックが表示されますが、これはさらに奇妙です。

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

LAN ネットワークで応答が非常に遅い理由は何でしょうか。Wireguard IP を使用する代わりに、「パブリック」 IP への誤ったルーティングが原因でしょうか。ポート 8472 に Wireguard アドレスを使用するように Kubernetes を構成することは可能ですか。

答え1

はい、解決策を見つけました。

Wireguard なしでクラスターのインストールをテストしました。その場合、アプリケーションauth0blog/kubernetes-tutorialも数秒間ハングします。そこで、単純な nginx http サービスに切り替えたところ、予想どおりの時間内に応答するようになりました。
ポート8472はフランネルによって使用されます。Github（2018年から）には、デフォルトで外部ネットワークインターフェースを使用するという問題があります。Wireguardインターフェースを使用するように構成する必要があります。参考:そしてhttps://github.com/rancher/rancher/issues/14721#issuecomment-417913067

つまり、これは多かれ少なかれhttps://stackoverflow.com/questions/66449289/is-there-any-way-to-bind-k3s-flannel-to-another-interface

私はKubernetes初心者なので、与えられたコマンドでその値をどのように変更すればよいのか疑問に思いました（質問を参照）。ドキュメントではパラメータについてのみ説明されており、どのように、どこに設定すればよいのかは説明されていません。調べてみたところ、https://stackoverflow.com/questions/47845739/flannel を kubernetes でデフォルト以外のインターフェイスを使用するように構成する

--iface=wg_k8s解決策は、flannel.yml をダウンロードし、そのファイルの正しい場所にパラメータを追加することであることがわかります。現在のバージョン (2022) では、200 行目以降にあります。

答え1

関連情報