流量管理

您可以通过修改 Service 资源的 traffic 规范来管理到 Knative Service 不同修订版本的流量路由。

当您创建 Knative Service 时，它没有任何默认的 traffic 规范设置。通过设置 traffic 规范，您可以将流量拆分到任意数量的固定修订版本，或者通过在 Service 的规范中设置 latestRevision: true 来将流量发送到最新的修订版本。

使用标签创建目标 URL

在以下示例中，规范定义了一个名为 tag 的属性。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - percent: 0
    revisionName: example-service-1
    tag: staging
  - percent: 40
    revisionName: example-service-2
  - percent: 60
    revisionName: example-service-3

当将 tag 属性应用于路由时，将为特定流量目标创建地址。

在本示例中，您可以通过访问 staging-<route name>.<namespace>.<domain> 来访问暂存目标。example-service-2 和 example-service-3 的目标只能使用主路由 <route name>.<namespace>.<domain> 访问。

当流量目标被标记时，会为该 Service 创建一个新的 Kubernetes Service，以便其他 Service 可以在集群内访问它。从前面的示例中，将在同一个命名空间中创建一个名为 staging-<route name> 的新 Kubernetes Service。该 Service 可以通过应用值为 cluster-local 的标签 networking.knative.dev/visibility 来覆盖此特定路由的可见性。有关如何限制特定路由可见性的更多信息，请参见有关 私有服务 的文档。

流量路由示例

以下示例显示了一个 traffic 规范，其中 100% 的流量被路由到 Service 的 latestRevision。在 status 下，您可以看到 latestRevision 解析到的最新修订版本的名称。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - latestRevision: true
    percent: 100
status:
  ...
  traffic:
  - percent: 100
    revisionName: example-service-1

以下示例显示了一个 traffic 规范，其中 100% 的流量被路由到 current 修订版本，并且该修订版本的名称指定为 example-service-1。即使没有流量被路由到最新就绪的修订版本，它也会保持可用。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0

以下示例显示了如何扩展 traffic 规范中的修订版本列表，以便在多个修订版本之间拆分流量。此示例将 50% 的流量发送到 current 修订版本 example-service-1，并将 50% 的流量发送到 candidate 修订版本 example-service-2。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0

使用 Knative CLI 路由和管理流量

您可以使用以下 kn CLI 命令在修订版本之间拆分流量。

kn service update <service-name> --traffic <revision-name>=<percent>

其中

• <service-name> 是您要为其配置流量路由的 Knative Service 的名称。
• <revision-name> 是您要配置为接收一定比例流量的修订版本的名称。
• <percent> 是您要发送到 <revision-name> 指定的修订版本的流量百分比。

例如，要拆分名为 example 的 Service 的流量，通过将 80% 的流量发送到修订版本 green，将 20% 的流量发送到修订版本 blue，您可以运行以下命令。

kn service update example-service --traffic green=80 --traffic blue=20

也可以向修订版本添加标签，然后根据您设置的标签拆分流量。

kn service update example --tag revision-0001=green --tag @latest=blue

@latest 标签表示 blue 解析为 Service 的最新修订版本。以下示例将 80% 的流量发送到最新修订版本，将 20% 的流量发送到名为 v1 的修订版本。

kn service update example-service --traffic @latest=80 --traffic v1=20

使用蓝绿部署路由和管理流量

您可以使用 蓝绿部署策略 安全地将流量从应用程序的实时版本重新路由到新版本。

步骤

1. 将应用程序创建并部署为 Knative Service。

2. 通过运行以下命令找到您部署 Service 时创建的第一个修订版本的名称。

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   其中 <service-name> 是您已部署的 Service 的名称。

3. 定义一个路由，将传入流量发送到该修订版本。

   路由示例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic goes to this revision
   

   其中；

   • <route-name> 是您为路由选择的名称。
   • <first-revision-name> 是上一步中初始修订版本的名称。

4. 验证您是否可以通过使用以下命令获得的 URL 输出查看您的应用程序。

   kubectl get route <route-name>
   

   其中 <route-name> 是您在上一步中创建的路由的名称。

5. 通过修改 Service 资源的 template 规范中的至少一个字段来部署应用程序的第二个修订版本。例如，您可以修改 Service 的 image 或 env 环境变量。

6. 通过应用更新后的 Service 资源来重新部署 Service。您可以通过应用 Service YAML 文件来完成此操作，或者如果您已安装 kn CLI，则可以使用 kn service update 命令。

7. 通过运行以下命令找到您重新部署 Service 时创建的第二个最新修订版本的名称。

   kubectl get configurations <service-name> -o=jsonpath='{.status.latestCreatedRevisionName}'
   

   其中 <service-name> 是您已重新部署的 Service 的名称。

   此时，Service 的第一个和第二个修订版本都已部署并运行。

8. 更新您现有的路由，为第二个修订版本创建一个新的测试端点，同时仍然将所有其他流量发送到第一个修订版本。

   更新后的路由示例

   apiVersion: serving.knative.dev/v1
   kind: Route
   metadata:
     name: <route-name>
     namespace: default
   spec:
     traffic:
       - revisionName: <first-revision-name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second-revision-name>
         percent: 0 # 0% of traffic routed to the second revision
         tag: v2 # A named route
   

   重新部署此路由后，重新应用 YAML 资源，第二个修订版本的应用程序现在已进入暂存阶段。

   没有流量被路由到主 URL 的第二个修订版本，Knative 创建了一个名为 v2 的新路由来测试新部署的修订版本。

9. 通过运行以下命令获取第二个修订版本的新的路由的 URL。

   kubectl get route <route-name> --output jsonpath="{.status.traffic[*].url}"
   

   您可以使用此 URL 来验证新版本的应用程序是否按预期工作，然后再将任何流量路由到它。

10. 再次更新您现有的路由资源，以便将 50% 的流量发送到第一个修订版本，将 50% 的流量发送到第二个修订版本。

    更新后的路由示例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 50
        - revisionName: <second-revision-name>
          percent: 50
          tag: v2
    

11. 当您准备好将所有流量路由到新版本的应用程序时，再次更新路由以将 100% 的流量发送到第二个修订版本。

    更新后的路由示例

    apiVersion: serving.knative.dev/v1
    kind: Route
    metadata:
      name: <route-name>
      namespace: default
    spec:
      traffic:
        - revisionName: <first-revision-name>
          percent: 0
        - revisionName: <second-revision-name>
          percent: 100
          tag: v2
    

    提示

    如果您不打算回滚修订版本，则可以删除第一个修订版本，而不是将其设置为 0% 的流量。然后，不可路由的修订版本对象会被垃圾回收。

12. 访问第一个修订版本的 URL，以验证不再有流量被发送到旧版本的应用程序。