在描述Knative时经常会强调它是无服务器构建块，但是有人认为，Kubernetes上的应用程序或微服务开发人员、运营管理人员等可能没有完全了解到它对他们的方便之处。

在谈论中服务器无关和抽象化这个从“词汇意味到的东西”会因人而异，而没有共同的理解，而没有具体验证，这是非常可惜的事情。

这是对Ahmet Alp Balkan（@ahmetb）的文章《Knative = Kubernetes Networking++》的日文翻译。本文解释了Knative如何解决在开发Kubernetes微服务时遇到的问题。它还在Kubernetes Podcast＃78中的“一周新闻”节目中被提及过。

如果你有兴趣，也可以试试我们制作的一个用日语一次性尝试说明内容的工作坊。此外，我们还有一个名为”build-your-own-platform-with-knative”的工作坊，你也可以看看。

Knative是Kubernetes网络的增强版。

Knativeプロジェクトは通常、«Kubernetes上のサーバーレス»のための構成要素として説明されます。この意味合いの結果として、ほとんどのKubernetesユーザーは、Knativeが非サーバーレスワークロードに対して何ができるかを認識していません。KnativeはKubernetes上のステートレスなマイクロサービスのオートスケールとネットワークを改善します。

«サーバーレス»をしばらく脇に置いておきましょう。ほとんどのKubernetesユーザーは12ファクターアップのマニフェストに従ってマイクロサービスを書きます。サービスはステートレスで、リクエスト/RPC越しに通信すべきです。

Kubernetesはそのような性質のマイクロサービスに対して適したレイヤーで動作しません。組み込みのKubernetesワークロードとネットワーク機能は、マイクロサービスの世界で必要となるいくつかの共通のタスクに不十分です。

• アプリケーションに2つのマニフェスト（Deployment、Service）を書く必要がある

• HTTP/gRPCのリクエスト/RPC単位のロードバランシングがない1

トラフィック分割がなく、ブルーグリーンデプロイが簡単にできない
CPU/メモリーベースのオートスケール（たいていスケールが遅く、求めているものではない）
同時実行数制御がない（例: Pod毎の最大リクエスト数）

KubernetesにインストールされたKnative ServingはKubernetesのこれらの短所に直接対処します。

• KubernetesのServiceとDeploymentを組み合わせた«Service»オブジェクト

• HTTP/gPRCのリクエスト単位のロードバランシング

• リクエストベースの迅速なオートスケール、素早い反応

• Serviceのリビジョンを利用したトラフィック分割（ブルーグリーンデプロイ）

• 迅速なオートスケールはすぐに使え、高度に設定可能

0 Podへのスケールイン（サスペンド）と0からN Podへのスケールアウト（アクティベーション）も設定できる
同時実行数制御（Pod毎のリクエスト数制限）

（オプション）HTTPメトリクス（レイテンシー、リクエスト数など）の自動監視サポート
（オプション）自動TLS証明書と外部エンドポイントの終端

在堆栈的关键路径上采用像Knative这样的新组件是一个艰难的决定。Knative项目涉及一些方面，可能会改变对此的看法。

• Knativeはv1.0間近で«安定»しつつあり、強固なコミュニティがあります。2

Knativeはモジュール式です。Servingコンポーネントのみをインストールできます。
KnativeはIstioに依存しなくなりました。Knativeはルーティングとトラフィックの分割にロードバランサーを必要としますが、GlooやAmbassadorのような代替手段、またはKourierなどのKnative専用に構築されたゲートウェイプロキシを使用できます。

Knative “Service” 的API

Knative将Kubernetes Deployment和Service合并为单一的Service类型。

ほとんどのステートレスなKubernetesのDeploymentマニフェストは、apiVersion / kindを変更し、いくつかの不要な部分をトリミングすることにより、非常に簡単にKnativeに移行できます。

# 変更前:
apiVersion: apps/v1
kind: Deployment

# 変更後:
apiVersion: serving.knative.dev/v1
kind: Service

Knative Serviceを更新するたびに、新しいRevisionオブジェクトが作成されます。Revisionオブジェクトはイミュータブルであり、デプロイのスナップショットを強制的に持つことになります。そうすると、Revisionオブジェクトを使用して、ロールアウト中にトラフィックを分割したり、単純にロールバックしたりできます。

Knative Serving为开发者提供了其他API，这些API是他们日常工作中很少遇到的。例如，它提供了将代码和配置分离的功能（遵循12因素应用的原则）。

Knative的自动缩放

如果作为开发者，在Kubernetes中让微服务自动扩展这个问题令人困扰，那肯定有足够的理由。

Kubernetesのオートスケールは、主にHorizo​​ntal Pod Autoscalerを使用して行われます。HPAコントローラーはデフォルトでCPU/メモリー使用量（またはカスタムメトリクス）を確認し、長い時間枠で動作します。そのため、突然のトラフィックスパイクへの反応は遅くなります。

一方、Knativeのオートスケールは«処理中のリクエスト»（同時実行性）によって駆動されます。サービスが処理できるよりも多くのリクエストを突然受け取った場合、Knativeはより短い時間枠で動作するため、より多くのPodをすばやく追加します。そのため、反応が迅速です。

KnativeはPodに来るすべてのリクエストを把握しています。3Knativeを使用すると、ソフトターゲットである«ターゲット同時実行»レベル、または各Podに送信される最大の実行リクエスト数を保証するハード«同時実行»制限を持つようにアプリを構成できます。並行処理の設定を念頭に置いて、Knativeオートスケーラーは受信リクエストを厳密に監視し、追加するPodの数をすばやく決定します。

在应用程序扩展期间，Knative将保留接收到的请求，并将请求代理到新的Pod，而不会丢弃请求。这在Kubernetes中是不可能的。

作为开发者，我更希望能够用一行配置写上「应用程序可以同时处理20个请求」，而不是在冗长的HorizontalPodAutoscaling清单中写上「以平均70％的CPU使用率为目标，在1到30个Pod之间进行扩展应用程序」。

さらに、Knativeはしばらくの間トラフィックを受信しないサービスに対して«0 Podへのスケールイン»を提供します（Kubernetesはネイティブにこれを行うことはできません4）。これは、Knative activatorコンポーネントを使用して実現されます。この機能はデフォルトでサーバーレス方式でオンになっているため、「コールドスタート」が発生します。ただし、簡単にオフにすることができます。

有关Knative自动缩放器的详细信息，请参考此博客文章、此文档和此示例。

作为Kubernetes的Knative

通过使用Knative部署的应用程序仍然是Kubernetes服务。它可以连接到其他Kubernetes服务，并可以使用本地Kubernetes服务发现进行连接。

Knative Services会作为Kubernetes Deployment进行部署。您可以通过Knative Service对象（例如）继续指定PodSpec的值（环境变量、卷挂载、其他细节）。

对于Kubernetes开发者来说，Knative进入门槛非常低。使用像Anthos上的Cloud Run这样的托管服务，您可以在云端和本地使用托管的Knative设置进行集群管理。

我认为很多Kubernetes用户目前都没有意识到Knative项目对他们的帮助。如果你对Knative的解释满意的话，请告诉我。我想继续写关于Knative的文章。