クラスターのアーキテクチャ

Kubernetesクラスターは、コントロールプレーンと、コンテナ化されたアプリケーションを実行するワーカーマシン群(ノードと呼ばれます)で構成されます。 各クラスターには、Podを実行するために少なくとも1つのワーカーノードが必要です。

ワーカーノードは、アプリケーションのワークロードを構成するPodをホストします。 コントロールプレーンは、クラスター内のワーカーノードとPodを管理します。 本番環境では、コントロールプレーンは通常複数のコンピューターにまたがって実行され、クラスターは通常複数のノードを実行することで、耐障害性と高可用性を提供します。

このドキュメントでは、完全に機能するKubernetesクラスターに必要なさまざまなコンポーネントの概要を説明します。

このアーキテクチャについて

図1は、Kubernetesクラスターのリファレンスアーキテクチャの一例を示しています。 コンポーネントの実際の配置は、具体的なクラスターの構成や要件によって異なる場合があります。

この図では、各ノードでkube-proxyコンポーネントが実行されています。 Service APIと関連する動作をクラスターネットワーク上で利用可能にするためには、各ノードにネットワークプロキシコンポーネントが必要です。 ただし、一部のネットワークプラグインは、独自のサードパーティ製プロキシ実装を提供しています。 そのようなネットワークプラグインを使用する場合、ノードでkube-proxyを実行する必要はありません。

コントロールプレーンコンポーネント

コントロールプレーンのコンポーネントは、クラスターに関する全体的な判断(たとえばスケジューリングなど)を行うほか、クラスターのイベントの検知と対応(たとえば、Deploymentのreplicasフィールドが満たされていない場合に新しいPodを起動するなど)を行います。

コントロールプレーンコンポーネントは、クラスター内の任意のマシンで実行できます。 ただし、単純化のため、セットアップスクリプトは通常すべてのコントロールプレーンコンポーネントを同じマシン上で起動し、そのマシンではユーザーのコンテナを実行しません。 複数のマシンにまたがって実行されるコントロールプレーンのセットアップ例については、kubeadmを使用した高可用性クラスターの作成を参照してください。

kube-apiserver

APIサーバーは、Kubernetes APIを外部に提供するKubernetesコントロールプレーンのコンポーネントです。 APIサーバーはKubernetesコントロールプレーンのフロントエンドになります。

Kubernetes APIサーバーの主な実装はkube-apiserverです。 kube-apiserverは水平方向にスケールするように設計されています—つまり、インスタンスを追加することでスケールが可能です。 複数のkube-apiserverインスタンスを実行することで、インスタンス間でトラフィックを分散させることが可能です。

etcd

一貫性、高可用性を持ったキーバリューストアで、Kubernetesの全てのクラスター情報の保存場所として利用されています。

etcdをKubernetesのデータストアとして使用する場合、必ずデータのバックアッププランを作成して下さい。

公式ドキュメントでetcdに関する詳細な情報を見つけることができます。

kube-scheduler

コントロールプレーン上で動作するコンポーネントで、新しく作られたPodにノードが割り当てられているか監視し、割り当てられていなかった場合にそのPodを実行するノードを選択します。

スケジューリングの決定は、PodあるいはPod群のリソース要求量、ハードウェア/ソフトウェア/ポリシーによる制約、アフィニティおよびアンチアフィニティの指定、データの局所性、ワークロード間の干渉、有効期限などを考慮して行われます。

kube-controller-manager

コントロールプレーン上で動作するコンポーネントで、複数のコントローラープロセスを実行します。

論理的には、各コントローラーは個別のプロセスですが、複雑さを減らすために一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動きます。

コントローラーにはさまざまな種類があります。 いくつか例を挙げます:

• Nodeコントローラー: ノードがダウンした際に、それを検知して対応する役割を担います。
• Jobコントローラー: 一度限りのタスクを表すJobオブジェクトを監視し、それらのタスクを完了まで実行するためのPodを作成します。
• EndpointSliceコントローラー: (ServiceとPodの間のリンクを提供するために)EndpointSliceオブジェクトを作成します。
• ServiceAccountコントローラー: 新しい名前空間に対してデフォルトのServiceAccountを作成します。

