Knative = Kubernetes网络++

原文转载自 「解道JDON」 (https://www.jdon.com/53390)

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

通常将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设置。

点击标题见原文。

                   

more_vert