Kubernetes アーキテクチャガイド

Kubernetes アーキテクチャのさまざまなコンポーネントがどのように組み合わされているかを理解することで、問題のトラブルシューティングを改善し、クラスターの健全性を維持し、ワークフローを最適化できるようになります。

Kubernetes を使用してコンテナをオーケストレーションする方法は簡単に説明できますが、それが実際に何を意味し、どのように実装するかを理解することはまったく別の問題です。 Kubernetes クラスターを実行または管理している場合は、Kubernetes が「コントロールプレーン」と呼ばれるマシンと他の多くのワーカーノードマシンで構成されていることをご存知でしょう。各タイプには、オーケストレーションを可能にする複雑だが安定したスタックがあり、各コンポーネントに精通することで、その動作を理解するのに役立ちます。

(ニヴェド・ベラユダン、CC BY-SA 4.0)

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

Kubernetes はコントロールプレーンと呼ばれるマシンにインストールされ、Kubernetes デーモンを実行し、コンテナやコンテナグループポッドを起動するときに Kubernetes デーモンと通信します。コントロールプレーンのコンポーネントについては、以下で説明します。

など

etcd は、コンテナグループ、レプリケーションコントローラー、シークレット、サービスなどの Kubernetes オブジェクトデータの永続ストレージとして使用される、高速で分散された一貫性のあるキー値ストアです。 etcd は、Kubernetes がクラスターの状態とメタデータを保存する唯一の場所です。 etcd に直接接続する唯一のコンポーネントは Kubernetes API サーバーです。他のすべてのコンポーネントは、API サーバーを介して間接的に etcd からデータを読み書きします。

etcd は、キーの変更を非同期的に監視するためのイベントベースのインターフェースを提供する監視機能も実装しています。キーを変更すると、そのモニターに通知されます。 API サーバーコンポーネントは、通知を受け取り、etcd を目的の状態に変更するためにこれに大きく依存しています。

etcd インスタンスの数はなぜ奇数にする必要があるのでしょうか?

通常、高可用性 (HA) 環境では 3、5、または 7 個の etcd インスタンスを実行しますが、その理由は何でしょうか? etcd は分散データストアであるため、水平方向にスケーリングできますが、各インスタンスのデータの一貫性を確保する必要があります。したがって、システムの現在の状態について合意に達する必要があり、etcd はこの目的のために RAFT コンセンサスアルゴリズムを使用します。

RAFT アルゴリズムでは、次の状態に入るために選択 (または仲裁) クラスターが必要です。 etcd インスタンスが 2 つしかなく、そのうちの 1 つに障害が発生した場合、多数決の概念がないため、etcd クラスターは新しい状態に移行できません。 etcd インスタンスが 3 つある場合、1 つのインスタンスが失敗しても、2 つのインスタンスが選択可能です。

API サーバー

API サーバーは、Kubernetes 内で etcd と直接対話する唯一のコンポーネントです。 Kubernetes の他のすべてのコンポーネントは、クライアント (kubectl) を含め、クラスターの状態を処理するために API サーバーを経由する必要があります。 API サーバーには次の機能があります。

etcd にオブジェクトを保存するための一貫した方法を提供します。
検証オブジェクトは、クライアントが誤って構成されたオブジェクトを保存するのを防ぐために強制されます (etcd データストアに直接書き込む場合に発生する可能性があります)。
リソースを作成、更新、変更、または削除するための RESTful API を提供します。
更新中に他のクライアントがオブジェクトを上書きできないように、楽観的同時実行ロックを提供します。
クライアントから送信されたリクエストを認証および承認します。プラグインを使用してクライアントのユーザー名、ID、グループを抽出し、認証されたユーザーが要求されたリソースに対して要求されたアクションを実行できるかどうかを判断します。
リクエストがリソースの作成、変更、または削除を試行する場合、権限制御を担当します。たとえば、AlwaysPullImages、DefaultStorageClass、ResourceQuota などです。
ユーザークライアントが変更を監視する監視メカニズム (etcd に類似) が実装されています。これにより、スケジューラやコントローラマネージャーなどのコンポーネントが API サーバーと疎結合で対話できるようになります。

