04-Revision和流量管理

发布时间:2023年12月18日

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-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>的格式访问
  • 管理标签的方法

    • 在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
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。