Knative快速入门与实践

前言

Serverless最重要三个特征

1. 隐藏了服务器的复杂性
2. 按需付费
3. 弹性伸缩

---

第1章 Knative入门

Knative有两个关键模块

Knative服务模块（Serving）

Knative服务模块提供了简化的部署语法来使服务在Kubernetes集群中运行，并且这些服务具备根据HTTP负载自动扩容或者缩容到零的能力

Knative事件模块（Eventing）

可以将Knative Service和其他的事件流系统（如Apache Kafka主题等）通过非HTTP方式连接起来

如何切换命名空间

$ kubectl config set-context --current --namespace=chapter-1

或者使用kubens将当前命名空间设置为chapter-1

$ kubens chapter-1

---

第2章 理解Knative服务模块

Knative服务模块通过提供更加简化的语法来部署应用，它会基于HTTP负载的变化选择自动扩容或者缩容到零，Knative平台将会管理服务的部署、版本、网络和扩缩容
Knative服务模块通过HTTP URL暴露服务，并且具有这么多安全的默认配置

Knative Service部署模型

在部署Knative Service过程中，Knative Service控制器会生成Knative配置、Knative修订版本（Revision）、Knative路由（Route）

Knative配置

表示服务部署期望状态，并使用微服务开发的12要素应用将代码和配置完全分离。基于期望状态，Knative配置控制器会为你的服务生成一个Kubernetes部署（Deployment）资源，每次对Knative配置的更改都会产生一个新的Kubernetes配置

Knative修订版本

每次对配置的更改都会产生一个新的修订版本。Knative修订版本类似于版本控制标签，它是不可变的。每个Knative修订版本都有一个与之关联的Kubernetes部署，因此可以将应用回滚到任何一个正确的配置版本

Knative路由

用于访问或调用Knative服务的URL

ksvc是Knative Service自定义资源（Knative Service Custom Resource）的简称，在Kubernetes集群中可通过以下命令查询

$ kubectl api-resources --api-group=serving.kative.dev

12要素应用

是一种构建SaaS应用的方法，为构建SaaS应用提供了方法论

1. 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目
2. 和操作系统间尽可能划清界限，在各个系统中提供最大的可移植性
3. 选择适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源
4. 将开发环境和生产环境的差异降到最低，并使用持续交付实施敏捷开发
5. 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序

部署Knative Service

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: greeter ❶
spec:
  template:
    metadata
      name: greeter-v1 ❷
    spec:
      containers:
      - image: quay.io/rhdevelopers/knative-tutorial-greeter:quarkus
        livenessProbe:
          httpGet:
            path: /healthz
        readinessProbe:
          httpGet:
            path: /healthz

❶ 服务名称。此Knative Service创建的所有Kubernetes资源都将在greeter为前缀

❷ Knative修订版本名字。如果不写，则Knative会自动生成

运行命令创建Knative Service greeter

$ kubectl -n chapter-2 apply -f service.yaml

使用命令kubectl get ksvc查询可用的ksvc服务

$ kubectl -n chapter-2 get ksvc greeter

Knative配置表示的是Knative Service的当前状态，即ksvc的哪个修订版本需要接收请求。当前应该只有一个修订版本；greeter-v1，因此执行kubectl -n chapter-2 get configurations greeter命令的结果应该是

$ kubectl get configrations greeter

更新Knative配置

12要素应用规定：对应用程序配置的任何更改均视为新修订，修订版本是不可变的，表示某个版本下的应用程序和配置状态。利用修订版本可以回滚到任何一个已知的历史状态
下图所示的Knative Service部署模型，一个ksvc生成一个配置，一个配置生成一个修订版本，一个修订版本生成一个部署，一个部署生成一个副本集（ReplicaSet），最终由副本集生成Pod来运行Knative Service
每次对Knative应用的更改，比如修改镜像、修改存活探针、修改环境变量等，都会导致Knative生成一个新的修订版本。每个修订版本都会生成一个相应的Kubernetes部署

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: greeter
spec:
  template:
    spec:
      containers:
        - image: quay.io/rhdevelopers/knative-tutorial-greeter:quarkus
          env:
            - name: MESSAGE_PREFIX
              value: Namaste
          livenessProbe:
            httpGet:
              path: /healthz
          readinessProbe:
            httpGet:
              path: /healthz
  traffic:
    - tag: v1
      revisionName: greeter-v1
      percent: 100
    - tag: v2
      revisionName: greeter-v2
      percent: 0
    - tag: latest
      latestRevision: true
      percent: 0

如果greeter-v1在60s（Knative默认的冷却窗口）内没有收到请求，那么实例数会自动缩容到0.当然这也是Knative通过Serverless服务帮你节省云计算资源的关键
对Knative Service的任何修改都会产生一个新的修订版本。现在对于Knative Service greeter应该有两个修订版本。使用以下命令查看这两个修订版本

$ kubectl -n chapter-2 get revisions

可以看到两个版本，分别为greeter-v1和greeter-v2
可以看到有个新的修订版本扩容出来了，不过并不会生成新的路由、ksvc和配置，可通过下面的指令来查看对应的Knative资源

❶ kubectl get routes

❷ kubectl get ksvc

❸ kubectl get configurations

设置Knative Service版本间分流

可通过Knative Service中的traffic设置来控制不同版本之间的流量分布。Knative Serving YAML的流量设置traffic描述了具体的流量分配方法，例如

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: greeter
spec:
  template:
    spec:
  traffic: ❶
    - tag: v1 ❷
      revisionName: greeter-v1 ❸
      percent: 50 ❹
    - tag: v2
      revisionName: greeter-v2
      percent: 50

❶ traffic描述的流量分配

