Kubernetesのクラスタの全体像

Kubernetesは複数のサーバーを連携して一つのサービスを提供します。

このまとまりのことをクラスタと呼びます。

(英語で「集まり、まとまり」という意味)

クラスタの内部にはコントロールプレーン,ノードコンポーネント(またはワーカーノード)と呼ばれる構成要素があり、

Kubernetesのアーキテクチャを理解するためにはこれらの用語を体系的に覚える必要があります。

Kubernetesのクラスタの構成要素

全体像は以下のとおりです。

Kubernetesのクラスタの全体図

Kubernetesのクラスタの構成要素は以下のとおりです。

Kubenetesのコントロールプレーンは以下のコンポーネントから構成されます。

kube-apiserver : コントロールプレーンの本体と言えるサーバーでAPIリクエストを受け付け、クラスタを修正します。
- 実際にはコマンドkube-ctlを実行することでkube-apiserverへAPIリクエストを投げることでクラスタの修正を行います。
etcd : Kubernetes内部に存在するノードの情報、リソースの詳細などの情報を貯めるデータベース
kube-controller-manager : 新しいPodを生成したり、新しいEndpointを生成したりします。
kube-scheduler : 生成されるPodの場所を決定する。（リソースの生成自体はcontroller-managerで行いますが、kube-schedulerは生成場所を決定します。
- その時の様々なリソースの状況を見たり、ユーザーが指定したPodのスケジュールの制約を鑑みたりしつつ、Podに最適なNodeを決定しています。
cloud-controller-manager : クラウドプロバイダとやりとりをするためのサービスです。

コントロールプレーンのサービスが落ちた場合、すぐにアプリケーションがしてしまうことはあり終了してしまうことはありません。なぜならコントロールプレーンの役割は「アプリケーションのコントロール」であり、本体であるワーカーノードはしばらくは正常に動作するでしょう。

ところが、「新しいコンテナのデプロイ」や「Kubernetesリソースの更新」はコントロールプレーンを通してワーカーノードへ伝えられるのでできなくなります。

そのため、コントロールプレーンには高い可溶性が求められます。 アプリケーションに求められる要件によって変わりますが、通常はコントロールプレーンは3つ以上存在することが求められるでしょう

kubernetesはコントロールプレーンが常にワーカーノードを監視しているため、高い可用性を維持できます。

ですがこの高可用性に対して、常にテストは必要です。

事前に予定されているメンテナンス時間内、

または夜間停止期間帯にワーカーノードを一つリブートして何が起こるかを観察するのです。 全く何も起こらなければ成功となります。

あるいはコントロールプレーンの一つをリブートするのも一つの手です。

きちんとしたkubernetesの構成であれば何事もなく乗り切れるはずです。

ノードのコンポーネントとは実際に実行されるサービスのこと。通常はDockerコンテナが動く。(別名Kubernetes Work Nodes)

Kubenetesのノードコンポーネントの構成要素は以下のとおりです。

ワーカーノードの障害発生は大きな問題にはなりません。

Kubernetesがコントロールプレーンが障害を察知してあるべき状態に戻してくれます。

ただ、大量のワーカーノードで障害が発生したときはサービスが利用不可能になる可能性はあります。(クラウドの一つのアベイラビリティゾーンがすべて使用不可能になるなど。)

そのため、kubernetesのワーカーノードは複数のアベイラビリティゾーンで運用することが優れた運用方法となります