コンテンツに関連します

LVS
HAProxy
港
etcd
Kubernetes（マスターワーカー）

全体のトポロジマップ

これらは、最小の利用可能な全体的な生産トポロジーグラフ（増加させるが減少しないように、必要に応じて関連するノード）であります

機能グループに分け

SLB
- LVS
- HAProxy
etcd
K8Sノード（マスター/ワーカー）

SLB

LVS、HAProxyは、ベース層を計画している主にレイヤ7ロードバランサ高可用性を提供します。
LVSによる高可用性VIP（仮想IP）を提供keepalivedの。
VIP DRモードは、バックエンドサーバーHAProxyに転送されます。
HAProxy抗世代K8Sマスターサーバーは、K8SマスターAPIは、高可用性と負荷分散機能を提供します。

nginxのではなく、HAProxyそれを使用することができますか？

なお、ここでHAproxyが原因出現HAproxy K8S文書のある使用可能であり、そして次の世代は、それによってHAProxyを使用してカウンタ項4層であってもよいです。

LVSはそれからマスターに直接転送することができますか？

理論的には可能で、私はテストしていません。
勧告はまだつのサービス・エージェントを設定する2機の不足ではない場合は7層に能力を持っています。
K8Sはapiserver、港、etcdは、7つの層がある場合は、フォローアップのプロキシサービス能力は維持し、拡張することが容易になります、HTTPのAPIとして提供されます。

推奨

使用	数量	CPU	メモリ
生き続ける	2	4	4ギガバイト
HAProxy	2	4	4ギガバイト

etcd

etcdはいかだアルゴリズムを使用して分散キー値ストレージシステムです。
これは、独立した分散型システムであり、あなたは、特定の導入の公式ウェブサイトに紹介を行うことはあまりないを参照することができ、排他的K8Sではありません。
私たちは、etcdクラスタを展開する静的ポッド方法を使用します。

耐障害性

最小フリーノード：（N / 2）+1し、次のノードの推奨される数であり、太字た参照テーブルである：
| |総故障公差| |生存起こっ
| - ：| - ：|： - ：|
。| 1 | 1 | 0 |
| 2 | 2 | 0 |
。| 3 | 2 | 1 |
···| 4 | 3 | 1 |
。| 5 | 3 | 2 |
。| 6 | 4 | 2 |
。| 7 | 4 | 3 |
| 8 | 5 | 3 |
| 9 | 5 | 4 |

推奨

カッコ内の公式の推奨構成です

使用	数量	CPU	メモリ
etcd	3	4（8〜16）	8ギガバイト（16ギガバイト〜64ギガバイト）

公式サイト：
https://etcd.io/
：公式には、ハードウェア推奨
https://etcd.io/docs/v3.3.12/op-guide/hardware/
静的ポッドの展開ドキュメント：
https://kubernetes.io/docs/setupを/本番環境/ツール/ kubeadm /セットアップ-HA-etcd-と-kubeadm /

Kubernetesクラスタ

マスターと労働者：kubernetesは、ノードの主に2つのタイプがありますクラスタ化します。
マスターは、クラスタのリードです。
労働者は、労働者のノードです。
これは、労働者のニーズは増加などのノードに応じて減らすことが、主な仕事のマスターノードにここで見ることができます。
マスターノードの高可用性トポロジの関係者は二つの選択肢を提供します。

積み上げetcdトポロジー（ETCDスタック）
外部etcdトポロジ（外部etcd）

主な違いは、展開のetcdていることが分かります。
第1の実施形態は、すべてのK8Sマスターノードがクラスタを形成ネイティブetcd etcd上で実行されていることです。
2番目のオプションは、外部etcdクラスター（追加の建物etcdクラスタ）を使用することです。
私たちは、第二、外部etcdを使用し、次のように、トポロジー図です。

etcd図スタックトポロジーを採用している場合：

ここでは、状況に応じて選択することができ、我々は、第二、外部etcdを使用することをお勧めします。

参考資料：
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

マスターノードコンポーネント

apiserver
コントローラマネージャ
スケジューラ

マスターノードは、主に上記の3つのコンポーネントが含まれています（クラウドコントローラマネージャは、ここで説明したように通常は使用しませんしません）
apiserver：サーバAPI、クラスターがそれを通過する必要があり、外部K8Sとのすべての対話を。（水平方向の拡張）
コントローラマネージャ実行ロジックコントローラ（従ってクラスタ状態監視apiserverで処理周期）（唯一つのノードがアクティブであるマスタクラスタ）：
スケジューラ：特定のノードでスケジュールポッド（のみクラスタマスタ内の1つのアクティブノードを有します）

アクティブ（クラスのHBase）ランニングapiserver単なる一例を可能にすることに加えてインスタンスは、それらの活性化状態を設定する前に利用可能でない場合にのみ、インスタンス上の他のノードにスタンバイ状態にアクティブ状態に属していることが分かります。
ここで（飼育係、領事や他の分散クラスタシステムはまた、リーダーシップの選挙が必要です）リーダーシップの選挙を必要とします

マスターの可用性は、複数のノードが必要ですか？失敗のどのくらい寛容？

K8Sは、データの一貫性に依存しているetcdので全く問題（etcdへのデータの一貫性の圧力）、K8S機構の投票が選出されるように、そして唯一の結節健康がリーダーになることができ習得取るので、必要はありません。
だから、ここではさえ、可能である、奇数習得する必要はありません。
次に、マスタノードは、少なくとも二つの高可用性を必要とする、耐障害性は、（N / 0）+1であり、それは限り健康K8Sクラスタが使用可能な状態に属するマスタが存在するように、です。（ここでは、etcdが利用できない場合、マスターが使用できなくなり、マスター依存性がetcdことに留意すべきです）

マスターコンポーネント説明：
https://kubernetes.io/docs/concepts/overview/components/
展開ドキュメント：
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

ハードウェア構成

使用	数量	CPU	メモリ
マスター	3	4	8ギガバイト

可用性を確認してください

これまで生産可能なK8Sクラスタは、「構造体を完成させました。」していますなぜ引用符を戦いますか？テストと検証がないので、私の下にリストされている検証のリストを与える

だけでなく、BGP関連の検証は記事の内容には関与しない、以降の説明は皆のためになります。

最後に書かれました

これらの仮想マシンのすべてがそう単一の物理マシン上の「一点の問題が」まだある場合には注意すべきもう一つのポイントは、物理マシンの可用性です。ここでは、少なくとも三つ以上の物理マシンをお勧めします。

なぜ我々は、3つ以上の物理マシンが必要なのですか？
主に2つだけの物理マシンが5つのetcdノードを展開した場合、問題のetcdのアカウント上で、3展開は、物理マシンの故障ということetcd、および失敗は、このように、etcdクラスタによって引き起こされるダウンタイムのために満足しetcd許容範囲ではありませんK8Sクラスタのダウンタイムを導きます。

高可用性クラスタの展開K8S