Kubernetes 入門から実践まで：WireGuardを利用してクロスクラウドでK3sクラスター環境を構築する

前書き#

最近、《クロスクラウドプロバイダーでの k3s クラスターのデプロイ》という記事から、また一つの楽しい遊び方を見つけたので、この文章ができました。最近、各大クラウドサービスプロバイダーがダブル 11 の大セールを行っていて、Tencent Cloud では数十元で 3 年間の小さなサーバーを購入できるようになりました。問題は、各クラウドサービスプロバイダーでは特別価格で 1 台しか購入できないため、最終的に私たちのクラウドサーバーは異なるクラウドサービスプロバイダーに分散し、十分に活用できないということです。これらを統合して計算能力を出力することは可能でしょうか？もちろん可能です！それは WireGuard を利用して Kubernetes クラスターを構築することです。

前述の文章で使用されているバージョンはすでに古くなっているので、最新のソフトウェアバージョンに基づいて記事の方法で始めましょう。

PS： 作業が終わった後、自分でやってみて、ある重要なことに気づきました。何かあれば、公式ドキュメントや公式コミュニティ（例えば GitHub）をもっと見るべきです。実際、公式は十分に詳細なドキュメントを提供しており、コミュニティにはすでにいくつかの問題を経験した人がいます。明るい道を見つけたいなら、公式ドキュメントを多く見ましょう。

環境準備#

ソフトウェア	バージョン
Ubuntu	20.04
Docker	20.10
WireGuard	v1.0.20200513
K3s	v1.23.14+k3s1

私は Tencent Cloud と Vultr にUbuntu 20.04がプリインストールされた数台のクラウドサーバーを準備しました。もちろん、任意のクラウドサービスプロバイダーのクラウドサーバーでも構いません。パブリックアクセスが可能で、Linux システムを実行できる必要があります。

クラウドサービスプロバイダー	パブリック IP	構成	ノード名	ノード役割	OS-IMAGE	KERNEL-VERSION	CONTAINER-RUNTIME
Tencent Cloud	42.193.XXX.XXX	4C4G	k3s-node-01	control-plane,master	Ubuntu 20.04 LTS	5.4.0-96-generic	docker://20.10.13
Vultr	45.63.YYY.YYY	1C1G	k3s-node-02	agent/worker	Ubuntu 20.04.3 LTS	5.4.0-131-generic	docker://20.10.11
Vultr	13.22.ZZZ.ZZZ	1C1G	k3s-node-03	agent/worker	Ubuntu 20.04.5 LTS	5.4.0-122-generic	docker://20.10.12

Docker のインストール#

sudo apt install docker.io -y

WireGuard のインストール#

各ノードに WireGuard ソフトウェアをインストールする必要があります。Ubuntu 20.04のインストールの詳細は以下の通りです。

# root権限に切り替え
sudo -i

# ソフトウェアソースを更新
apt update

# WireGuardソフトウェアをインストール
apt install wireguard resolvconf -y

# IPV4 IP転送を有効にする
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

ここでは WireGuard の正しいインストールを完了するだけで、設定や起動は必要ありません。他のことは K3s に任せてネットワーク設定を行わせます。私たちがすることは K3s を使って働かせることだけで、彼に美しく仕事をさせることです。実際、K3s はすでに私たちのために準備が整っており、簡単に起動パラメータを設定するだけで済みます。

クロスクラウドでの K3s クラスターの構築#

私のクラウドサーバーは異なるクラウドサービスプロバイダーに分散しているため、サービスプロバイダーの内部ネットワーク環境を通じて相互にアクセスすることはできません。ここでは WireGuard を利用して異地ネットワークを構築する必要があります。K3s は Flannel を通じてすでに WireGuard を統合しているため、いくつかの簡単な設定でネットワークを簡単に構築できます。

WireGuard フランネルバックエンドオプションを利用する前に、すべてのノード（サーバーとエージェント）の上に WireGuard をインストールする必要があります。wireguardバックエンドは、Flannel からネイティブにwireguard-nativeバックエンドに置き換えられるため、v1.26 から削除されます。

