Kubernetes の高可用性の探求: シングル マスター クラスターとマルチ マスター ノード クラスター ソリューション

1. シングルマスタークラスター

k8s クラスターは、k8s を実行するノードのグループで構成されます。ノードは物理マシン、仮想マシン、またはクラウド サーバーになります。 k8s クラスター内のノードは、マスターとノードの 2 つの役割に分かれています。

• マスターノード: マスターノードは、クラスター全体の制御と管理を担当します。 kube-apiserver、kube-scheduler、kube-controller-manager などのいくつかの主要コンポーネントを実行します。マスター ノードは 1 つ以上存在できます。マスターノードが複数ある場合は、分散キー値ストレージである etcd を通じてデータの一貫性を維持する必要があります。
• ノード: ノードは、ユーザー アプリケーションを実行する動作ノードです。 kubelet、kube-proxy、コンテナ ランタイムなどの必要なコンポーネントを実行します。ノードは 1 つ以上存在できます。複数のノードがある場合は、ネットワーク プラグインを介して通信およびルーティングする必要があります。

通常は、シングルマスターのマルチノード クラスターを構築します。これは、マスター ノードが 1 つだけあり、ノードが複数ある一般的な k8s クラスター アーキテクチャです。このアーキテクチャの利点は、シンプルで構築が簡単で、k8s の機能や特徴を学習およびテストするのに適していることです。このアーキテクチャの欠点は、マスター ノードが単一障害点になることです。マスターノードに問題がある場合、クラスター全体が正常に動作しなくなります。

k8s シングルマスター マルチノード クラスターを構築する方法は多数あります。さまざまなニーズやシナリオに応じて、ノード クラスターを構築および運用するための適切な方法を選択できます。一般的に言えば、いくつかの一般的な方法があります。

• kubeadm の使用: これは、公式ツール kubeadm を使用してノード クラスターをすばやく作成および管理する方法です。 kubeadm は、kubelet、kube-proxy、コンテナ ランタイムなど、ノードに必要なコンポーネントを自動的にインストールして構成できます。このアプローチは、学習やテストの目的、または単純な本番環境に適しています。
• kops の使用: これは、オープンソース ツール kops を使用して、クラウド サービス プロバイダー (AWS、GCP など) 上でノード クラスターを作成および管理する方法です。 Kops は、仮想マシン、ネットワーク、ストレージなどのクラウド リソースを自動的に作成および構成し、ノードに必要なコンポーネントをインストールして構成できます。この方法は、クラウドに高可用性とスケーラビリティを備えたノード クラスターを展開するのに適しています。
• 他のツールまたはプラットフォームの使用: これは、他のサードパーティが提供するツールまたはプラットフォームを使用してノード クラスターを作成および管理する方法です。たとえば、Ansible、Terraform、Rancher などのツールを使用して、ノード クラスターの作成と構成のプロセスを自動化およびカスタマイズできます。あるいは、クラウド サービス プロバイダーが提供するマネージド サービス (EKS、GKE、AKS など) を使用して、ノード クラスターを直接作成および管理することもできます。このアプローチはさまざまなニーズや好みに適していますが、より多くの学習とデバッグのコストが必要になる可能性があります。

2. マルチマスタークラスタ

通常、マスター ノードが 1 つしかない場合、そのマスター ノードに障害が発生したり、使用できなくなったりすると、クラスター全体が制御を失い、操作は実行されなくなります。したがって、クラスターの高可用性を確保するには、マスター クラスターを構築するために複数のマスター ノードが必要です。マルチマスター クラスターは、アプリケーション クラスターとストレージ クラスターに分けることができます。アプリケーション クラスターは、主に apiserver、スケジューラ、およびコントローラ マネージャーのクラスターです。これらは個別のノードとして負荷分散クラスターを実装することができ、etcd はマルチノードの高可用性クラスターを実装できます。その中で、etcd はクラスタ化が可能であり、組み込みクラスタと外部クラスタに分けられます。詳しい紹介は以下の通りです。

1. アプリケーション負荷分散クラスター

Kubernetes マルチマスター クラスターとは、複数のマスター ノードを使用してクラスターの可用性とフォールト トレランスを向上させるソリューションを指します。マスターノードは、クラスター内のリソースとサービスを制御および管理する役割を担います。次のコンポーネントを実行します。

• kube-apiserver: HTTP REST インターフェースの主要なサービス プロセスを提供します。これは、クラスター内のすべてのリソースを追加、削除、変更、および照会するための唯一のエントリ ポイントであり、クラスター制御のエントリ プロセスでもあります。
• kube-scheduler: リソースのスケジューリング (Pod のスケジューリング) を担当するプロセス。バス会社の「配車室」に相当します。
• kube-controller-manager: クラスター内のすべてのリソース オブジェクトの自動制御センター。リソース オブジェクトの「ゼネラル マネージャー」として理解できます。