コントローラーマネージャー

Kubernetes では、コントローラーがクラスターの状態を継続的に監視し、必要に応じて変更を加えたり要求したりします。各コントローラは、現在のクラスタの状態を目的の状態に変更しようとします。コントローラーは少なくとも 1 つの Kubernetes リソースタイプを追跡し、これらの各オブジェクトには目的の状態を表すフィールドがあります。

コントローラーの例:

レプリケーションマネージャー (ReplicationController リソースを管理するコントローラー)
レプリカセット、デーモンセット、タスクコントローラ
デプロイメントコントローラー
ステートフルロードコントローラ
ノードコントローラ
サービスコントローラー
アクセスポイントコントローラ
名前空間コントローラ
永続ボリュームコントローラー

コントローラには監視メカニズムを通じて変更が通知されます。これらは、API サーバーを監視してリソースの変更を検出し、新しいオブジェクトの作成、既存のオブジェクトの更新または削除など、変更ごとにアクションを実行します。ほとんどの場合、これらの操作には、追加のリソースの作成や監視対象リソース自体の更新が含まれます。ただし、監視を使用してもコントローラーがイベントを見逃さないことが保証されるわけではないため、コントローラーはイベントが見逃されないようにするために、定期的に一連のアクションを実行します。

コントローラーマネージャーはライフサイクル機能も実行します。例としては、名前空間の作成とライフサイクル、イベントガベージコレクション、終了したコンテナーグループのガベージコレクション、カスケード削除のガベージコレクション、ノードのガベージコレクションなどがあります。詳細については、「Cloud Controller Manager」を参照してください。

スケジューラ

スケジューラは、コンテナのグループをノードに割り当てるコントロールプレーンプロセスです。割り当てられたノードがない新しく作成されたコンテナグループを監視します。スケジューラは、検出された各コンテナグループを、それを実行するのに最適なノードに割り当てます。

コンテナグループのスケジュール要件を満たすノードは、スケジュール可能なノードと呼ばれます。適切なノードがない場合、コンテナグループはスケジューラが配置できるようになるまでスケジュールされないままになります。スケジュール可能なノードが見つかると、一連の関数を実行してノードにスコアを付け、スコアが最も高いノードを選択して、選択したノードについて API サーバーに通知します。このプロセスはバインディングと呼ばれます。

ノードの選択は 2 つのステップに分かれています。

すべてのノードのリストをフィルター処理して、コンテナグループをスケジュールできるノードのリストを取得します (たとえば、PodFitsResources フィルターは、候補ノードにコンテナグループの特定のリソース要求を満たすのに十分な使用可能なリソースがあるかどうかを確認します)。
最初のステップで取得したノードリストにスコアを付けて並べ替え、最適なノードを選択します。最高スコアを持つノードが複数ある場合、ラウンドロビンプロセスにより、コンテナグループがすべてのノードに均等にデプロイされます。

スケジュールを決定する際に考慮すべき要素は次のとおりです。

コンテナグループはハードウェア/ソフトウェアリソースを要求しますか?ノードはメモリまたはディスクの負荷を報告しますか?
ノードには、コンテナグループ仕様のノードセレクターと一致するラベルがありますか?
コンテナグループが特定のホストポートへのバインドを要求した場合、そのポートは使用可能でしょうか?
コンテナグループはノード汚染を許容しますか?
コンテナグループでは、ノードアフィニティルールまたは非アフィニティルールが指定されていますか?

スケジューラは、選択したノードにコンテナグループを実行するように指示しません。スケジューラが行うことは、API サーバーを通じてコンテナグループ定義を更新することだけです。次に、API サーバーは、監視メカニズムを通じて、コンテナグループがスケジュールされたことを kubelet に通知します。その後、ターゲットノード上の kubelet サービスは、コンテナグループがそのノードにスケジュールされたことを確認し、コンテナグループを作成して実行します。

ワーカーノードのコンポーネント

ワーカーノードは kubelet エージェントを実行し、コントロールプレーンがそれらを受け入れて負荷を処理できるようにします。コントロールプレーンと同様に、ワーカーノードはこれを実現するためにいくつかの異なるコンポーネントを使用します。次のセクションでは、ワーカーノードのコンポーネントについて説明します。

