コンテナ はアプリケーション・ソース・コーロをあらゆる環境でコードを実行するのに必要なすべての オペレーティング・システム （OS）ライブラリーや 依存関係 と組み合わせる、軽量で実行可能なアプリーション・コンポーネントです。

コンテナは、 オペレーティング・システム （OS） 仮想化を提供することで、 プロセスを分離し、各プロセスがアクセスできる  CPU、メモリー、ディスクの量を制御して、複数のアプリケーションがOSの単一インスタンスを共有できるようにします。 コンテナは 仮想マシン （VM）よりも小さく、リソース効率がよく、持ち運びしやすいものなので、現代の クラウドネイティブ ・アプリケーション の 事実上の コンピューティング ・ユニットとなりました。

最近のIBMの調査  （PDF、1.4MB） では、ユーザーはコンテナやそれに関連するテクノロジーを採用したことに結果として、技術面およびビジネス面でいくつかの特定のメリットを享受したと報告しています。 

コンテナ、仮想マシン、従来型インフラストラクチャーの対比

コンテナをITインフラストラクチャーの自動化および抽象化の一連の流れの最新形として理解するほうが、わかりやすいかもしれません。

従来のインフラストラクチャーでは、アプリケーションは物理サーバー上で稼働し、取得可能なすべてのリソースを排他的に使用します。 この場合、1 つのアプリケーションが他のアプリケーションの分までリソースを占有することがないようにと願いながら単一サーバー上で複数のアプリケーションを実行することを選ぶか、リソースの無駄と拡張性の欠如をふまえた上でアプリケーションごとに専用サーバーを割り当てることを選ぶかの、いずれかとなります。

仮想マシン（VM）は、実際のコンピューター・ハードウェアを抽象化したサーバーであり、これにより、ユーザーは単一の物理サーバー上にある複数の VM または複数の物理サーバーをまたがる単一の VM を実行できるようになります。 各VMはそれぞれ固有のOSインスタンスを実行しており、各アプリケーションをそれぞれ固有のVM内に分離できるため、基盤となる同じ物理ハードウェアで実行されているアプリケーション同士が相互に影響し合う可能性が低下します。 VMはリソースをより有効に使用するため、従来のインフラストラクチャーと比べて、規模の拡大がはるかに容易で、コスト効率も高まります。 また、VM は廃棄可能です。アプリケーションを実行する必要がなくなったら、VMを削除すればよいのです。

VM に関するその他の情報については、「仮想マシン：基本ガイド」を参照してください。

コンテナは、この抽象化をより高いレベルに引き上げたものです。具体的には、基礎となる仮想化ハードウェアを共有するだけでなく、基礎となる仮想化された OS カーネルも共有します。 コンテナは、VMと同様に、分離機能、拡張性、廃棄可能性を備えていますが、自身のOSインスタンスのペイロードを維持しないため、VMよりも軽量です（つまり、占有スペースが少なくなります）。 また、コンテナはより優れたリソース効率を実現します。つまり、より多くのアプリケーションをより少ないマシン（仮想マシンと物理マシン）で実行することができ、OSインスタンスの数も少なくてすみます。 コンテナは、デスクトップ、データセンター、クラウド環境の間で、より簡単に移植できます。 また、アジャイルおよび DevOps プラクティスに最適です。

「コンテナ: 基本ガイド」では、コンテナとコンテナ化についての説明を網羅しています。 また、「コンテナとVM: その違い」というブログ記事では、違いを列挙してあります。

Dockerとは

Dockerは、Linux®コンテナを作成して実行するために頻繁に利用されているツールです。 コンテナの初期の形式は、数十年前から（FreeBSD JailsやAIX Workload Partitionsなどの技術で）導入されていましたが、2013年に、開発者にとって使いやすく、クラウドで利用しやすい、Dockerの新たな実装が公開されたことで、コンテナは一般に普及していきます。

Dockerはもとはオープンソース・プロジェクトでしたが、今日ではDockerの開発元の会社であるDocker Inc.のことも指します。Dockerとは、オープンソース・プロジェクトを基に構築されている商用のコンテナ・ツールキットです（そして、その改良は、オープンソース・コミュニティーに還元されています）。