Kubernetes マスター クラスターを実装する方法は多数あります。さまざまなニーズやシナリオに応じて、マスター クラスターを構築および運用するための適切な方法を選択できます。一般的に、負荷分散クラスターは実装方法に応じて次のソリューションに分類できます。

• ハードウェア ロード バランシング: ハードウェア ロード バランシングは、F5、Cisco などの特殊なハードウェア デバイスを使用してロード バランシングを実装するソリューションです。ハードウェア ロード バランシングの利点は、パフォーマンスが高く、安定性が強いことですが、欠点はコストが高く、スケーラビリティが低いことです。
• ソフトウェア負荷分散: ソフトウェア負荷分散は、Nginx、HAProxy などの一般的なサーバーとソフトウェアを使用して負荷分散を実装するソリューションです。ソフトウェア負荷分散の利点は、コストが低く、スケーラビリティに優れていることですが、欠点はパフォーマンスが低く、安定性が低いことです。
• ハイブリッド ロード バランシング: ハイブリッド ロード バランシングは、ハードウェア デバイスをグローバル エントリとして使用し、ソフトウェアをローカル配布に使用するなど、ハードウェアとソフトウェアを組み合わせてロード バランシングを実現するソリューションです。ハイブリッド負荷分散の利点は、パフォーマンスとコストの両方を考慮していることですが、欠点は非常に複雑で保守が難しいことです。

2. ストレージ高可用性クラスター

etcd: クラスター内のすべてのリソース オブジェクトのステータスとメタデータを保存するために使用される分散キー値ストレージ システム。

k8s は高可用性 (HA) Kubernetes etcdクラスターを構成します。

次の 2 種類の HA クラスターを設定できます。

• etcdノードがコントロールプレーンノードと共存するスタックされたコントロールプレーンノードを使用する
• 外部etcdノードを使用する（etcdはコントロールプレーンとは別のノードで実行される）

（1）スタックされたetcdトポロジー - 組み込みetcdクラスター

スタックされた HA クラスターは、etcd 分散データ ストレージ クラスターが kubeadm によって管理されるコントロール プレーン ノード上にスタックされ、コントロール プレーンのコンポーネントとして実行されるトポロジです。

各コントロール プレーン ノードは、kube-apiserver、kube-scheduler、および kube-controller-manager のインスタンスを実行します。 kube-apiserver は、ロード バランサーを使用してワーカー ノードに公開されます。

各コントロール プレーン ノードは、そのノードの kube-apiserver とのみ通信するローカル etcd メンバーを作成します。同じことがローカルの kube-controller-manager および kube-scheduler インスタンスにも当てはまります。

このトポロジは、コントロール プレーンと etcd メンバーを同じノードに結合します。外部の etcd クラスターを使用する場合と比較して、セットアップが簡単で、レプリカの管理も容易になります。

ただし、クラスターを積み重ねると、結合が失敗するリスクが伴います。ノードに障害が発生すると、etcd メンバーとコントロール プレーン インスタンスの両方が失われ、冗長性が影響を受けます。コントロール プレーン ノードを追加することで、このリスクを軽減できます。

したがって、HA クラスターでは少なくとも 3 つのスタックされたコントロール プレーン ノードを実行する必要があります。

これは kubeadm のデフォルトのトポロジです。 kubeadm initとkubeadm joinを使用する場合  --コントロールプレーン コントロール プレーン ノードにローカル etcd メンバーを作成すると、コントロール プレーン ノードにローカル etcd メンバーが自動的に作成されます。

（２）外部etcdトポロジー - 外部etcdクラスタ

外部 etcd を使用した HA クラスターは、etcd 分散データ ストレージ クラスターがコントロール プレーン ノードとは独立した他のノード上で実行されるトポロジです。

スタックされた etcd トポロジと同様に、外部 etcd トポロジ内の各コントロール プレーン ノードは、kube-apiserver、kube-scheduler、および kube-controller-manager のインスタンスを実行します。同様に、kube-apiserver はロードバランサーを使用してワーカーノードに公開されます。ただし、etcd メンバーは異なるホスト上で実行され、各 etcd ホストは各コントロール プレーン ノードの kube-apiserver と通信します。

このトポロジは、コントロール プレーンと etcd メンバーを分離します。したがって、コントロール プレーン インスタンスまたは etcd メンバーの損失による影響が少なく、スタックされた HA トポロジのようなクラスターの冗長性に影響を与えない HA セットアップが提供されます。

ただし、このトポロジでは、スタックされた HA トポロジの 2 倍のホスト数が必要になります。このトポロジの HA クラスターには、コントロール プレーン ノード用に少なくとも 3 つのホストと、etcd ノード用に 3 つのホストが必要です。