We’ve recently done a redeployment of Istio 1.1 across our clusters, configured according to the Split-horizon EDS topology documented here. The contents of the two relevant clusters are distributed like this:
- Istio control plane in
cert-managerinstallation in the
- Central gateway definition in
istio-system(due to limitations regarding resolving the secrets produced by the cert-manager auto-renewal).
- Istio Citadel and sidecar injector as proscribed by the documentation.
- Deployment and service for application named
productionnamespace to add routing for
production/birdcageto the gateway in cluster-1.
My expectation here was that when I created the
VirtualService in cluster-2, the Istio control plane in cluster-1 (which was configured at installation to have access to the K8S API of cluster-2) would be informed. It would then attempt to serve the resource request in the local (cluster-1), resolving the gateway in
cluster-1/istio-system. The definitions for the gateway defined in cluster-1 and the virtual service defined in cluster-2 are reproduced below:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: birdcage namespace: production spec: hosts: - myapp.test.mydomain.io gateways: - central-gateway.istio-system.svc.cluster.local http: - match: - uri: prefix: /login route: - destination host: birdcage.production.svc.cluster.local
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: central-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - hosts: - '*.test.mydomain.io` - test.mydomain.io port: name: http number: 80 protocol: HTTP tls: httpRedirect: true - hosts: - '*.test.mydomain.io' - test.mydomain.io port: name: https number: 443 protocol: HTTPS tls: mode: SIMPLE privateKey: /etc/istio/ingressgateway-certs/tls.key serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
Edit 3/28/2019: Rewrote question for added clarity.