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 つのステップに分かれています。

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

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

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

スケジューラは、選択したノードにコンテナ グループを実行するように指示しません。スケジューラが行うことは、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 内で何が起こっているかをより深く理解できるようになり、問題の診断、クラスターの健全性の維持、ワークフローの最適化に役立ちます。