K
Q

k8s: Is it possible to have two identical deployments but route different traffic to them?

12/17/2021

Here is my use case:

I have a microservice which gets sent traffic via an ingress gateway in real time and via a batch process. What I'd like to be able to do is be able to conceptually define a deployment and have it create two sets of pods:

  • One set for real time request
  • Another for batch.

When a new version of the microservice gets deployed, the k8s deployment is updated and both real time and batch use the new version.

Is this possible in k8s or will I need to create two deployments and manage them separately?

-- Mat
kubernetes
kubernetes-deployment

Similar Questions

Grafana installed on kubernated web href not working
helm init - error executing access token command
How to change a running pod name?
How to mount HostPath Volume in Kubernetes with SELinux
Ingress on GKE is using ephemeral addresses despite specifiying a static one

1 Answer

12/29/2021

This is a community wiki answer posted for better visibility. Feel free to expand it.

Since we don't know the complete information about the architecture used, the following suggestions from comments can be used in the future to solve the problem.

1. With Deployments, Services, Selectors

You can have two identical deployments and route different traffic to them. It may be implemented by Services:

In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined by a selector.

Such approach has some advantages.

  • By default, traffic will be routed to endpoints in random way if you are using iptables proxy mode. When you try to send traffic to specific pods covered by the same deployment - it may happen large differences in CPU and Memory usage leading to the resource exhaustion or wasting resources.
  • It will be easier to manage service versioning, CPU and Memory assignment and rollouts.

2. With Istio

From David M. Karr

If a service is defined as a VirtualService, you can route to different DestinationRule objects depending on header values (or other qualifications).

Additionally

If you need to deploy a new version of the microservice, you can choose between different strategies, which is more suitable for your needs. Kubernetes deployment strategies:

  • recreate: terminate the old version and release the new one
  • ramped: release a new version on a rolling update fashion, one after the other
  • blue/green: release a new version alongside the old version then switch traffic
  • canary: release a new version to a subset of users, then proceed to a full rollout
  • a/b testing: release a new version to a subset of users in a precise way (HTTP headers, cookie, weight, etc.). A/B testing is really a technique for making business decisions based on statistics but we will briefly describe the process. This doesn’t come out of the box with Kubernetes, it implies extra work to setup a more advanced infrastructure (Istio, Linkerd, Traefik, custom nginx/haproxy, etc).
-- Andrew Skorkin
Source: StackOverflow