Kubernetes
Kubernetesは、コンテナ化されたアプリケーションのデプロイメント、管理、スケーリングを自動化する、オープンソースのコンテナ・オーケストレーション・プラットフォームです。
黒と青の背景
Kubernetesとは

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とは

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:二者択一の関係でないもの」(英語)をご覧ください。

Kubernetesによるコンテナ・オーケストレーション

今日では、組織に数百あるいは数千のコンテナがあることも珍しくありません。コンテナが急増するにつれ、運用チームでは、コンテナのデプロイメント、ネットワーキング、拡張性、可用性をスケジュールし自動化する必要がありました。  それにともない、コンテナ・オーケストレーション市場が登場しました。

他のコンテナ・オーケストレーションの選択肢(特にDocker SwarmとApache Mesos)は初めのころはある程度のけん引力を得たものの、Kubernetesがすぐに最も広く採用されるようになっていきました(実際、ある時点では、オープンソース・ソフトウェアの歴史の中で最も急速に成長したプロジェクトとなりました)。

 

開発者は、幅広い機能性、成長し続けるオープン・ソース ・サポート・ツールの大規模なエコシステム、複数のクラウド・サービス ・プロバイダーにわたるサポートと移植性を理由に、Kubernetesを選び続けています。          Amazon Web Services(AWS)、Google Cloud、IBM Cloud、Microsoft Azureなどの大手パブリッククラウド・プロバイダーすべてが、フルマネージドのKubernetesサービスを提供しています。

  

Kubernetesでは何ができるのか

Kubernetesは、以下に挙げるように、アプリケーションのライフサイクルを通じて、コンテナ関連のタスクのスケジューリングと自動化を行います。

   
  • デプロイメント:指定された数のコンテナを指定のホストにデプロイし、それらのコンテナを適切な状態で稼働し続けます。 

  • ロールアウト:ロールアウトはデプロイメントに加える変更です。  Kubernetesにより、ロールアウトの開始、一時停止、再開、またはロールバックが可能です。

  • サービスのディスカバリー:KubernetesはDNS名またはIPアドレスを使用して、コンテナをインターネットまたは他のコンテナに自動で公開できます。    

  • ストレージのプロビジョニング:必要に応じてコンテナ用に永続的なローカル・ストレージまたはクラウド・ストレージをマウントするようにKubernetesを設定します。  

  • ロード・バランシング:CPU使用率またはカスタム・ メトリクスに基づき、Kubernetesのロード・バランシングは、ネットワーク全体でワークロードを分散し、パフォーマンスと安定性を維持します。       

  • 自動スケーリング:トラフィックの急増時に、Kubernetesの自動スケーリングは、必要に応じて新しいクラスターをスピンアップし、追加のワークロードに対処します。   

  • 高可用性のための自己修復:コンテナに障害が発生した場合、Kubernetesはダウンタイムを防ぐために、自動的にコンテナを再始動したり、別のコンテナと交換することができます。     正常性チェックの要件を満たさないコンテナを削除することもできます。

KubernetesとDocker

ここまでお読みいただければ、Kubernetesは、Docker Swarmの代替手段である(英語)が、(いまだによくある誤解とは逆に)Docker自体の代替または競合相手ではないことをすでにご理解いただいていることでしょう。

   

それどころか、Dockerを積極的に採用してDockerベースの大規模なコンテナ・デプロイメントを作成している場合、Kubernetesオーケストレーションこそ、ワークロードを管理するための論理的な次のステップとなります。

詳しくは、「KubernetesとDocker:二者択一の関係でないもの」(英語)をご覧ください。

Kubernetesアーキテクチャー

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

クラスターとノード(コンピュート)

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

  

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

   

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

Kubernetesのクラスターについて詳しくは、「Kubernetesクラスター:迅速かつ制御されたクラウド・アプリケーション・デリバリーのためのアーキテクチャー」をご覧ください。

 

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

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

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

Kubernetesのデプロイメントの詳細については、「Kubernetesのデプロイ:迅速な開始」(英語)をご覧ください。

Istioサービス・メッシュ

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

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

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

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

 
Istioの詳細はこちら
Knativeとサーバーレス・コンピューティング

Knative(ケイネイティブ)は、Kubernetes上にあるオープンソース・プラットフォームであり、クラウドネイティブ開発に2つの重要な利点をもたらします。

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

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

Knativeでは、開発者がコンテナを1度作成すれば、そのコンテナをソフトウェア・サービスまたは サーバーレス機能として実行できます。 開発者はこれらすべてを認識することはありません。つまり、Knativeはバックグラウンドで詳細を処理し、開発者はコードに集中できます。

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

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

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

Build:KnativeのBuildコンポーネントは、ソースコードを自動的にクラウドネイティブなコンテナまたは関数に変換します。    具体的には、リポジトリーからコードをプルし、必要な依存関係をインストールして、コンテナ・イメージをビルドしたうえで、他の開発者が使用できるようにそれをコンテナ・レジストリーに配置します。   Knativeがコンポーネントを検出できるようにするために、開発者はコンポーネントの場所を指定する必要がありますが、一度指定すると、Knativeはビルドを自動的に行います。

  