始める前に、公式ガイドを通読することをお勧めします。来歴を理解することで、霧を晴らすことができます。異なるバージョンの K3s の設定パラメータには違いがあることが言及されており、特にv1.26からは起動パラメータが元のflannel-backend: wireguardからflannel-backend: wireguard-nativeに変更されることに注意が必要です。

前回の記事《Kubernetes 入門から実践へ：K3s クラスターの初体験》のデプロイコマンドを参考にできます。

K3s Server のインストール#

各サーバーを起動する際には、以下の起動パラメータを追加する必要があります。これにより WireGuard が有効化されます。

-node-external-ip <SERVER_EXTERNAL_IP> --flannel-backend wireguard-native --flannel-external-ip

K3s Server の完全な起動プロセスは以下の通りです。

# K3sバージョンを指定
export INSTALL_K3S_VERSION=v1.23.14+k3s1
# インストールのみで起動しない
export INSTALL_K3S_SKIP_START=true
# クラスターに追加する各ノードにユニークな名前を設定：https://docs.rancher.cn/docs/k3s/installation/installation-requirements/_index#先決条件
export K3S_NODE_NAME=k3s-node-01
# ノードのパブリックIPを取得するか、手動で設定
export PUBLIC_IP=`curl -sSL https://ipconfig.sh`
##
# カスタム起動実行コマンド：
# --docker：Dockerランタイムを有効にする
# --disable servicelb：（オプション）servicelbを無効にする
# --disable traefik：（オプション）traefikを無効にする
# --node-ip $PUBLIC_IP --node-external-ip $PUBLIC_IP：ノードのパブリックIPを設定し、ノード間でパブリックIPを使用してネットワーク通信を行う
# --flannel-backend wireguard-native --flannel-external-ip：Flannel CNIを有効にし、WireGuardを使用してネットワークを構築する
export INSTALL_K3S_EXEC="--docker --disable servicelb --disable traefik --node-ip $PUBLIC_IP --node-external-ip $PUBLIC_IP --flannel-backend wireguard-native --flannel-external-ip"
# アリババクラウドのミラーソーススクリプトを使用してインストール
curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -
# K3sサービスを手動で起動します。上記でINSTALL_K3S_SKIP_START=trueが設定されているため
systemctl enable --now k3s
# K3sサービスの状態を確認
systemctl status k3s

# metrics-serverの実行ログを確認し、問題を特定するのに便利
kubectl logs -f pod/metrics-server-5bb8d5f679-btt96 -n kube-system

K3s Agent のインストール#

各エージェントを起動する際には、以下の起動パラメータを追加する必要があります。これにより WireGuard が有効化されます。

-node-external-ip <AGENT_EXTERNAL_IP>

K3s Agent の完全な起動プロセスは以下の通りです。

# 基本パラメータはServerの起動パラメータと一致させる
export INSTALL_K3S_VERSION=v1.23.14+k3s1
export INSTALL_K3S_SKIP_START=true
# Agent特有のパラメータを設定するだけで済む
export K3S_NODE_NAME=k3s-node-02
export PUBLIC_IP=`curl -sSL https://ipconfig.sh`
export INSTALL_K3S_EXEC="--docker --node-ip $PUBLIC_IP --node-external-ip $PUBLIC_IP"
# K3S_URLを設定すると、デフォルトで「agent」となります。K3S_URLが設定されていない場合、デフォルトで「server」となります
export K3S_URL=
# サーバーまたはエージェントをクラスターに追加するための共有シークレット
# マスターノードで取得：cat /var/lib/rancher/k3s/server/node-token
export K3S_TOKEN=K105a308b09e583fccd1dd3a11745826736d440577d1fafa5d9dbaf5213a7150f5f::server:88e21efdad8965816b1da61e056ac7c4
# 私のノードはVultrにあるため、ここでは公式ソーススクリプトを使用してインストールします。国内のホストは依然としてアリババクラウドのミラーソーススクリプトを使用できます
# curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -
curl -sfL https://get.k3s.io | sh -
# K3sサービスを手動で起動します。上記でINSTALL_K3S_SKIP_START=trueが設定されているため
systemctl enable --now k3s-agent

