現在のテスト セットアップには、Debian-11 を実行する VM がいくつかあります。すべてのノードにはプライベート IP と 2 番目の Wireguard インターフェイスがあります。将来的には、ノードは異なるネットワークを持つ異なる場所に配置され、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 と kubeadm/kubelet/kubectl バージョン 1.23.5 をインストールしました。また、すべてのノードに haproxy もインストールしました。これは、localhost:443 にリストし、リクエストをオンライン コントロール プレーンの 1 つに転送することで、ロード バランサーとして機能します。
次にkubeadmでクラスタを起動しました
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
その後、フランネルまたはカリコのいずれかを統合することをテストしました。--iface=<wireguard-interface>カスタム マニフェストを追加または設定することによって...nodeAddressAutodetectionV4.interface: <wireguard-interface>。
通常のノードを追加すると、すべて正常になります。ノードが追加され、ポッドが作成され、定義されたネットワーク インターフェイスを介して通信が行われます。
Wireguardインターフェースなしでコントロールプレーンを追加すると、異なるコントロールプレーンを追加することもできます。
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
もちろん、その前に、、、、など/etc/kubernetes/pkiのいくつかのファイルをvm01 から vm02 にコピーしましca.*た。sa.*front-proxy-ca.*apiserver-kubelet-client.*etcd/ca.*
しかし、Wireguard インターフェイスと一緒に Flannel または Calico ネットワークを使用すると、join コマンドの後に奇妙なことが起こります。
root@vm02:~# kubeadm join 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1892971c5f0004043d88f62328d051a31ce8b697ad4a --control-plane
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mimas] and IPs [10.96.0.1 192.168.10.11 127.0.0.1]
[certs] Using the existing "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Creating static Pod manifest for "etcd"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[kubelet-check] Initial timeout of 40s passed.
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: timeout waiting for etcd cluster to be available
To see the stack trace of this error execute with --v=5 or higher
そして、そのタイムアウト後、vm01 でも API サーバーが動作を停止し、kubeadm コマンドや kubectl コマンドを実行できなくなります。6443 の HTTPS サービスは停止しています。ただし、2 番目の API サーバーを追加すると vm01 の API サーバーが動作を停止する理由がわかりません。また、出力が 192.168.... IP について言及している理由もわかりません。クラスターは 10.11.12.0/24 Wireguard ネットワーク経由でのみ通信する必要があるためです。
答え1
同様の問題を発見した後、https://stackoverflow.com/questions/64227042/異なる IP で kubernetes マスターを設定するここでもこれが解決策だと思います。 を追加すると--apiserver-advertise-address=<this-wireguard-ip>、出力が変わり (192.168.. IP なし)、参加します。理解できないのは、VM01 API サーバーが動作を停止する理由です。
join コマンドが内部で何をしているかにかかわらず、2 番目のコントロール プレーンに etcd サービスを作成する必要があり、そのサービスも flannel/calico ネットワーク インターフェイスと同じ IP で実行する必要があります。プライマリ ネットワーク インターフェイスを使用する場合、このパラメーターは 2 番目または 3 番目のコントロール プレーンでは必要ありません。