Kubernetes(別称「k8s」、「kube」)は、コンテナ化されたアプリケーションのデプロイメント、管理、スケーリングをスケジューリングして自動化するためのコンテナ・オーケストレーション・プラットフォームです。
Kubernetesは当初、Googleのエンジニアらによって開発され、2014 年にオープンソース化されました。 その前身となったのは、Google社内で使用されていたコンテナ・オーケストレーション・プラットフォームであるBorgです。 Kubernetesは操舵手 またはパイロット を意味するギリシャ語です。そのため、Kubernetesのロゴ(英語)(ibm.com外部へのリンク)には舵輪が描かれているのです。
今日、Kubernetesと、より広範なコンテナ・エコシステムは、最新のクラウド・インフラストラクチャーとアプリケーションのための基本的な構成要素として、仮想マシン(VM)に匹敵する、汎用コンピューティングのプラットフォームとエコシステムへと成長を遂げています。 このエコシステムを活用することで、組織では、生産性の高いPlatform as a Service(PaaS)の実現が可能となっています。PaaSは、クラウドネイティブ開発を取り巻く、インフラストラクチャーと運用に関連したさまざまなタスクや問題に対処します。これにより、開発チームはコーディングとイノベーションのみに集中できるようになります。
次の動画では、Kubernetesの基礎についてご説明します。
コンテナとは、アプリケーション・ソース・コードと任意の環境でそれらのコードを実行するために必要なすべてのオペレーティング・システム(OS)ライブラリー、依存関係を組み合わせた、軽量の実行可能なアプリケーション・コンポーネントです。
コンテナは、オペレーティング・システム(OS)の仮想化を提供することで、プロセスを分離し、各プロセスがアクセスできるCPU、メモリー、ディスクの量を制御して、複数のアプリケーションがOSの単一インスタンスを共有できるようにします。 コンテナは、仮想マシン(VM)よりも小さく、リソース効率が良く、移植性が高いため、最新のクラウドネイティブ・アプリケーションの事実上 の計算ユニットです。
最近のIBMの調査(PDF、1.4 MB)では、コンテナと関連テクノロジーの採用によって、具体的な技術的メリットとビジネス上のメリットが複数得られたことがユーザーによって報告されています。
コンテナは、ITインフラストラクチャーの自動化および抽象化の一連の流れの最新形として理解するほうが、わかりやすいかもしれません。
従来のインフラストラクチャーでは、アプリケーションは物理サーバー上で稼働し、取得可能なすべてのリソースを排他的に使用します。 この場合、1つのアプリケーションが他のアプリケーションの分までリソースを占有することがないようにと願いながら単一サーバー上で複数のアプリケーションを実行することを選ぶか、リソースの無駄と拡張性の欠如をふまえた上でアプリケーションごとに専用サーバーを割り当てることを選ぶかの、いずれかとなります。
仮想マシン(VM)は、実際のコンピューター・ハードウェアを抽象化したサーバーであり、1つの物理サーバー上で複数のVMを実行したり、複数の物理サーバーにまたがる単一のVMを実行したりできます。 各VMはそれぞれ固有のOSインスタンスを実行しており、各アプリケーションをそれぞれ固有のVM内に分離できるため、基盤となる同じ物理ハードウェアで実行されているアプリケーション同士が相互に影響し合う可能性が低下します。 VMはリソースをより有効に使用するため、従来のインフラストラクチャーと比べて、規模の拡大がはるかに容易で、コスト効率も高まります。 また、VMは廃棄可能です。アプリケーションを実行する必要がなくなったら、VMを削除すればよいのです。
VMの詳細については「仮想マシンとは」を参照してください。
コンテナは、この抽象化をより高いレベルに押し上げます。具体的には、基盤となる仮想化ハードウェアの共有に加えて、基盤となる仮想化OSカーネルも共有します。 コンテナは、VMと同様に、分離機能、拡張性、廃棄可能性を備えていますが、自身のOSインスタンスのペイロードを維持しないため、VMよりも軽量です(つまり、占有スペースが少なくなります)。 コンテナはリソース効率が高く、より少ないマシン(仮想および物理)上で、より少ないOSインスタンスで、より多くのアプリケーションを実行できます。 コンテナは、デスクトップ、データセンター、クラウド環境の間で、より簡単に移植できます。 また、アジャイルおよびDevOps開発プラクティスに最適です。
「コンテナとは」で、コンテナとコンテナ化について詳細に説明しています。 そしてブログ記事「コンテナとVM:相違点について」(英語)では、両者の相違点がすべて概説されています。
Dockerは、Linux®コンテナを作成して実行するために最も広く利用されているツールです。 コンテナの初期の形式は、数十年前から(FreeBSD JailsやAIX Workload Partitionsなどの技術で)導入されていましたが、2013年に、開発者にとって使いやすく、かつクラウドで利用しやすい、Dockerの新たな実装が公開されたことで、コンテナは一般に普及していきます。
Dockerはオープンソース・プロジェクトとして始まりましたが、現在、Dockerは、オープンソース・プロジェクト上に構築される商用コンテナ・ツールキットのDockerを提供する(そして、これらの改善によってオープンソース・コミュニティーに貢献する)企業であるDocker社を示す場合もあります。
Dockerは、従来のLinuxコンテナ(LXC)テクノロジーに基づいて構築されていますが、Linuxカーネル・プロセスのきめの細かい仮想化を可能にするとともに、コンテナの作成、デプロイ、管理、保護をより簡単にする機能を開発者に提供します。
今日、Dockerの代替コンテナ・プラットフォーム(Open Container Initiative(OCI)、CoreOS、Canonical(Ubuntu)LXDなど)は存在するものの、事実上、コンテナと言えばDockerを指すと言っても過言ではないほど、Dockerは非常に広く採用されています。また、Kubernetesなどの無料の技術と誤解されることもあります。詳細は、以下にある動画「KubernetesとDocker:二者択一の関係でないもの」(英語)をご覧ください。
今日では、組織に数百あるいは数千のコンテナがあることも珍しくありません。コンテナが急増するにつれ、運用チームでは、コンテナのデプロイメント、ネットワーキング、拡張性、可用性をスケジュールし自動化する必要がありました。 それにともない、コンテナ・オーケストレーション市場が登場しました。
他のコンテナ・オーケストレーションの選択肢(特にDocker SwarmとApache Mesos)は初めのころはある程度のけん引力を得たものの、Kubernetesがすぐに最も広く採用されるようになっていきました(実際、ある時点では、オープンソース・ソフトウェアの歴史の中で最も急速に成長したプロジェクトとなりました)。
開発者は、幅広い機能性、成長し続けるオープン・ソース ・サポート・ツールの大規模なエコシステム、複数のクラウド・サービス ・プロバイダーにわたるサポートと移植性を理由に、Kubernetesを選び続けています。 Amazon Web Services(AWS)、Google Cloud、IBM Cloud、Microsoft Azureなどの大手パブリッククラウド・プロバイダーすべてが、フルマネージドのKubernetesサービスを提供しています。
Kubernetesは、以下に挙げるように、アプリケーションのライフサイクルを通じて、コンテナ関連のタスクのスケジューリングと自動化を行います。
ここまでお読みいただければ、Kubernetesは、Docker Swarmの代替手段である(英語)が、(いまだによくある誤解とは逆に)Docker自体の代替または競合相手ではないことをすでにご理解いただいていることでしょう。
それどころか、Dockerを積極的に採用してDockerベースの大規模なコンテナ・デプロイメントを作成している場合、Kubernetesオーケストレーションこそ、ワークロードを管理するための論理的な次のステップとなります。
詳しくは、「KubernetesとDocker:二者択一の関係でないもの」(英語)をご覧ください。
Kubernetesアーキテクチャーの主要コンポーネントには、以下のものがあります。
クラスター は、Kubernetesアーキテクチャーのビルディング・ブロックです。 クラスターはノード で構成され、各ノードは単一の計算ホスト(仮想マシンまたは物理マシン)を表します。
各クラスターは、クラスターのコントロール・プランとして機能するマスター・ノード と、コンテナ化されたアプリケーションをデプロイ、実行、管理する複数のワーカー・ノード で構成されています。 マスター・ノードは、開発者が設定したデプロイメント要件と使用可能なコンピュート能力に基づいて、コンテナをいつどこにデプロイするのかを自動化するスケジューラー・サービスを実行します。 各ワーカー・ノードには、Dockerなどのコンテナの管理に使用されるツールと、マスター・ノードからの命令を受信して実行するKubelet というソフトウェア・エージェントが含まれています。
開発者は、Kuvernetes APIと直接通信するkubectl というコマンド・ライン・インターフェース(cli)を使用してクラスター運用を管理します。
Kubernetesのクラスターについて詳しくは、「Kubernetesクラスター:迅速かつ制御されたクラウド・アプリケーション・デリバリーのためのアーキテクチャー」をご覧ください。
ポッド は、同じコンピュート・リソースと同じネットワークを共有するコンテナのグループです。 ポッドは、Kubernetesにおける拡張性の単位でもあります。ポッド内のコンテナのトラフィック量が、対応可能な量よりも多くなってきたら、Kubernetesはクラスター内の他のノードにポッドを複製します。 このため、リソースを共有する必要があるコンテナのみが含まれるように、ポッドをコンパクトにすることをお勧めします。
デプロイメント は、コンテナ化されたアプリケーションの作成と状態を制御し、これを実行し続けます。 また、クラスター上で実行されるポッドのレプリカの数を指定します。 ポッドに障害が発生した場合、デプロイメントによって新しいポッドが作成されます。
Kubernetesのデプロイメントの詳細については、「Kubernetesのデプロイ:迅速な開始」(英語)をご覧ください。
Kubernetesは、ポッドをデプロイおよび拡大できますが、ポッド間の経路を管理または自動化することはできず、ポッド間の接続を監視、保護、デバッグするツールも提供しません。 クラスター内のコンテナ数が増えるにつれて、これらのコンテナ間を結ぶことができるパスの数は飛躍的に増化します(例えば、2つのコンテナに存在し得る接続は2つですが、10個のポッドではこれが90個になります)。これにより、構成と管理が非常に困難になるおそれがあります。
Kubernetesクラスター用のオープンソースのサービス・メッシュ・レイヤーであるIstioの説明に移りましょう。 各Kubernetesクラスターに対し、Istioは、サイドカー・コンテナを追加します。基本的にこれをプログラマーや管理者が意識することはありません。このサイドカー・コンテナが、他のコンテナ間の対話を構成、監視、管理します。
Istioを使用すると、コンテナ間の接続を構成する単一のポリシーを設定することができ、それぞれの接続を個別に構成する必要がありません。 これにより、コンテナ間の接続をより簡単にデバッグできるようになります。
また、Istioにはダッシュボードが用意されており、DevOpsチームや管理者はダッシュボードを使用して、コンテナ間の接続について、遅延、サービス時間、エラー、その他の特性をモニタリングできます。 さらに、Istioにはセキュリティー(具体的には、権限のないユーザーがコンテナ間のサービス呼び出しをスプーフィングできないようにするID管理)と、認証、許可、および監査(AAA)の機能が組み込まれています。これらを使用して、セキュリティーの専門家はクラスターをモニターすることができます。
Knative(ケイネイティブ)は、Kubernetes上にあるオープンソース・プラットフォームであり、クラウドネイティブ開発に2つの重要な利点をもたらします。
サーバーレス・コンピューティングは、クラウドネイティブ・アプリケーションの効率とコスト効果を高めるコードをデプロイする比較的新しい方法です。 コードのインスタンスを継続的にデプロイしておき、要求の待機中はアイドル状態となる方法の代わりに、サーバーレスでは必要に応じてコードが起動され、要求の変動に合わせて拡大・縮小されます。その後、使用されなくなったコードは削除されます。 サーバーレスでは、コードが実際に実行された時間に対してのみ課金されるので、コンピューティング容量と電力を節約し、コストを削減できます。
Knativeでは、開発者がコンテナを1度作成すれば、そのコンテナをソフトウェア・サービスまたは サーバーレス機能として実行できます。 開発者はこれらすべてを認識することはありません。つまり、Knativeはバックグラウンドで詳細を処理し、開発者はコードに集中できます。
開発者にとって、コードのコンテナ化は多くの反復ステップを要する作業となります。また、コンテナのオーケストレーションには、数多くの構成とスクリプト作成の作業(構成ファイルの生成、依存関係のインストール、ロギングとトレースの管理、および継続的統合/継続的デプロイメント(CI/CD)のスクリプトの作成など)が必要です。
Knativeは、以下の3つのコンポーネントによる自動化によって、これらのタスクをより簡単にします。
Build:KnativeのBuildコンポーネントは、ソースコードを自動的にクラウドネイティブなコンテナまたは関数に変換します。 具体的には、リポジトリーからコードをプルし、必要な依存関係をインストールして、コンテナ・イメージをビルドしたうえで、他の開発者が使用できるようにそれをコンテナ・レジストリーに配置します。 Knativeがコンポーネントを検出できるようにするために、開発者はコンポーネントの場所を指定する必要がありますが、一度指定すると、Knativeはビルドを自動的に行います。
Serve:Serveコンポーネントは、コンテナをスケーラブルなサービスとして実行します。数千もの コンテナ・インスタンスにスケール・アップすることも、なくなるまでスケール・ダウンすることも可能です(ゼロスケール と呼ばれています)。 さらに、Serveには2つの非常に便利な機能があります。構成 はコンテナを実働にプッシュするたびにコンテナのバージョンを保存(スナップショット と呼ばれます)し、これらのバージョンを同時に実行できるようにします。そして、サービス ・ルーティング は、これらのバージョンに対して異なるトラフィック量を指示できるようにします。 これらの機能を組み合わせて使用すると、コンテナのロールアウトを段階的に実行したり、コンテナ化されたアプリケーションのカナリア・テストをステージングしたりしてから、コンテナをグローバルな運用に配置できます。
Event:Eventコンポーネントにより、指定されたイベントがコンテナ・ベースのサービスまたは関数をトリガーするようにできます。 これは、特にKnativeのサーバーレス機能にとって不可欠です。ある機能が必要になった場合に、その機能を起動するようシステムに指示する必要があります。 Eventコンポーネントにより、チームは特定のイベント・タイプに対して「興味」を示すことができます。そうすると、Eventコンポーネントがイベント・プロデューサーに自動的に接続してイベントをコンテナにルーティングするので、これらの接続をプログラムする必要がなくなります。
Kubernetesは、オープンソース・プロジェクトの歴史で最も急速な成長を遂げたものの1つであり、この成長はいまも加速しています。 Kubernetesを採用する開発者と企業の間で、採用件数は急増し続けています。 注目すべきデータ・ポイントをいくつか示します。
Kubernetesの使用を開始する準備ができている場合 、またはKubernetesやKubernetesエコシステムのツールを使用してスキルの構築を検討している場合は、以下のチュートリアル(英語)のいずれかをお試しください。
Red Hat OpenShift on IBM Cloudを使用すると、OpenShiftの開発者は、エンタープライズ・ワークロードをKubernetesクラスターにコンテナ化してデプロイするための高速で安全な方法を利用できます。
ツールチェーン、データベース、AIを含む一般的な一連のクラウド・サービスを使用して、ベンダーを問わずオンプレミス、エッジコンピューティング、およびパブリッククラウドの各環境にわたり、アプリケーションを一貫してデプロイし実行します。
フルマネージドのサーバーレス・プラットフォームであるIBM Cloud Code Engineを使用することで、コンテナ、アプリケーション・コード、またはバッチ・ジョブをフルマネージドのコンテナ・ランタイムで実行することができます。