# K3sサービスの状態を確認
$ systemctl status k3s-agent
● k3s-agent.service - Lightweight Kubernetes
     Loaded: loaded (/etc/systemd/system/k3s-agent.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-11-19 12:23:59 UTC; 50s ago
       Docs: https://k3s.io
    Process: 707474 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
    Process: 707476 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
    Process: 707477 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
   Main PID: 707478 (k3s-agent)
      Tasks: 14
     Memory: 255.6M
     CGroup: /system.slice/k3s-agent.service
             └─707478 /usr/local/bin/k3s agent

Nov 19 12:23:59 vultr k3s[707478]: I1119 12:23:59.986059  707478 network_policy_controller.go:163] Starting network policy controller
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.057408  707478 network_policy_controller.go:175] Starting network policy controller full sync goroutine
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.698216  707478 kube.go:133] Node controller sync successful
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.702931  707478 kube.go:331] Overriding public ip with '45.63.XXX.XXX' from node annotation 'flannel.alpha.coreos.com/public-ip-overwrite'
Nov 19 12:24:00 vultr k3s[707478]: time="2022-11-19T12:24:00Z" level=info msg="Wrote flannel subnet file to /run/flannel/subnet.env"
Nov 19 12:24:00 vultr k3s[707478]: time="2022-11-19T12:24:00Z" level=info msg="Running flannel backend."
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.865979  707478 wireguard_network.go:78] Watching for new subnet leases
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.866258  707478 wireguard_network.go:172] Subnet added: 10.42.0.0/24 via 42.193.XXX.XXX:51820
Nov 19 12:24:00 vultr k3s[707478]: I1119 12:24:00.956299  707478 iptables.go:260] bootstrap done

# クラスターのノード情報を確認すると、k3s-node-02のINTERNAL-IPがパブリックIPであることがわかります
$ kubectl get nodes -owide
NAME          STATUS   ROLES                  AGE   VERSION         INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
k3s-node-01   Ready    control-plane,master   19m   v1.23.14+k3s1   10.0.20.12      42.193.XXX.XXX   Ubuntu 20.04 LTS     5.4.0-96-generic    docker://20.10.13
k3s-node-02   Ready    <none>                 14m   v1.23.14+k3s1   45.63.YYY.YYY   45.63.YYY.YYY    Ubuntu 20.04.3 LTS   5.4.0-131-generic   docker://20.10.11

metrics-server の問題について#

metrics-server
指標を取得できないのは、kubelet-preferred-address-types
の値が優先的に InternalIP であり、クラウドサーバーの InternalIP が内部 IP であるため、異なるクラウドプロバイダーの内部 IP セグメントが異なり、通信できないからです。

問題は、metrics-serverが CPU、メモリなどの利用率のコア指標を取得できず、手動で設定を変更する必要があることです。新しいバージョン **v1.23.14+k3s1**では、flannel-external-ip=trueオプションを有効にすると、-kubelet-preferred-address-types=ExternalIP,InternalIP,Hostnameのアドレスの優先順位が動的に調整されることが修正されました。

この機能の調整が K3s クラスターに与える影響について詳しく説明します。

v1.23.13+k3s1 バージョンおよびそれ以前のバージョン#

デフォルト設定を確認します。

# CPU、メモリなどの利用率のコア指標を取得できない
$ kubectl top node
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

$ kubectl top node
NAME          CPU(cores)   CPU%        MEMORY(bytes)   MEMORY%
k3s-node-01   133m         3%          2232Mi          56%
k3s-node-02   <unknown>    <unknown>   <unknown>       <unknown>

$ kubectl describe pod/metrics-server-d76965d8f-t2sll -n kube-system | grep -i types
      --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname

metrics-serverのマニフェストを変更する必要があります。以下のコマンドを使用してmetrics-serverのマニフェストをオンラインで編集します。

kubectl -n kube-system edit deploy metrics-server

以下の実行パラメータを調整して保存し、終了します。

    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=10250
-       - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
+       - --kubelet-preferred-address-types=ExternalIP
        - --kubelet-insecure-tls
        - --kubelet-use-node-status-port
        - --metric-resolution=15s

