Knative を使用したサーバーレスワークロード ¶
公開日: 2019-04-10, 改訂日: 2024-01-17
Knative を使用したサーバーレスワークロード¶
著者: Mark Chmarny、Google の Cloud OSS 担当 TL
現在、Kubernetes はデプロイのデフォルトターゲットであるはずです。はい、Kubernetes が最適ではないユースケースはまだありますが、これらは最新のワークロードの数がますます少なくなっています。
Kubernetes の主な価値は、インフラストラクチャ管理の多くの苦痛を大幅に抽象化することです。事実上すべての主要なクラウドサービスプロバイダー (CSP) 間での幅広いサポートは、ワークロードが移植可能であることを意味します。Kubernetes 関連ツールの活気あるエコシステムと組み合わせることで、Kubernetes の管理を担当するオペレーターのエクスペリエンスは非常にスムーズになりました。
しかし、Kubernetes の上でソリューションを構築する開発者のエクスペリエンスはどうでしょうか?
一部の人が言うかもしれないことにもかかわらず、Kubernetes はまだ今日のアプリケーションサーバーではありません。まず、Kubernetes 上でサービスを開発、デプロイ、管理する行為は、まだ複雑すぎます。はい、ロギング、モニタリング、統合などの多くのオープンソースプロジェクトがありますが、これらを適切に組み合わせたとしても、Kubernetes での開発エクスペリエンスは依然として脆弱で、非常に手間がかかります。
まるでそれだけでは足りないかのように、コード開発の原子単位としての関数の人気が高まっていることが、全体的な複雑さにさらに拍車をかけています。多くの場合、2 つの接続されていない表面領域 (関数 (FaaS) 用とアプリケーション (PaaS) 用) で異なる開発パターンを作成します。
その結果、今日の開発者は、イメージの構築、レジストリの公開、デプロイメントサービス、ロードバランシング、ロギング、モニタリング、スケーリングなど、インフラストラクチャ関連の懸念事項を心配することを余儀なくされています。しかし、彼らが本当にやりたいことは、コードを書くことです。
Knative の紹介
今週、サンフランシスコで開催された Google Cloud Next で、Google は GKE サーバーレスアドオン (g.co/serverlessaddon) の早期プレビューを発表しました。Google は、サーバーレスアドオン (github.com/knative) を強化するプロジェクトである Knative (ケイネイティブ) をオープンソース化しました。
Knative は、Google からの多くの学習内容を実装しています。オープンソースプロジェクトには、Pivotal、IBM、Red Hat、SAP などの企業からの貢献があり、OpenWhisk、riff、Kyma などのオープンソースの Function-as-a-Service フレームワークコミュニティとのコラボレーションがあります。これらのコミュニティは Knative にリプラットフォームするか、Knative プロジェクトの 1 つ以上のコンポーネントを利用します。
Knative は、開発者が Kubernetes で最新のサーバーレスワークロードを構築、デプロイ、管理するのに役立ちます。
Kubernetes での最新のソース中心およびコンテナベースの開発ワークロードを可能にする一連の構成要素を提供します
Knative のドキュメントには、インストール方法、Google Cloud Platform などのホスト型 Kubernetes オファリングや、IBM、および Pivotal によって提供されるようなオンプレミスの Kubernetes インストールでのインストール方法に関する手順が記載されています。最後に、Knative リポジトリには、Kubernetes での開発を開始するためのサンプルとハウツー手順も含まれています。
Knative の概要
Knative は、関心の明確な分離という前提に基づいています。開発者とオペレーターは、Kubernetes に見られるオブジェクトモデルを拡張する Custom Resource Definitions (CRD) の形式でプリミティブオブジェクトを定義することにより、ワークロードの開発、デプロイ、管理について推論することができます。
- 構成 — コードと構成の両方を含む、サービスの目的の状態です
- リビジョン — コードと構成の特定の時点における不変のスナップショットを表します。
- ルート — サービスのリビジョン（単数または複数）にトラフィックを割り当てます。
- サービス — 上記のすべてのオブジェクトを組み合わせたライトバージョンで、シンプルなユースケースを可能にします。
これらのオブジェクトに加えて、Knativeはイベント処理のための主要なオブジェクトも定義しています…なぜなら、サーバーレスだからです。 Knativeはイベントプロデューサーとコンシューマーを分離し、イベント処理を効率化するためにCNCF CloudEvents（v0.1）を実装しています。
- イベントソース — イベントのプロデューサー（例：GitHub）を表します。
- イベントタイプ — さまざまなイベントソースでサポートされているイベントのタイプを記述します（例：上記のGitHubソースのWebhook）。
- イベントコンシューマー — アクションのターゲットを表します（つまり、Knativeによって定義された任意のルート）。
- イベントフィード — イベントタイプをアクションに接続するバインディングまたは構成です。
Knativeオブジェクトモデルの機能的な実装は、Knativeが開始しやすいだけでなく、ソリューションの複雑さが増すにつれてより高度なユースケースに対応できることを意味します。
まとめ
この紹介を通して、Knativeの価値についてご理解いただけたでしょうか。また、Knativeのオブジェクトがアプリケーションや機能のどちらに取り組んでいるかにかかわらず、Kubernetes上での開発をどのように効率化するのかを理解していただけたでしょうか。
今後数週間で、Knativeの主要な使用パターン（イメージプッシュ、ブルー/グリーンデプロイモデル、ソースからURLなど）をそれぞれ取り上げていきます。各記事では、そのパターンを説明し、Knativeで再現できるようにサンプルコードも提供します。Knativeを皆様と共有できることをとても嬉しく思っており、またのご訪問をお待ちしております。