04-Revision和流量管理

1 Revision

关于Revision
- 应用程序代码及相关容器配置某个版本的不可变快照
- KService上的spec.template的每次变动，都会自动生成一个新的Revision
- 通常不需要手动创建及维护
Revision的使用场景
- 将流量切分至不同版本的应用程序间（Canary Deployment、Blue/Green Deployment）
- 版本回滚: 默认的流量策略中，所有的请求都会由就绪状态的最新版本的Revision处理

2 KService的客户端流量处理

集群外部流量
- 通过KService的外部名称（ksvc-name.namespace.DOMAIN）将流量发给入口网关（例如istio-ingressgateway的Service使用的ExternalIP）的外部地址
  - 需要在集群外部的DNS系统上设定相应的名称解析
  - 暴露的服务较多时，可以使用泛域名解析
- 通过KService使用的Domainmapping中定义的名称，将流量发往入口网关的外部地址
集群内部流量
- 未启用mesh时：通过KService的内部名称（ksvc-name.namespace.DOMAIN）将流量发往Knative使用的istio-system名称空间下的knative专用本地流量网关knative-local-gateway
- 启用mesh时，流量将由mesh根据流量策略进行转发。此时，无须再设置本地流量网关
支撑一个KService对象的流量转发的关键是Route

3 Route

Route
- 由KService的spec.traffic自动生成
- 未定义时，将由就绪状态的Revision列表中的最新版本的Revision接收和处理该KService的所有请求
- Route依托入口网关和网格（或本地网关）完成流量转发
- Route会自动按需创建如下资源
  - Kubernetes Service
  - Istio VirtualService（以Istio为网络层时）
配置Private KService
- 默认情况下，KService会由Knative同时配置内部（私有）或公共服务
- 仅创建私有服务的方法,不暴露外部
  - 全局配置：修改configmap/config-domain，将默认域设置为svc.cluster.local；
  - 单KService配置：使用“networking.knative.dev/visibility”标签，并设定其值为cluster-local
    - 设定于KService对象之上
    - 无KService时，设定于相关的Route和Kubernetes Service之上
- 示例：~$ kubectl label ksvc hello networking.knative.dev/visibility=cluster-local
  - 提示：若为ksvc/hello设置了域名映射，则外部客户端依然可通过该映射对其进行访问

4 自定义流量策略

修改Kservice流量策略的方法
- 命令行：kn service update <service-name> --traffic revisionRef=percent
  - 引用revision的方法：revisonName、Tag，以及使用“@latest”引用最新的就绪版本
  - "–traffic"选项可以多次使用，直到全部的流量比例之和为100%
- 在Kservice的资源配置上，使用spec.traffic进行定义
- 为目标Kservice创建自定义Route资源，为其配置临时流量策略。

命令行配置示例

创建kservice/hello, 有2个revision： revision-001: hello world, revision-002: hello knative

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hello
spec:template:spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "World"
---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hello
spec:template:spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "knative"

目前有2个revision，默认100%流量会到最新的那个revision
将流量完全发送给hello-00001这个Revision(rollback)
```
kn service update hello --traffic hello-00001=100
```
可以发现立即生效，所有的流量立马切换到Hello-00001的Revision：

将流量切分至不同的Reviision

kn service update hello --traffic hello-00001=10 --traffic hello-00002=90

验证：

在这里插入图片描述

将流量完全发送至最新的版本Revision
```
kn service update hello --traffic '@latest'=100
```
验证：将全部流量发送给最新的Revision

资源配置清单

将流量发送给最新版本10%, revision-2 70%,revision-1 20%

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hello
spec:template:spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Little boy"traffic:- latestRevision: truepercent: 10- revisionName: hello-00002percent: 70- revisionName: hello-00001percent: 20

验证：基本7-2-1比例

在这里插入图片描述

5 路由标签（tag）

场景：可以为特定的Revision打上tag,然后可以通过特定的URL格式来访问
- 附带tag的路由项指向的Revision，可通过<tag-name>-<ksvc-name>.<namespace>.<domain>的歌格式访问；
- 无tag的路由项，仅可通过<ksvc-name>.<namespace>.<domain>的格式访问

管理标签的方法

在Traffic Target上直接配置

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: hello
spec:template:spec:containers:- image: ikubernetes/helloworld-goports:- containerPort: 8080env:- name: TARGETvalue: "Cloud-Native"traffic:- latestRevision: truepercent: 0tag: staging- revisionName: hello-00002percent: 90- revisionName: hello-00001percent: 10

命令
- 设定标签：kn service update <ksvc> --tag revisionRef=tagNmae
- 删除标签: kn service update <ksvc> --untag tagName

示例

先给hello-00001打上tag名字为staging的标签：

kn service update hello --tag hello-00001=staging

kubectl get ksvc hello -o yaml

在这里插入图片描述

访问带tag的revision 00001

curl -H "Host: staging-hello.default.icloud2native.com" 192.168.58.100

在这里插入图片描述

6 Configuration Target和流量逐步迁移

Configuration Target
- ConfigurationName也可以作为路由项中的流量目标，意味着相关的流量部分由该Configurate下最新就绪的Revision承载
- 存在问题
  - 在新的Revision就绪之后，Configuration Target上的所有流量会立即转移至该Revision
  - 这可能会导致QP或Activator的请求队列过长，以至于部分请求可能会被拒绝
- 解决方式
  - 在KService或Route上使用“serving.knative.dev/rollout-duration”注解来指定流量迁移过程的时长；新的Revision上线后，它会先从Configuration Target迁出1%的流量；随后再等分迁出余下的流量部分
  - 配置案例
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloannotations:serving.knative.dev/rollout-duration: "380s"
spec:
...traffic:- percent: 55configurationName: hello # Pinned to latest ready Revision- percent: 45revisionName: hello-00001 # Pinned to a specific Revision.
```