CloudNative Days 2019の登壇資料です。 https://cloudnativedays.jp/cndt2019/
YouTubeはこちら https://youtu.be/rD9czFIT4Iw
Knativeで実現する Kubernetes上のサーバーレスアーキテクチャ @toshi0607 #CNDT2019#OSDT2019#RoomE#1E3
View Slide
※https://cloudnativedays.jp/cndt2019/#CNDT2019#OSDT2019#RoomE#1E3
自己紹介 ● 杉田 寿憲 ○ Toshinori Sugita ○ toshi0607 ● Software Engineer@メルペイ ○ Go、gPRC、GKEなマイクロサービスのバックエンド開発 ● 本 ○ 『Knativeの歩き方 KubernetesからServerlessを訪ねて』 ○ 『GoとSAMで学ぶAWS Lambda』 ○ 『Extensive Xamarin(共著)』 #CNDT2019#OSDT2019#RoomE#1E3
#ふわふわくん#CNDT2019#OSDT2019#RoomE#1E3
今日のお話 ● Knativeの概要 ● KnativeとKuberentes ● KubernetesとServerless ● Knativeのユースケース ● まとめ ● 参考資料 #CNDT2019#OSDT2019#RoomE#1E3
Knativeとは? Kubernetes-based platform to build, deploy, and manage modernserverless workloads ※https://github.com/knative#CNDT2019#OSDT2019#RoomE#1E3
Knativeとは? ● Kubernetesのリソースを抽象化する ○ 開発者から見てよりシンプルに ● 独自のPaaS/FaaSを構築するためのパーツを提供 ○ Serving、Build、Eventingから構成される ● よくあるが難しい課題を解決 ○ コンテナのデプロイ ○ ソースコードからURLでアクセスできるアプリケーションへ ○ ブルー/グリーンデプロイを伴うルーティングとトラフィック管理 ○ オートスケーリングと需要に基づくワークロードのサイズ設定 ○ 実行中のサービスをイベントエコシステムに結び付ける ※https://github.com/knative/docs#CNDT2019#OSDT2019#RoomE#1E3
Knativeの構成要素 ※https://github.com/knative/docs/tree/master/docsKubernetes Istio or Gloo Serving Build Eventing Platform Gateway Primitives
Servingの役割 ※https://github.com/knative/docs/tree/master/serving● コンテナの迅速なデプロイ ● オートスケールアウト・イン(0まで) ● Istio向けのトラフィック・ネットワーク設定 ● コードと設定のバージョン管理 #CNDT2019#OSDT2019#RoomE#1E3
Servingの構成要素 ※https://github.com/knative/docs/tree/master/serving● Revision: コードと設定のスナップショット ● Configuration: 最新のRevision ● Route: Revisionにルーティング ● Service: RouteとConfigurationを管理。k8sのServiceとは別 #CNDT2019#OSDT2019#RoomE#1E3
REVISIONServingの構成要素 ※https://github.com/knative/serving/blob/master/docs/scaling/DEVELOPMENT.md● Autoscaler: Revisionの同時リクエスト数を監視、調整 ● Activator: RevisionがReserve State時リクエストを受ける ROUTEIstio Route Activator Pods Deployment Autoscaler metrics resize active route inactive route activate create watch first
Istioは必須? ※https://knative.dev/docs/install/index.html代替手段はあるがKnative全コンポーネントを利用するには今のところ必須 #CNDT2019#OSDT2019#RoomE#1E3
Buildの役割と構成要素 ※https://github.com/knative/docs/tree/master/build● ソースコードをコンテナイメージに変換する ● ビルドパイプラインは複数のstepで構成される ○ 各stepはコンテナイメージ ○ クラスタのコンテナ内で実行される ● BuildTemplateでテンプレート化・再利用できる #CNDT2019#OSDT2019#RoomE#1E3
BuildTemplate ※https://github.com/knative/build-templates#CNDT2019#OSDT2019#RoomE#1E3
BuildとTeketon ※https://github.com/knative/build/issues/614● knative/build-pipelineとしてはじまったknative/build強化プロジェクトのTektonPipelineに移行の議論中 ● v0.7でServingがBuildを利用していた機能(DockerイメージにBuild自体を指定する)を廃止 ● BuildのREADME上でもdeplicationへのfeedback受付中を明記 ● v1.0でknative/buildをアーカイブするスケジュール #CNDT2019#OSDT2019#RoomE#1E3
BuildとTeketon ※https://github.com/knative/build/issues/614● 2019/7/12にKnative BuildをTektonに移行するためのドキュメントPRがtektoncd/pipelineにマージされる ● K8sリソースの対応関係、差異、BuildTemplate -> TaskとBuild -> TaskRunの移行例がまとまっている #CNDT2019#OSDT2019#RoomE#1E3
BuildとTeketon ※https://github.com/triggermesh/tm/releases/tag/v0.0.12● Knative活用プロジェクトにも移行が完了したものがある ● knative/buildの互換性は維持 #CNDT2019#OSDT2019#RoomE#1E3
Eventingの役割 ※https://github.com/knative/docs/tree/master/eventing● イベントドリブンなアーキテクチャをサポート ● イベントの発行元と受け手を抽象化 ● 既存の発行元、受け手の変更なく他サービスを接続 ● CNCF Serverless WGのCloudEventsに則りサービス間の相互運用性を保証 #CNDT2019#OSDT2019#RoomE#1E3
Eventingの構成要素 ※https://github.com/knative/docs/tree/master/eventing● Source: イベントソース。種類毎にリソースを定義 ● Broker: イベントを受け取り、フィルタリングされたものをService(subscriber)に渡す ● Trigger: subscriberにわたすイベントのフィルター Broker Service Trigger ✓ ✓ ✓filter subscriber broker #CNDT2019#OSDT2019#RoomE#1E3
Eventingの構成要素(〜v0.3) ※https://github.com/knative/docs/tree/master/eventing● Source: イベントソース。種類毎にリソースを定義 ● Channel: イベントのバッファリング、Serviceへの到達保証 ● Subscription: ChannelからイベントをServiceに渡す #CNDT2019#OSDT2019#RoomE#1E3
Event Source ※https://github.com/knative/docs/tree/master/docs/eventing/sourcesContainerSource Event Sourceとして独自に作成することも可能 #CNDT2019#OSDT2019#RoomE#1E3
Kubernetesとは? Kubernetes (K8s) is an open-source system for automatingdeployment, scaling, and management of containerizedapplications. ※https://kubernetes.io/#CNDT2019#OSDT2019#RoomE#1E3
Kubernetesのコンセプト ● 「あるべきリソースの状態」を宣言的に定義した設定を適用 ● K8sのコントローラーがリソースを監視し、「あるべきリソースの状態」を維持し続ける →故障時の復旧や高負荷時のオートスケールなどで運用負荷を低減できる ※https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#CNDT2019#OSDT2019#RoomE#1E3
Kubernetesのアーキテクチャ node2 node1 kubectl etcd kube- apiserver kube- scheduler kube- controller- manager kube-proxy kubelet kube-proxy kubelet Docker etc... Docker etc... ・・・※https://kubernetes.io/docs/concepts/architecture/cloud-controller/#CNDT2019#OSDT2019#RoomE#1E3
カスタムリソース ● 独自のリソースを追加できる ○ CustomResourceDefinition ○ API server aggrigation ● バリデーションやその他メタ情報を定義 ● CRDで定義したカスタムリソースに対するCRUDが可能になる ※https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#CNDT2019#OSDT2019#RoomE#1E3
カスタムコントローラー ● 独自のコントローラーを追加できる ● 既存のリソースやカスタムリソースの変更を検知し、理想状態になるよう調整する ● カスタムコントローラーのDockerイメージをDeploymentでK8sクラスター上にデプロイする ※https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Kubernetes nativeなKnative ※https://github.com/knative/serving/tree/master/config● Knativeもカスタムリソースとカスタムコントローラーで構成されている ● KnativeのインストールはCRD(左図青枠がknative/servingのもの)に加え、カスタムコントローラーのDeploymentなど必要なコンポーネントのyamlをkubectl applyすることが主な作業になる ● K8s nativeな手法でプラットフォームを拡張する #CNDT2019#OSDT2019#RoomE#1E3
サーバーレスとは ※https://martinfowler.com/articles/serverless.html● サーバーレスアーキテクチャは、サードパーティのBaaSサービスを組み込んだ、またはFaaSプラットフォーム上の管理された一時的なコンテナで実行されるカスタムコードを含むアプリケーション設計 ● ベンダー依存と比較的未成熟なサービスサポートと引き換えに運用コスト、複雑性、エンジニアリングリードタイムを低減 #CNDT2019#OSDT2019#RoomE#1E3
サーバーレスとは ※https://medium.com/@PaulDJohnston/serverless-is-a-doctrine-not-a-technology-4193ccb66cfc● (FaaSなどの)サービス自体はサーバーレスではない。どのように構築されるかのアプローチがサーバーレスであり、サーバーレスアプリケーションを生み出す。 ● サーバーレスアプリケーションは、アプリケーションのライフサイクル全体にわたって最大のビジネス価値を提供するものであり、データストレージの費用を除いて、誰も使用していないときに実行する必要はないというもの
サーバーレスとは ※https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview● サーバー管理を必要としないアプリケーションを構築および実行するという概念 ● 必要とされている正確な需要に応じて実行、拡張、請求を行うデプロイモデル ● サーバーレスコンピューティングの利用者は、サーバーのプロビジョニング、メンテナンス、アップデート、拡張、キャパシティプランニングに時間とリソースを費やす必要がなくなる ● 開発者がよりアプリケーションのビジネスロジック開発に集中できるようになる ● 運用者がよりビジネスクリティカルなタスクに集中できる
Kubernetesとサーバーレス ※https://github.com/knative/serving/blob/master/docs/spec/motivation.md● Knativeはステートレス、プロセススケールアウトモデル、アプリケーションレベルのリクエストトラフィック駆動をサーバーレスワークロードを捉える ● それらのうちK8s自体で基本的なパーツは提供している ● 共通インフラの自動化を一層推進するための抽象度の高いパーツを標準化することで「yamlをkubectlで更新」より使いやすいツールキットを提供できるはず #CNDT2019#OSDT2019#RoomE#1E3
Knativeとは? ● Kubernetesのリソースを抽象化する ○ 開発者から見てよりシンプルに ● 独自のPaaS/FaaSを構築するためのパーツを提供 ○ Serving、Build、Eventingから構成される ● よくあるが難しい課題を解決 ○ コンテナのデプロイ ○ ソースコードからURLでアクセスできるアプリケーションへ ○ ブルー/グリーンデプロイを伴うルーティングとトラフィック管理 ○ オートスケーリングと需要に基づくワークロードのサイズ設定 ○ 実行中のサービスをイベントエコシステムに結び付ける ※https://github.com/knative/docs開発者・運用者がよりビジネス価値に集中できるプラットフォームを構築する
Knativeによるプラットフォームの拡張 ※https://github.com/knative/docs/tree/master/docsKubernetes Istio or Gloo Serving Build Eventing Platform Gateway Primitives GitLab Serverless Your Own! Pivotal FunctionService OpenFaaS functions Cloud Run Knative LambdaRuntimes Products
ユースケース① コンテナのデプロイ ※https://github.com/toshi0607/CNDT2019-Knative/tree/master/usecase1● 課題 ○ URLでアクセスできるサービスをより楽に管理したい ○ Deployment、Service… ● knative/serving ○ Deployment、Service(K8s)リソースなどが抽象化されたService(Knative)リソースを適用してURLアクセスできるアプリケーションを楽にデプロイ ● Demo ○ TARGET環境変数にセットされた文字列を使ってHello worldを出力するアプリケーションをService(Knative)リソースの適用でデプロイ #CNDT2019#OSDT2019#RoomE#1E3
ユースケース① コンテナのデプロイ Deployment k8s Service ReplicaSet Pod #CNDT2019#OSDT2019#RoomE#1E3
ユースケース② オートスケール ※https://github.com/toshi0607/CNDT2019-Knative/tree/master/usecase2● 課題 ○ リクエスト数に応じてオートスケールさせたい ○ スケール具合を可視化しながら調整したい ● knative/serving ○ Pod毎の並列リクエスト数を制御・設定 ■ K8sのメモリベースのHPA(Horizontal Pod Autoscaler)に変更でき、カスタムメトリクス対応も目標の1つとされている ○ servingのReleasesにモニタリング系のyamlも含まれており、メトリクス、ログ、トレースそれぞれ選択肢がある ■ kubectl apply --filenamehttps://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml ● Demo
ユースケース② オートスケール ※https://github.com/knative/docs/blob/master/docs/serving/configuring-the-autoscaler.md● autoscalerの設定はConfigMapとして管理されている ● knative/servingのインストール(kubectlapply)時に適用するyamlにこのデフォルト設定が含まれる ● Serviceリソースのspec.template.metadata.annotationsで設定できるものもあるが詳細はConfigMapを変更する
ユースケース③ トラフィック分割 ※https://github.com/toshi0607/CNDT2019-Knative/tree/master/usecase3● 課題 ○ 新実装へのトラフィックを徐々に増やし、影響を見ながら安全にデプロイしたい ● knative/serving ○ Routeを利用したブルーグリーンデプロイ ● Demo ○ Hello Worldアプリケーションに設定するTARGET環境変数を“blue”から“green”に変更(2つのRevisionを作成) ○ “green”のRevisionへのトラフィックを0 -> 50 -> 100%と大きくしていく #CNDT2019#OSDT2019#RoomE#1E3
ユースケース④ イベントエコシステム ※https://github.com/knative/docs/tree/master/docs/eventing/samples/gcp-pubsub-source● 課題 ○ 特定のイベントが発生したときに処理を実行したい ● knative/eventing ○ イベントをServiceリソースへのリクエストに変換して処理を実行する ● Demo ○ Google Cloud PubSubをイベントソースとして利用 ○ 必要な権限は事前に準備済み ■ eventing-contribのgcppubsub関連のリソースをapply ■ pubsub.editor権限付きservice accountを作成 ■ service accountのJSONファイルからSecretリソース作成 ○ 受け取ったイベントをフォーマットして出力するアプリケーション #CNDT2019#OSDT2019#RoomE#1E3
ユースケース④ イベントエコシステム ※https://cloudevents.io/#CNDT2019#OSDT2019#RoomE#1E3
ユースケース⑤ ビルドパイプライン ● 課題 ○ CI/CDもK8sの世界で済ませたい ○ ビルドパイプラインを共有したい ● knative/build -> tektoncd/pipeline ○ K8sのリソースでビルドパイプラインを定義する ○ テンプレート化できるので再利用できる ※https://github.com/tektoncd/pipeline#CNDT2019#OSDT2019#RoomE#1E3
ユースケース⑤ ビルドパイプライン Pipeline Task Task PipelineResource(input) PipelineResource(output) PipelineResource(input) Pipeline Run Step Step Step Step ※https://github.com/tektoncd/pipeline
ユースケース⑥ FaaS イベントpull型 ※https://github.com/triggermesh/knative-lambda-runtime● 課題 ○ イベントドリブンな関数をシュッとデプロイしたい ● knative/serving + knative/build (BuildTemplate) ○ triggermesh/knative-lambda-runtimeを利用するとユーザーはAWS Lambda互換のfunctionだけ書いたらデプロイできるプラットフォームを構築できる ○ Serviceでリクエストを受けfunctionに受け渡す処理(aws-custom-runtime、bootstrap)はBuildTemplateを活用してイメージビルド時に埋め込む #CNDT2019#OSDT2019#RoomE#1E3
AWS Lambdaのfunction(Go) ※https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/go-programming-model-handler-types.html● Handler: イベントを引数にそれをハンドリングするメイン処理を書く ● lambda.Start: rpcサーバーにhandlerを登録し、rpcサーバーを起動する
aws/aws-lambda-go AWS LambdaとRuntime Interface ※https://github.com/aws/aws-lambda-goAmazon APIGateway lambda.start(handler) container rpc server AWS Lambda Runtime AWS Lambda Runtimeはrpcサーバーを含むコンテナを起動し、イベントを渡す request proxy event event http request S3 event SQS event DynamoDB stream event
AWS LambdaとRuntime Interface ※https://qiita.com/toshi0607/items/39004c19d7361a837986Amazon APIGateway container bootstrap AWS Lambda Custom Runtimes bootstrapからRuntime APIにイベントを取得にし行くのでCOBOLも動く proxy event event http request S3 event SQS event DynamoDB stream event Next InvocationAPI InvocationResponse API Invocation ErrorAPI Initialization ErrorAPI response event error error
ユースケース⑥ FaaS イベントpull型 ※https://github.com/triggermesh/knative-lambda-runtime● aws-custom-runtimeがAWS Runtime Interfaceとタスクキューを実装 ● bootstrapがイベントを取得し、functionをinvoke Route Service Build Build Template Pod aws/aws-lambda-go lambda.start(handler) tm/aws-custom-runtime bootstrap Configuration Revision get event exec bin exec bin rpc Server http request K8s request #CNDT2019#OSDT2019#RoomE#1E3
BuildTemplateで生成するDockerfile ※https://github.com/triggermesh/knative-lambda-runtime/blob/master/go-1.x/buildtemplate.yaml
ユースケース⑦ FaaS イベントpush型 ※https://github.com/openfaas● 課題 ○ イベントドリブンな関数をシュッとデプロイしたい ● knative/serving + knative/build (BuildTemplate) ○ OpenFaaSのwatchdogサーバーを利用するとユーザーはfunctionだけ書いたらデプロイできるプラットフォームを構築できる ○ Serviceでリクエストを受けfunctionに受け渡す処理(watchdog)はBuildTemplateを活用してイメージビルド時に埋め込む #CNDT2019#OSDT2019#RoomE#1E3
OpenFaaSのfunction(Go) ※https://github.com/openfaas/faas/blob/master/sample-functions/BaseFunctions/golang/handler.gofunctionは標準入力経由でリクエスト・イベント情報を受け取って処理
OpenFaaSのアーキテクチャー ※https://docs.openfaas.com/architecture/gateway/#CNDT2019#OSDT2019#RoomE#1E3
Watchdogによるfunction制御 ※https://docs.openfaas.com/architecture/watchdog/● functionの起動、モニタリングを責務とするGoで書かれたサーバー ● リクエストを標準入力経由でfunctionのプロセスに渡す ● watchdogとして再利用することでプラットフォームのユーザーはビジネスロジック(function)の実装に集中できる
ユースケース⑦ FaaS イベントpush型 リクエストとfunctionのハンドリングにwatchdogを活用 Route Service Build Build Template Configuration Revision http request K8s #CNDT2019#OSDT2019#RoomE#1E3
watchdogとfunction同梱のDockerfile ※https://github.com/openfaas/faas/blob/master/sample-functions/BaseFunctions/golang/Dockerfile
Knativeを使ったFaaS ● Serviceでデプロイするのはコンテナなので、functionの実装に集中するためにリクエストをfunctionに渡すサーバーを準備する必要がある ● サーバーからfunctionを独立させることでサーバーとfunctionを同梱するイメージテンプレートを準備できる ● faas-cliやtmのようにCLIでmanifestとkubectlを意識させないデプロイも実現できる ● イベントがcloudeventsに準拠していると各イベント用のライブラリを各言語で準備する手間も省ける #CNDT2019#OSDT2019#RoomE#1E3
ユースケース⑧ コンテナサーバーレス ※https://cloud.google.com/run/● 課題 ○ コンテナをシュッとデプロイしたい ● knative/serving + knative/build ○ Cloud RunやCloud Run on GKEを利用し、コンテナを手軽にデプロイし、負荷に応じてスケールさせることができるプラットフォームを構築する #CNDT2019#OSDT2019#RoomE#1E3
ユースケース⑧ コンテナサーバーレス ※https://twitter.com/ahmetb/status/1116041166359654400● Cloud Runマネージドサービスもあり、コンテナを動かすのにK8sの運用をなくす選択肢もある ● Knative Serving APIと互換のAPIで操作するので操作感も同じ ● GCPのコンソールからどちらも同じように状態や生成されたRevisionのyamlを確認できる #CNDT2019#OSDT2019#RoomE#1E3
まとめ ● KnativeはK8s nativeな方法でK8sプラットフォームを拡張・抽象化する ● K8s上でサーバーレスを実現する手段の1つがKnativeであり、FaaSに限らず課題に応じて開発者の生産性向上、運用者の負荷低減のための様々な使い方ができる ● FaaSを自分で構築することもできるし、Knativeを利用したプロダクトを利用することもできる #CNDT2019#OSDT2019#RoomE#1E3
参考資料 Knative ● 公式ドキュメント ○ とても整理されていて図も豊富でわかりやすいです ○ 主なユースケースのサンプル・解説もある ○ https://github.com/knative/docs ● 『Getting Started with Knative』 ○ Pivotalの方が執筆したebookが無料です ○ https://content.pivotal.io/ebooks/getting-started-with-knative ○ バージョンは古くなってしまったがそれでもユースケースまで載っていて楽しい ● 『Knativeの歩き方 KubernetesからServerlessを訪ねて』 ○ 完全な手前味噌 ○ https://booth.pm/ja/items/1309468 #CNDT2019#OSDT2019#RoomE#1E3
※https://techbookfest.org/event/tbf07● Knative既刊ユースケース + 書き直しの大幅パワーアップ! ● Knativeの実装を見ながらK8sのコントローラーを学ぶ新刊 参考資料 Knative #CNDT2019#OSDT2019#RoomE#1E3
参考資料 Knative ● 8/29 ServerlessDays Melbourne 2019 ○ Build serverless application on the top of Kubernetes ● 10/21、22 ServerlessDays Tokyo 2019 ○ Knativeのハンズオンをする可能性あり ○ プロポーザル募集中! ■ https://tokyo.serverlessdays.io/ ● 12/13、14 ServerlessDays Fukuoka 2019 ○ Knativeで作るDIY FaaSの話をすべく準備します #CNDT2019#OSDT2019#RoomE#1E3
ご清聴ありがとうございました! Knativeで実現する Kubernetes上のサーバーレスアーキテクチャ #CNDT2019#OSDT2019#RoomE#1E3