Change the corresponding word to 'stacked'.
This commit is contained in:
parent
38b08a4524
commit
8a3b79913f
|
|
@ -10,7 +10,7 @@ weight: 50
|
||||||
|
|
||||||
HAクラスターは次の方法で設定できます。
|
HAクラスターは次の方法で設定できます。
|
||||||
|
|
||||||
- 積み重なったコントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。
|
- 積層コントロールプレーンノードを使用する方法。こちらの場合、etcdノードはコントロールプレーンノードと同じ場所で動作します。
|
||||||
- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。
|
- 外部のetcdノードを使用する方法。こちらの場合、etcdがコントロールプレーンとは分離されたノードで動作します。
|
||||||
|
|
||||||
HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。
|
HAクラスターをセットアップする前に、各トポロジーの利点と欠点について注意深く考慮する必要があります。
|
||||||
|
|
@ -19,9 +19,9 @@ HAクラスターをセットアップする前に、各トポロジーの利点
|
||||||
|
|
||||||
{{% capture body %}}
|
{{% capture body %}}
|
||||||
|
|
||||||
## 積み重なったetcdトポロジー
|
## 積層のetcdトポロジー
|
||||||
|
|
||||||
積み重なったHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
|
積層のHAクラスターは、コントロールプレーンのコンポーネントを実行する、kubeadmで管理されたノードで構成されるクラスターの上に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
|
||||||
|
|
||||||
各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。
|
各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`を実行します。`kube-apiserver` はロードバランサーを用いてワーカーノードに公開されます。
|
||||||
|
|
||||||
|
|
@ -29,23 +29,23 @@ HAクラスターをセットアップする前に、各トポロジーの利点
|
||||||
|
|
||||||
このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。
|
このトポロジーは、同じノード上のコントロールプレーンとetcdのメンバーを結合します。外部のetcdノードを使用するクラスターよりはセットアップがシンプルで、レプリケーションの管理もシンプルです。
|
||||||
|
|
||||||
しかし、積み重なったクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。
|
しかし、積層のクラスターには、結合による故障のリスクがあります。1つのノードがダウンすると、etcdメンバーとコントロールプレーンのインスタンスの両方が失われ、冗長性が損なわれます。より多くのコントロールプレーンノードを追加することで、このリスクは緩和できます。
|
||||||
|
|
||||||
そのため、HAクラスターのためには、最低でも3台の積み重なったコントロールプレーンノードを実行しなければなりません。
|
そのため、HAクラスターのためには、最低でも3台の積層のコントロールプレーンノードを実行しなければなりません。
|
||||||
|
|
||||||
これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。
|
これがkubeadmのデフォルトのトポロジーです。`kubeadm init`や`kubeadm join --control-place`を実行すると、ローカルのetcdメンバーがコントロールプレーンノード上に自動的に作成されます。
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## 外部のetcdトポロジー
|
## 外部のetcdトポロジー
|
||||||
|
|
||||||
外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
|
外部のetcdを持つHAクラスターは、コントロールプレーンコンポーネントを実行するノードで構成されるクラスターの外部に、etcdにより提供される分散データストレージクラスターがあるような[トポロジー](https://en.wikipedia.org/wiki/Network_topology)です。
|
||||||
|
|
||||||
積み重なったetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。
|
積層のetcdトポロジーと同様に、外部のetcdトポロジーにおける各コントロールプレーンノードは、`kube-apiserver`、`kube-scheduler`、および`kube-controller-manager`のインスタンスを実行します。しかし、etcdメンバーは異なるホスト上で動作しており、各etcdホストは各コントロールプレーンノードの`kube-api-server`と通信します。
|
||||||
|
|
||||||
このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積み重なったHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。
|
このトポロジーは、コントロールプレーンとetcdメンバーを疎結合にします。そのため、コントロールプレーンインスタンスまたはetcdメンバーを失うことによる影響は少なく、積層のHAトポロジーほどクラスターの冗長性に影響しないHAセットアップが実現します。
|
||||||
|
|
||||||
しかし、このトポロジーでは積み重なったHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。
|
しかし、このトポロジーでは積層のHAトポロジーの2倍の数のホストを必要とします。このトポロジーのHAクラスターのためには、最低でもコントロールプレーンのために3台のホストが、etcdノードのために3台のホストがそれぞれ必要です。
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue