Knativeのこれまでとv1.0の変更点

本記事は「TUNA-JP Advent Calendar 2021」の５日目のエントリとして、Cloud Native Runtimes for VMware Tanzuで利用されているKnativeのこれまでと、先月リリースされたv1.0での変更点をちょろっとだけ解説します。

Knative v1.0リリース！

2021年11月2日、ついにKnativeがバージョン1.0になりました。3年掛かってのv1.0です。
Knativeが初めて公開された際にちょっと触ってみたけど、リソース消費キツイしコンポーネント多いし大変だ、と思ってそれ以来Knativeを敬遠されている方なんかには是非読んでいただければと思います。¹

なお、Knativeが何かとか、動かし方については今回は対象外としています。
そちらに関してはQiita内でも多数記事があるので、是非検索してみてください。

なるべく情報ソースはコミュニティにあるものをベースに調べていますが、古い情報も多く時期やバージョンなどに誤りがあるかもしれません。
誤りを見つけていただいた方は、コメント欄で指摘していただけると助かります。

Knativeのはじまり〜v1.0

2018年6月　Knative、生誕

2018年6月に開催されたGoogle Cloud Next 2018でKnativeが初めてアナウンスされました。この時の開発メンバはGoogle, Pivotal（現在はVMware）, IBM, Red Hat, SAPでした。
当時はGKE serveless add-onとセットで発表され、オンプレミス環境でもGKE serverless add-onと同等のワークロードを処理できることを目的としていました。
これにより、従来はパブリッククラウドでないと利用が難しかったサーバレスコンピューティングをオンプレミスで利用できるようになり、利用者が「サーバレス使いたいけど、パブリッククラウドは従量課金やセキュリティ面で嫌だなー、オンプレミスでやりたいなー」のような思考を持った時、knativeは一つの解となりました。
当初は「Kubernetesベースで最新のサーバレスワークロードを構築、デプロイ、管理するプラットフォーム」として打ち出されており、コンポーネントも

• Build：ソースからコンテナへのビルド
• Serving：Scale-to-Zeroも可能なリクエストドリブンなコンピュートサービス
• Eventing：イベントの管理と配信

の3つから構成されていました。
また、当時はIstioをベースに設計されており、Istioは必須コンポーネントとなっていました。（余談ですが、この頃はまだIstioも1.0になっていませんでした。）
Istio前提や色々なコンポーネントの集合体ということもあり、フットプリントは軽くなく、ローカルPCや低スペックサーバで味見するには辛い時代でした。

2019年2月　Ingress ControllerにGlooが選択可能に

knatvieのためのIngress Controllerとして2019年2月にGlooがリリースされました。
GlooもIstioと同様にEnvoyをベースとしたAPIゲートウェイで、Istioと異なる特徴としてKnativeに必要な機能のみ提供されるため、Istioと比べてより軽量に動かすことが出来るようになりました。
ちなみに今はKnativeの公式インストール手順ではKourier、Ambassador、Contour、Istioのいずれかのインストール手順が記載されています。種類が増えていますが、Glooが載っていないのは何故なんでしょうね。。。

2019年6月　BuildがTekton Pipelineと統合し、Knativeから削除

v0.7でKnativeの3機能のうちの1つのBuildがKnativeからTektonに移行し、Knatvieで提供されるBuildはメンテナンスモードに入りました。（最終的な廃止はv0.9）
TektonはKubernetesのために作られたCIツールであり、Tekton Pipelineのファーストリリースは2019年の2月とKnativeのリリース後でしたが、2019年の3月に発足したContinuous Delivery Foundationがホストする最初のOSSに名前を列ねるなど、急速に知名度を高めていきました。
またTektonの特徴としてKnativeのBuildをベースとしていたため、Knativeとの親和性も高く、Buildの受け入れ先としても適切だったようです。
以下にBuildをTektonに移行するProposalがあり、当時の様子を少し垣間見ることが出来ます。
https://github.com/knative/build/issues/614

2021年11月　Knativeが1.0に！そしてCNCFへ

0.25,0.26と1刻みで進んでいたバージョンが、突如v1.0となりました。
https://knative.dev/blog/articles/announcing-knative-1.0/
v1.0を宣言した背景は色々ありますが、シンプルに言うと「成熟した」ということになるかと思います。
APIの仕様はv1.0になったことで一旦Fixとなり、Versionの違いでAPIの挙動が異なるようなことはなくなり、安心して利用できるようになりました。
CNCFでのサーベイではサーバレスのソフトウェアとしてKnativeは利用率が1位となっており、多くのサーバレスソフトウェア利用者にとって嬉しいニュースになったかと思います。
https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf

なお、1点注意したい点として、v1.0＝GAではありません。
バージョンの足並みを揃えるために全てのコンポーネントを一度v1.0とし、コンポーネントごとにバージョンとは別にGAかどうかをマークしていると記載があります。
https://knative.dev/blog/articles/knative-1.0/#what-does-it-mean-to-be-10
Serving、Eventingに関しては問題ないですが、拡張コンポーネントは個別に確認する必要がありそうです。

