4、Knative与Istio集成原理：Knative默认Istio配置、VirtualService与DestinationRule自动生成机制

4.1 集成架构总览

Knative Serving 在部署时默认集成 Istio 作为服务网格层，利用 Istio 的流量管理能力实现版本路由、灰度发布、流量镜像与弹性伸缩。Knative 并不直接操作 Istio 的 CRD，而是通过 net-istio 控制器自动生成 VirtualService 和 DestinationRule，将 Knative 的 Revision、Configuration、Route 等抽象映射为 Istio 的流量规则。

4.2 Knative 默认 Istio 配置

Knative 安装时通过 KnativeServing 自定义资源指定 Istio 集成参数。默认配置包含以下关键字段：

4.3 VirtualService 自动生成机制

当用户创建 Knative Service 或 Route 时，net-istio 控制器会监听这些资源的变化，自动生成对应的 VirtualService。生成的规则遵循以下映射逻辑：

• 域名映射： Knative Service 的 status.url 中的域名（如 hello.default.example.com）被设置为 VirtualService 的 hosts 字段。
• 网关绑定： 自动关联 knative-serving/knative-ingress-gateway 和 knative-serving/knative-local-gateway。
• 版本路由： 根据 Knative Route 的 traffic 配置，生成多个 http.route 条目，每个条目指向一个 Revision 对应的 Service。
• 流量镜像： 如果 Route 中配置了 mirror 字段，VirtualService 中会自动添加 mirror 和 mirrorPercentage 规则。

以下是一个自动生成的 VirtualService 示例：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello-route
  namespace: default
  ownerReferences:
    - apiVersion: serving.knative.dev/v1
      kind: Route
      name: hello
spec:
  gateways:
    - knative-serving/knative-ingress-gateway
    - knative-serving/knative-local-gateway
    - mesh
  hosts:
    - hello.default.example.com
    - hello.default.svc.cluster.local
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: hello-v1-service.default.svc.cluster.local
            port:
              number: 80
          weight: 90
        - destination:
            host: hello-v2-service.default.svc.cluster.local
            port:
              number: 80
          weight: 10
      mirror:
        host: hello-mirror-service.default.svc.cluster.local
        port:
          number: 80
      mirrorPercentage:
        value: 5.0

4.4 DestinationRule 自动生成机制

DestinationRule 用于定义对目标服务的访问策略，包括负载均衡、连接池、熔断和 TLS 设置。Knative 自动生成的 DestinationRule 主要关注以下方面：

自动生成的 DestinationRule 示例：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: hello-destination
  namespace: default
  ownerReferences:
    - apiVersion: serving.knative.dev/v1
      kind: Service
      name: hello
spec:
  host: hello-v1-service.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      http:
        maxRequestsPerConnection: 100
    tls:
      mode: ISTIO_MUTUAL
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

4.5 自动生成流程与生命周期

net-istio 控制器采用 Reconciler 模式，持续监听 Knative 资源的变化并同步 Istio CRD。整个流程分为以下步骤：

1. 监听事件： 控制器 Watch Knative Service、Route、Configuration、Revision 资源的变化。
2. 构建期望状态： 根据当前 Knative 资源的状态，计算出期望的 VirtualService 和 DestinationRule 配置。
3. 对比当前状态： 从集群中读取已有的 Istio CRD，与期望状态进行对比。
4. 创建/更新/删除： 如果存在差异，则执行对应的 API 操作，确保 Istio CRD 与 Knative 资源一致。
5. 状态回写： 更新 Knative Route 或 Service 的 status 字段，反映流量配置是否生效。

4.6 关键差异对比：Knative 自动生成 vs 手动编写 Istio CRD

4.7 常见问题与排查

• VirtualService 未生成： 检查 net-istio 控制器 Pod 日志，确认是否因 RBAC 权限不足导致无法创建 Istio CRD。
• 流量路由不符合预期： 使用 istioctl proxy-status 查看 Envoy 是否已接收到最新的 VirtualService 配置。
• 自动生成的 CRD 被手动修改： 控制器会持续覆盖手动修改，应通过 Knative 资源调整配置，而非直接编辑 Istio CRD。
• Gateway 冲突： 如果业务使用了自定义 Gateway，确保 Knative 的 Gateway 与业务 Gateway 的 hosts 字段不重叠。