2018の22日目です。さんの「続・IaaS基盤をテストする環境を作る話」でした。この記事では、Knativeを構成するコンポーネント群と、それらを構成するCRDについて紹介したいと思います。ニフクラではエンジニアリングパーツという形でニフクラ上のシステムに組み込みやすいパーツを提供しています。サーバーレスを実現するサービスです。エンジニアリングパーツのようなサービスを実現するためには数多くの技術を取り入れる必要があるのですが、Knativeはその中で注目している技術のうちの一つです。KnativeとはKnativeとは、2018年7月にGoogleから発表された、Kubernetesネイティブなコンポーネント群です。OSSとして精力的に開発が行われており、次世代の基盤として期待が集まっています。Knative自体は複数のコンポーネントから構成されています。これらのコンポーネントは、クラウド上のシステムでよく必要となる機能が実装されたプリミティブなパーツと捉えることができます。Knativeのコンポーネントを利用することで、数多くのベンダーがそれぞれ独自に似たようなものを実装する必要性が薄まります。各コンポーネントは疎結合で、連携して動作させることもできますし、あるシステムにとって必要な一部のコンポーネントだけを利用することもできます。KnativeはKubernetesとIstio上に構築されることを前提としています。Service)の基盤というような扱われ方をすることがあります。それが誤りというわけではないのですが、Knativeが実現する世界のうち、FaaSは一部分です。Knativeを利用することでFaaSを実現することはできます。Istio上で構築可能な、非サーバーレスのシステムのうえであっても、Knativeのコンポーネントを活用することもできるでしょう。以下でより詳細に解説していきますが。Definition)で構成されています。コンポーネントとCRDを把握すると、Knativeの内部理解が高まることでしょう。CRDだけではないのですが、今回はCRDという視点を中心に説明したいとおもいます。インストールした状態で検証しています。Knativeのコンポーネント現在、Knativeでは下記のコンポーネントが存在しています。コンポーネントも開発されているようです。Build、Serving、Eventingを組み合わせることでFaaSやサーバーレスなシステムを構築することができます。Buildで実現する(他のコンポーネントは特に使わない)というシーンもありえるかもしれません。以下で各コンポーネントについてみていきたいと思います。Buildが果たす具体的な機能としては、下記が挙げられています。リポジトリからソースコードを取得する複数のジョブを逐次処理する。Buildでは、下記のCRDが定義されています。確認することができます。ClusterBuildTemplateそれぞれのCRDは下記のような役割になっています。ビルド処理内容の実体。stepsという単位でビルドの処理を記述する。同じようなBuildをテンプレートとして記述できる。BuildTemplateのCluster版。基本的に、Buildリソースを作成すると、定義されたstepに従って処理される形になります。Builderという概念が出てきます。Builderは、Build内のstepで指定されている個々のコンテナイメージのことを指します。あるので、試してみます。Buildをインストールした環境で、下記のBuildリソースを作成してみます。stepsに定義されている内容が実行されるリソースになります。created確認してみると、ビルドは成功しているようです。32s実際にはビルド用のPodが動作しており、Pod名を下記で確認することができます。いう名前の初期化用途と思われるコンテナが動いていたことがわかります。initialized."}上記は非常にシンプルな例ですが、実際にはこのBuildのstepとしてビルドの処理やイメージリポジトリへのpush処理を書いていく形になるようです。同じようなstepsを記述して複数のBuildで使いまわしたい場合は、BuildTemplate/ClusterBuildTemplateでテンプレート化も可能になっています。FaaSやサーバーレスなシステムを実現します。リクエスト駆動でサーバーレスなコンテナの実行を行うことができます。Servingが果たす具体的な機能としては、下記が挙げられています。サーバーレスなコンテナの高速デプロイ自動スケールアップ及び、ゼロスケールIstioによるルーティングとネットワーク操作デプロイされたソースコードと設定のポイントインタイムスナップショットゼロスケールというのが大きな特徴で、アプリケーションに全くリクエストが来ない状態が続くと、アプリケーションのPod自体が1個も立ち上がらない状態になります。0個の状態で、新たにアプリケーションへのリクエストが発生すると、改めてPodが立ち上がります。そのため、たまにしかリクエストが来ないアプリケーションかつ初回の応答速度が求められる場合は、向いていないかもしれません。なく、常時リクエストがきていたり、バッチ処理のように起動時間が誤差のようなアプリケーションであれば、問題にならないと思われます。CRDは下記のとおりです。ServiceそれぞれのCRDは下記のような役割になっています。デプロイメントの状態を保持するリソース。従ってソースコードと設定を分離してくれる。Configurationのイミュータブルなスナップショット。APIのServiceと同名なので若干ややこしい。Servingを使ってみる既に試して解説されている例がいくつかありますので、そちらを参照するのがわかりやすいです。仕様に準拠した、イベント処理を実現するものです。イベントコンシューマーとイベントソースという概念にわかれており、汎用的なイベント連携インターフェースを備えているようです。Eventingは下記のようにデザインされているようです。CRDは下記のとおりです。前者がイベントコンシューマー、後者がイベントソースに相当するようです。KubernetesEventSourceそれぞれのCRDは下記のような用途になっています。合わせて見るとよいでしょう。Service)にイベントを配信するリソース。Service)に流す仕組み。流す際に変換をかけることもできる。イベントを生成できるコンテナを立ち上げ、それをもとにイベントを発生させるイベントソース。PubSubなどの実装が既にあり、参考にして自分で実装することもできそうです。イベント配信の耐障害性などの要件に応じて内部の実装の使い分けができるということのようです。Eventingのサンプルが掲載されているので、試してみます。サンプルが見当たらなかったので、KubernetesEventSourceのサンプルをやってみます。