❷ tag表示当前服务的版本，在traffic中是唯一的

❸ revisionName表示当前流量分配指定的版本

❹ 当前版本接收的流量的百分比，注意这里所有的版本接收的流量的百分比总和需要确保是100%
Knative服务模块为每个标识符创建了一个唯一的服务URL。可以使用以下命令查询

$ kubectl -n chapter-2 get ksvc greeter -oyaml | yq -r 'status.traffic[*.url]'

---

第3章 Knative自动扩缩容

Knative通过缩容到零（scale-to-zero）和自动扩缩容（autoscaling）特性能够有效地满足这些需求
HPA依赖于3个重要指标

❶ 并发数

❷ 每秒请求数

❸ CPU

KPA可以看作HPA的扩展版本，对默认HPA算法进行了一些调整，使其能更适应且更快速地响应并处理流量驱动的Knative扩缩容需求

配置Knative Service自动扩缩容

Kubernetes的knative-serving命名空间下的ConfigMap config-autoscaler定义了所有关于缩容到零和自动扩缩容的参数 。可以用kubectl命令查看该ConfigMap

$ kubectl -n knative-serving get cm config-autoscaler -o yaml

以下代码段展示了ConfigMap config-autoscaler的简要内容。重点看本章示例的一些参数 ，如下所示

apiVersion: serving.knative.dev/v1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    autoscaler:
      container-concurrency-target-default: '100' ❶
      enable-scale-to-zero: 'true' ❷
      stable-window: 60s ❸
      scale-to-zero-grace-period: 30s ❹

❶ 每个服务Pod能随的最大请求并发数，默认值是100

❷ 是否允许缩容到零，默认值是true

❸ 监听请求调用次数和相关指标的时间窗口，默认值是60s

❹ 非活跃Pod被终止的时间窗口，默认值是30s

缩容到零（即Knative终止非活跃Pod的能力）可以由参数enable-scale-to-zero配置。enable-scale-to-zero默认值为true，表示如果Knative在stable-window时间窗口内未再收到请求，则会尝试启动Knative的缩容到零功能。将此参数设置为false，可以禁用此功能

stable-window表示监听请求数指标的时间窗口。在默认情况下，如果Pod过去60s内未收到新的请求，则自动扩缩容会通过将Pod标记为inactive来启动缩容到零功能
Stable-to-zero-grace-period是自动扩缩容监听被标记为inactive的Pod的时间窗口，并且在这个时间段内，自动扩缩容会尝试终止被标记为inactive的Pod

配置Knative Service以处理突发请求

配置Knative Service的默认并发数来处理突增的请求。

在Knative Service的YAML配置中，可以加上注解来覆盖默认值和自动扩容参数

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: preference
  labels:
    serving.knative.dev/visibility: "cluster-local"
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10" ❶
    spec:
      containers:
        - image: quay.io/rhdevelopers/istio-tutorial-preference:v1
          env:
            - name: COM_REDHAT_DEVELOPER_DEMOS_CUSTOMER_REST_RECOMMENDATIONSERVICE_MP_REST_URL
              value: "http://recommendation.knativetutorial.svc.cluster.local"

❶ 配置Pod的并发数是10

使用hey工具进行压测

$ hey -c 50 -z 10s \ ❶
  -host "$HOST_HEADER" \ ❷
  "http://$IP_ADDRESS/?sleep=3&upto=10000&memload=100" ❸

❶ 表示使用hey负载测试工具时间是10s，并且请求并发数是50

❷ 和之前一样，设置请求头HOST。在这个例子中，我们将其设置成prime-generator.chapter-3.example

❸ 对应的是请求URL，具体如下

• sleep，模拟慢请求行为，通过将sleep设置为3s来模拟
• upto，不断计算生成质数，直到最大值
• memload，模拟内存负载为100MB
  观察Pod扩容过程

$ watch kubectl get pods

---

第4章 Knative事件模块

Knative事件模块有3种主要使用方法

事件源到接收器（Source to Sink）模式

是最简单的方法。提供了单个接收器，即事件接收服务，该服务不需要队列、背压和过滤。事件源到接收器模式不支持事件回复，意味着接收消息而不需要返回值。事件源只负责传递消息，而不会等待接收器的回复。可以把事件源到接收器模式比作发后不理（fire and forget）消息模式

图4-1 事件源到接收器模式

source-sink

管道与订阅（channel and subscription）模式

在管道与订阅模式下，Knative事件模式定义了一个管道，可以连接多个后端，例如内存、Kafka和GCP PubSub作为事件源。如图所示，在接收器服务框中，每个管道都至少有一个订阅者，每个订阅者都可以接收事件消息并按需处理。管道中的消息都会被格式化成标准CloudEvents，并且继续往后发送给其他订阅者以进行下一步的处理。管道与订阅模式不具备过滤消息的能力

图4-2 管道与订阅模式

channels-subs

代理与触发器（Broker and Trigger）模式

代理与触发器模式类似于管道与订阅模式，但是它支持过滤消息。消息过滤机制允许订阅者订阅它感兴趣的来自代理的消息。Knative事件模块会给每个代理默认创建一个Knative事件模块管道。如图4-3所示，每个触发器都可以从代理处订阅消息，并且在其对应的代理上设置消息过滤。过滤器会在消息分发到消息接收器服务（订阅者）之前生效

brokers-triggers

使用事件源产生事件

Knative事件源是指那些可以产生事件的组件。事件源的职责是连接、限流、捕获和缓存外部系统的事件，并且将这些事件传递给接收器
Knative事件源安装了4个开箱即用的事件源

$ kubectl api-resources --api-group=sources.eventing.knative.dev

查看eventinghello Pod日志

$ stern eventinghello -c user-container