ポイント: コンテナはアプリケーションのポータビリティと管理を向上させ、Kubernetesはそれらのデプロイとスケーリングをオーケストレーションします。両者を組み合わせることで、開発プロセスが効率化されます。
- Kubernetesは負荷分散、自己修復、自動スケジューリングなどの機能を提供します。
- 開発者は多様な環境でコンテナ化されたアプリケーションを効率的に管理できます。
アプリケーションコンテナ化はIT業界で標準となっています。これにより、組織や開発者はアプリケーションコードとそのすべての依存関係をポータブルな環境にカプセル化し、アプリをほぼどこにでもデプロイできるようになります。
Kubernetesは、コンテナ化されたアプリケーションの管理に使用できる強力なオープンソースのオーケストレーションサービスです。
この記事では、両方の技術を深く掘り下げ、どのように互いを補完するかを見ていきます。
コンテナの仕組み
コンテナについて学ぶ前に、まずなぜコンテナが設計されたのかを知る必要があります。
従来のアプリ開発では、アプリケーションやサービスが開発されると、次のステップはそれをデプロイすることです。これは複雑で時間がかかるプロセスになる場合があります。それは、成功するアプリデプロイメントには、リソースの割り当てや依存関係の管理から環境変数の設定まで、無数の注意深い設定が必要だからです。
もう一つの考慮事項はアプリケーションのポータビリティです。もし開発者がデプロイ環境を変更したり、新しいクラウドプロバイダーに移動する必要がある場合、彼らは一から再度デプロイプロセスを経なければなりません。これもまた、面倒で時間がかかるプロセスで、次のような問題を引き起こす可能性があります：
- 設定のドリフト
- 本番環境のバグ
コンテナは、アプリケーションコードベースをすべての依存関係（ランタイム、システムツール、設定ファイル、ライブラリなど）と共に「コンテナ」と呼ばれるパッケージにまとめることで、この問題に成功裏に対処します。このコンテナ化は、軽量で安全、かつ不変のパッケージとして知られるコンテナイメージを作成します。
このイメージは、任意の環境にコンテナ化されたアプリケーションをデプロイするために使用でき、開発者は環境の制約を心配することなくアプリケーションを開発する自由を提供します。
コンテナ
コンテナの利点
開発者がコンテナを好む理由はさまざまです：
- 一貫した環境。コンテナ化は、アプリケーションコードと依存関係を1つのパッケージにバンドルすることで一貫した環境を提供します。これにより、開発、テスト、本番環境全体での一貫性が確保されます。
- ユニバーサルな互換性。コンテナは、Windows、Linux、macOSからクラウドプロバイダーやデータセンターまで、事実上どこにでもデプロイできます。サーバーレスデプロイメントもコンテナをサポートしています。
- ポータビリティ。コンテナは、必要なソフトウェアと依存関係が標準化されたコンテナ形式でパッケージ化されているため、ほとんど変更なしで新しい環境に簡単に移動できます。（リフトアンドシフトシナリオを容易に促進します。）
- 隔離。コンテナは、そのコンテナ化された特性と、CPU、メモリ、ストレージ、ネットワークリソースなどの基盤となるオペレーティングシステムリソースのサンドボックス化されたビューにより、外部要因から強力に隔離されています（OSレベルの仮想化）。
- スケーリング。コンテナの軽量性は、迅速なスケーリング能力に寄与します：ユーザーの需要に応じて、限られたリソースでコンテナを簡単に作成および破棄できます。
コンテナと仮想マシン（VM）
コンテナは仮想マシンに似ています。両者は、アプリケーションがすべての依存関係と共にデプロイされる孤立した環境を作成するために使用できます。
しかし、両者の技術には根本的な違いがあります。
仮想マシン
最も単純な形で、VMは基盤となるハードウェアを仮想化し、単一のマシンで複数のオペレーティングシステムを実行するように設計されています。それにより、VMは仮想化された環境（単一のマシン/サーバー）で異なるタイプのオペレーティングシステムを実行できます。このハードウェアを利用するための共有アプローチにより、組織は物理的なハードウェアリソースを効率的かつコスト効果的に管理できます。
VMを作成して管理するには、ハイパーバイザーと呼ばれるソフトウェアが必要です。一般的なハイパーバイザーには、次のようなものがあります：
VMを使用する際の主な欠点はそのサイズです。各仮想マシンにはオペレーティングシステムイメージ、ライブラリ、ソフトウェアなどが含まれているため、すぐに大きなサイズになり、次のような問題を引き起こすことがあります：
- 追加のメンテナンス
- スケーラビリティの問題
VMとは異なり、コンテナは基盤となるオペレーティングシステムを仮想化します。その結果、コンテナは基盤となるオペレーティングシステムのすべてのリソースが利用可能であると見なすことができます。
この共有アプローチを使用すると、各コンテナに別々のOSイメージをホストし、ライブラリを読み込むためにOSを起動する必要がなくなります。これにより、VMに対して次の2つの利点が得られます：
- コンテナの全体的なサイズをVMと比較して大幅に削減
- 単一のサーバーでより多くのコンテナを展開できる
さらに、このコンテナの共有アプローチにより、メンテナンスの必要性が減少します。開発者は基盤となるオペレーティングシステムのみを更新およびパッチする必要があり、各個別のコンテナを更新する必要はありません。
コンテナは、「コンテナランタイム」と呼ばれるソフトウェアを利用して、コンテナを実行および管理します。一般的に使用されるコンテナランタイムには、次のようなものがあります：
コンテナの主な欠点は、定義されたオペレーティングシステムに限定されることです。コンテナは、定義されたオペレーティングシステムでのみデプロイでき、VMでは、ユーザーがLinuxサーバー上でWindowsの仮想マシンを実行したり、その逆を行ったりすることができます。もしコンテナがLinux用に定義されている場合、Linuxでのみデプロイできます。
(詳細な解説を読むには、コンテナとVMを参照してください。
Kubernetesがコンテナを管理する方法
コンテナが何であるかを理解したので、次の論理的なステップはコンテナを管理することです。
まず最初に、すべてのコンテナを手動で管理することが常に可能です。しかし、これはスケーラブルでも効率的でもない解決策です。
その代わりに、Kubernetesを使用できます！Kubernetes、別名K8sは、コンテナ化されたアプリケーションを簡単にデプロイ、管理、およびスケールするためのオープンソースのコンテナオーケストレーションプラットフォームです。
(包括的なKubernetesチュートリアルシリーズを探索してください。
Kubernetesの構造
Kubernetesは、単一のサーバーからマルチサーバーデプロイメントにコンテナ化されたアプリケーションをスケールするための理想的な解決策です。このようなマルチサーバーの分散アプローチはKubernetesクラスターとして知られています。
Kubernetesはコンテナを取得し、異なるサーバー（ノード）間のリソースの可用性に基づいてアプリケーションを配布します。アプリケーションは最終ユーザーには単一のエンティティとして表示されますが、実際には複数のノードで実行される緩やかに結合されたコンテナのグループです。
Kubernetesは、コンテナ化されたアプリに対する組み込みのサポートも提供します。これには次のものが含まれます：
- サービス発見
- 負荷分散
- スケーリング
- ヘルスモニタリング
Kubernetesのコアコンポーネント
Kubernetesは以下のコアコンポーネントで構成されています：
- コントロールプレーン
- ノード
- ポッド
コントロールプレーンは、Kubernetesクラスターの脳であり、スケジューリングからクラスターイベントまでを管理します。コントロールプレーンは、さまざまなコンポーネントで構成されています。たとえば：
- APIサービスを管理するkube-apiserver
- ポッドを対応するノードにデプロイするkube-scheduler
- その他多数
コントロールプレーンコンポーネントは、クラスター内の任意のノードで実行できます。標準的な実践は、コントロールプレーンタスクに単一のインスタンスを関連付けることです。
次のコンポーネントはノードです。ノードは、Kubernetesクラスターのエンドポイントまたはマシンです。これらは、Kubernetesでコンテナがデプロイされる場所です。ノードはコンテナの実行環境を提供する責任があります。
ノードは、次のようなさまざまなコンポーネントで構成されています：
- ネットワークルートを維持するkube-proxy
- コンテナの健康を管理および監視するkubelet
最後の重要なコンポーネントはポッドです。ポッドは、コンテナの論理的なラッパーです。（ポッドはKubernetesでの最小のデプロイ可能コンポーネントでもあります。）K8sポッドは次のいずれかを指します：
- 単一のコンテナ
- 共有リソース（ネットワーキング、ストレージなど）を持つ複数のコンテナ
ポッド内のコンテナは緊密に結合されており、コンテナ化されたアプリケーションのコア機能に不可欠です。
これらの3つのコンポーネントがどのように連携するかをまとめると、コントロールプレーンは、Kubernetesクラスター内のノードにこれらのポッドをリソースの可用性やアプリケーションの負荷に応じて配布します：
- リソースの可用性
- アプリケーションの負荷
基本的なKubernetesデプロイメント
シンプルなKubernetesデプロイメントでは、クラスター全体を管理するためのコントロールプレーン（マスターノード）用の専用サーバーがあります。コントロールプレーン内のコントローラーは、クラスター内のすべてのノードやサービスを管理します。さらに、スケジューリング、APIサービス、状態管理をetcdを使用して行います。
他のサーバーやノードは、コンテナを実行するための実行環境を提供する労働者（ワーカーノード）として機能します。Kubernetesポッドは、リソースの割り当て、管理、スケーリングを容易にするために、単一のエンティティを作成するためにコンテナまたは複数のコンテナをラップします。
(Kubernetesデプロイメントの動作を理解するには、Kubernetesデプロイメントがどのように機能するかを参照してください。
Kubernetesと通常のコンテナランタイム
Kubernetesが通常のコンテナランタイムと異なるのは、コンテナに加えて提供する機能です。その機能のいくつかは次のとおりです：
- 負荷分散。負荷バランサーを作成し、利用可能なポッド間でトラフィックを分配します。
- 自動スケジューリング。最適なパフォーマンスを得るために、ポッドを最も適切なノードに自動的に分配します。
- 水平スケーリング。アプリケーションの要求に応じて、ポッドを迅速にスケールアップまたはダウンします。
- 自己修復。すべてのポッドは常に監視され、障害が発生した場合に自動的に再起動または交換されます。
- ローリングアウト。Kubernetesは、異なるデプロイメント戦略を使用してコンテナ化されたアプリケーションを簡単にデプロイできる管理されたローリングアウトとロールバックを促進します。
コンテナとKubernetesの使用
コンテナとKubernetesは、相互に補完し合う2つの技術です。
開発者として、それらに適応する最も簡単な方法は：
- 孤立したポータブルパッケージとして、マルチプラットフォームの互換性を持つコンテナ化されたアプリケーションを作成します。
- これらのコンテナ化されたアプリケーションをオーケストレーションするために、堅牢で機能豊富なKubernetesプラットフォームを使用します。
これは本質的に、開発者がアプリケーションをKubernetesクラスター内のコンテナとして簡単に維持できることを意味します。開発からデプロイ、メンテナンスまでのアプリケーションライフサイクルを通じて。
各技術が他を補完するため、これら2つの技術の強みを組み合わせることで、より便利で短く、複雑さの少ない開発とデプロイメントプロセスが実現します。
Kubernetesクラスターは、すべての主要なクラウドプロバイダーまたはオンプレミスのデプロイメントでサポートされています。したがって、クラスターを簡単に立ち上げて、わずか数コマンドでアプリケーションをデプロイでき、Kubernetesは負荷分散やスケーリングなどの面倒で時間のかかる管理タスクを処理します。Kubernetesの組み込み機能により、他の外部ツールやサービスに依存することなく、アプリケーション全体を管理できます。
開発者の敏捷性を高める
コンテナとKubernetesは、開発者やデリバリーチームの作業負荷を軽減するために設計された現代の技術です。コンテナはアプリケーションをパッケージ化する標準化された方法を提供し、Kubernetesはそれらを簡単に管理するのを助けます。
コンテナとKubernetesの基本的な概念を理解したので、次のステップはこれらの概念を探求して、完璧なコンテナ化されたアプリケーションを作成することです。まずは私たちのKubernetesチュートリアルシリーズを始めてください。
関連する読み物
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。