Generator-jhipster: Use Spring Cloud Kubernetes in JHipster

Created on 28 Feb 2019 · 9Comments · Source: jhipster/generator-jhipster

Overview of the feature request

It will be great to have an option to use Spring Cloud Kubernetes to avoid using the JHipster Registry when deploying to Kubernetes. This will also span to the Gateway project, which I believe is going to be the first real user of the Spring Cloud Kubernetes Discovery Client.
For individual Microservices, unless is really needed, we only need to make sure that can be configured using ConfigMaps and Secrets.

Motivation for or Use Case

I believe that Spring Cloud Kubernetes could be the right place for other integrations as well. I do see more and more projects aiming towards (K8s + Istio + Knative) and all these integrations can be provided inside Spring Cloud Kubernetes Projects, with auto detect mechanisms (if Istio is installed, or if KNative is there, for example)

Another, even bigger, motivation that is see in the near future is to provide a JHipster Kubernetes Operator, which is basically aware of Kubernetes (Istio + Knative) resources and can understand, coordinate and manage the lifecycle of the deployed microservices. This will simplify integrations and promote people extensions for their domain specific requirements.

I will appreciate feedback about this @saturnism @PierreBesson @jdubois , knowing that I am personally involved with the Spring Cloud Kubernetes project and we can make contributions for the next release to make sure that we include all what we need there.

I know that some of you guys already tried this approach, so I am interested to understand what was missing, failing, not working as expected. I will be more than happy to work on an example where I fine tune the generated microservices to see if I can get it working, but I will appreciate feedback (and recommendations) first before starting that work.

Related issues or PR

I can see these two issues by @saturnism
1) https://github.com/jhipster/generator-jhipster/issues/8437
2) https://github.com/jhipster/generator-jhipster/issues/7507

These were both closed and my understanding is that was in favour of not maintaining several alternatives for each type of deployment. I totally sympathise with that, but I do believe that we can solve some of the problems by using profiles or fine tuning the generators.

Just as a reference, I've tried using the Spring Boot Admin application from CodeCentric with Spring Cloud Kubernetes Discovery (hacking the dependencies) and everything worked fine.(https://github.com/codecentric/spring-boot-admin)

[ x] Checking this box is mandatory (this is just to show you read everything)

area kubernetes

Source

salaboy

👍29 👀1

Most helpful comment

Not all our users are going to use Kubernetes, so this shouldn't be our only approach, but in my opinion the trend is clear and Kubernetes is going to be the de-facto standard for our microservices architecture (and also for monoliths, but we have less issues there).

Please also note that the current developer experience with Kubernetes is not very good, but we have enrolled (under NDA, so we can't say much) in a specific Google program for this, and we believe this can be solved for Google Next this year.

My general idea is that we should embrace Kubernetes, make the JHipster Registry optional (it goes further than we are going to do here, but it would not be mandatory to use), and maybe use Spring Cloud Kubernetes but I'm not sure it's needed:

For configuring the applications: I would just like to use a Kubernetes secret to store an application.yml file which should be mounted on the directory in which the application is run. This provides less advanced options than with the JHipster Registry or Spring Boot Kubernetes, but it has no dependency on anything (it's just a file) and it's much more secure (the secrets are not available as env variables or anything).
For circuit breakers or service discovery: I would just use Istio and let it handle everything. So no need for Hystrix, Ribbon, etc. This also provides less options (I like to configure a fallback when a microservice goes down), but also here there's nothing to do on the application side, and I like the simplicity of this.
For monitoring/insights: now that we fully support Micrometer we're already all set
For distributed cache: this is the main issue for scalability in my opinion, but I've seen that there is a Kubernetes support in Hazelcast that does exactly the same as what I coded in JHipster (it's so close I wouldn't be surprised they copied it from us!)
For gateways: we could configure a Kubernetes load balancer (there are lots of options here, so we need to check this in detail), and that would totally remove the need for a JHipster gateway
For the JHipster Kubernetes Operator: I love your idea @salaboy

What I like here is that in the end we would:

Remove the need for the JHipster Registry and for the JHipster gateways.
Make microservices be exactly the same as a monolith on the server side: the only difference is that they have no front-end.
It would not be a requirement to have Kubernetes on your laptop in order to deploy your application locally. Kubernetes would just "enhance" the application (adding production configuration, network management, monitoring...) but the application would not need it to run.

So that would definitely simplify what we generate, and ease our maintenance burden, while still providing our usual awesome developer experience :-)

Now for what is missing and why this isn't ready: we're doing this mostly on our free time, and we just don't have much of it. This is just that the personal agendas of the commiters (including me) are full with other things than spending our evenings on Open Source (like spending time with wife & kids). -> all help is welcome here, obviously

jdubois on 28 Feb 2019

👍14

All 9 comments

I tested our current development of https://github.com/ordina-jworks/microservices-dashboard/ on Kubernetes with the discovery client, works like a charm 👌

EDIT: this only works with 2.0.0.BUILD-SNAPSHOT of the microservices-dashboard project, 1.x is not compatible with Spring Boot 2

TYsewyn on 28 Feb 2019

For configuring the applications: I would just like to use a Kubernetes secret to store an application.yml file which should be mounted on the directory in which the application is run. This provides less advanced options than with the JHipster Registry or Spring Boot Kubernetes, but it has no dependency on anything (it's just a file) and it's much more secure (the secrets are not available as env variables or anything).
For circuit breakers or service discovery: I would just use Istio and let it handle everything. So no need for Hystrix, Ribbon, etc. This also provides less options (I like to configure a fallback when a microservice goes down), but also here there's nothing to do on the application side, and I like the simplicity of this.
For monitoring/insights: now that we fully support Micrometer we're already all set
For distributed cache: this is the main issue for scalability in my opinion, but I've seen that there is a Kubernetes support in Hazelcast that does exactly the same as what I coded in JHipster (it's so close I wouldn't be surprised they copied it from us!)
For gateways: we could configure a Kubernetes load balancer (there are lots of options here, so we need to check this in detail), and that would totally remove the need for a JHipster gateway
For the JHipster Kubernetes Operator: I love your idea @salaboy

What I like here is that in the end we would:

Remove the need for the JHipster Registry and for the JHipster gateways.
Make microservices be exactly the same as a monolith on the server side: the only difference is that they have no front-end.
It would not be a requirement to have Kubernetes on your laptop in order to deploy your application locally. Kubernetes would just "enhance" the application (adding production configuration, network management, monitoring...) but the application would not need it to run.

So that would definitely simplify what we generate, and ease our maintenance burden, while still providing our usual awesome developer experience :-)

jdubois on 28 Feb 2019

👍14

@jdubois thanks for the very detailed answer. This is exactly what I was expecting to read :)

