Generator-jhipster: Feature Request - Add options to generate Istio-friendly deployments MVP

[saturnism]

Overview of the issue

Add a generator for Istio deployment

Motivation for or Use Case

With Istio deployment, we can potentially simplify the microservices and removing several components, and relying on Istio for Load Balancing and Circuit Breaking.

Suggest a Fix

• [x] Microservices/Gateway Generator
  
  
  
  • [x] Generate w/o Eureka, Hystrix, Zuul (#7695)
  
  
  • [x] Generate w/ server.servlet.context-path for easier Ingress mapping #7695)
  
  
• [x] Kubernetes Generator
  
  
  
  • [x] Generate Ingress mapping (#7695)
  
  
  • [x] Use Istio Ingress Class (#7697)
  
  
  • [x] Propagate Istio Headers (mostly done through Spring Cloud Sleuth 2) (#7697)
  
  
  • [x] Generate Istio Destination Rules for Circuit Breaker (#7697)
  
  
  • [x] If using Eureka/Consul, use host name rather than IP (#7697)
  
  
  • [x] Prefix service port names (e.g., http) for Istio (#7697)
  
  
• [x] Documentation Update (In Progress Done - JHipster Doc 577]

After this initial MVP, see #7708

[stephanj]

Would be awesome! More than happy to beta test. 🤓

[jdubois]

@saturnism wouldn't this remove the need for large part of Spring Cloud? No more need for load balancing/circuit breakers, and maybe no gateway (not sure, as it's like with Traefik, our gateway does much more than just routing, so maybe you want the option to use both).
-> can you confirm this? BTW this is how it works with Heroku - the platform does load balancing/circuit breaking, making a big part of Spring Cloud useless. So this would be some kind of "common use case" for advanced platforms.

[saturnism]

I guess it would remove some of Spring Cloud, but probably can't say all. E.g.,

• Can keep Spring Cloud Sleuth for trace propagation. There are a lot of good integrations there. See Istio By Example for a Span Extractor that works w/ Spring Cloud.
• Still need bulk heading, i.e., ability to return default value when the service is ultimately not working

Probably don't need:

• Client Side Load Balancer, Ribbon
• Eureka

(But you are right - App Engine would also benefit from the common use case :)

[saturnism]

Would it make sense to be a configuration flag for the existing Kubernetes generator?

Or, a new generator, but it'll end up re-using a lot of the same templates.

[sendilkumarn]

Can we add this as a separate blueprint ?

[deepu105]

@saturnism I would suggest making it an option in the existing k8s generator rather than a new one

[jdubois]

I agree with @deepu105 - I don't know Istio very much (I just had a demo by @dgageot ), but to me we could integrate it the same way we integrate Traefik (see the documentation at https://www.jhipster.tech/traefik/ )

[PierreBesson]

It would be great to support Istio but I think offering the option to use spring-cloud-kubernetes as an alternative to spring-cloud-eureka and spring-cloud-consul will be a pre-requisite. Then, I would love to work on this if this is where we want to go !

[PierreBesson]

Just found a great github repo from IBM with precious info on exactly this issue of integrating spring cloud with k8s and istio : https://github.com/IBM/spring-cloud-kubernetes-with-istio

[PierreBesson]

@saturnism Although the official spring cloud kubernetes is not compatible with Spring Boot 2, this third party lib is : https://github.com/DTForce/kubernetes-discovery-spring and it might be just what we need...

[srinivasa-vasu]

Both the links use a similar code for service discovery. Retrieving the host, port details from endpoint. I guess this won't work with Istio, as we can not skip the service call. With this way, ribbon would end up load balancing to the actual pods by totally bypassing the side car proxy.

[mrts]

Note that you need Ambassador besides Istio for API gateway. Quoting:

_Ambassador is a Kubernetes-native API gateway for microservices. Ambassador is deployed at the edge of your network, and routes incoming traffic to your internal services (aka "north-south" traffic). Istio is a service mesh for microservices, and is designed to add application-level Layer (L7) observability, routing, and resilience to service-to-service traffic (aka "east-west" traffic). Both Istio and Ambassador are built using Envoy._

[jdubois]

Hi, this has been opened for 2 month and no work has started - while I agree that this would be a cool feature, I don't want to have opened feature requests for too long if nobody is working on this, and this is why I'm closing this.

If anybody wants to do this, please step up and I will gladly re-open the ticket, in order to track the work.

[PierreBesson]

I have many ideas around this but I will need some time as I never used Istio myself and we have other priorities. Anyway from most people point of view it's still a bit early to go to prod with Istio. Similarly to the early days of k8s where setting it up was more complex and then new features arrive that simplify everything (like deployments vs replication controllers).

Anyway if some people want to help on this please come forward !

[sendilkumarn]

@PierreBesson We do have to remove Eureka & Ribbon & zuul and from our default generated application. probably for the ( No service discovery option )

Once we were able to do this, then it will be easier to add Istio on top of that. WDYT ?

[PierreBesson]

Yes that's exactly the plan but if we do provide this istio option, we need to setup a complete dev workflow to use kubernetes discovery on the local machine.

I'm still thinking on how to do that, maybe using telepresence to switch out local apps with the one running in kubernetes. Also I would like to configure the JHipster registry to be able to connect to kubernetes service discovery so that you can still access your API docs and monitoring. We really want to keep the same great workflow and everything working from dev to prod out of box...

We also need to think on a solution for the gateway to have automatic routes setup. Maybe this can be done with Traefik/Istio router/something else but we have to decide on a setup and actually implement it.

[srinivasa-vasu]

@PierreBesson @sendilkumarn, We don't need to remove any of the components (eureka, ribbon and zuul). Istio would work perfectly with registry (with RestTemplate) as long as we set two of the eureka properties. EUREKA_INSTANCE_PREFER_IP_ADDRESS to false and EUREKA_INSTANCE_HOSTNAME to 'service' manifest name. With this, requests will always be routed through envoy sidecar. Only downside is, in the registry and gateway display would be http://service-name for all the instance replicas. This would be with minimal changes without impacting the existing setup. I tested this and applied some of the istio's routing rules as well. Everything is working as expected!

[PierreBesson]

@srinivasa-vasu interesting approach ! So it means we could add Istio support in the k8s subgen with current jhipster apps.

[srinivasa-vasu]

@PierreBesson Yes, I have a working version

[jdubois]

Oh thanks for the tip @srinivasa-vasu ! I think this could also be useful for our Heroku sub-generator (ping @jkutner ) as microservices on Heroku are using something similar

[sendilkumarn]

@srinivasa-vasu I am wondering keeping other components along with istio won't be an overhead? I mean it is not absolutely necessary to have those components right?

[srinivasa-vasu]

@sendilkumarn Yep, it is not necessary, but this is something that we can start with without impacting the current code generation logic. It's not much of an overhead, essentially all the intelligence will be played out by Istio, rest of the components would just simply exist. Though Istio helps to replace/complement some of the spring cloud services, we don't necessarily need to replace all those components now, as our code is well integrated with those components. With this, change is very minimal, you have the option of benefiting from both the worlds without compromising much. I am still testing out few cases, once done I'll probably commit my code.

[deepu105]

Thats awesome Srini

On Sat, 26 May 2018, 2:42 pm Srinivasa Vasu, [e-mail]
wrote:

@sendilkumarn https://github.com/sendilkumarn Yep, it is not necessary,
but this is something that we can start with without impacting the current
code generation logic. It's not much of an overhead, essentially all the
intelligence will be played out by Istio, rest of the components would just
simply exist. Though Istio helps to replace/complement some of the spring
cloud services, we don't necessarily need to replace all those components
now, as our code is well integrated with those components. With this,
change is very minimal, you have the option of benefiting from both the
worlds without compromising much. I am still testing out few cases, once
done I'll probably commit my code.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/7337#issuecomment-392248742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlFywb3LLwZKHap66hTRINKQYF2PAOks5t2RyPgaJpZM4S0qRp
.

[saturnism]

if we use EUREKA_INSTANCE_HOSTNAME, would hystrix still kick in for circuit breaking etc?

IIRC, there is already an option to generate JHipster projects w/ Eureka. In which case, Gateway should be generated w/o Zuul. To make it simple, we can generate an Ingress to map to backends so it completely by passes Zuul.

Finally, in the Kubernetes generator, we can eventually generate circuit breaking/retry rules. However, I will wait on this until Istio 0.8 is released (changes coming).

[saturnism]

@jdubois can you assign this to me? :)

[saturnism]

oops, noticed @srinivasa-vasu has some code to check in first. will wait for those checkins. After that, I can:

• [ ] generate gateway w/o zuul?
• [ ] generate microservices w/ application.contextPath for easier mapping
• [ ] generate kubernetes ingress

And finally, w/ Istio 0.8:

• [ ] option to generate Istio circuit breaking rules

[PierreBesson]

It's OK I assigned both of you.

[saturnism]

nice! i feel the 2 PR combined makes it whole!

[saturnism]

it looks like removing zuul completely is a little difficult. it's also used for generating swagger api docs.

[PierreBesson]

Oh yes currently we need Zuul to rewrite the swagger docs json with the correct basePath but this could be done with Istio as well right ?
Note: the swagger is served by the microservice itself just with / as the basepath.

[saturnism]

path rewriting can be done w/ istio, but i'm also thinking of the case where istio is not used, but simply using k8s ingress.

does swagger doc rewrite /api/MyEntity to /ms1/api/MyEntity?

[PierreBesson]

I guess it will work with the context-path that you set.

[wangh09]

Does the spring security integration needs to be changed? As Istio has the ability for inter-service authentication.

[saturnism]

@wangh09 can that requirement be discussed in #7708 for further enhancements? :)

[saturnism]

I think this is all done! Thanks everyone!

[HamzaZo]

Hello
Does istio solve the problem of no service discovery option ? or how we can use kubernetes service discovery ?

[deepu105]

Use istio for k8s only service discovey

On Tue, 30 Oct 2018, 4:10 pm HamzaK8s, [e-mail] wrote:

Hello
Does istio solve the problem of no service discovery option ? or how we
can use kubernetes service discovery ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/7337#issuecomment-434338780,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF4JQ09AtlxZromGrLDAN7pbhRE38ks5uqGvWgaJpZM4S0qRp
.

[HamzaZo]

@deepu105 thanks for your reply,
so Istio make sur that the gateway forward traffic to other microservices when we want to hit a particular microservices throught gateway ?

[Pranavism]

@deepu105 does UAA +Gateway+Microservice architecture work with istio(no service discovery) option for K8s.
I see jwt auth based architecture works.
I just could not get it working , the health checks simply fails for some reason.

[deepu105]

Its not a combination that I tested. May be @xetys will know more