04-Revision和流量管理
2023-12-18 19:18:14
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中定义的名称,将流量发往入口网关的外部地址
- 通过KService的外部名称(ksvc-name.namespace.DOMAIN)将流量发给入口网关(例如istio-ingressgateway的Service使用的ExternalIP)的外部地址
- 集群内部流量
- 未启用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-go ports: - containerPort: 8080 env: - name: TARGET value: "World" --- apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello spec: template: spec: containers: - image: ikubernetes/helloworld-go ports: - containerPort: 8080 env: - name: TARGET value: "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-go ports: - containerPort: 8080 env: - name: TARGET value: "Little boy" traffic: - latestRevision: true percent: 10 - revisionName: hello-00002 percent: 70 - revisionName: hello-00001 percent: 20
验证:基本7-2-1比例
-
5 路由标签(tag)
-
场景:可以为特定的Revision打上tag,然后可以通过特定的URL格式来访问
- 附带tag的路由项指向的Revision,可通过
<tag-name>-<ksvc-name>.<namespace>.<domain>
的歌格式访问; - 无tag的路由项,仅可通过
<ksvc-name>.<namespace>.<domain>
的格式访问
- 附带tag的路由项指向的Revision,可通过
-
管理标签的方法
-
在Traffic Target上直接配置
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello spec: template: spec: containers: - image: ikubernetes/helloworld-go ports: - containerPort: 8080 env: - name: TARGET value: "Cloud-Native" traffic: - latestRevision: true percent: 0 tag: staging - revisionName: hello-00002 percent: 90 - revisionName: hello-00001 percent: 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: hello annotations: serving.knative.dev/rollout-duration: "380s" spec: ... traffic: - percent: 55 configurationName: hello # Pinned to latest ready Revision - percent: 45 revisionName: hello-00001 # Pinned to a specific Revision.
-
-
文章来源:https://blog.csdn.net/weixin_38753143/article/details/135068522
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!