あと、この記事をダラダラ書き溜めていた時にニュースが！
KnativeはCNCFに寄贈されることとなりました！
このまま採択されれば、CNCFのサーバレスのプロジェクトとしてはKEDAに続き２例目になります。
これによりサーバレスの標準化の議論などが進むといいですね。

Knative v1.0 release note (抜粋)

v1.0ということもあって、変更点は結構あります。
https://knative.dev/blog/releases/announcing-knative-v1-0-release/
以下、Breaking or NotableとNew Features & Changesに絞ってざっくり翻訳＋紹介してみます。
コマンドラインなどの変更もあるので、利用されている方は本家のrelease noteの方もご確認ください。

Breaking or Notable

(翻訳)Namespaceごとのワイルドカード証明書Provisionerがベースのコントローラに統合され、namespace-wildcard-cert-selectorフィールドで制御されるようになりました。このフィールドでは、Kubernetes LabelSelectorを使用して、どのNamespaceに証明書をプロビジョニングするかを選択することができます。

これは元々Cert Managerと連携してTLSの証明書を取得・更新するように設定する際に、namespaceごとに証明書をプロビジョニングする場合は

kubectl apply -f serving-nscert.yaml

でnet-nscert-controllerをインストールしていたものが、本体側に取り込まれて不要になったものです。
以下のドキュメントを見比べると、利用方法が少し簡単になったのが分かります。

• v0.24版：https://knative.dev/v0.24-docs/serving/using-auto-tls/
• 最新版：https://knative.dev/docs/serving/using-auto-tls/

指定方法も各namespaceのannotationに記載する方法からlabelで指定する方法に変わっており、serving-nscertで導入したリソースも削除する必要があるため、利用していた人は注意が必要です。

New Features & Changes

(翻訳)Namespaceごとのワイルドカード証明書のプロビジョニングが、主なKnativeコントローラに統合され、個別にインストールする必要がなくなりました。現在は、KubernetesのNamespaceのLabel Selectorで制御されるようになりました。

これはBreaking or Notableで書いている話です。

(翻訳)実験的な新機能 "concurrencyStateEndpoint "により、コンテナのconcurrency(同時実行数)がゼロになる/ゼロから増える時に、Webhookに通知することができるようになりました。

元々はリクエストが来なければ即時にコンテナをpauseにする、lambda/openwhiskライクなfreeze-proxyというKnative addonが出発点だったようです。
いわゆる従量課金のFaaSのような形で利用する場合、即時にコンテナが停止してくれることが望ましいですが、Knativeの標準機能では満たせません。
その辺りをカバーするために、リクエスト数がゼロになった時/ゼロから増えた時にfreeze-proxyのようなものを呼び出す口が用意されました。
非常に面白そうですが、試せてないので詳細までは掴めていません。。。
(ドキュメントも今時点では非常に少なく、実装を追わないと厳しそう。。。)

(翻訳)ネットワークのconfigmapでmesh compatibility modeが"auto"に設定されていない場合、ActivatorはKubernetesのReadinessを尊重し、KubernetesのReadinessがActivatorのprobeよりも早く伝播した場合、probeを回避するようになりました。

ActivatorはServingのコンポーネントの1つでリクエストを受信・バッファリングし、またメトリクスを取得して別のコンポーネントであるautoscalerにスケールに関するリクエストを発行するなどの役割を持つものです。
knative-servingのnamespaceのConfigMapにconfig-networkというものがありますが、この中でmesh-compatibility-modeというパラメータがあり、Podへのアクセス方法を指定するのですが、このパラメータが"auto"以外(enabledかdisabledの場合)、Activatorが持つProbe機能よりもKubernetes本来のReadinessProbeを優先する、というのがここでの変更点となります。

最後に

おまけ程度になりますが、TUNA Advent Calandarということで、Tanzu関連の話も少しだけ。
VMwareではCloud Native Runtimes for VMware Tanzu(以下CNR)というKnativeに付加価値をつけた製品をリリースしています。
https://docs.vmware.com/en/Cloud-Native-Runtimes-for-VMware-Tanzu/index.html
以下でブラウザからCNRを触って試すことも出来ます（無料です！）。
https://tanzu.vmware.com/developer/workshops/
knativeの商用サポートが必要な場合は是非ご確認ください。
製品の詳細は先日行われたVMworldの以下のセッションが参考になるかと思います。
https://vmworld.jp/content/MA11158/

Knativeは煩雑なYAML管理から解放してくれ、ビルド、デプロイ、監視などを自動運用できる素敵なOSSです。
v1.0ということで以前よりも安心して使えるようになっており、是非触ってみてください。
（安心、といいつつ、v1.0にVUPして動かなくなった、という声もちらほらあるので、VUPする際は慎重にお願いします）

1. 今は1ノードでも作れて必要なリソースも少なくなっており、自宅環境でも簡単につくれるようになってます。https://knative.dev/docs/install/serving/install-serving-with-yaml/ ↩