Knative = Kubernetes网络++


通常将Knative项目解释为“ Kubernetes上的无服务器”的构建基块。因此，大多数Kubernetes用户都不知道Knative可以为他们的非无服务器工作负载做什么：它可以 为Kubernetes上的无状态微服务提供更好的自动缩放和联网功能。
让我们暂时不谈“无服务器”。大多数Kubernetes用户遵循十二项应用程序声明编写微服务：服务应该是无状态的，并且可以通过request / RPC相互通信。但是Kubernetes不能真正满足微服务：

  • 需要为一个应用编写两个清单（部署，服务）
  • 没有针对HTTP / gRPC按请求/按RPC的负载平衡
  • 没有流量分配，因此无法轻松进行蓝色/绿色部署
  • 基于CPU /内存的自动缩放（通常很慢，而不是您所需要的）
  • 没有并发控制（即每个Pod最多N个正在进行中的请求）

安装在Kubernetes集群上的Knative Serving直接解决了Kubernetes的这些缺点：
  • Kubernetes Service + Deployment组合而成的«Service»对象
  • HTTP / gRPC的每个请求的负载平衡
  • 基于请求的快速自动缩放，反应迅速
  • 使用服务修订版进行流量拆分（蓝色/绿色部署）
  • 开箱即用的快速自动缩放功能，高度可配置
    • 比例缩放到零（挂起）和0到N（激活），也可配置
    • 并发控制（限制每个Pod的运行中请求）
  • （可选）对HTTP指标（延迟，请求等）的自动监视支持
  • （可选）自动TLS证书和外部端点的终止

在堆栈的关键路径上采用像Knative这样的新组件可能是一个艰难的决定。Knative项目的多个方面可能会改变您的想法：
  • Knative即将达到v1.0并变得“稳定”，拥有一个坚实的社区.
  • Knative是模块化的：您只能安装其服务组件。
  • Knative不再依赖Istio：Knative需要用于路由和流量拆分的负载平衡器，但是您可以使用Gloo或 Ambassador之类的替代方案，或专为Knative构建的网关代理（例如 Kourier）。

Knative«Service»API
Knative将Kubernetes Deployment + Service组合为一种Service类型。
Deployment通过更改apiVersion/ kind修剪一些不必要的部分，可以非常轻松地将大多数无状态Kubernetes 清单迁移到Knative ：

# modify this:
apiVersion: apps/v1
kind: Deployment

# to this:
apiVersion: serving.knative.dev/v1
kind: Service

每次更新Knative时Service，Revision都会创建一个新对象。 Revision对象是不可变的，迫使您拥有部署的快照。然后，您可以使用Revision对象在首次发布或直接回滚期间拆分流量。
Knative Serving提供了开发人员日常可能不会遇到的其他API，例如Configuration鼓励将您的代码和配置分开的（另一种12要素应用程序规范）。

自动缩放
作为开发人员，如果您在解决如何在Kubernetes中自动扩展微服务方面遇到问题，则有充分的理由。
Kubernetes自动缩放主要是使用Horizo​​ntal Pod Autoscaler完成的。HPA控制器会查看CPU /内存使用情况（或自定义指标），默认情况下会在很长时间内运行。因此， 对突发流量高峰的反应速度较慢。
另一方面，Knative自动缩放是由“进行中的请求”（并发）驱动的：如果您的服务突然收到超出其处理能力的请求，Knative将在较短的时间范围内迅速添加更多Pod。因此，反应更快。
Knative知道Pod的所有请求。使用Knative，您可以将应用程序配置为具有“目标并发性”级别，这是一个软性目标，或者是一个严格的“并发性”限制，以确保发送到每个Pod的最大运行中请求。考虑到并发设置，Knative自动缩放器会密切监视传入的请求并快速确定要添加的Pod数。
在扩大您的应用程序时，Knative会保留传入的请求，并将它们代理到新的Pod，而不会删除请求，这是Kubernetes不可能做到的。
作为一名开发人员，我更喜欢说“我的应用程序可以在一行配置中一次处理20个请求”，而不是在较长的Horizo​​ntalPodAutoscaling 清单中配置： “目标是平均70％CPU使用率并在1至30个容器之间缩放我的应用程序” 。
此外，Knative为一段时间内未收到流量的服务提供“从零扩展”（Kubernetes本身无法做到这一点4）。这可以通过使用Knative activator 组件来实现。默认情况下，此功能以无服务器方式打开，因此会导致“冷启动”。但是，可以轻松关闭它。
您可以参考此博客文章，此文档和本示例，以了解有关Knative自动缩放器的更多信息。

Knative仍然是Kubernetes
用Knative部署的应用程序仍然是Kubernetes服务，他们可以连接其他Kubernetes服务，也可以使用本机Kubernetes服务发现进行连接。
Knative Services部署为Kubernetes Deployments，仍然可以通过Knative Service对象（示例）来指定PodSpec值（环境变量，卷安装和其他详细信息）。
对于Kubernetes开发人员而言，Knative的进入门槛非常低。借助诸如Anthos上的Cloud Run之类的托管服务，您可以在群集中的云端或本地群集中拥有托管Knative设置。

点击标题见原文。