Kubernetes のアーキテクチャとは
Kubernetes は、クラスタ全体でのサービス検出を可能にする疎結合メカニズムを提供するアーキテクチャです。Kubernetes クラスタには、1 つ以上のコントロール プレーンと、1 つ以上のコンピュート ノードがあります。おおまかな役割として、コントロール プレーンはクラスタ全体の管理、アプリケーション プログラム インターフェイス（API）の公開、望ましい構成に基づくコンピュート ノードの起動とシャットダウンのスケジューリングを行います。各コンピュート ノードは、Docker などのコンテナ ランタイムを実行するほか、コントロール プレーンと通信するエージェントである kubelet を実行します。各ノードは、ベアメタル サーバにすることも、オンプレミスまたはクラウドベースの仮想マシン（VM）にすることもできます。
vSphere with Tanzu 101：vSphere 管理者向け概要
Kubernetes とコンテナに VMware の仮想化が選ばれる理由
Kubernetes のアーキテクチャのコンポーネント
Kubernetes クラスタの主なコンポーネントは次のとおりです。
ノード：ノードは、コンテナ化されたアプリケーションをホストする仮想マシンまたは物理サーバです。クラスタ内の各ノードでは、1 つ以上のアプリケーション インスタンスを実行できます。ノードは 1 つだけにすることもできますが、一般的な Kubernetes クラスタには複数のノードが配置されます（数百以上のノードを含む環境も珍しくありません）。
イメージ レジストリ：コンテナ イメージはレジストリに保持され、コンテナ Pod で実行するためにコントロール プレーンによってノードに転送されます。
Pod：Pod は、コンテナ化されたアプリケーションが実行される場所です。Pod は、1 つ以上のコンテナを保持でき、Kubernetes クラスタでアプリケーションをデプロイするための最小単位になります。
Kubernetes コントロール プレーンのアーキテクチャ
Kubernetes コントロール プレーンは、Kubernetes クラスタを制御するためのレイヤーです。コントロール プレーンのコンポーネントは次のとおりです。
- kube-apiserver：名前からもわかるように、この API サーバは、通信の中心となる Kubernetes API を提供します。CLI やその他のユーザー インターフェイス（UI）を介した外部との通信は kube-apiserver に渡され、すべてのコントロール プレーンとノード間の通信もこの API サーバを経由します。
- etcd：クラスタに関連するすべてのデータが保存されるキー バリュー ストアです。etcd へのすべてのアクセスは API サーバを経由するため、etcd は高い可用性と一貫性が確保されます。etcd 内の情報は全体的に人間が読める YAML（「YAML Ain't Markup Language」の略）形式で記述されています。
- kube-scheduler：新しく作成された Pod は、このコンポーネントによってノードに割り当てられ、リソース要件、ポリシー、「アフィニティ」仕様（位置情報やほかのワークロードとの干渉に関する仕様）に基づいて実行されます。
- kube-controller-manager：Kubernetes クラスタには複数のコントローラ機能がありますが、それらはすべて、kube-controller-manager と呼ばれる単一のバイナリにコンパイルされます。
このプロセスに含まれるコントローラ機能は次のとおりです。
- レプリケーション コントローラ：クラスタ内で実行されているレプリケーションされた各 Pod について、正しい数の Pod が存在するように維持します。
- ノード コントローラ：各ノードの健全性を監視し、ノードがオンラインになったときや応答しなくなったときにクラスタに通知します。
- エンドポイント コントローラ：Pod とサービスを接続して、エンドポイント オブジェクトを生成します。
- サービス アカウントおよびトークン コントローラ：クラスタ内の新しいネームスペースに API アクセス トークンとデフォルト アカウントを割り当てます。
- cloud-controller-manager：クラウド コントローラ マネージャは、クラスタの一部または全体がクラウドベースである場合に、クラスタをクラウド プロバイダーの API にリンクします。クラウド プロバイダーに固有のコントロールのみが実行されます。クラウド コントローラ マネージャは、完全にオンプレミスであるクラスタには存在しません。フォルト トレランスのためや、クラウド全体のパフォーマンスを向上させるために、1 つのクラスタ内で複数のクラウド コントローラ マネージャを実行することもできます。
クラウド コントローラ マネージャの要素は次のとおりです。
- ノード コントローラ：応答しなくなったクラウドベースのノードの状態（ノードが削除されたかどうかなど）を決定します。
- ルート コントローラ：クラウド プロバイダーのインフラストラクチャでルートを確立します。
- サービス コントローラ：クラウド プロバイダーのロードバランサーを管理します。
Kubernetes ノードのアーキテクチャ
Kubernetes では、ノードとは、実行する Pod が配置されるマシン（仮想マシンまたは物理サーバ）です。ノードのコンポーネントは次のとおりです。
kubelet：各ノードには、kubelet と呼ばれるエージェントがあります。このエージェントは、PodSpec に記述されたコンテナが適切に稼働するように維持します。
kube-proxy：各ノードで動作するネットワーク プロキシです。クラスタの内部か外部かを問わず、Pod からネットワーク セッションへの通信を可能にするネットワーク ノードを維持し、利用可能な場合はオペレーティング システム（OS）のパケット フィルタリングを使用します。
コンテナ ランタイム：コンテナ化されたアプリケーションの実行を管理するソフトウェアです。もっとも代表的なものは Docker ですが、Kubernetes では、Kubernetes CRI（Container Runtime Interface）に準拠するすべてのランタイムがサポートされます。
Kubernetes インフラストラクチャのその他のコンポーネント
Pod：Pod は、Kubernetes アプリケーションのもっとも基本的な実行単位であり、1 つ（または複数）のアプリケーション コンテナをカプセル化します。各 Pod には、実行に必要なコードとストレージ リソースが含まれ、一意の IP アドレスが割り当てられます。Pod には構成オプションも含まれます。通常、Pod には 1 つのコンテナか、特定のアプリケーションまたはビジネス機能に統合され、一連のリソースとデータを共有する複数のコンテナが配置されます。
デプロイメント：コンテナ化されたアプリケーション Pod をデプロイする方法です。デプロイメントには望ましい状態が記述されており、コントローラは、順序に則った方法でその状態を実現するためにクラスタの実際の状態を変更します。詳細については、「Kubernetes デプロイメント」をご覧ください。
ReplicaSet：指定された数の同一の Pod が常に実行されるように維持します。
クラスタ DNS：Kubernetes サービスの運用に必要な DNS レコードを提供します。
コンテナ リソース監視：コンテナのメトリックを取得し、中央データベースに記録します。
Kubernetes のアーキテクチャに関するベスト プラクティスと設計原則
Gartner のコンテナ ベスト プラクティスでは、セキュリティ、ガバナンス、監視、ストレージ、ネットワーク、コンテナ ライフサイクル管理、そして Kubernetes のようなオーケストレーションを考慮したプラットフォーム戦略を提案しています。
Kubernetes クラスタを設計する際のベスト プラクティスを以下に示します。
- Kubernetes の最新バージョン（この記事の執筆時点では 1.18）にアップデート済みであることを確認する。
- 開発チームと運用チームのトレーニングに先行投資する。
- 全社的なガバナンスを確立する。ツールやベンダーが Kubernetes オーケストレーションと連携することを確認する必要があります。
- イメージスキャン プロセスを CI/CD プロセスの一部として統合し、ビルドと実行のフェーズでスキャンすることで、セキュリティを強化する。GitHub リポジトリからプルされたオープンソースのコードは、常に疑わしいと考えるべきです。
- クラスタ全体でロールベースのアクセス コントロール（RBAC）を採用する。最小権限のゼロトラスト モデルを標準にする必要があります。
- root 以外のユーザーのみを使用すること、またファイル システムを読み取り専用にすることで、コンテナの保護を強化する。
- デフォルト値の使用は避ける。シンプルな宣言文の方がエラーが少なく、意図をより明確に示すことができます。
- ベーシックな Docker Hub イメージを使用する際には注意する。このようなイメージは、マルウェアを含んでいる場合や、不要なコードで肥大化している場合があります。リーンでクリーンなコードから始め、そこからパッケージを構築していくべきです。小さなイメージは、ビルドが速く、使用するディスク領域が少なく、イメージのプルも速くなります。
- コンテナをシンプルに保つ。各コンテナのプロセスを 1 つにし、その 1 つのプロセスが健全かどうかオーケストレーターを通じて把握します。
- 疑わしい場合は、クラッシュさせる。Kubernetes では障害が発生したコンテナが再起動されるため、障害時に再起動しないようにする必要があります。
- 詳細にする。説明的なラベルは、現在の開発者にとって役立つだけでなく、後に続く開発者にとっても大きな助けとなります。
- マイクロサービスで細分化しすぎない。論理コード コンポーネント内の機能のひとつひとつを別々のマイクロサービスにする必要はありません。
- 効果がある場合は自動化する。CI/CD パイプラインを自動化すると、Kubernetes のデプロイ全体を手動で行う必要がなくなります。
- livenessProbe と readinessProbe を使用して、Pod のライフサイクルを管理する。そうしない場合、Pod が初期化中に終了してしまったり、準備が整う前にユーザー リクエストの受け付けを開始してしまうことがあります。
Kubernetes のアーキテクチャはシンプルでわかりやすくなっています。コントロール プレーンとノード間の結び付きが緩やか（疎結合）であるため、ほぼ無限の柔軟性が実現され、変化するニーズに合わせて実質的に瞬時にアプリケーションをスケールアウトできます。また、ユーザーを新しいビルドに移行することも、オンプレミスからクラウドベースのノードに、またはクラウド間で移行して、各クラウド プロバイダーの必要な機能を利用することも簡単です。
関連するソリューションおよび製品
Kubernetes によるアプリケーションのモダナイゼーション
従来のアプリケーションとモダン アプリケーションを並行して実行可能
Horizon Cloud on Microsoft Azure
クラウドネイティブな仮想デスクトップ プラットフォーム