保存後、リソースが再スケジュールされるのを待つと、metrics-server がパブリック IP を使用してノードと通信できるようになります。コア指標を再確認します。

$ kubectl top node
NAME          CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k3s-node-01   259m         6%     2269Mi          57%
k3s-node-02   203m         20%    534Mi           54%

$ kubectl top pods -A
NAMESPACE     NAME                                      CPU(cores)   MEMORY(bytes)
default       nginx-85b98978db-659cl                    0m           5Mi
default       nginx-85b98978db-tt2hh                    0m           5Mi
default       nginx-85b98978db-zr47g                    0m           2Mi
kube-system   coredns-d76bd69b-k8949                    4m           15Mi
kube-system   local-path-provisioner-6c79684f77-nc2xn   1m           7Mi
kube-system   metrics-server-d76965d8f-t2sll            6m           25Mi

v1.23.14+k3s1バージョンおよびそれ以降のバージョン#

pod/metrics-server-を記述し、ARGS を探して、flannel-external-ip=falseの場合のシナリオを確認します：-kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
同じ手順を実行し、flannel-external-ip: trueに変更し、flannel-external-ip=trueの場合の-kubelet-preferred-address-types=ExternalIP,InternalIP,Hostnameを確認します。

⚠️ 注意事項 ⚠️#

（なぜか聞かないで、試してみてください）

セキュリティグループのファイアウォールで関連ポートを開放する必要があります
- TCP 6443：K3s Server ポート
- TCP 10250：metrics-serverサービスポート。K3s Server と Agent 間で指標を収集するための通信に使用され、CPU、メモリなどの利用率のコア指標を取得できなくなります
- UDP 51820：flannel-backend: wireguard-nativeのデフォルトポートを開放。Flannel バックエンドが WireGuard を使用するためのポート
- TCP 30000-32767：K8s NodePort 範囲。外部からのデバッグを容易にします
オプションの起動パラメータ
- --tls-san
  - TLS 証明書に他のホスト名や IP を追加してホストの代替名として使用します
  - パブリック環境でパブリック IP を介してリモートクラスターにアクセス、操作を許可します
  - または、複数のサーバーをデプロイし、LB を使用して負荷分散を行う場合は、パブリックアドレスを保持する必要があります
- --disable servicelb
- --disable traefik
未使用のコンポーネントを無効にしてパフォーマンスを節約する
- Service Load Balancer
  - K3sは、利用可能なホストポートを使用できるKlipper Load Balancerという負荷分散器を提供しています。LoadBalancerタイプのServiceを作成することができますが、LBの実装は含まれていません。一部のLBサービスはクラウドプロバイダーが必要です（例：Amazon EC2）。対照的に、K3s service LBは、クラウドプロバイダーなしでLBサービスを使用できるようにします。
  - 組み込みの LB を無効にするには、各サーバーを起動する際に--disable servicelbオプションを使用します。
- Traefik Ingress Controller
  - Traefikは、現代的な HTTP リバースプロキシおよび負荷分散器です。サーバーを起動すると、デフォルトで Traefik がデプロイされます。Traefik Ingress Controller は、ホスト上の 80 および 443 ポートを使用します（これらのポートは HostPort または NodePort に使用できません）。
  - これを無効にするには、各サーバーを起動する際に--disable traefikオプションを使用します。

K3s クロスクラウドクラスターおよびネットワークの検証#

クロスクラウドクラスターの検証#

$ kubectl get nodes -owide
NAME          STATUS   ROLES                  AGE   VERSION         INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
k3s-node-01   Ready    control-plane,master   69m   v1.23.14+k3s1   10.0.20.12      42.193.XXX.XXX   Ubuntu 20.04 LTS     5.4.0-96-generic    docker://20.10.13
k3s-node-02   Ready    <none>                 63m   v1.23.14+k3s1   45.63.XXX.XXX   45.63.YYY.YYY    Ubuntu 20.04.3 LTS   5.4.0-131-generic   docker://20.10.11
k3s-node-03   Ready    <none>                 16m   v1.23.14+k3s1   13.22.ZZZ.ZZZ   13.22.ZZZ.ZZZ    Ubuntu 20.04.5 LTS   5.4.0-122-generic   docker://20.10.12