Dockerは、従来のLinuxコンテナ（LXC）テクノロジーに基づいて構築されていますが、Linuxカーネル・プロセスのきめの細かい仮想化を可能にするとともに、コンテナの作成、デプロイ、管理、保護をより簡単にする機能を開発者に提供します。

今日、Dockerの代替コンテナ・プラットフォーム（Open Container Initiative（OCI）、CoreOS、Canonical（Ubuntu）LXDなど）は存在するものの、事実上、コンテナと言えばDockerを指すと言っても過言ではないほど、Dockerは非常に広く採用されています。また、Kubernetesなどの無料の技術と誤解されることもあります。詳細は、以下にあるビデオ「KubernetesとDocker：二者択一の関係でないもの」をご覧ください。

Kubernetesアーキテクチャーの主要コンポーネントには、以下のものがあります。

クラスターとノード（コンピュート）

クラスター は、Kubernetesアーキテクチャーのビルディング・ブロックです。 クラスターは ノードで構成され、各ノードは単一の 計算 ホスト（仮想マシンまたは物理マシン）を表します。

各クラスターは、クラスターのコントロール・プランとして機能する マスター・ノード と、コンテナ化された アプリケーションをデプロイ、実行、管理する 複数の ワーカー・ノード で構成されています。 マスター・ノードは、開発者が設定したデプロイメント要件と使用可能なコンピュート能力に基づいて、コンテナをいつどこにデプロイするのかを 自動化する スケジューラー・サービスを実行します。 各ワーカー・ノードには、 Docker などのコンテナの管理に使用されるツールと、マスター・ノードからの命令を受信して実行する Kubelet というソフトウェア・エージェントが含まれています。

開発者は、 Kuvernetes API と直接通信する kubectlという コマンドライン インターフェース（cli）を使用してクラウター運用を管理します。

 Kubernetesクラスターについて深くしるためには、「Kuvernetesクラスター：迅速で制御されたクラウド・アプリ配信のためのアーキテクチャ」」というこのブログ記事を参照してください。

ポッドとデプロイメント（ソフトウェア）

ポッドは、同じコンピュート・リソースと同じネットワークを共有するコンテナのグループです。 それらは、Kubernetes内で拡張性の単位でもあります。ポッド内のコンテナが、取り扱い可能量よりも渋滞してきたら、Kuberenetesはクラスター内の他のノードにポッドを複製します。 このため、リソースを共有する必要があるコンテナのみが含まれるように、ポッドをコンパクトにすることをお勧めします。

デプロイメントは、コンテナ化されたアプリケーションの作成と状態を制御し、それを実行し続けます。 また、クラスター上で実行されるポッドのレプリカの数を指定します。 ポッドに障害が発生した場合、デプロイメントによって新しいポッドが作成されます。

Kubernetesのデプロイの詳細については、「Kubernetesのデプロイ：迅速な開始」をご覧ください。

Kubernetesは、ポッドをデプロイおよび拡大できますが、ポッド間の経路を管理または自動化することはできず、ポッド間の接続を監視、保護、デバッグするツールも提供しません。 クラスター内のコンテナ数が増えるにつれて、それらコンテナ間を結ぶことができるパスの数は飛躍的に増化します（例えば、2つのコンテナに存在し得る接続は2つですが、10個のポッドではそれが90個になります）。これにより、構成と管理が非常に困難になるおそれがあります。

Kubernetesクラスターのオープンソースのサービス・メッシュ・レイヤーであるIstioを入力してください。 各Kubernetesクラスターに対し、Istioは、サイドカー・コンテナを追加します。基本的にこれをプログラマーや管理者が意識することはありません。このサイドカー・コンテナが、他のコンテナ間の対話を構成、監視、管理します。

Istioを使用すると、コンテナ間の接続を構成する単一のポリシーを設定することができ、それぞれの接続を個別に構成する必要がありません。 これにより、コンテナ間の接続をより簡単にデバッグできるようになります。