Serve:Serveコンポーネントは、コンテナをスケーラブルなサービスとして実行します。数千もの コンテナ・インスタンスにスケール・アップすることも、なくなるまでスケール・ダウンすることも可能です(ゼロスケール と呼ばれています)。   さらに、Serveには2つの非常に便利な機能があります。構成 はコンテナを実働にプッシュするたびにコンテナのバージョンを保存(スナップショット と呼ばれます)し、これらのバージョンを同時に実行できるようにします。そして、サービス ルーティング  は、これらのバージョンに対して異なるトラフィック量を指示できるようにします。  これらの機能を組み合わせて使用すると、コンテナのロールアウトを段階的に実行したり、コンテナ化されたアプリケーションのカナリア・テストをステージングしたりしてから、コンテナをグローバルな運用に配置できます。

  

Event:Eventコンポーネントにより、指定されたイベントがコンテナ・ベースのサービスまたは関数をトリガーするようにできます。  これは、特にKnativeのサーバーレス機能にとって不可欠です。ある機能が必要になった場合に、その機能を起動するようシステムに指示する必要があります。   Eventコンポーネントにより、チームは特定のイベント・タイプに対して「興味」を示すことができます。そうすると、Eventコンポーネントがイベント・プロデューサーに自動的に接続してイベントをコンテナにルーティングするので、これらの接続をプログラムする必要がなくなります。

Knativeの詳細はこちら
GitHubのKubernetesリポジトリーへのコミット数など、Kubernetesの人気を実証するいくつかのデータ

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

  • この記事の執筆時点で、GitHub上のKubernetesリポジトリー(英語)(ibm.com外部へのリンク)に対して行われたコミットの数は120,190を超えています。そのうち、過去18カ月の間に34,000近い数のコミットが行われています。また、プロジェクトに対するアクティブなコントリビューターの数は3,100を超えています。    Cloud Native Computing Foundation(CNCF)によると、すべてのKubernetes関連リポジトリー(Kubernetesダッシュボードと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 (英語)(ibm.com外部へのリンク)で引用された2021年の調査によると、新型コロナウイルス感染症のパンデミックの間に、IT専門家の68%のKubernetesの使用が増加したことが分かりました。

  • ZipRecruiter(英語)(ibm.com外へのリンク)によると、Kubernetes関連の職業の平均年俸 (北アメリカ)は147,732米ドルです。 この記事の執筆時点で、57,000 件を超えるKubernetes関連の求人がLinkedIn(ibm.com外部へのリンク)に掲載されていますが、18カ月前の掲載件数は21,000件でした。
  •  
関連ソリューション
Red Hat OpenShift on IBM Cloud

Red Hat OpenShift on IBM Cloudを使用すると、OpenShiftの開発者は、エンタープライズ・ワークロードをKubernetesクラスターにコンテナ化してデプロイするための高速で安全な方法を利用できます。

Red Hat OpenShiftの詳細はこちら
IBM Cloud Satellite

ツールチェーン、データベース、AIを含む一般的な一連のクラウド・サービスを使用して、ベンダーを問わずオンプレミス、エッジコンピューティング、およびパブリッククラウドの各環境にわたり、アプリケーションを一貫してデプロイし実行します。

IBM Cloud Satelliteソリューションの詳細はこちら
IBM Cloud Code Engine

フルマネージドのサーバーレス・プラットフォームであるIBM Cloud Code Engineを使用することで、コンテナ、アプリケーション・コード、またはバッチ・ジョブをフルマネージドのコンテナ・ランタイムで実行することができます。

Code Engineの詳細はこちら
参考情報 企業におけるコンテナ

新しいIBMの調査では、コンテナとKubernetesの採用が急増していることが明らかになっています。

ハイブリッドクラウドに適した柔軟性とレジリエンシーのある安全なIT

コンテナは、どこからでもワークロードの構築と管理を可能にする、ハイブリッドクラウド戦略の一部です。

サーバーレスとは

サーバーレスとは、クラウド・アプリケーションの開発と実行のモデルです。これにより、開発者は、サーバーを管理したり、使用していないクラウド・インフラストラクチャーへの支払いを行ったりせずに、コードを構築して実行できます。

詳細情報はこちら

Red Hat OpenShift on IBM Cloudを使用すると、OpenShiftの開発者は、エンタープライズ・ワークロードをKubernetesクラスターにコンテナ化してデプロイするための高速で安全な方法を利用できます。 可用性の高いフルマネージドのKubernetesクラスターを、お客様のコンテナ化されたアプリケーションに、ワンクリックでデプロイできます。IBMがOpenShift Container Platform(OCP)を管理するため、お客様はコア・タスクに集中できる時間が増加します。

Red Hat OpenShift on IBM Cloudの詳細はこちら