私の焦点は、この構成パラメーター「controlPlaneEndpoint」の使用方法にあると思います。現在、「controlPlaneEndpoint」を使用するとバグがあります。 https://kubernetes.io/docs/setup/independent/high-availability/
私の実際の状況を辛抱強く見ていただければ幸いです。
まず、構成パラメーター「controlPlaneEndpoint」は、vip または負荷分散ですよね? そこで、4 層の負荷分散を使用して「controlPlaneEndpoint」を構成します。aws\ali を試してみました。すべての結果は、使用中にタイムアウトする可能性があることを示しており、kubeadm でのインストール中に「nodexxx not found」が 100% の確率で表示されました。
なぜこうなった？パラメータ "controlPlaneEndpoint" で 4 層の負荷分散を使用すると、ネットワークの問題が発生します。たとえば、ServerA、ServerB、ServerC の 3 つの master があり、serverA で「kubectl get pod」というコマンドを入力します。タイムアウトの確率は 33% でした。serverA 要求が 4 層の負荷分散を介して ServerB または ServerC に送信されると、すべて問題ありません。4 層の負荷分散を介して ServerA 自体に要求が送信された場合、タイムアウトが発生することは間違いありません。
ServerA がサーバーでありリクエスターでもある場合、4 層の負荷分散を使用できないためです。これは、4 層負荷分散のネットワーク機能です。同じ理由で、kubeadm で新しいクラスターを作成すると、最初のマスターは serverA になります。ServerA の apiserver はすでに docker で実行されており、ServerA-IP:6443 に成功して telnet できますが、kubelet はパラメーター "controlPlaneEndpoint" で 4 レイヤーの負荷分散 IP:prot をチェックします。そのため、「controlPlaneEndpoint」を構成すると、kubeadm を使用したインストール中に「nodexxx not found」が 100% 表示されました。
ali などのパブリック クラウド環境では、keepalived+haproxy を使用できません。これは、k8s-apiserver に 7 層の負荷分散を使用する必要があることを意味します。必要な場合は、パラメーター「controlPlaneEndpoint」を使用します。右？
レイヤー 7 負荷分散を使用して kubeadm-config を構成するにはどうすればよいですか? httpsです、kubeadmの認証に問題がありました。ドキュメントはありますか？