また、Istioにはダッシュボードが用意されており、DevOpsチームや管理者はダッシュボードを使用して、コンテナ間の接続について、レイテンシー、サービス時間に関するエラー、その他の特性を監視できます。 さらに、Istioにはセキュリティー（具体的には、権限のないユーザーがコンテナ間の サービス呼び出しをスプーフィングできないようにするID管理）と、認証、許可、および監査（AAA）の機能が組み込まれています。これらを使用して、セキュリティーの専門家はクラスターを監視することができます。

Istioの詳細や動画、使用例については、記事「Istioとは」をご覧ください。

Knative（ケイネイティブ）は、Kubernetes上で稼働するオープンソース・プラットフォームです。クラウドネイティブな開発のために、以下の2つに分類される重要なメリットをもたらします。

Knativeはサーバーレス・コンピューティングへの移行を容易にする

サーバーレス・コンピューティングは、クラウドネイティブ・アプリケーションの効率とコスト効果を高めるコードをデプロイする比較的新しい方法です。 要求の待機中にアイドル状態になっている進行中のインスタンス・コードをデプロイする代わりに、サーバーレスは 必要に応じてコードを起動し（需要の変動に応じてスケールアップまたはスケールダウンさせます）、コードが使用されなくなったら終了させます。 サーバーレスでは、コードが実際に実行された時間に対してのみ課金されるので、コンピューティング容量と電力を節約し、コストを削減できます。

Knativeでは、開発者がコンテナを1度作成すれば、そのコンテナをソフトウェア・サービスまたはサーバーレス機能として実行できます。 Knativeは開発者に対して透過的なものです。Knativeは詳細をバックグラウンドで取り扱い、開発者はコードに焦点を当てられます。

Knativeはコンテナの開発とオーケストレーションを簡素化する

開発者にとって、コードのコンテナ化は多くの反復ステップを要する作業となります。また、コンテナのオーケストレーションには、数多くの構成とスクリプト作成の作業（構成ファイルの生成、依存関係のインストール、ロギングとトレースの管理、継続的なインテグレーション／継続的なデプロイメント（CI/CD）スクリプトの記述）も必要となります。

Knativeは、以下の3つのコンポーネントによる自動化によって、これらのタスクをより簡単にします。

• ビルド： Knativeのビルド・コンポーネントは、 ソースコード を自動的にクラウドネイティブなコンテナまたは関数に変換します。 具体的には、リポジトリーからコードをプルし、必要な 依存関係をインストールして、 コンテナ・イメージをビルドしたうえで、他の開発者が使用できるようにそれをコンテナ・レジストリーに配置します。 Knativeがコンポーネントを検出できるようにするために、開発者はコンポーネントの場所を指定する必要がありますが、一度指定すると、Knativeはビルドを 自動的に 行います。
• サーブ： サーブ・コンポーネントは拡張可能なサービスとしてコンテナを実行します。サーブ・コンポーネントは 数千 ものコンテナ・インスタンスに拡大したり、０まで縮小（ ゼロに基準化と呼ばれています）したりできます。 さらに、サーブには2つの非常に便利な機能があります。 構成はコンテナを実働へと押し出す度にコンテナのバージョンを保存し、（ スナップショットと呼ばれています）それらのバージョンを同時に実行できるようにします。 サービス ルーティングは、異なる量のトラフィックをこれらのバージョンへ伝えることを可能とします。 これらの機能を組み合わせて使用すると、コンテナのロールアウトを段階的に実行したり、 コンテナ化されたアプリケーション のカナリア・テストをステージングしたりしてから、コンテナをグローバルな運用に配置できます。
• イベント： イベントにより、指定されたイベントがコンテナ・ベースのサービスまたは関数をトリガーするようにできます。 これは、特にKnativeの サーバーレス 機能にとって不可欠なものです。ある機能が必要になった場合に、その機能を起動するようシステムに指示する必要があります。 イベントにより、チームは特定のイベント・タイプに対して「興味」を示すことができます。そうすると、イベントがイベント・プロデューサーに自動的に接続してイベントをコンテナにルーティングするので、これらの接続をプログラムする必要がなくなります。

「Knaive：基本ガイド」を読むと、Knativeの詳細を学べます。

