We have a .Net 3 tiered app that wasn't designed to scale horizontally. I've heard we can use docker to containerize our app and then put it on kubernetes. Is that enough for kubernetes to make it scale horizontally, or do we have to re-engineer our app?

3 Answers 3


All Kubernetes does is spin up multiple copies of your Docker container and load balance across these containers. If one of these containers dies, a replacement is automatically launched. If one of these containers can't handle traffic for some reason, Kubernetes will not send traffic to that container in question.

This means you don't scale the app by adding more resources to it - you scale the app by cloning it and distributing the clones to multiple locations. Kubernetes does not care about the internals of your app - it only cares that it's in a container.

If this seems like an ideal end situation for your needs, perfect.

There are some edge cases:

  1. What if your app needs to coordinate across these copies somehow? These come up in Kubernetes when running applications that need some notion of a primary or a master, such as Zookeeper. Kubernetes annotates your Docker containers with certain metadata, and enables applications inside a container to query the Kubernetes API to figure out who the leader should be across these applications using the metadata. To support this, you will need to redesign the app a little to rely on the Kubernetes API.

  2. What if your app requires some notion of global state? Kubernetes offers support for this using stateful sets, a Kubernetes concept that attaches a persistent volume that all containers, new and old, share across all nodes.

tl;dr Kubernetes is just a container scheduler with some nice features to allow containers to work with each other. This may or may not work for what you want.


It's hard to say for sure because don't explain what about this app would prevent it from scaling horizontally but in general the answer is "no". Just throwing an app on Kubernetes will not magically allow it to scale horizontally.

In other words, if the application can't work properly when distributed across multiple hosts, running it in Kubernetes is not going to change that. What you need to do or how much work that will be cannot be answered without more detail.


Kubernetes is just an automation tool. Before it, engineers made applications scale using different tools, a bunch of sh scripts, DNS, proxies and so on. K8s makes everything easier and manageable even from non-ops guys (with some guidance hopefully). Aside from that, it cannot do anything else for you. If the application is not scalable, we are talking about an application concern, automate scalability of a non-scalable app is like to install a bluetooth infotainment system on a bike

So what you need first to reach your target?

  1. Make sure that your server manages stateles workloads: no sessions, no context data used between subsequent requests, nor elections/consensus/distributed states

  2. Your DBMS can scale horizontally as well as other infra services (message queues)

  3. You are able to split your application in microservices, eventually

  4. As the number of microservices grows up, you will set up all the needed tools to make your platform observable

4.1 a trace collection system, to identify bootleneck and track dataflows in distribuited transactions

4.2 Monitoring system, to measure application and infrastructure load and act consequently

4.3 Log collection system, to analyze app behaviour

4.4 Error reporting system, to catch all internal fault conditions

  1. Your are able to build a full fledged CD supply chain

  2. You want to provide environemnts dynamically or debug remote applications

If you are able to follow the roadmap, then kubernetes will be you best friend, otherwise it will be only a very cool unnecessary complication

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.