Similar to the Docker Compose sub-generator, JHipster also comes bundled with a Kubernetes sub-generator. In order to use it, just like with Docker Compose, we will create a new folder and name it Kubernetes. Then, we will go inside the folder to create the configuration files.

We can create Kubernetes configuration files with the following command:

> mkdir kubernetes && cd kubernetes
> jhipster kubernetes

We then need to answer the questions that the sub-generator asks us, as follows:

• The first question the sub-generator asks is what type of application we'd like to deploy. It provides two options: monolithic and microservices. We will choose the microservices option:

• Then, it asks us to enter the root directory. We will select the default option since our directories are present as the siblings of the Kubernetes folder:

• Then, the sub-generator will list all the folders with our JHipster-generated applications. Here, it will list all three applications that we need—store, invoice, and notification. Select all three applications and hit Enter:

• Then, it will ask whether we need monitoring. The options are JHipster Console or Prometheus, and we will select JHipster Console:

• Next, it will ask whether we need clustering enabled for MongoDB, similar to the docker-compose sub-generator. Let's skip clustering and proceed. Just hit Enter:

• Then, it will ask us to provide the password for the registry service. In our case, it is JHipster Registry. We will select the default one for now, but it is generally advisable to use a strong password here:

• Afterward, it will ask us for the namespace that we need to use in Kubernetes.

So, what is a namespace? We can consider namespaces as a group within which resources should be named uniquely. When the cluster is shared between different users or teams, namespaces can provide resource quotas for them. Ideally, namespaces should be used only for a larger team. For smaller teams, it is better to go with default options. Kubernetes, by default, provides three namespaces, which are as follows:

• default: When you start a container or pod without providing any namespaces, they will end up in the default namespace.
• kube-system: This namespace contains Kubernetes system-based objects.
• kube-admin: This is a public namespace, which will be shown to all the users publically without any authentication.

We will set jhipster as the namespace here for the sake of this demo. Let's see what else the sub-generator asks us:

• The sub-generator will ask for our Docker repository name so that Kubernetes can use this Docker repository to pull the images (the login username of the Docker repository, or the URL in case of a custom Docker Registry):

• Then, the sub-generator will ask for the command that needs to be used to push the image to the Docker repository. We will select the default command here:

• Then, it will ask whether we want to use Istio. We will see what Istio is and how to use it later in this chapter. For now, choose No:

• Then, the generator will ask us to choose the Kubernetes service type. So, what is the service type?

In Kubernetes, everything that we deploy is a pod. These pods are managed by replication controllers that can create and destroy any pods. Each pod needs an identifier, so they are tagged with an IP address. This dynamic nature of pods will lead to a lot of problems for other pods that depend on them. As a solution to this problem, Kubernetes introduced services. Services are nothing but a logical grouping of unique pods that have policies attached to them. These policies are applicable for all the pods inside the services, but we need to publish these services to the external world to access them.

Kubernetes gives us four different service types, as follows:

• ClusterIP: This is the default type. This will assign the cluster's internal IP and make it visible within the cluster itself.
• NodePort: This will expose the service to a static port in the node's IP. The port will be random and will be chosen between 30000-32767.
• LoadBalancer: This will expose the service externally. Kubernetes will assign an IP automatically. This will create a route to the NodePort and cluster IP internally.
• Ingress: This is a special option that Kubernetes provides. This will provide load balancing, SSL termination, and name-based virtual hosting to the services.

We will select the LoadBalancer option:

That's it. This will generate the necessary configuration files for us to deploy the application with Kubernetes and will print out the commands needed for the next steps:

Next up, we will check the files that have been generated.