rfcs/1-jhipster-rfc-k8s-operator.md
The JHipster Operators use Kubernetes CRDs (Custom Resource Definitions) to encapsulate operational knowledge about JHipster Applications.
Integrating with Kubernetes requires more than just the Kubernetes Manifest to get our containers running inside the platform. The JHipster Kubernetes Operator will enable JHipster MicroService Applications (projects) to be managed and understood by the platform in a native way.
Note: It is important to understand that the current JHipster architecture is not going to be changed. A Kubernetes Operator is something that will run along our JHipster Applications.
The JHipster Kubernetes Operator adds on top of existing JHipster Applications running in K8s all the operational knowledge required to manage and maintain these applications over time.
The whole idea of having an operator makes sense only after having an application running in Kubernetes for some time. In other words, if you are looking for just deploying your application you should use the jhipster kubernetes or jhipster kubernetes-helm generators.
Once your application is running there will be questions that start to pop up such as:
With the JHipster Operator we try to provide a place (component) where we can iteratively answer all these questions.
Notice that all the JHipster applications are running as we know them today inside a K8s cluster, and the JHipster K8s Operator sits on top and with these existing applications.
Main objectives:
Things that the Operator will NOT do:
jhipster kubernetes-helm generatorYou can use the JHipster Kubernetes Operator to monitor and manage your JHipster MicroServices Applications running inside Kubernetes. In order to deploy your applications to Kubernetes you can use the jhipster kubernetes and jhipster kubernetes-helm generators to generate the Kubernetes Manifest required to run your containers in K8s.
After deploying your applications to a Kubernetes environment you can deploy the JHipster Kubernetes Operator to your cluster by (GUIDE on how to deploy here)
Once the Operator is running you will be able to:
The Operator defines 4 Custom Resource Definitions:
These CRDs definitions can be found here.
The JHipster Kubernetes Operator will use these resource definitions to understand, monitor and manage deployed applications. When an application is deployed to Kubernetes, we will need to decorate our existing K8s Services descriptors with these Custom Resources for the Operator to understand the application structure. These Custom Resources instances such as JHipster Application, MicroService, Gateway can be generated based on the JDL syntax by the jhipster kubernetes and jhipster kubernetes-helm generators.
Once these resources are deployed as part of the normal Kubernetes deployment procedure, the Operator will be able to monitor the state of the entire application.
The Operator will expose a set of APIs to fine tune the default behavior and also to expose relevant information such as:
Because we are using CRDs we will be able to ask the Kubernetes APIs about our JHipster Resources using for example the kubectl command.
An important aspect of the Operator is that it will not be in charge of deploying applications. Deployment should be done by standard tools such as HELM, or the default Kubernetes APIs that we use after generating the Kubernetes Manifests. The Operator's responsibility is to monitor and manage applications, not to deploy them.
The JHipster Kubernetes Operator can be built as a Spring Boot Starter meaning that it doesn't necessarily need to be its own independent container it can be attached to an existing service if it is required.
The Operator will provide an excellent entry point for domain specific extensions and integrations with another platform wide services such as Istio, KNative, Jenkins X (Tekton Pipelines), etc. It will provide the entry point for a Developer Workflow on top of Kubernetes.
Because the Operator will run inside a Kubernetes Pod, we need to grant the Operator's deployment with a special Service Account, Role and Role Bindings for it to be able to interact with the Kubernetes APIs. You can find these extra manifests here.
A Kubernetes Operator only makes sense if you are planning to run your application in Kubernetes, for people that are not there yet, this might cause confusion. The Operator Documentation and guides should clearly explain what and why the Operator is trying to solve these platform wide concerns and its advantages.
Building Kubernetes Operators is a long journey. In order to find some best practices we need to iterate and improve while we learn. We don't have all the answers right now, but having a concrete project will help us to improve it until it is useful for the entire community.
You can see here my first attempt here: https://github.com/salaboy/jhipster-operator/tree/jhipsterconf19 The README.md file provides a glimpse of this first iteration, but after a lot of feedback a set of changes will be applied in the master branch to make the Operator simpler and more focused.
jhipster kubernetes and jhipster kubernetes-helm generators, so we are not changing anything regarding our deployment architecture. We are just decorating our existing manifest with JHipster Specific Resources, and this decoration can be optional. The CRDs are encapsulated, managed and installed by the Operator itself.