$ kubectl create deploy whoami --image=traefik/whoami --replicas=3
deployment.apps/whoami created

$ kubectl get pod -owide
NAME                      READY   STATUS    RESTARTS   AGE   IP          NODE          NOMINATED NODE   READINESS GATES
whoami-84d974bbd6-57bnt   1/1     Running   0          10m   10.42.1.4   k3s-node-02   <none>           <none>
whoami-84d974bbd6-hlhdq   1/1     Running   0          10m   10.42.2.2   k3s-node-03   <none>           <none>
whoami-84d974bbd6-g894t   1/1     Running   0          10m   10.42.0.6   k3s-node-01   <none>           <none>

$ kubectl create deploy nginx --image=nginx --replicas=3
deployment.apps/nginx created

$ kubectl get pod -owide
NAME                      READY   STATUS    RESTARTS   AGE   IP           NODE          NOMINATED NODE   READINESS GATES
whoami-84d974bbd6-hlhdq   1/1     Running   0          82m   10.42.2.2    k3s-node-03   <none>           <none>
whoami-84d974bbd6-g894t   1/1     Running   0          82m   10.42.0.6    k3s-node-01   <none>           <none>
whoami-84d974bbd6-57bnt   1/1     Running   0          82m   10.42.1.4    k3s-node-02   <none>           <none>
nginx-85b98978db-ptvcb    1/1     Running   0          32s   10.42.1.5    k3s-node-02   <none>           <none>
nginx-85b98978db-m2nlm    1/1     Running   0          32s   10.42.2.3    k3s-node-03   <none>           <none>
nginx-85b98978db-fs8gk    1/1     Running   0          32s   10.42.0.17   k3s-node-01   <none>           <none>

クロスクラウドネットワークの検証#

クラスター内蔵の CoreDNS、Service、Pod 間でネットワークをデバッグし、異なるノードのネットワークが到達可能かどうかを検証します。

始める前に、whoamiという名前の Service を素早く作成します。

$ kubectl expose deploy whoami --type LoadBalancer --port 80 --external-ip 42.193.XXX.XXX
service/whoami exposed

$ kubectl get svc -owide
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE   SELECTOR
kubernetes   ClusterIP      10.43.0.1      <none>           443/TCP        75m   <none>
whoami       LoadBalancer   10.43.77.192   42.193.XXX.XXX   80:32064/TCP   12s   app=whoami

$ kubectl describe svc whoami
Name:                     whoami
Namespace:                default
Labels:                   app=whoami
Annotations:              <none>
Selector:                 app=whoami
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.43.77.192
IPs:                      10.43.77.192
External IPs:             42.193.XXX.XXX
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  32064/TCP
Endpoints:                10.42.0.6:80,10.42.1.4:80,10.42.2.2:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

では、Service の負荷分散効果をどうテストしますか？#

Service、Pod の IP アドレスはすべて Kubernetes クラスターの内部ネットワークセグメントであるため、kubectl execを使用して Pod 内部に入る必要があります（またはクラスターの任意のノードに SSH ログインして）、curl などのツールを使用して Service にアクセスします。

クラスター内蔵の CoreDNS のおかげで、クラスター内部からドメイン名を介して対応する Service、Pod にアクセスできます。

Service オブジェクトの完全な形式のドメイン名は「オブジェクト。名前空間.svc.cluster.local」ですが、多くの場合、後半の部分を省略し、「オブジェクト。名前空間」または「オブジェクト」と書くだけで十分です。デフォルトでオブジェクトが存在する名前空間が使用されます（ここではdefaultです）。
- 例えばwhoami、whoami.defaultなど
Kubernetes は各 Pod にドメイン名を割り当てており、形式は「IP アドレス。名前空間.pod.cluster.local」ですが、IP アドレスの.を-に変更する必要があります。
- 例えば10.42.2.2は、対応するドメイン名は10-42-2-2.default.podです。

これにより、Service、Pod オブジェクトの IP アドレスを気にする必要はなく、名前を知っているだけで DNS を介してバックエンドサービスにアクセスできます。

外部からアクセスする#

