OpenShift 4.3 之Knative-Tutorial(4) 自动扩展和收缩

自动扩展和收缩功能说明

在自动扩展和收缩过程中，Revision 有三种状态：

1. Active：当他们活跃地服务请求时。在Active状态下，每个Revision都有一个Deployment，用以维护所需数量的Pod。 它还有一个Autoscaler（单租户时每个Revision一个;多租户时所有Revision用一个），Autoscaler监视流量指标并调整部署所需的pod数量。每个Pod每秒钟向Autoscaler报告其并发请求数。
2. Reserve：当他们缩小到0个Pod。在Reserve状态下，Revision没有预定的Pod并且不使用CPU。Revision的Istio路由规则指向单个多租户Activator，Activator将捕获所有到Reserve Revision的流量。当Activator捕获一个Reserve Revision的请求时，它会将Revision修改为Active状态，然后在准备就绪时将请求转发给Revision。
3. Retired：当他们将不再接收流量。

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

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

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

假设一个Knative服务一旦不再看到流量进入它，我们希望将此服务收缩到零个副本。这称为"缩放到零"。缩放到零是使 Knative 成为无服务器平台的主要属性之一。在定义的空闲时间（所谓的稳定窗口）后，Revision被视为非活动。此时指向现在非活动Revision的所有路由都将指向所谓的Activator。由于这种网络的重新指向是异步的，因此应提供足够的宽延时间，这个时间就为scale-to-zero-grace-period。当scale-to-zero-grace-period结束后，Revision最终将缩放为零副本。此时如果再有请求尝试获访问Revision，Activator将获取它，指示Autoscaler尽快为Revision创建新的 Pod，并缓冲请求，直到创建Pod成功。

Knative将定义Autoscaler的配置参数放在knative-serving项目中的一个ConfigMap对象中。我们可以查看该对象。

$ oc get cm -n knative-serving
NAME                   DATA   AGE
config-autoscaler      11     17h
config-defaults        6      17h
config-deployment      3      17h
config-domain          2      17h
config-gc              5      17h
config-istio           3      17h
config-logging         6      17h
config-network         2      17h
config-observability   3      17h
config-service-ca      1      17h
config-tracing         3      17h
 
$ oc get cm config-autoscaler -oyaml -n knative-serving
apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
  container-concurrency-target-default: "100"
  container-concurrency-target-percentage: "1.0"
  enable-scale-to-zero: "true"
  max-scale-up-rate: "10"
  panic-threshold-percentage: "200.0"
  panic-window: 6s
  panic-window-percentage: "10.0"
  scale-to-zero-grace-period: 30s
  stable-window: 60s
  tick-interval: 2s

1. container-concurrency-target-default：指定一个容器最多处理的并发请求。
2. container-concurrency-target-percentage：在稳定状态情况下，使用container-concurrency-target-default最大值比例，例如0.7代表70%的比例。如果Revision指定container-concurrency-target-default为 10，则Autoscaler将为每个Pod尝试维护 7 个并发连接 。
3. enable-scale-to-zero：是否可以收缩到零个。
4. max-scale-up-rate：在一个Autoscaler扩展期间，最高的扩展倍数。如果是10，代表一次可以将Pod从N扩展到10N。
5. panic-window：panic模式的监控时间窗口长度。
6. panic-window-percentage：在panic-window内，当Container的并发处理达到container-concurrency-target的百分比（例如200%），就进入panic模式。
7. panic-window-percentage：Panic窗口和Stable窗口的时间比。
8. tick-interval：每次计算是否Autoscaler的时间间隔。

配置自动扩展收缩

1. 创建以下内容的prime-service.yaml文件。它定义了每个Pod能处理10个并发请求。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: prime-generator
spec:
  template:
    metadata:
      annotations:
        # Target 10 in-flight-requests per pod.
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: quay.io/rhdevelopers/prime-generator:v27-quarkus
        livenessProbe:
          httpGet:
            path: /healthz
        readinessProbe:
          httpGet:
            path: /healthz

2. 确认环境中有hey应用。如果没有，在此下载。
3. 执行命令，向prime-generator的route持续发送请求。

$ hey -c 50 -z 10s $(kn route list prime-generator | grep prime-generator | awk '{print $2}')/?sleep=3&upto=10000&memload=100
[1] 11849
[2] 11850
[2]+  Done                    upto=10000

4. 稍后运行以下命令查看Pod数量，可以看到Knative通过Autoscaler启动了5个Pod处理请求。

$ oc get pod
NAME                                                READY   STATUS              RESTARTS   AGE
prime-generator-z48n5-deployment-6c76646b79-68w7b   2/2     Running             0          9s
prime-generator-z48n5-deployment-6c76646b79-ffdf5   2/2     Running             0          12s
prime-generator-z48n5-deployment-6c76646b79-fhqtg   0/2     ContainerCreating   0          11s
prime-generator-z48n5-deployment-6c76646b79-kx7vs   0/2     ContainerCreating   0          7s
prime-generator-z48n5-deployment-6c76646b79-pkf22   0/2     ContainerCreating   0          11s

配置扩展收缩上下限

在Knative服务实际运行中Knative 以默认的 1 个副本启动每个服务。如果应用启动时间很长，但还需要在任何情况下保持及时响应，则可通过设置autoscaling.knative.dev/minScale的注释来保留最少运行的 Pod 数。

1. 创建以下内容的service-min-max-scale.yaml文件。其中定义了Autoscaler上下限是10-2。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: prime-generator
spec:
  template:
    metadata:
      annotations:
        # the minimum number of pods to scale down to
        autoscaling.knative.dev/minScale: "2"
        # Target 10 in-flight-requests per pod.
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: quay.io/rhdevelopers/prime-generator:v27-quarkus
        livenessProbe:
          httpGet:
            path: /healthz
        readinessProbe:
          httpGet:
            path: /healthz

2. 运行命令，更新prime-generator的Service配置。

$ oc apply -f service-min-max-scale.yaml

3. 查看当前Pod数量为2。

$ oc get pod
NAME                                               READY   STATUS    RESTARTS   AGE
prime-generator-qz46n-deployment-9d68c8d7c-5zr4q   2/2     Running   0          10s
prime-generator-qz46n-deployment-9d68c8d7c-mz59q   1/2     Running   0          9s