Feasibility of standard way of application deployment in different nodes using Kubernetes architecture

4/25/2018

I am planning to use Kubernetes and Jenkins for my microservice deployment.

Nature Of Application

I have total 15 Spring Boot micro services. And need to deploy all these 15 micro services for different customers - everyone using same code, but need to deploy this all separately. Means every customer have their own deployed. Total I have 5 customer (This is assumption. Not exact one. It will varies from 20 to 50).

My Current Design

I am currently planning to use 5 Kubernetes Nodes.Means one cluster master plus 5 Node. Total 6 VMs. And planning to deploy each of these 15 micro services in these 5 nodes for 5 customer. So everyone will get their own deployment. And also I will install Jenkins in my Kubernetes cluster master VM for making a CI/CD pipeline.

So these about all architecture. I am only a starter in architecture and designing of cloud application. Here I need to know that any issues related with this architecture. I need to confirm its feasibility.

Please clear my confusion about my current approach. If this is a good one, I can continue. I am only searching this is a industrial standard way of using Kubernetes. Is this way a good architecture?

-- Jacob
architecture
kubernetes

1 Answer

4/25/2018

Several things come to mind:

  • one master is not enough. The loss of that VM, the underlying hardware, or a failure of the services on the master will lead to an outage for all customers, and potentially catastrophic data loss. Run 3 masters at minimum.
  • each client running distinct copies of each of the services is a suboptimal tenancy model. There are lots of situations in which that's required, but in those situations each client is often running their own distinct release of the services. Managing that in a microservice architecture is awful.
  • CD in an environment where each client is running their own copies of services, potentially their own versions of each, will be impossible.
  • the JVM is a heavy CPU and memory consumer. A single JVM was designed to itself support multiple workloads. So there can be conflicts between container resource management and JVM resource management, and running JVM microservices
-- Jonah Benton
Source: StackOverflow