Hello all. I am trying to find a proper rollout process for switching from our current, Eureka-based, dockerized, micro-service environment, to an Istio-based, Kubernetes-based, micro-service environment. Ideally, i would like to be able to do B/G and Canary-like traffic weight management between the instances of the service foo in the old environment and the instances of the same service foo in the new environment.
As far as i understand, one approach is to include the service instances of the old environment to the single mesh by implementing a Eureka Pilot platform adapter and load both env instances into a single mesh. However, this requires Envoy proxies to be added to the old environment and i would prefer i do not touch it like that.
I am trying to find another approach that does not require Envoy proxies to be added to the current env. I am reading about the ServiceEntry feature and i am trying to understand whether this can provide a solution. I guess what i would like to have is the ability to configure the network routing for a service foo with 2 subsets - versions, the “old” and the “new”, where “new” instances refer to the instances of the foo service inside the mesh and “old” instances refer to the instances of the foo service outside the mesh, in our current environment. There is no need for “old” instances to be defined explicitly; we maintain a special proxy service that contains the Eureka client and registers to the current registration and discovery system and can be referenced through a DNS. The “old” instances of ALL the services can be accessed through this proxy, just by passing a special header with the upstream service name. The requirement though is this one: being able to define different traffic weights between the “new” version and the “old” version of the instances.
So, a client service in the mesh, bar, needs to communicate with the upstream service, foo. The request should be either routed to the “old” subset of instances of the service foo or the “new” subset of instances, based on the configurable traffic weight. If the request is routed internally, the Istio destination rules should be followed, as usual. If the request is routed to the “old” subset, a special header should be added with a value equal to the service name and the request should be routed to a configurable DNS where the Eureka-based proxy awaits, in order to perform its own load balancing between the instances of the foo service in the “old” world.
Is the above possible? If not, can you help with an alternate solution?