Knative-serving资源详解

最新推荐文章于 2022-04-29 10:08:12 发布

转战容器化

最新推荐文章于 2022-04-29 10:08:12 发布

阅读量1k

点赞数

分类专栏： knative 文章标签： kubernetes

本文链接：https://blog.csdn.net/weixin_45710811/article/details/121722020

版权

knative 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Knative-serving资源详解

Knative-serving资源详解

Knative-serving资源详解

友情链接：Knative简介
友情链接：Knative-serving安装

1.Configuration（配置）和 Revision（修订版本）

Knative Serving 始于 Configuration。您可以在 Configuration 中为部署定义所需的状态。最小化 Configuration 至少包括一个配置名称和一个要部署容器镜像的引用。在 Knative 中，定义的引用为 Revision。Revision 代表一个不变的，某一时刻的代码和 Configuration 的快照。每个 Revision 引用一个特定的容器镜像和运行它所需要的任何特定对象（例如环境变量和卷）。然而，您不必显式创建 Revision。由于 Revision 是不变的，它们从不会被改变和删除，相反，当您修改 Configuration 的时候，Knative 会创建一个 Revision。这允许一个 Configuration 既反映工作负载的当前状态，同时也维护一个它自己的历史 Revision 列表。

例如：

apiVersion: serving.knative.dev/v1alpha1
kind: Configuration
metadata:
  name: knative-helloworld
  namespace: default
spec:
  revisionTemplate:
    spec:
      container:
        image: docker.io/gswk/knative-helloworld:latest
        env:
          - name: MESSAGE
            value: "Knative!"
        ports:
          - containerPort: 8081

其中默认情况下，Knative 将假定您的应用程序监听 8080 端口。

Configuration 可以指定一个已有的容器镜像。或者，它也可以选择指向一个 Build 资源以从源代码创建一个容器镜像。

Knative 转换 Configuration 定义为一些 Kubernetes 对象并在集群中创建它们。在启用 Configuration 后，可以看到相应的 Deployment、ReplicaSet 和 Pod。

2.Route（路由）

Knative 中的 Route 提供了一种将流量路由到正在运行的代码的机制。它将一个命名的，HTTP 可寻址端点映射到一个或者多个 Revision。Configuration 本身并不定义 Route

apiVersion: serving.knative.dev/v1alpha1
kind: Route
metadata:
  name: knative-helloworld
  namespace: default
spec:
  traffic:
  - configurationName: knative-helloworld
percent: 100

这里展示了一个将流量发送到指定 Configuration 最新 Revision 的最基本路由定义。

这个定义中，Route 发送 100% 流量到由 configurationName 属性指定 Configuration 的最新就绪 Revision，该 Revision 由 Configuration YAML 中 latestReadyRevisionName 属性定义。您可以通过发送如下 curl 命令来测试这些 Route 和 Configuration ：

此访问地址可以参考kubectl get knative获取的路由路径
<network-layer>：是安装knative-serving时安装的网络层访问地址

curl -H "Host: knative-routing-demo.default.example.com"
http://<network-layer>

你可以通过指定流量版本名称

apiVersion: serving.knative.dev/v1alpha1
kind: Route
metadata:
  name: knative-routing-demo
  namespace: default
spec:
  traffic:
  - revisionName: knative-routing-demo-00001
    name: v1
    percent: 100

指定的 Revision 可以使用 v1 子域名访问，如下 curl 命令所示：

此访问地址可以参考kubectl get knative获取的路由路径
<network-layer>：是安装knative-serving时安装的网络层访问地址

curl -H "Host: v1.knative-routing-demo.default.example.com"
http://<network-layer>

Knative 也允许以百分比的方式跨 Revision 进行流量分配。支持诸如增量发布、蓝绿部署或者其他复杂的路由场景

3.Autoscaler（自动伸缩器）和 Activator（激活器）

Serverless 的一个关键原则是可以按需扩容以满足需要和缩容以节省资源。Serverless 负载应当可以一直缩容至零。这意味着如果没有请求进入，则不会运行容器实例。Knative 使用两个关键组件以实现该功能。它将 Autoscaler 和 Activator 实现为集群中的 Pod。您可以看到它们伴随其他 Serving 组件一起运行在 knative-serving 命名空间中.

在这里插入图片描述

Autoscaler 收集打到 Revision 并发请求数量的有关信息。为了做到这一点，它在 Revision Pod 内运行一个称之为 queue-proxy 的容器，该 Pod 中也运行用户提供的 (user-provided) 镜像。可以在相应 Revision Pod 上，通过运行 kubectl describe 命令可以看到这些容器

...
Containers:
  user-container:
    Container ID:  docker://f02dc...
    Image:         index.docker.io/gswk/knative-helloworld...
...
  queue-proxy: 
    Container ID:  docker://1afcb...
    Image:         gcr.io/knative-releases/github.com/knative...
...