上記はすべてを網羅したリストではありません。

cloud-controller-manager

クラウド特有の制御ロジックを組み込むKubernetesのコントロールプレーンコンポーネントです。 クラウドコントロールマネージャーは、クラスターをクラウドプロバイダーAPIとリンクし、クラスターのみで相互作用するコンポーネントからクラウドプラットフォームで相互作用するコンポーネントを分離します。

cloud-controller-managerは、利用しているクラウドプロバイダーに固有のコントローラーのみを実行します。 オンプレミス環境でKubernetesを実行している場合や、自分のPC内の学習環境で実行している場合、クラスターにcloud-controller-managerは存在しません。

kube-controller-managerと同様に、cloud-controller-managerは、論理的に独立した複数の制御ループを、単一のプロセスとして実行する1つのバイナリにまとめています。 パフォーマンスの向上や障害への耐性を高めるために、水平方向にスケール(複数のコピーを実行)できます。

次のコントローラーは、クラウドプロバイダーに依存する可能性があります。

• Nodeコントローラー: ノードが応答を停止した後、そのノードがクラウド上で削除されたかどうかを判断するためにクラウドプロバイダーを確認します。
• Routeコントローラー: 基盤となるクラウドインフラ内でルートを設定します。
• Serviceコントローラー: クラウドプロバイダーのロードバランサーの作成、更新、削除を行います。

---

Nodeコンポーネント

ノードコンポーネントはすべてのノード上で実行され、実行中のPodの維持やKubernetesの実行環境の提供を行います。

kubelet

クラスター内の各ノード上で実行されるエージェント。 コンテナがPod内で実行されていることを保証します。

kubeletは、さまざまなメカニズムを通じて提供される一連のPodSpecを受け取り、そのPodSpecに記述されたコンテナが実行され、正常であることを保証します。 kubeletは、Kubernetesによって作成されていないコンテナを管理しません。

kube-proxy(オプション)

kube-proxyはクラスター内の各nodeで動作しているネットワークプロキシで、KubernetesのServiceコンセプトの一部を実装しています。

kube-proxyは、Nodeのネットワークルールをメンテナンスします。これらのネットワークルールにより、クラスターの内部または外部のネットワークセッションからPodへのネットワーク通信が可能になります。

kube-proxyは、オペレーティングシステムにパケットフィルタリング層があり、かつ使用可能な場合、パケットフィルタリング層を使用します。それ以外の場合は自身でトラフィックを転送します。

Serviceに対するパケット転送を自身で実装し、kube-proxyと同等の動作を提供するネットワークプラグインを使用している場合、クラスター内のノードでkube-proxyを実行する必要はありません。

コンテナランタイム

Kubernetesがコンテナを効果的に実行するために不可欠なコンポーネントです。 Kubernetes環境においてコンテナの実行とライフサイクルの管理を担います。

Kubernetesはcontainerd、CRI-Oなどのコンテナランタイムと、Kubernetes CRI (Container Runtime Interface)のすべての実装をサポートします。

アドオン

アドオンは、Kubernetesのリソース(DaemonSetやDeploymentなど)を使用してクラスターの機能を実装します。 これらはクラスターレベルの機能を提供するため、アドオンの名前空間に属するリソースはkube-system名前空間に配置されます。

いくつかのアドオンについて以下で説明します。 利用可能なアドオンのより詳細な一覧については、アドオンを参照してください。

DNS

他のアドオンは厳密には必須ではありませんが、多くの例がクラスターDNSに依存しているため、すべてのKubernetesクラスターはクラスターDNSを備えるべきです。

クラスターDNSは、環境内にある他のDNSサーバーに加えて稼働するDNSサーバーであり、KubernetesのService用のDNSレコードを提供します。

Kubernetesによって起動されたコンテナは、自動的にこのDNSサーバーをDNS検索に含めます。

