The goal of this is to make revision transparent to user. Rather than specifying a revision as part of the pod/namespace, we will do routing at a gateway based on some metadata. For this example we will user an arbitrary setting we configure on the pod - in practice we would likely use something like ISTIO_VERSION which is configured automatically for the user.
To deploy this, add the following annotation to a pod:
annotations:
proxy.istio.io/config: |
discoveryAddress: istio-ingressgateway.istio-system.svc:443
controlPlaneAuthPolicy: MUTUAL_TLS
proxyMetadata:
ROUTER: istiod.istio-system.svc
sidecar.istio.io/proxyImage: gcr.io/howardjohn-istio/proxyv2:1588805810
And another pod:
annotations:
proxy.istio.io/config: |
discoveryAddress: istio-ingressgateway.istio-system.svc:443
controlPlaneAuthPolicy: MUTUAL_TLS
proxyMetadata:
ROUTER: istiod-canary.istio-system.svc
sidecar.istio.io/proxyImage: gcr.io/howardjohn-istio/proxyv2:1588805810
The first one will use the default revision, the second the canary revision.
In a real setup, this would likely be derived from something automatically - no user configure here would be needed, as that defeats the purpose. To make things simple here (and allow testing with two pods running the same version) we explicitly define some metadata to drive routing decisions.
Next we need to set up config for the gateway. Apply tls.yaml
, which will do SNI routing to our different control plane pods based on this.
Note that this requires a custom proxy image to:
- Set the value of ROUTER to
sni
. - Change match_subject_alt_names to
*.istio-system.svc
. Making this actually secure is TBD.
In a real deployment, we might choose to route based on other properties:
- ISTIO_VERSION - 1.x pods go to 1.x control plane, 1.y -> 1.y
- Really fine grained - pod name, deployment name, etc. This is a bit harder with TLS than plaintext since we only have one SNI value we can set. With plaintext we can set N headers, and routing can choose to use any combination of them