クベレット

Kubelet は、クラスター内のすべてのノードで実行され、ワーカーノードで実行されるすべてのものを担当するエージェントです。コンテナがポッド内で実行されていることを確認します。

kubelet サービスの主な機能は次のとおりです。

API サーバーにノードリソースを作成して、実行中のノードを登録します。
API サーバー上のノードにスケジュールされたコンテナグループを継続的に監視します。
構成されたコンテナランタイムを使用して、コンテナグループのコンテナを起動します。
実行中のコンテナを継続的に監視し、そのステータス、イベント、リソース消費量を API サーバーに報告します。
コンテナの生存検出を実行し、検出に失敗した場合はコンテナを再起動し、コンテナグループが API サーバーから削除されたら終了します (コンテナグループが終了したというメッセージをサーバーに通知します)。

サービスエージェント

サービスプロキシ (kube-proxy) は各ノードで実行され、1 つのコンテナグループが別のコンテナグループと通信できること、1 つのノードが別のノードと通信できること、1 つのコンテナが別のコンテナと通信できることを保証します。これは、API サーバーを監視してサービスおよびコンテナグループ定義の変更を検出し、ネットワーク構成全体を最新の状態に保つ役割を担います。サービスが複数のコンテナグループによってサポートされている場合、プロキシはそれらのコンテナグループ間で負荷分散を実行します。

kube-proxy は、実際には接続を受け入れてコンテナグループにプロキシするプロキシサーバーであるため、プロキシと呼ばれます。現在の実装では、iptables ルールを使用して、実際のプロキシサーバーを経由せずに、ランダムに選択されたバックエンドコンテナーのグループにパケットをリダイレクトします。

仕組みの概要:

サービスを作成すると、仮想 IP アドレスがすぐに割り当てられます。
API サーバーは、ワーカーノードで実行されている kube-proxy プロキシに新しいサービスがあることを通知します。
各 kube-proxy は、iptables ルールを設定することでサービスをアドレス指定可能にし、各サービス IP/ポートペアがインターセプトされ、宛先アドレスがサービスをサポートするコンテナグループに変更されるようにします。
API サーバーを監視して、サービスまたはそのエンドポイントオブジェクトの変更を検出します。

コンテナランタイム

コンテナランタイムには 2 つの種類があります。

下位レベルのコンテナランタイム: 主にコンテナの実行と、コンテナの名前空間と cgroup の設定に関係します。
高レベルのコンテナランタイム (コンテナエンジン): フォーマット、解凍、管理、イメージの共有、開発者向け API の提供に重点を置いています。

コンテナランタイムは次の処理を担当します。

コンテナイメージがローカルに存在しない場合は、イメージリポジトリから取得されます。
イメージはコピーオンライトファイルシステムに解凍され、すべてのコンテナーレイヤーが積み重ねられて、マージされたファイルシステムが作成されます。
コンテナのマウントポイントを準備します。
上書きコマンド、ユーザーが入力したエントリコマンドなどのコンテナイメージのメタデータを設定し、コンテナが期待どおりに実行されるように SECCOMP ルールを設定します。
プロセス、ネットワーク、ファイルシステムなどの分離をコンテナに割り当てるようにカーネルに指示します。
CPU やメモリの制限など、何らかのリソース制限を割り当てるようにカーネルに指示します。
コンテナを起動するには、システムコール (syscall) をカーネルに渡します。
SElinux/AppArmor が正しく設定されていることを確認してください。

コラボレーション

システムレベルのコンポーネントは連携して動作し、Kubernetes クラスターのすべての部分が目的を達成し、機能を実行できるようにします。 YAML ファイルの編集に深く関わっている場合、リクエストがクラスター全体でどのように伝達されるかを理解するのが難しい場合があります。各要素がどのように組み合わされているかを理解したので、Kubernetes 内で何が起こっているかをより深く理解できるようになり、問題の診断、クラスターの健全性の維持、ワークフローの最適化に役立ちます。

<<: Citrix パフォーマンスの問題をトラブルシューティングする方法

>>: 大人でもわかるGitOps初心者ガイド