I assume that Zuul offers a lots of features as an edge service for traffic management, routing and security functions. It has to declare API Gateway the main point of accessing microservices by the external clients as per Microservice Architecture pattern Design. However, Zuul needs to somehow discover underlying microservices and for Kubernetes you might need to adapt Kubernetes Discovery Client which defines the rules how API Gateway will detect routes and transmit network traffic to the nested services.

As per design, Istio represents Service mesh architecture and becomes Kubernetes oriented solution with smooth integration as well. The main concept here is using advanced version of Envoy proxy by injecting sidecars into Kubernetes Pods with no need to change or rewrite existing deployment or use any other methods for service discovery purposes. Zuul API Gateway can be fully replaced by Istio Gateway resource as the edge load balancer for ingress or egress HTTP(S)/TCP connections. Istio contains a set of traffic management features which can be included in the general configuration.

You might be interested with other fundamental concepts of functional Istio facilities like:

• Authorization model;

• Authentication policies;

• Istio telemetry and Mixer policies.