Kubernetesの歴史

今日のITインフラストラクチャーに関して言えば、コンテナ化されたソフトウェア・アプリケーション（アプリ）とサービスの展開、管理、スケーリングを自動化するオープンソースの コンテナ・オーケストレーション・プラットフォームであるKubernetesの役割を過小評価することはできません。

Cloud Native Computing Foundation（CNCF）のレポート（ibm.com外部へのリンク）によると、Kubernetesは、世界で2番目に大きなオープンソース・プロジェクト（首位はLinux）で、Fortune誌が選ぶ世界の上位企業100社の実に71%により主要コンテナ・オーケストレーション・ツールとして選ばれています。Kubernetesがどのようにしてクラウド・コンピューティングとマイクロサービス市場を支配するようになったかを理解するには、その歴史を知る必要があります。

古代ギリシャ語で「パイロット」または「舵取り」（船を操縦する人）を意味するKubernetesの歴史は、Googleの3人のエンジニア（Craig McLuckie、Joe Beda、Brendan Burns）がオープンソースのコンテナ管理システムを構築するアイデアを提案した2013年に遡ります。3人のパイオニアは、Googleの社内インフラストラクチャーに関する専門知識を大規模なクラウド・コンピューティングにもたらす方法を模索していました。また、Googleが当時のクラウド・プロバイダーの中で類を見ないリーダーであったAmazon Web Services（AWS）と競争できるようにする方法を探していました。

従来のITインフラストラクチャーと仮想ITインフラストラクチャーの比較

しかし、Kubernetes（「Kube」または「K8s」とも呼ばれる「数字の略語」（ibm.com外部へのリンク）の歴史を理解するには、従来のITインフラストラクチャーと仮想ITインフラストラクチャーの観点からコンテナを検討する必要があります。

これまで、組織はアプリケーションを物理サーバー（Bare Metal Serverとも呼ばれます） 上でのみ実行していました。しかし、これらのアプリのシステム・リソースの境界を維持する方法がありませんでした。例えば、物理サーバーで複数のアプリケーションを実行している場合、1つのアプリケーションがそのサーバー上の処理能力、メモリー、ストレージ容量、またはその他のリソースをすべて消費する可能性があります。このような事態を防ぐために、企業は各アプリケーションを別の物理サーバーで実行していました。しかし、複数のサーバーでアプリを実行することで、リソースの使用率が低下し、拡張性が低下するという問題が生じます。さらに、多数の物理マシンを所有することは、場所をとり、コストもかかります。

仮想化

その後、クラウド・コンピューティングの基盤となるプロセスである仮想化が登場しました。仮想化テクノロジーは、1960年代後半にまで遡ることができますが、広く採用され始めたのは2000年代初頭になってからでした。

仮想化は、ハイパーバイザーと呼ばれるソフトウェアを使用します。ハイパーバイザーは、単一の物理サーバーのCPU上で複数の仮想マシン（VM）を実行できるようにする軽量のソフトウェアです。各仮想マシンには、ゲスト・オペレーティング・システム（OS）と、OSの実行に必要なハードウェアの仮想コピー、およびアプリケーション、そして関連するライブラリーと依存関係が含まれています。

アプリケーションを実行する際のハードウェア・リソースの使用効率は物理サーバーよりも効率的ですが、それでも大量のシステム・リソースを消費します。これは、同じ物理サーバー上で多数の仮想マシンが実行され、それぞれが独自のゲスト・オペレーティング・システムを持っている場合に特に重要です。

コンテナ

ここで、コンテナ・テクノロジーの登場です。コンテナ開発における歴史的なマイルストーンは、1979年にUnixバージョン7オペレーティング・システムの一部であるchroot（ibm.com外部へのリンク）が開発されたときでした。Chrootは、アプリケーションのファイル・アクセスを特定のディレクトリー（ルート）とその子プロセス（またはサブプロセス）に制限することで、プロセス分離の概念を導入しました。

今日のコンテナは、アプリケーション・コードがライブラリーや依存関係とともにパッケージ化されたソフトウェアの実行可能な単位です。これにより、デスクトップ、プライベート・データセンター、パブリッククラウドなど、オンプレミスでもオフプレミスでも、あらゆる環境でアプリケーションを迅速に実行することができます。

コンテナは、仮想マシン（VM）などの基盤となるハードウェアを仮想化するのではなく、オペレーティング・システム（通常は、LinuxやWindows）を仮想化します。ゲストOSがないため、コンテナは仮想マシンより軽量で、高速かつポータブルです。