Kubernetesは、オープンソース・プロジェクトの歴史で最も急速な成長を遂げたものの1つであり、この成長はいまも加速しています。 Kubernetesを採用する開発者と企業の間で、採用件数は急増し続けています。 注目すべきデータ・ポイントをいくつか示します。

• これを書いている時点で、過去18か月で34,000件近くのコミットが増え、120,190件を超えるコミットが GitHub上の Kubernetesレポジトリー （ibm.comへのリンク）上に作成されました。また、プロジェクトへアクティブなコントリビューターは、3,100を超えます  Cloud Native Computing Foundation （CNCF） によりと、すべてのKubernetes関連リポジトリ（Kubernetes DashboardとKubernetes MiniKubeを含む）全体で148,000件を超えるコミットが存在しています。 すべての統計は ここ （ibm.com外へのリンク）を参照してください。
• 2,000社を超える企業が、自社の実動ソフトウェア・スタックにKubernetesを使用しています。 これには、AirBnB社、Ancestry社、Bose社、CapitalOne社、Intuit社、Nordstrom社、Philips社、Reddit社、Slack社、Spotify社、Tinder社、そして、もちろんIBMなど、世界的に有名な企業が含まれます。 これらとその他の採用事例をお読みください。（ibm.com 外へのリンク）
• Container Journalで引用された2021年の 調査（ibm.com外へのリンク）によると新型コロナウイルスのパンデミックの最中に、IT専門家の68%はよりKubernetesを使うようになったことが分かりました。
• ZipRecruiter（ibm.com外へのリンク）によると、Kubernetes関連の職業の平均年俸 （北アメリカ）は147,732米ドルです。 この記事を書いている現時点で、57,000 件を超えるKubernetes関連のポジションがLinkedIn（ibm.com外へのリンク）にリストされていますが、たった18か月前にリストされていたのは21,000件でした。

Kubernetes を使い始める準備ができている場合やKubernetesおよびKubernetesエコシステム・ツールを使用してスキルの構築を検討している場合は、以下のチュートリアルのいずれかをお試しください。

• Kubernetesチュートリアル：無料の認定付きのハンズオン・ラボ
• Kubernetesチュートリアル：迅速にスキルを構築する5つの方法
• Kubernetesの8つのヒントとコツ
• Kubernetesを使用して、マイクロサービス・アプリケーションをIBM Cloud上にデプロイ
• Kubernetesアプリケーションのデバッグとロギング
• Kubernetesネットワーキング：基本ネットワーキングのコンセプトに基づくラボ
• Istio 101：KubernetesでIstioを使用する方法を学習するためのラボ（ ibm.com外へのリンク）
• Knative 101：Knativeの習得に役立つよう考案された演習

コンテナーは アプリケーションの最新化 と ITインフラストラクチャー最適化に適しています。  KubernetesやオープンソースのKubernetesエコシステム内の他のツールで構築され、IBM Cloudのコンテナー・サービスは クラウドネイティブ アプリケーション開発や、プライベート・クラウド、 パブリック・クラウド 、 オンプレミス のITインフラストラクチャにある優れた機能や関数を統合するオープン・ハイブリッド・クラウド・アプローチへのパスを促進して加速させることができます。

次のステップに進みます：

•  IBM Cloud上の Red Hat OpenShiftを使用してシングル・クリックをすることで、 一元化されたアプリケーション のための可用性が高く、完全管理されたKubernetesクラスターをデプロイする方法を学びましょう。
•  IBM Cloud Satelliteを使って、 コンテナ化されたアプリケーション をあらゆるベンダーの オンプレミス、エッジ・コンピューティング、 パブリック・クラウド 環境全体で絶えずデプロイ、管理します。
•  IBM Code Engineを使って、 コンテナー・イメージ、バッジ・ジョブまたはソース・コードをサーバーレス・ワークロードとして実行します。サイジング、 デプロイ、ネットワーキング、スケーリングは必要とされません。
• IBM Cloud Kubernetes Serviceを使用するネイティブKubernetesエクスペリエンスで、安全で可用性の高いアプリケーションをデプロイします。

すぐに開始するために、 IBM Cloudアカウントのための サインアップ をします。