Kubernetes の定義
Contoso のコンテナー化されたワークロードの調整に関する Kubernetes の適合性を判断するには、Kubernetes のアーキテクチャ、用語、定義に加えて、Kubernetes を使用してストレージとネットワークを管理する方法について理解しておくことが重要です。
Kubernetes の概要
Kubernetes からは、複数のサーバーに展開されたコンテナー化アプリケーションを運用および管理する手段が提供されます。 コンテナーを実行する方法と場所を制御するためのオープンソースのアプリケーション プログラミング インターフェイス (API) が提供され、使用可能なコンピューティング リソースと各コンテナーのリソース要件に基づいて、クラスター化された VM 上でのコンテナーの実行がスケジュールされます。 Kubernetes の重点はアプリケーションのワークロードであって、基になるインフラストラクチャ コンポーネントではありません。
Kubernetes は、コンテナーベースのアプリケーションにとって次のような利点があります。
移植性。 Kubernetes の宣言型アプローチによる配置は、軽量の YAML マニフェスト ファイルを使用して実装されます。 アプリケーションを更新するとき、インフラストラクチャを再設計する必要はありません。
スケーラビリティ。 コンテナーをスケジュールして配置し、必要に応じてスケーリングし、そのライフサイクルを管理することができます。
拡張性。 Kubernetes のオープンソース API を使用すると、好みのプログラミング言語、オペレーティング システム (OS)、ライブラリ、メッセージング バスを使用して、アプリケーションを構築できます。 また、既存の継続的インテグレーションと継続的デリバリー (CI/CD) ツールを統合することもできます。
Kubernetes アーキテクチャ
Kubernetes クラスターは、2 つのコア コンポーネントに分かれています。
ノードつまり "ワーカー ノード" によって、クラスター内でアプリケーションのワークロード (タスク) が実行されます。 クラスターには、通常、コントロール プレーンによって管理される複数のノードが含まれます。 ノードのサブコンポーネントとして、kubelet、kube-proxy、"コンテナー ランタイム" が含まれます。
コントロール プレーンつまり "マスター ノード" により、クラスター内のタスクをスケジュールおよび制御することによってアプリケーションのワークロードを調整するために使用されるコア Kubernetes サービスが提供されます。 コントロール プレーンを構成するコンポーネントとしては、kube-api-server、"コントローラー"、kube-scheduler があります。
注意
現時点では、Kubernetes の "マスター ノード" のホスト OS としてサポートされているのは Linux OS だけです。
各 Kubernetes クラスターには、少なくとも 1 つのコントロール プレーンと、1 つ以上のワーカー ノード インスタンスが含まれています。 ワーカー ノード インスタンスは、Linux OS または Windows Server 2019 のどちらかを基にすることができます。 一般的な Kubernetes ワークロードは、クラスター内の複数のワーカー ノードに分散されている複数のコンテナーで構成されます。
用語と定義
次の表では、Kubernetes の重要な用語をいくつか定義します。
| 期間 | 定義 |
|---|---|
| ポッド | Kubernetes の基本的な操作単位。 コンテナーはポッドにグループ化され、ポッドは目的の状態に合わせてスケーリングされます。 "ポッド" により、その中のコンテナーを実行するための仕様が提供されます。 また、それらのコンテナーによって使用されるストレージとネットワーク リソースの仕様も提供されます。 |
| サービス (service) | これは、抽象化された、つまり論理的なポッドのセットと、それらにアクセスするためのポリシーです。 ポリシーにより、ポッドのセットにアクセスする方法が定義され、ポリシーが適用されるポッドが指定されています。 ポッドの論理セットとポリシーを組み合わせるこのパターンは、"マイクロサービス" と呼ばれることもあります。 |
| コントローラー | Kubernetes リソースの状態に対する変更を追跡し、リソースを目的の状態にします。 ワークロード コントローラーの種類には、ReplicaSet、Deployments、Job、CronJob などがあります。 |
| kubectl | Kubernetes クラスターのコントロール プレーンに接続するためのコマンド ライン インターフェイス (CLI) を提供する管理ツールです。 |
| kubeadm | 最小限の機能とアドオンを使用して、Kubernetes クラスターをすばやく作成するためのツールのセットです。 |
| kubelet | クラスター内の各ノードで実行されるエージェントで、コントロール プレーンからのオーケストレーション要求を処理し、要求されたコンテナーの実行をスケジュールします。 |
| kube-proxy | ネットワーク トラフィックをルーティングし、サービスとポッドの IP アドレスを管理することによって、各ノードの仮想ネットワークを管理します。 |
| コンテナー ランタイム | コンテナー化されたアプリケーションが仮想ネットワークやストレージなどの追加リソースを実行して操作できるようにするためのノード コンポーネントです。 |
| kube-api-server | kubectl や Kubernetes ダッシュボードなどの管理ツールとの対話を可能にするために、基になる Kubernetes API を公開するコントロール プレーン コンポーネントです。 |
| kube-scheduler | ワークロードを実行できるノードを決定し、アプリケーションが起動または作成されたらそれらを開始します。 |
コンテナー、ポッド、ノード
"コンテナー" は "ポッド" 内で実行され、ポッドは "ノード" 内で実行されます。
Containers
コンテナーは、互いに密接に関連し、ディスクなどのリソースを共有する必要がある場合は、1 つの "ポッド" にまとめることによってのみスケジュールする必要があります。
ポッド
ポッド:
- 1 つ以上のコンテナーを保持できます。
- アプリケーションの 1 つのインスタンスを表すために使用されます。
- ポッド内のコンテナーによって共有される、ネットワークやストレージの詳細など、ポッド内のコンテナーを実行する方法の仕様が含まれます。
ポッド テンプレートを使用して、使用するコンテナー イメージやポートなど、ポッドに関する情報を定義できます。
Nodes
ノード:
- 複数のポッドを保持できます。
- クラスターに応じて、仮想マシンまたは物理マシンのいずれかを使用できます。
各ノードは、コントロール プレーンまたは "マスター ノード" によって管理されます。 マスター ノードにより、クラスター内のノード全体でのポッドのスケジュールが管理されます。
ヒント
"ノード アフィニティ" を使用することで、特定のノードに Kubernetes ポッドを割り当てることができます。 これを行うには、kubectl コマンドと .yaml マニフェスト ファイルの組み合わせを使用します。
注意
"サービス" は、実質的には、独自の IP アドレスを持つポッドのコレクションです。
ストレージとネットワーク
コンテナーベースのアプリケーションに関連付けられているネットワークとストレージのコンポーネントも、Kubernetes によって管理されます。
ストレージ
ストレージとして、Kubernetes では "ボリューム" が使用されます。 ボリュームは基本的に、ポッド内のコンテナーがファイルを格納するためにアクセスできるディレクトリです。 Kubernetes のストレージ ボリュームは、2 つの大きなカテゴリに分けることができます。
- "永続ボリューム"。 永続ボリュームにより、Kubernetes リソースとしてストレージ ボリュームが提供されます。 ボリュームとデータはどちらも、コンテナーの再起動後も利用できます。
- "エフェメラル ボリューム"。 エフェメラル ボリュームにより、読み取り専用の入力データ用の一時的なストレージが提供されます。 コンテナーを再起動すると、エフェメラル ボリュームとデータは使用できなくなります。
注意
Kubernetes では、Microsoft Azure データ ディスクをポッドにマウントするための azureDisk、Azure ファイル ボリュームをポッドにマウントするための azureFile、iSCSI など、さまざまな種類のボリュームがサポートされています。
ネットワーク
Kubernetes により、次の領域におけるネットワークのサポートが提供されます。
- コンテナー ネットワーク。 ポッド内のコンテナー間のネットワーク通信に関係します。
- クラスター ネットワーク。 クラスター内のポッド間のネットワーク通信が提供されます。
- サービス (外部)。 クラスターの外部から、ポッドで実行されているアプリケーションにネットワーク アクセスできます。
- サービス (内部)。 クラスター内のリソース間で使用できるネットワーク サービスが指定されています。
前に説明したシナリオでネットワーク通信を実現するには、次のようなコア コンポーネントが Kubernetes でどのように構成されているかを把握しておく必要があります。
- コンテナー:
- コンテナーは、IP アドレスなどのポッド ネットワークの構成を共有します。
- コンテナーは同じポッド内に共有リソースを持ち、同じポッド内の他のコンテナーと通信できます。
- ポッド内のすべてのコンテナーは、ネットワークに関して同じホスト上にあるかのように動作します。
- ポッド:
- すべてのポッドには、独自の一意の IP アドレスがあります。
- 複数サービス:
- すべてのサービスには、独自の仮想 IP アドレスがあります。
- クラスター:
- すべてのクラスター ノードには、通常のクラスター ホストと同じように、独自の IP アドレスがあります。
クラスターからサービスへの通信には、kube-dns および kube-proxy サービスを使用した、サービス IP アドレスからポッド IP アドレスへのルーティングが含まれます。
ポッド間の直接通信 (ポッドからポッドへの接続など) をサポートし、その通信にポリシーを適用できるようにするには、Kubernetes クラスターにコンテナー ネットワーク インターフェイス (CNI) プラグインを追加する必要があります。 CNI は、ネットワーク プラグインに関する業界仕様です。Kubernetes には、この仕様に準拠している多くのプラグインが用意されています。
注意
CNI プラグインにより、ポッドの物理ネットワークの抽象化が作成されます。 その抽象化されたネットワークの仮想的性質により、ポッド ネットワークの構成、操作、自動化が容易になります。 物理ネットワークは "アンダーレイ ネットワーク" と呼ばれ、抽象化された仮想ネットワークは "オーバーレイ ネットワーク" と呼ばれます。