I think that it will be good if we break it up into separate topics and I would like to propose the following "experiments", let me know if they make sense and sounds worth the (my spare) time:

New Spring Cloud Gateway with Spring Cloud Kubernetes: this is basically to replace the current Zuul approach and to maintain the concept of a Gateway with a FrontEnd + routing. At the end of the day, this is the only one that really need discovery for registering the routes. I believe that having a plain Kubernetes Loadbalancer will not be enough. Notice that this gateway can evolve to an K8s operator, so the name gateway might be confusing, but in general I think about this as the JHipster component that understand about the microservices that are around and know how everything is wired together. @saturnism @jdubois @pierre-filliolaud Do you think that this one is a good start? I think that we can see an example and then decide what is the next step.
Create a Kubernetes profile to remove eureka, config, ribbon and other libraries that will not be needed: I think that the Spring Cloud Config dependency should be used to read those yml files from secrets and configmaps. This make the use of configuration files intuitive to any spring boot developer, following the config server approach, the property source locator implementation will just look the files. I am interested in understanding how your approach will work and where the yml file will be stored, if you are running in a remote cluster. (notice that my experience so far with Kubernetes (3years+) is not to use a 1 node local k8s cluster with Minikube or docker for Mac) . Regarding all the other libraries, I think that we can choose not generate all the code that is using them, but it will be better to have AutoConfigurations that can be disabled if the kubernetes profile is enabled. I am really conscious about the amount of work that this might involve, but I will be more than happy to collaborate with someone to get this done.
Istio++: totally agree with using Istio. It is also related to the gateway discussion. Istio provide the concept of Gateway instead of using Ingress, so we should rely on that. But I would like to keep as phase 2 for the gateway/operator. If you think about Istio main advantages are about defining how the envoy proxy behaves to wire different microservices together, that means that it will be great to have a JHipster component (operator) that knows about this and configure Istio accordingly depending on the type of application that the user is deploying.

As a side note, and completely off topic.. If you guys are working with Google, you are probably also thinking about K8s + Istio + KNative, which I believe is fundamental to have a complete developer experience. I have this tech stack in mind while contributing to Spring Cloud K8s, to make sure that we have the right tools to build services that are aware of the infrastructure or K8s Operators.

Feedback is highly appreciated :)

salaboy on 1 Mar 2019

👍4

Thanks @salaboy - there are 2 points that needs more explanation from my side:

For the gateway: as we generate the whole Kubernetes config, we can also generate the configuration for the routes. Also, there are gateways that can be automatically configured from Kubernetes (Traefik for example). So here I'd rather have just a component that we configure, and not generate any application anymore. I don't know for Spring Cloud Gateway and I don't know why Pivotal created one more application gateway, but there are tons of great solutions here, and I'd rather use one which is more well-known, or even just a Kubernetes loadbalancer if that is enough (which I hope).
For the configuration: if you put a configuration file, for example application-prod.yml in the same directory as your application, it will override your application's configuration. I do this all the time, for example for https://start.jhipster.tech . This file can be stored as a Kubernetes secret (and then that's the responsibility of the Kubernetes ops team, which I find is normal, and which should have the right tools to handle those files), and then just mounted on the filesystem. It's more secure than using environment variables and is the recommended way in Kubernetes to get secrets. It's less powerful than what we have with Spring Cloud Config, but it's much easier to use (no server to run, it's just a file), it is more secure, and it's really simple to mock (on my dev box, I just put a real file...).

jdubois on 1 Mar 2019

@salaboy Can you create an RFC linked to this issue as described in https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md