最強のServerlessプラットフォーム？ Knative登場

本日開催されている Google Cloud Next ’18 ですが、非常に面白いプロダクトが発表されました。

その名も Knative (kay-nay-tiv ケイネイティブと発音)　 Kubernetes上でServerlessを実現するプロダクトです。

f:id:jaco-m:20180725040441p:plain

https://github.com/knative/docs より引用

KubernetesでServerlessって何が新しいの？

この界隈追っている方はご存じかもしれませんが、KubernetesでServerless Platformを実現するという考え方自体は新しいものではありません。

CNCF Serverless Landscape　を見てみると分かりますが

などなど既に多くのOSSが存在しています。これら先行のServerlessプロダクトとKnativeは何が異なるのでしょうか？

既存のServerlessプロダクト乱立しすぎ問題

既に多くのOSSが存在していて、これといった標準が存在しない。それ自体が一番の問題と言えるかもしれません。

結果として、 Serverless(FaaS)≒Lambda　といった状態が続いてしまっています。Serverlessのプロダクトを紹介するときに、一番分かりやすい説明が「AWS Lambdaのようなもの」だったりしますしね。

Lambdaは素晴らしいサービスですが、AWSのプロプラエタリでありこれ以外に選択肢が限られているのはあまり良い状況とは言えません。

より抽象度を高めてKubernetesの複雑さを低減

そもそもKubernetesだけではダメなの？ Serverlessを載せるメリットは何なの？と思う人もいるかもしれません。

そのあたりについてはSoftware Designの2018年8月号にKubernetes(CaaS)、PaaS、Serverlessのメリット・デメリットを書いたのですが、端的にいうと「Kubernetes複雑すぎ、難しすぎ」　なのです。

gihyo.jp

Kubernetesはコンテナプラットフォームです。コンテナプラットフォームとは、コンテナそのものと関連するリソース(ネットワークやストレージなど) を管理するプラットフォームです。

KubernetesはManifestファイルでインフラを定義する、いわゆるInfrastructure as Codeを実現できる機能を提供していますが、要はすごく高度なインフラの技術なわけですね。

とても優れている仕組みなのですが、そこまでインフラ技術に通じていないアプリケーション開発者からみると、よく分からないKubernetes独自の概念を理解していかないと使えない、「めんどくさい」仕組みでもあるんです。

コンテナだとかオーバーレイネットワークだとかはどうでもいい。この作ったアプリをうまいこと動かしてくれれば、裏の仕組みはどうでもいいんだよ

そういった、アプリケーション開発者の要望に応えていくためには、もっと抽象度を上げたプラットフォームを提供していく必要があります。 Knativeも、まさにそのような希望に応えるためのプロダクトです。

Build, Event, Serving

詳しくは後続の記事で解説していく予定ですが、Knativeは疎結合な3つのコンポーネントから構成されています。

これらのコンポーネントはKubernetesのCRDを利用して実現されています。

Build

コンテナイメージを作成する仕組みです。Kubernetesではあらかじめ何らかの方法でコンテナイメージを作成し、レジストリに保存しておく必要がありますが、KnativeなこのBuildの働きにより、ソースコードからコンテナイメージを作成します。

このコンテナイメージは、ServerlessなFunctionの実行だけでなく、コンテナとしてのアプリケーション実行にも利用されます(別記事にて開設予定)

コンテナイメージの作成にはいくつかの手段が利用可能です。

Buildpack (Cloud Foundry)
Google Container Builder
Bazel
Kaniko
Jib

Cloud FoundryやHerokuで使われているBuildpackに対応しているのが要注目ポイントですね。そう、KnativeはこれまでのPaaS的な要素も持ち合わせているんです。

Event

ServerlessといえばEvent Drivenなアーキテクチャが特徴の一つです。EventによりKafkaやGoogle Cloud Pub/SubへのPublish/Subscribeが可能です。Subscribe先からのメッセージによりFunctionやアプリケーションのトリガーが可能になります

Serving

コンピューティングリソースのスケーリングやライフサイクルの管理、ネットワークエンドポイントのマッピングなどを行うコンポーネントです

Istioの統合

https://github.com/knative/docs　の図にもあるように、KnativeにはサービスメッシュであるIstioがガッツリ利用されています。 Google Cloud Nextでは、ちょうど Istio 1.0が発表されたところです。

Istioの統合により、例えばアプリケーションへの重み付けルーティングをこのように実現できたり

---
apiVersion: serving.knative.dev/v1alpha1
kind: Route
metadata:
  name: buildpack-sample-app
  namespace: default
spec:
  traffic:
  - configurationName: buildpack-sample-app
    percent: 100           ⇐これ

knative-ingressgatewayにより、ホストヘッダを利用してのリクエストルーティング(Cloud FoundryのGorouterみたいなもの) が実現されます。これまた面白い機能なので、後続の記事で解説して行ければと。

業界をリードする各社が関わっている

KnativeのAuthorsには以下の企業が記載されています。

Google LLC
Pivotal Software, Inc.
IBM Corp
Red Hat, Inc.
Cisco Systems, Inc.

GoogleだけでなくPivotalやRed Hatといった、コンテナやPaaS界隈をリードしてきた各社が関わっていますね。

例えば、Buildpackの機能やServerless周りはPivotalがコントリビュートしています。IBMも、OpenWhiskの知見をもとにコントリビュートを行っているようです。

このように、業界をリードする各社がガッツリ関わっていることは、冒頭にも書いた「事実上の標準の不在」に対しての解決策になるのではないかと思います。

試してみるには

正直Knativeの面白さは文字だけでは伝えられないと思っているので、もし興味のある方は是非試してみるのがよいでしょう。

試すには、公式のドキュメントを参考に手持ちのKubernetes環境に構築してくのが良いです。

github.com

GKEだけでなく、Pivotal Container ServiceやAKS、Minikubeなどへのインストール方法も記載されています。

ということで、次は実際に動かしてみます。

jaco.udcp.info

Cloud Penguins

Flying penguins in the cloud.