2000年代初頭、Googleは成長を続けるインフラストラクチャーをサポートし、パブリックラウド・プラットフォームを提供するために、仮想サーバーから最高のパフォーマンスを引き出す方法を必要としていました。これにより、初の統合コンテナ管理システムであるBorgが開発されました。2003年から2004年にかけて開発されたBorgシステムは、スタートレックのエイリアン、Borgにちなんで命名されました。Borgは、「ザ・コレクティブ」と呼ばれる集合意識（集団意識）を共有することによって機能するサイバネティック・オーガニズムです。

Borgという名前は、Googleのプロジェクトにぴったりでした。Borgの大規模クラスター管理システムは、基本的に、データセンター全体でコンテナ化されたワークロードを実行するための中心的な頭脳として機能します。Googleの検索エンジンとともに動作するように設計されたBorgは、Gmail、Google Docs、Google Search、Google Maps、YouTubeなどのGoogleのインターネット・サービスを構築するために使用されました。

Borgにより、Googleは、さまざまなアプリケーションから多くのマシンにわたって、数十万のジョブを実行できるようになりました。これにより、Googleは大規模なワークロードに対して高いリソース使用率、フォールト・トレランス、拡張性を実現しました。Googleでは、現在でもBorgが同社の主要な内部コンテナ管理システムとして使用されています。

2013年、Googleは、第2世代のコンテナ管理システムであるOmegaを導入しました。Omegaは、Borgのエコシステムをさらに推し進め、大規模なコンピューター・クラスター用に柔軟でスケーラブルなスケジューリング・ソリューションを提供しました。Kubernetesの歴史において重要な役割を果たすDockerが登場したのも2013年でした。

Dockerは、Platform-as-a-Service（PaaS）テクノロジー企業であるdotCloudによって開発され、オンライン・ソフトウェア開発者がコンテナ化されたアプリケーションを構築、展開、管理できるようにするオープンソース・ソフトウェア・ツールとして、2013年にリリースされました。

Dockerのコンテナ技術では、Linuxカーネル（オペレーティング・システムの基本コンポーネント）とカーネルの機能を使用してプロセスを分離し、独立して実行できます。混乱を避けるために、Dockerという同名はDocker, Inc.（旧称dotCloud、ibm.com外部へのリンク）も指します。同社は、オープンソースのコンテナ化プラットフォームを中心に構築された生産性向上ツール、およびDockerオープンソース・エコシステムとコミュニティー（ibm.com外部へのリンク）を開発しています。

Dockerは、軽量なコンテナ・ランタイムを普及させ、アプリケーションをパッケージ化し、配布し、マシンに展開する簡単な方法を提供することで、Kubernetesの創設者に種とインスピレーションを与えました。Dockerが登場したとき、Google社員のCraig McLuckie、Joe BedaとBrendan Burnsは、個々のコンテナを構築して個々のマシンで実行できるDockerの機能に興奮していました。

Dockerは、クラウドネイティブ・インフラストラクチャーの環境を一変させましたが、単一ノードで実行するように構築されていたため、自動化が不可能という制約がありました。例えば、アプリが何千もの個別のコンテナ用に構築されると、さまざまな環境でアプリを管理することが困難になり、個々の開発を手動でパッケージ化する必要がありました。Googleのチームは、複数のマシン間で複数のコンテナを展開および管理できるコンテナ・オーケストレーターが必要であり、チャンスでもあると考えました。こうして、Googleの第3世代のコンテナ管理システムであるKubernetesが誕生しました。

Kubernetesの開発者の多くはBorgの開発に携わっており、BorgとOmegaシステムの設計と開発を通じて学んだことを組み込んだコンテナ・オーケストレーターを構築し、ユーザー・フレンドリーなインターフェース（UI）を備えた、それほど複雑ではないオープンソース・ツールを開発したいと考えていました。Borgへのオードとして、『スタートレック：ヴォイジャー』の登場人物で元ボーグ・ドローンにちなんで「Project Seven of Nine」と名付けました。元のプロジェクト名は定着しませんでしたが、Kubernetesのロゴ（ibm.com外部へのリンク）の7つの点に反映されることになりました。

Kubernetesアーキテクチャーは、複数のマシンや環境にわたってコンテナを実行できるようにする実行クラスターで構成されています。通常、各クラスターは、2つのクラスのノードで構成されています。

• コンテナ化されたアプリケーションを実行するワーカー・ノード
• クラスタを制御するコントロール・プレーン・ノード

コントロール・プレーンは基本的にKubernetesクラスターのオーケストレーターとして機能し、いくつかのコンポーネントが含まれます。 API サーバー（Kubernetesとのすべてのやりとりを管理）、コントロール・マネージャー（すべての制御プロセスを処理）、クラウド・コントローラー・マネージャー（クラウド・プロバイダーのAPIとのインターフェース）などです。ワーカー・ノードは、Dockerなどのコンテナ・ランタイムを使用してコンテナを実行します。ポッドはクラスター内でデプロイ可能な最小単位であり、1つまたは複数のアプリ・コンテナを保持し、ストレージやネットワーク情報などのリソースを共有します。