$ curl http://42.193.XXX.XXX:32064
Hostname: whoami-84d974bbd6-57bnt
IP: 127.0.0.1
IP: 10.42.1.4
RemoteAddr: 10.42.0.0:42897
GET / HTTP/1.1
Host: 42.193.XXX.XXX:32064
User-Agent: curl/7.68.0
Accept: */*

$ curl http://42.193.XXX.XXX:32064
Hostname: whoami-84d974bbd6-hlhdq
IP: 127.0.0.1
IP: 10.42.2.2
RemoteAddr: 10.42.0.0:3478
GET / HTTP/1.1
Host: 42.193.XXX.XXX:32064
User-Agent: curl/7.68.0
Accept: */*

$ curl http://42.193.XXX.XXX:32064
Hostname: whoami-84d974bbd6-g894t
IP: 127.0.0.1
IP: 10.42.0.6
RemoteAddr: 10.42.0.1:3279
GET / HTTP/1.1
Host: 42.193.XXX.XXX:32064
User-Agent: curl/7.68.0
Accept: */*

外部から Service にアクセスすると、メインノード[http://42.193.XXX.XXX:32064](http://42.193.XXX.XXX:32064)を入口として、異なるノード上の Pod に負荷分散され、正しく応答していることがわかります。

クラスター各ノードから Service `CLUSTER-IP`にアクセスする#

root@k3s-node-01:~# curl 10.43.77.192:80
Hostname: whoami-84d974bbd6-g894t
IP: 127.0.0.1
IP: 10.42.0.6
RemoteAddr: 10.42.1.5:36010
GET / HTTP/1.1
Host: 10.43.77.192
User-Agent: curl/7.68.0
Accept: */*

root@k3s-node-01:~# curl 10.43.77.192:80
Hostname: whoami-84d974bbd6-57bnt
IP: 127.0.0.1
IP: 10.42.1.4
RemoteAddr: 10.42.0.0:23957
GET / HTTP/1.1
Host: 10.43.77.192
User-Agent: curl/7.68.0
Accept: */*

root@k3s-node-01:~# curl 10.43.77.192:80
Hostname: whoami-84d974bbd6-hlhdq
IP: 127.0.0.1
IP: 10.42.2.2
RemoteAddr: 10.42.0.0:26130
GET / HTTP/1.1
Host: 10.43.77.192
User-Agent: curl/7.68.0
Accept: */*

ノード間で直接 Service にアクセスすると、何度もリクエストを送信した後、異なるノード上の Pod に正常に負荷分散され、正しく応答していることがわかります。

クラスター内部から Service、Pod にアクセスする#

$ kubectl exec -it nginx-85b98978db-ptvcb -- sh
# curl whoami
Hostname: whoami-84d974bbd6-g894t
IP: 127.0.0.1
IP: 10.42.0.6
RemoteAddr: 10.42.1.5:36010
GET / HTTP/1.1
Host: whoami
User-Agent: curl/7.74.0
Accept: */*

# curl whoami.default
Hostname: whoami-84d974bbd6-57bnt
IP: 127.0.0.1
IP: 10.42.1.4
RemoteAddr: 10.42.1.5:33050
GET / HTTP/1.1
Host: whoami.default
User-Agent: curl/7.74.0
Accept: */*

# curl whoami.default.svc.cluster.local
Hostname: whoami-84d974bbd6-hlhdq
IP: 127.0.0.1
IP: 10.42.2.2
RemoteAddr: 10.42.1.5:57358
GET / HTTP/1.1
Host: whoami.default.svc.cluster.local
User-Agent: curl/7.74.0
Accept: */*

多方面のネットワーク検証を経て、Flannel が WireGuard を統合したマルチクラウドネットワーク環境が利用可能であることが証明され、安心して楽しむことができます。

参考リンク#

原文地址：https://y0ngb1n.github.io/a/setup-k3s-cluster-multicloud-with-wireguard.html

もしこの内容が役に立ったと思ったら、いいねを押して友達にシェアしてください。ありがとうございます。

もし今後の内容の更新をより早く見たい場合は、「いいね」、「シェア」、「好き」をクリックしてください。これらの無料の励ましが今後の内容の更新速度に影響を与えます。