Web UI(Dashboard)

Dashboardは、Kubernetesクラスターのための汎用的なWebベースのUIです。 ユーザーはこれを使って、クラスター内で稼働しているアプリケーションやクラスター自体の管理やトラブルシューティングを行えます。

コンテナリソースの監視

コンテナリソースの監視は、コンテナに関する一般的な時系列メトリクスを中央のデータベースに記録し、そのデータを閲覧するためのUIを提供します。

クラスターレベルのロギング

クラスターレベルのロギングの仕組みは、コンテナのログを検索・閲覧用のインターフェースを備えた中央のログストアに保存する役割を担います。

ネットワークプラグイン

ネットワークプラグインは、Container Network Interface(CNI)仕様を実装するソフトウェアコンポーネントです。 PodへのIPアドレスの割り当てや、クラスター内でPod同士が通信できるようにする役割を担います。

アーキテクチャのバリエーション

Kubernetesの中核となるコンポーネントは一貫していますが、それらがデプロイされ管理される方法はさまざまです。 これらのバリエーションを理解することは、特定の運用上のニーズを満たすKubernetesクラスターを設計し維持するうえで非常に重要です。

コントロールプレーンのデプロイオプション

コントロールプレーンコンポーネントは、いくつかの方法でデプロイできます。

従来のデプロイ

コントロールプレーンコンポーネントは専用のマシンやVM上で直接実行され、多くの場合systemdのサービスとして管理されます。

static Pod

コントロールプレーンコンポーネントはstatic Podとしてデプロイされ、特定のノード上のkubeletによって管理されます。 これはkubeadmのようなツールで使われる一般的なアプローチです。

セルフホスト

コントロールプレーンはKubernetesクラスター自体の内部でPodとして実行され、DeploymentやStatefulSet、その他のKubernetesのプリミティブによって管理されます。

マネージドKubernetesサービス

クラウドプロバイダーは多くの場合コントロールプレーンを抽象化し、そのコンポーネントを自身のサービス提供の一部として管理します。

ワークロード配置に関する考慮事項

コントロールプレーンコンポーネントを含むワークロードの配置は、クラスターのサイズ、パフォーマンス要件、運用ポリシーによって異なる場合があります:

• より小規模なクラスターや開発用のクラスターでは、コントロールプレーンコンポーネントとユーザーのワークロードが同じノード上で実行されることがあります。
• より大規模な本番クラスターでは、多くの場合特定のノードをコントロールプレーンコンポーネント専用にし、ユーザーのワークロードから分離します。
• 一部の組織では、重要なアドオンや監視ツールをコントロールプレーンのノード上で実行します。

クラスター管理ツール

kubeadm、kops、Kubesprayといったツールは、クラスターのデプロイと管理に対してそれぞれ異なるアプローチを提供しており、コンポーネントの配置や管理の方法もそれぞれ独自のものです。

カスタマイズと拡張性

Kubernetesのアーキテクチャは、大幅なカスタマイズを可能にします。

• カスタムスケジューラーをデプロイして、デフォルトのKubernetesスケジューラーと並行して動作させたり、完全に置き換えたりできます。
• APIサーバーは、CustomResourceDefinitionやAPIアグリゲーションによって拡張できます。
• クラウドプロバイダーは、cloud-controller-managerを使用してKubernetesと深く統合できます。

Kubernetesのアーキテクチャの柔軟性により、組織は運用の複雑さ、パフォーマンス、管理のオーバーヘッドといった要素のバランスを取りながら、クラスターを特定のニーズに合わせて調整できます。

次の項目

以下についてさらに学べます。

• ノードとコントロールプレーンとの通信。
• Kubernetesのコントローラー。
• クラスターオブジェクトのガベージコレクション。
• Kubernetesのデフォルトスケジューラーであるkube-scheduler。
• etcdの公式ドキュメント。
• Kubernetesにおけるいくつかのコンテナランタイム。
• cloud-controller-managerを使用したクラウドプロバイダーとの統合。
• kubectlコマンド。