infinite_loop
infinite_loop

Reputation: 151

Application control plane and data plane in kubernetes

I am new to Kubernetes. I am planning to build/deploy an application to EKS. This will likely be deployed on azure and gcp as well.

I want to separate data plane and control plane in my application deployed in EKS.

Is there anyway EKS/kubernetes allows to accomplish this?

Or should we go for two EKS with one for data plane and another for control plane?

Here is the problem(copied from the answer below)

I have an application, built using the microservice architecture (meaning you will have it split into components that will communicate with eachother).

I want to deploy this application on a public cloud (EKS, GCP, AWS).

I want a separation of the APPLICATION control plane (decision making components like authentication APIs, internal service routing) from the APPLICATION data plane (the serving of your application data to the clients through the egress).

Upvotes: 0

Views: 454

Answers (2)

Matthew
Matthew

Reputation: 21

I great open-source observability control plane for you apps is Odigos. The installation is super easy and within a few minutes you can get traces, metrics and logs. You get auto-instrumentation for all languages (including GO) as well as a manager of your opentelemetry collectors. Check it out: https://github.com/keyval-dev/odigos

Upvotes: 1

zer0
zer0

Reputation: 2909

My Understanding

What I understand from your description is:

  1. You have an application, built using the microservice architecture (meaning you will have it split into components that will communicate with eachother).
  2. You want to deploy this application on a public cloud (EKS, GCP, AWS).
  3. You want a separation of the APPLICATION control plane (decision making components like authentication APIs, internal service routing) from the APPLICATION data plane (the serving of your application data to the clients through the egress).

If those 3 points above are true, then the answer is yes, every cloud platform has these capabilities. You will need to architect your application in a manner that your control microservices are isolated from your data microservices. There are many ways in which you can do it (most/all of them are available in all public clouds).

Some Design Ideas

Here is a conceptual description:

  1. By using authentication and authorization mechanisms to ensure authorized communication between control and data plane applications. Think kubernetes ServiceAccounts.
  2. By using network policies to restrict unauthorized traffic flow between microservices. You will require a networking overlay that supports these. Think calico CNI.
  3. By using separate namespaces for your application services as necessary for better isolation.
  4. At one level below, in your cloud, you can limit the traffic using security groups. Or even gateways.
  5. You can use different instance types that match your various workload types, this will not only ensure optimal performance but also separation of failure domains. For example, if a dedicated database instance crashed, the event streaming service will still be running.

Some Notes

Also understand that in a public cloud solution (even EKS) a cluster->cluster traffic is more expensive for you than the traffic inside a single cluster. This will be a very important cost factor and you should consider using a single cluster for your application. (k8s clusters can typically scale to 1000s of nodes).

I hope this somewhat answers your question. There are a lot of decisions you need to make but in short, yes, it is possible to do this separation, and your entire application will have to be designed in this way.

Upvotes: 1

Related Questions