04-Revision和流量管理

本文主要是介绍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.
      

这篇关于04-Revision和流量管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---