Kubernetesの核はコンテナではなくAPIフレームワークである

2013 年に戻りましょう。単純な docker run postgre コマンドで Postgre のような複雑な従来のサービスを実行できるようになったとき、開発者は衝撃を受け、啓示を受けたように感じました。 Docker に代表される実用的なコンテナ技術の出現は、アジャイル インフラストラクチャへの扉が開かれようとしていることも示しています。その後、すべてが急速に発展し始めました。

• アプリケーションを構築および実行するための標準的な方法としてコンテナを採用し始める開発者が増えています。
• 業界では、このカプセル化方式をコンピューティング クラスターに導入し、Kubernetes や Mesos などのオーケストレーターを通じてコン​​ピューティング タスクをスケジュールすることが簡単であることも認識されました。それ以来、コンテナはこれらのスケジューラにとって最も重要なワークロード タイプになりました。

しかし、この記事では、コンテナが Kubernetes の最も重要で価値のある部分ではないこと、そして Kubernetes が広い意味で単なるワークロード スケジューラではないことを説明します。さまざまな種類のワークロードを効率的にスケジューリングすることは、Kubernetes が提供する重要な価値の 1 つに過ぎず、それが成功の理由ではありません。

APIはコアです

「ちょっと待ってください。Kubernetes は単なる API の集まりですか?」

「ごめんなさい、いつもそうなんですよ！」

Kubernetes の成功と価値は、ソフトウェア定義のインフラストラクチャ サービス (この記事で言及されている「インフラストラクチャ」は IaaS よりも大規模です) を記述および使用するために使用できる標準プログラミング インターフェイス (API) を提供することにあります。

• 仕様 + 実装は完全な API フレームワークを形成し、さまざまなタイプとサイズのインフラストラクチャ サービスを設計、実装、使用するために使用されます。
• これらの API はすべて、同じコア構造とセマンティクスに基づいています。つまり、型指定されたリソースがコントローラーによって監視および調整されます (リソースは型ごとに分割され、コントローラーは対応する型のリソースを監視し、実際のステータスを仕様で想定されるステータスに調整します)。

これをさらに説明するために、Kubernetes 以前のシナリオを考えてみましょう。

Kubernetes以前: 各ベンダーが独自の車輪を再発明し、パッケージベンダーは異なるAPIを持っていた

Kubernetes 以前のインフラストラクチャは、基本的にさまざまな API、フォーマット、セマンティクスを備えた「クラウド」サービスの寄せ集めでした。

• クラウドベンダーは、コンピューティングインスタンス、ブロックストレージ、仮想ネットワーク、オブジェクトストレージなどの基本的な構成要素のみを提供します。開発者は、比較的完全なインフラストラクチャ ソリューションを作成するために、それらをパズルのように組み合わせる必要があります。
• 他のクラウド ベンダーの場合は、プロセス 1 を繰り返します。各クラウド ベンダーの API、構造、セマンティクスは同じではなく、大きく異なる場合もあるためです。

Terraform などのツールの登場により、ベンダー間で共通のフォーマットが提供されていますが、元の構造とセマンティクスは依然として多様であり、AWS 用に記述された Terraform 記述子は Azure では使用できません。

Kubernetes の登場: 標準化されたクロスベンダー API、構造、セマンティクス

それでは、Kubernetes が最初から提供してきたもの、つまりさまざまなリソース要件を記述するための標準 API について見てみましょう。例えば：

• ポッドやコンテナなどのコンピューティング要件を記述する API。
• Service や Ingress などの仮想ネットワーク機能を記述する API。
• ボリュームなどの永続ストレージ用の API について説明します。
• サービス アカウントなどのサービス ID API も含まれています。

これらの API はパブリック/プライベート クラウドおよびクラウド ベンダーにまたがっており、各クラウド ベンダーは Kubernetes の構造とセマンティクスをそれぞれのネイティブ API に接続します。したがって、Kubernetes はソフトウェア定義のインフラストラクチャ (つまり、クラウド) を管理するための標準インターフェースを提供すると言えます。つまり、Kubernetes はクラウド サービスの標準 API フレームワークです。

Kubernetes API 拡張機能: CRD

コア インフラストラクチャ (Pod/Service/Volume/ServiceAccount/…) を宣言するためのベンダー間の標準構造とセマンティクスのセットを提供することが、Kubernetes の成功の基盤となります。これに基づいて、CRD (カスタム リソース定義) を通じてこの構造をあらゆるインフラストラクチャ リソースに拡張します。

CRD は 1.7 で導入され、クラウド ベンダーと開発者は Kubernetes の spec/impl プログラミング フレームワークを独自のサービスに再利用できるようになりました。

CRD を使用すると、ユーザーは Kubernetes API によって事前定義されたコンピューティング、ストレージ、ネットワーク サービスを宣言できるだけでなく、データベース、タスク ランナー、メッセージ バス、デジタル証明書など、クラウド ベンダーが考えつくあらゆるものを宣言できます。

Operator Framework や SIG API Machinery などのプロジェクトの登場により、これらの CRD を簡単に作成および管理できるツールが提供され、ユーザーの作業負荷が最小限に抑えられ、標準化が最大限に高まります。

たとえば、Crossplane などのプロジェクトは、コア Kubernetes コントローラーが独自のコントローラーを使用してネットワーク カードやディスクなどのカスタム リソースを管理するのと同じように、RDS データベースや SQS キュー リソースなどのベンダー リソースを Kubernetes API にマッピングします。 Google や RedHat などの Kubernetes ディストリビューターも、ベース Kubernetes ディストリビューションにカスタム リソース タイプをますます多く含めるようになっています。

まとめ

Kubernetes の中核は API フレームワークであると言われていますが、この API フレームワークが完璧であるという意味ではありません。実際、Kubernetes モデルは事実上の標準となっているため、後者の点は (あまり) 重要ではありません。開発者はそれを理解し、多数のツールが積極的にそれに接続し、主流のメーカーはすでにそれをネイティブにサポートしています。多くの場合、ユーザーの受け入れと相互運用性が、他のどの側面よりも製品の成功を決定します。

Kubernetes リソース モデルの人気が高まるにつれ、Kubernetes リソースのセットを使用してソフトウェア定義のコンピューティング環境全体を記述できるようになりました。 docker run を使用して単一のプログラムを起動するのと同じように、kubectl apply -f を使用して、分散アプリケーションをデプロイして実行できます。その際、プライベート クラウド上にあるか、パブリック クラウド上にあるか、またはどのクラウド ベンダー上にあるかを気にする必要はありません。 Kubernetes API フレームワークはこれらの詳細を保護しています。

したがって、Kubernetes はコンテナではなく API に関するものです。