IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

Knativeとは何か

こんにちは。IBMのデベロッパー・アドボケイト、Sai Vennamです。今回は、現在のクラウドネイティブ分野において最も成長著しいオープン・ソース・プロジェクトの1つであるKnativeについてお話しましょう。

ビデオをお楽しみください。

Kubernetes上にインストールされたプラットフォーム

Knativeが発表されたのは最近のことです。IBM、Google、その他多くの業界トップのエンジニアによって開発されました。KnativeはKubernetes上にインストールされるプラットフォームで、サーバーレス機能を提供し、Kubernetesでのサーバーレスなワークロードの実行を可能にします。また、クラウドネイティブのアプリをKubernetes上でまさにネイティブ・アプリのように動かせるユーティリティーが数多く備わっています。

Knativeの主要な3つのコンポーネント: Build、Serve、Event

Kubernetes上に構成されるKnativeの主要なコンポーネントが3つあります。 まずBuildです。次にServe。最後にEventです。

これら3つのコンポーネントはPrimitive(プリミティブ)と呼ばれていて、Knativeを構成するビルディング・ブロックです。これらは基本的にKubernetes内でサーバーレス・ワークロードを実行するためのものですが、違和感なく簡単にKnativeを使えるようにするエンドポイントやツールも提供しています。

The three major components of Knative: Build, Serve, and Event

Knative Primitive #1: Build

ではBuildから始めましょう。例を使って説明します。Kubernetesでアプリケーションを使えるようにするために、すべての開発者が行わなければならないことは何でしょう?まずはコーディングですね?開発者全員がコードを持っています。おそらくGitHubにアップされているでしょう。

Knative Primitive #1: Build

次は、このコードをコンテナ化します。コーディングした後、そのコードをコンテナ化する必要があります。Kubernetes、Dockerや、使用するその他のコンテナ・テクノロジーが認識できる形にするということです。

これはdocker buildなどを使用して簡単に行えます。ビルドの複雑さによっては、何段階かの手順を踏んで最終的なコンテナ・イメージを完成させる方法もあります。ところで、このプロセスを実際に実行するには、ローカル・マシンにコードを落とし込むか、TravisやJenkinsのようなツールでコンテナを構築する必要があります。

Knative Primitive #1: Build

さてイメージを作成したら、クラウド・レジストリーにpushします。Docker Hubやプライベートのイメージ・レジストリーなどです。そうすることでKubernetesが検索、デプロイできるようになります。そのためにはYAMLでマニフェスト・ファイルを作るとよいでしょう。デプロイの複雑さに応じて、複数のYAMLファイルでデプロイメントを実行すると良いかもしれません。

Knative Primitive #1: Build

Kubernetes上で開発を反復している開発者が手順の多さにうんざりする様子が想像できますね。Knativeを使えば、このプロセスすべてをKubernetesクラスター上で実行できます。ソース・コード管理、複雑なビルドやカスタム・ビルド、さらに必要に応じて多くのテンプレートを活用できます。例えばCloud Foundryのビルドパックを使ってアプリケーションを構築したい場合には、それに適したテンプレートを使用できます。

Knative Primitive #1: Build

つまりKnative Buildを使うと、これらすべてをクラスター内で実行できるのです。反復型の開発を行っている開発者の作業がかなり楽になります。これらすべての手順を1つのマニフェストのデプロイで簡単に実行できるので、より迅速かつアジャイルにアプリケーションを開発できるようになります。

Knative Primitive #2: Serve

Buildについては以上です。次にServeについてお話しましょう。Serveの役割は非常に重要で、Knativeでも面白い部分です。ServeにはIstioのコンポーネントが組み込まれています。Istioについて詳しくは、下部に記載されているリンクからご覧ください。かいつまんで説明すると、Istioには多くの機能が備わっています。トラフィック管理、インテリジェント・ルーティング、オートスケールやゼロスケールなどの素晴らしいコンセプトがあります。サーバーレス・アプリケーションを稼働させ、例えば1,000Podまで拡大したり、そのサービスへのアクセスがない時には0に戻したりできます。

KnativeのServeが管理するサンプルのServiceを見てみましょう。まずServiceから始めます。これは従来のマイクロサービスや機能と言えます。

このServiceは2つの異なるものを対象に管理しています。RouteとConfigです。KnativeのServeでまだお話していなかったとても優れた機能として、pushを行うと毎回プロビジョンが保管されるというものがあります。

Knative Primitive #1: Build

サービスへのpushを2回実行したとしましょう。Revision 1、Revision 2が割り当てられます。Revision 2はアプリケーションの新しい方のバージョンで、Configはこれら両方を管理します。

Knative Primitive #2: Serve

Routeは基本的にすべてのトラフィックを管理していて、トラフィックを1つまたはそれ以上のRevisionにルーティングします。Istioのトラフィック管理機能を使って、例えば全トラフィック中の10%をRevision 2にルーティングし、90%をRevision 1に残します。こうすることで段階的なロールアウトやさらにはA/Bテストも計画することができます。

Knative Primitive #2: Serve

要約すると、KnativeのServeはスナップショット、インテリジェント・ルーティング、そしてスケーリングを提供します。いずれも非常に優れた機能です。BuildとServeを合わせて活用することで、CI/CDやKuberntesへのマイクロサービスのデプロイメントを実行する際に起こり得る多くの問題を解決できると思います。

Knative Primitive #2: Serve

Knative Primitive #3: Event

最後にEventingについてお話しましょう。これはKnativeでまだ開発中の、未完成の機能の1つです。最近リリースされたプロジェクトの1つです。この動画の作成時点ではまだ開発中ですが、すでに使用可能な機能も多くあります。

Eventingはどのようなサーバーレス・プラットフォームにおいても不可欠な要素です。プラットフォームによる対応を促す何らかのイベント、つまりトリガーを作る機能が必要です。

例えば配達の経路変更アルゴリズムがあり、悪天候が検出されると必ずこのアルゴリズムをサーバーレス・アクションでトリガーしたいとします。Eventingを使えばトリガーをセットアップすることができます。

別の事例になりますが、EventingをCI/CDパイプラインと統合することもできます。例えばこのフローをすべて作成した後に、マスターに対して新規のpushがあると自動的にこのフローが開始されるようにしたいとします。あるいはマスターに対して新規のpushがあると、トラフィックの10%が該当バージョンのアプリをpushするようにしたいとします。

Knative Primitive #3: Event

Eventingを活用すればこれを実現できます。Eventingでパイプラインを作成するというオプションもあります。この機能の開発がさらに進み、より堅固なものになれば、KnativeのEventingを有効活用できる選択肢や機会が増えるでしょう。

Knativeを強力にするビルディング・ブロック

Knativeがとても強力なのは、これら3つのコンポーネントが揃っているからです。Knativeがクラウド・ネイティブやKubernetesの分野で大きな注目を浴びつつあるのは間違いありません。

このKnativeについての説明が皆さんのお役に立てば幸いです。ぜひ、今後のセッションもご覧ください。詳しくお知りになりたい場合は、IBM Cloud BlogやDocsをご覧ください。

最後までご覧いただきありがとうございました。

Sai Vennam Developer Advocate—IBM Cloud Kubernetes Service