我々はK8Sクラスタのみ1駅長を構築する前に、可用性が高くありませんが、二日には、高可用性クラスタを構築するために始めたが、使用の有無はkubeadmコマンドでクラスタ作成前に--controlプレーン・エンドポイントのパラメータを、あなたが直接、今すぐアップグレードすることはできませんクラスタは再作成する高可用性（ハイアベイラビリティ）クラスタに、そこにあります。
高可用性クラスタの原理は非常に単純な、複数のマスター、各クラスタのデータは、マスターの一部がダウンしたときにそうすることを、（etcd）特殊な構造を通じて均衡のすべてのノードへのアクセスAPIサーバーの負荷を格納しているされ、クラスタの正常動作に影響はありません。
私たちは、3つのマスターを過ごしたが、夢見たことがない問題が発生した第一段階のマスターサーバーに高可用性クラスタの作成を開始します。
kubeadmのinit \
--kubernetes版v1.16.3 \
--controlプレーン・エンドポイント"K8S-API：6443" --upload-certsの\
--image-リポジトリregistry.aliyuncs.com/google_containers \
--podネットワーク-cidr = 192.168.0.0 / 16 --v = 6
時間を節約するために、我々は、追加の負荷分散の展開を所有していませんが、直接IPの均衡アリ雲の負荷を解決するためにK8S-APIのマスターになります上記のホストで、均衡アリクラウドネットワーク負荷（4つの前方のTCP）を使用します。
しかし、常に、次のエラーメッセージクラスタの作成に失敗
[kubeletチェック]渡された40年代の初期タイムアウト。 I1217 08：39：21.852678 20972 round_trippers.go：443] GETます。https：// K8S-API：？30000ミリ秒で6443 / healthzタイムアウト= 32S
調査の後、我々はアリクラウド4つの負荷分散が同じサーバに要求を転送するサポートしていないため、サーバが同じサーバにすることはできませんバックエンドサーバーに転送された要求を送信することを発見しました。
その後、我々は、マスターサーバー上の均衡IP負荷にK8S-APIの解決さ、問題を解決するための回避策を使用していないが、決意は、ノードのみでバランスをとる決意IP負荷に、自分自身のIPをマスターします。
私たちは、高い上の大きな豪華クルーズ船を楽しむのに十分な時間を優れた高可用性クラスタを構築していないとき、彼らは奇妙なDNS解決の問題が発生します。コンテナ内のホスト名を解決するときに、この問題を持っている、非常に遅く、時には正常に解決、そして時には解決に失敗し、K8Sかどうか、サービス名、または手動でDNS解決のレコードを追加、またはアリクラウドサービスをRedisの。キャラコを使用してcoredns、ポッドネットワークを使用してDNS解決サービス。3ザ・マスター台湾ノードのクラスタがありました、私たちは疲れてこの目的のために最後の夜を終え、このクラスタネットワークを構築するための時間で始まる問題K8Sネットワークは、フランネル、後で変更キャラコであることを考えるようになったが、無駄に長い時間をトス怒っクラスタシャットダウンのベッドにすべてのサーバーを移行する前に、実行する力。
ブート今日、彼らは物事を夢見たことがない遭遇、問題は、私はそれだけでエピソード中にクルーズ船のアップグレードだと思った、魔法が消えたことが判明しました。
一日の終わりには、私はまた、フランネルのネットワークを使用して（同じDNS解決に問題が登場一部ノードにのみ非可用性クラスタ1つの駅長を構築するために使用するには、オンラインで夢を見たことがないものに遭遇しましたノード）、ちょうど学んだ永続的なトリックによると、再起動の問題は、問題はすぐに姿を消しました。
実際には、すべて同じDNSで問題が解決していた、そして、異なるポッドネットワークを使用して、異なるネットワークアドレス（192.168.0.0/16は10.244.0.0/16ている）を使用して2つの異なるクラスター、再起動することにより、問題のうち、私たちの心の出航に、この奇妙な質問を解決することができます。
贅沢から経済への豪華クルーズ船への浪費と簡単に、準備によって、我々は漁船（docke群れ）をオープンにしたくない。しかし、いずれにせよ、ボートが開くように継続する必要があります。