queue-proxy 检测该 Revision 上观察到的并发量，然后它每隔一秒将此数据发送到 Autoscaler。Autoscaler 每两秒对这些指标进行评估。基于评估的结果，它增加或者减少 Revision 部署的规模。

默认情况下，Autoscaler 尝试维持每 Pod 每秒平均 100 个并发请求。这些并发目标和平均并发窗口均可以变化。Autoscaler 也能够被配置为利用 Kubernets HPA (Horizontal Pod Autoscaler) 来替代该默认配置。

这将基于 CPU 使用率来自动伸缩但不支持缩容至零。这些设定都能够通过 Revision 元数据注解 (annotations) 定制。

例如，一个 Revision 每秒收到 350 个请求并且每次请求大约需要处理 0.5 秒。使用默认设置 (每 Pod 100 个并发请求)，这个 Revision 将扩展至两个 Pod：

350 * .5 = 175
175 / 100 = 1.75
ceil(1.75) = 2 pods

Autoscaler 也负责缩容至零。Revision 处于 Active (激活) 状态才接受请求。当一个 Revision 停止接受请求时，Autoscaler 将其置为 Reserve (待命) 状态，条件是每 Pod 平均并发必须持续 30 秒保持为 0 (这是默认设置，但可以配置)。

处于 Reserve 状态下，一个 Revision 底层部署缩容至零并且所有到它的流量均路由至 Activator。Activator 是一个共享组件，其捕获所有到待命 Revisios 的流量。当它收到一个到某一待命 Revision 的请求后，它转变 Revision 状态至 Active。然后代理请求至合适的 Pods。

3.1 Autoscaler 如何伸缩

Autoscaler 采用的伸缩算法针对两个独立的时间间隔计算所有数据点的平均值。它维护两个时间窗，分别是 60 秒和 6 秒。Autoscaler 使用这些数据以两种模式运作：Stable Mode (稳定模式) 和 Panic Mode (忙乱模式)。在 Stable 模式下，它使用 60 秒时间窗平均值决定如何伸缩部署以满足期望的并发量。如果 6 秒窗口的平均并发量两次到达期望目标，Autoscaler 转换为 Panic Mode 并使用 6 秒时间窗。这让它更加快捷的响应瞬间流量的增长。它也仅仅在 Panic Mode 期间扩容以防止 Pod 数量快速波动。如果超过 60 秒没有扩容发生，Autoscaler 会转换回 Stable Mode。

4.service

在 Knative 中，Service 管理负责的整个生命周期。包括部署、路由和回滚。（不要将 Knative Service 和 Kubernetes Service 混淆。它们是不同的资源。） Knative Service 控制一系列组成软件的 Route 和 Configuration。Knative Service 可以被看作是一段代码 —— 您正在部署的应用或者函数。

一个 Service 注意确保一个应用有一个 Route、一个 Configuation，以及为每次 Service 更新产生的一个新 Revision。当创建一个 Service 时，您没有特别定义一个 Route，Knative 创建一个发送流量到最新 Revision 的路由。您可以选择一个特定的 Revision 以路由流量到该 Revision。

不要求您明确创建一个 Service。Route 和 Configuration 可以被分开在不同的 YAML 文件。在这种情形下，您可以应用每个单独的对象到集群。然而，推荐的方式使用一个 Service 来编排 Route 和 Configuration。

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: knative-helloworld
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: docker.io/gswk/knative-helloworld:latest

注意这个 service.yml 文件和 configuration.yml 非常相似。这个文件定义 Configuration 并且是最小化 Service 定义。由于这里没有 Route 定义，一个默认 Route 指向最新 Revision。Service 控制器整体追踪它所有的 configuration 和 Route 的状态。然后反映这些状态在它的 ConfigurationsReady 和 RoutesReady conditions 属性里。当通过 CLI 使用 kubectl get ksvc 命令请求 Knative Service 信息的时候，这些状态可以被看到。

# kubectl get ksvc xxx -o yaml

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
...
  name: knative-helloworld
  namespace: default
...
spec:
...
status:
conditions:
  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ
    status: "True"
    type: ConfigurationsReady
  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ
    status: "True"
    type: Ready
  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ
    status: "True"
    type: RoutesReady
  domain: knative-helloworld.default.example.com
  domainInternal: knative-helloworld.default.svc.cluster.local
  latestCreatedRevisionName: knative-helloworld-00001
  latestReadyRevisionName: knative-helloworld-00001
  observedGeneration: 1
  targetable:
    domainInternal: knative-helloworld.default.svc.cluster.local
  traffic:
  - percent: 100
    revisionName: knative-helloworld-00001

5.总结

Knative-serving的资源有Service、Route、Configuration 和 Revision。Revision 是不变的并且只能经由 Configuration 改变而被创建。您可以分别单独创建 Configuration 和 Route，或者把它们组合在一起并定义为一个 Service。理解 Serving 组件的这些构建块是使用 Knative 的基础。您部署的应用均需要一个 Service 或者 Configuration 以在 Knative 中作为容器运行。