2014年、KubernetesはBorgのオープンソース・バージョンとして登場し、Microsoft、RedHat、IBM、DockerがKubernetesコミュニティーの初期メンバーとして参加しました。このソフトウェア・ツールには、次のようなコンテナ・オーケストレーションの基本的な機能が含まれていました。

• アプリケーションの複数のインスタンスをデプロイするための複製
• 負荷分散とサービス検出
• 基本的な正常性チェックと修復
• 多数のマシンをグループ化し、作業を分散するスケジュール設定

2015年、O'Reilly Open Source Convention（OSCON）（ibm.com外部へのリンク）にて、Kubernetesの開発者は、Kubernetesの拡張および改良版であるKubernetes 1.0を発表しました。その後すぐに、Red Hat OpenShiftチームの開発者がGoogleのチームに加わり、エンジニアリングとエンタープライズの経験をプロジェクトに役立てました。

2015年のKubernetes 1.0のリリースに合わせて、Googleは非営利のLinux Foundationの一部であるCloud Native Computing Foundation（CNCF）（ibm.com外部へのリンク）にKubernetesを寄贈しました。CNCFは、Docker、Google、Microsoft、IBM、Red Hatなど、世界有数のコンピューティング企業のメンバーによって共同で設立されました。CNCFのミッション（ibm.com外部へのリンク）は、「クラウドネイティブ・コンピューティングをユビキタスにする」ことです。

2016年、KubernetesはCNCFが最初にホストするプロジェクトとなり、2018年までにCNCFの最初の卒業プロジェクトとなりました。積極的に貢献している企業の数は急速に増加し、メンバーは700名を超え、Kubernetesは瞬く間に歴史上最も急速に成長しているオープンソース・プロジェクトの1つになりました。2017年までに、 Docker Swarm やApache Mesosなどの競合他社を凌駕し、コンテナ・オーケストレーションの業界標準になりました。

クラウドが登場する前は、ソフトウェア・アプリケーションは稼働中のハードウェア・サーバーに関連付けられていました。しかし、2018年、Kubernetesとコンテナがクラウド販売組織の管理標準になるにつれ、クラウドネイティブ・アプリケーションの概念が定着し始めました。これにより、クラウド・ベースのソフトウェアの研究開発への扉が開かれました。

Kubernetesは、クラウドネイティブのマイクロサービス・ベースのプログラムの開発を支援し、既存のアプリのコンテナ化を可能にして、アプリ開発を高速化します。Kubernetesは、複数のアプリケーションを同時に効率的に管理するために必要な自動化とオブザーバビリティーも提供します。Kubernetesの宣言型でAPI駆動型のインフラストラクチャーにより、クラウドネイティブ開発チームは独立して運用し、生産性を向上させることができます。

Kubernetesの歴史と、コンテナ化されたワークロードとマイクロサービスを管理するための移植可能で拡張可能なオープンソース・プラットフォームとしてのその役割は、進化し続けています。

Kubernetesが2016年にCNCFに寄贈されて以来、コントリビューターの数は8,012人と、実に996%も増加しました（ibm.com外部へのリンク）。CNCFの主要国際会議であるKubeCon + CloudNativeCon（ibm.com外部へのリンク）は、何千人もの参加者を集め、Kubernetesやその他のDevOpsのトレンドに関する開発者とユーザーの情報とインサイトを提供する年次フォーラムです。

クラウド・トランスフォーメーションとアプリケーションのモダナイゼーションの面では、Kubernetesの導入が減速する兆候は見られません。Gartner のレポート「コンテナーとKubernetesのCTO向けガイド」（ibm.com外部へのリンク）によると、2027年までに世界の組織の90%以上がコンテナ化されたアプリケーションを本番環境で稼働させる見込みです。

2014年当時、IBMはKubernetesオープンソース・コミュニティーと手を組み、コンテナ・オーケストレーションを企業に導入した最初の大企業の一つでした。今日では、IBMは、Kubernetesのコンテナ・オーケストレーションやその他のクラウド・ベースの管理ソリューションの導入により、企業の継続的なクラウド・ジャーニーを支援しています。

クラウドネイティブ・アプリケーション開発、大規模なアプリのデプロイメント、マイクロサービスの管理など、貴社の目標がどのようなものであっても、Kubernetesとその豊富なユースケースの活用をお手伝いします。

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

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