我正在 mesh-virtual-service 中定义金丝雀路由,并想知道我是否也可以使其适用于入口流量(使用 ingress-virtual-service)。像下面这样,但它不起作用(来自入口的所有流量都将转到非金丝雀版本)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: test-deployment-app
namespace: test-ns
spec:
gateways:
- mesh
hosts:
- test-deployment-app.test-ns.svc.cluster.local
http:
- name: canary
match:
- headers:
x-canary:
exact: "true"
- port: 8080
headers:
response:
set:
x-canary: "true"
route:
- destination:
host: test-deployment-app-canary.test-ns.svc.cluster.local
port:
number: 8080
weight: 100
- name: stable
route:
- destination:
host: test-deployment-app.test-ns.svc.cluster.local
port:
number: 8080
weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: test-deployment-app-internal
namespace: test-ns
spec:
gateways:
- istio-system/default-gateway
hosts:
- myapp.dev.bla
http:
- name: default
route:
- destination:
host: test-deployment-app.test-ns.svc.cluster.local
port:
number: 8080
weight: 100
因此,当我调用 x-canary:true
时,我期待 myapp.dev.bla
响应标头,但我没有看到。
答案 0 :(得分:2)
答案仅部分包含在您包含的链接中。我认为在使用 Istio 时要意识到的重要事情是“什么是 Istio 服务网格”。服务网格是每个带有 Istio envoy-proxy sidecar + 所有网关的 pod(网关是独立的 envoy-proxy)。他们都因为 IstioD 而相互了解,因此他们可以合作。
您的 k8s 集群中没有 Istio sidecar(包括入口 pod 或即 kube-system pod)的任何 pod 都不了解 Istio 或服务网格。如果这样的 pod 想要将流量发送到 Service Mesh(应用一些像你一样的流量管理规则)必须通过 Istio 网关发送它。 Gateway
是创建标准部署 + 服务的对象。部署中的 Pod 包含独立的 envoy-proxy
容器。
Gateway
对象是一个与 k8s 入口非常相似的概念。但它不一定必须在 nodePort 上侦听。您也可以将其用作“内部”网关。网关充当您的服务网格的入口点。用于外部甚至内部流量。
mesh
网关。它只不过是 istio-gateway
或 istio-system
命名空间内的 k8s 服务istio-gateway
或 istio-system
命名空间中。或者,您可以仅为您的应用程序创建新网关并应用 {{1 }} 到新网关。