Answers: <h2>Is the app stateless</h2>
  <blockquote>
  <p>The software is stable as such but my concern is pods, by nature, are meant to be replaceable</p>
  </blockquote>
  <p>This is your primary concern. Is the app <em>stateless</em> (e.g. can the requests be served by any of multiple instances without problem?). If <strong>not</strong> - be very careful to run it on Kubernetes (e.g. don't use rolling-deployment) and don't run the app in the cloud :)</p>
  <p>Apps running on Kubernetes or cloud should follow <a href="https://12factor.net/" rel="nofollow noreferrer">The Twelve Factor principles</a></p>
  <h2>Number of Servers</h2>
  <p>It would be good to be able to use two or more servers. This reduce the Single-Point-Of-Failure, and you can e.g. take down one server for maintenance but still serve your users.</p>
  <h2>App directly on Server or in Container</h2>
  <blockquote>
  <p>pods (on the same server) or 1 standalone application?</p>
  </blockquote>
  <p>An application runs as a <em>process</em> on the Operating System, whether you run it on a container or as non-container process. There is almost no runtime overhead, what you get with containers is <em>repeatability</em> and <em>maintainability</em>.</p>
  <p>A container is designed to be <em>hermetically sealed</em>, so it is not sensitive to your servers configuration e.g. what language-settings or character encoding. This was a bigger problem before containers was used. With containers the app runs in an identical environment every time, except the <em>kernel</em>. In addition it is easier to maintain and manage processes when run as containers, you can e.g. set limits for CPU usage, Memory limit and they get its own network e.g. multiple containers on the same server can listen to port 8080 (from the applications standpoint).</p>
  <p>If your apps run as containers on a server cluster, you can also easyli scale out or in by adding or removing servers.</p>
  <h2>Control of resources</h2>
  <blockquote>
  <p>My guess is that once 1 pod gets into to much trouble (memory pressure to name a thing) Kubernetes is going to restart it, as pods are meant to be replaceable.</p>
  </blockquote>
  <p>Yeah, but this is a good thing. Kubernetes is mostly <em>self-healing</em>. If you don't have such &quot;control-loops&quot;, you will need manual internvention - since it is the same app that e.g. may have memory leaks.</p>
  <h2>Run app on Kubernetes or not</h2>
  <blockquote>
  <p>whether we do or don't use Kubernetes doesn't depend on this part of the implementation alone</p>
  </blockquote>
  <p>The first thing to check: <strong>Is the app stateless?</strong>
  and also, you should use <strong>two or more servers</strong> otherwise you get little advantage of running it in Kubernetes.</p>
  <p>There is a cost to maintain Kubernetes. You need skills and you need to maintain an addition system. Make sure it adds enough value for you.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-02-06T13:44:37.727Z
Answers: I'll add to this, it's only worth considering deploying it in Kubernetes if you already have a cluster running.  Otherwise, it's way too much effort to deploy it for a single app that can run just fine on a standalone server.
Answers: maplebird
Answers: CC BY-SA 4.0
Answers: 2021-02-06T10:15:29.120Z
Answers: 2021-02-06T10:15:29.120Z
Answers: Jonas
Body: <p>For a client we're going to roll out a certain type of software installation.</p>
  <p>(I can give more details in the comments if you like.)</p>
  <p>The question is: would you go for 2 pods (on the same server)?</p>
  <p>Or would a single installation be more stable?</p>
  <p>The software is stable as such but my concern is pods, by nature, are meant to be replaceable...</p>
  <p>There is also the option of a single pod on the machine, but I have deep concerns about this approach...</p>
  <p>My guess is that once 1 pod gets into to much trouble (memory pressure to name a thing)
  Kubernetes is going to restart it, as pods are meant to be replaceable.</p>
  <p>(Bringing down the clients' application during the process.)</p>
  <p>So I guess 2 pods is a solution here.</p>
  <p>1 pod should be able to handle the load (his load + the extra load of the restarting pod).</p>
  <p>What I don't know is whether 2 pods would be as stable as running the software on 1 node,
  without Kubernetes.</p>
  <p>In the same process we're also going to roll out 2 pods on 2 virtual machines, with other software,</p>
  <p>so the choice whether we do or don't use Kubernetes doesn't depend on this part of the implementation alone.</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-02-05T22:41:23.720Z
Comments: If you do single installation without kubernetes, do you have automatic restart if it does go down? (eg linux or windows services can have auto-restart as can anything in a webserver).  If you have, what value would kubernetes still add?
Comments: Chris F Carroll
Tags: <kubernetes>
Title: What's better: 2 pods (on the same server) or 1 standalone application?
UserDisplayName: Delogiastref
ThreadText: # What's better: 2 pods (on the same server) or 1 standalone application?
  
  (Asked by: username_0 on 2021-02-05)
  
  For a client we're going to roll out a certain type of software installation.
  
  (I can give more details in the comments if you like.)
  
  The question is: would you go for 2 pods (on the same server)?
  
  Or would a single installation be more stable?
  
  The software is stable as such but my concern is pods, by nature, are meant to be replaceable...
  
  There is also the option of a single pod on the machine, but I have deep concerns about this approach...
  
  My guess is that once 1 pod gets into to much trouble (memory pressure to name a thing)
  Kubernetes is going to restart it, as pods are meant to be replaceable.
  
  (Bringing down the clients' application during the process.)
  
  So I guess 2 pods is a solution here.
  
  1 pod should be able to handle the load (his load + the extra load of the restarting pod).
  
  What I don't know is whether 2 pods would be as stable as running the software on 1 node,
  without Kubernetes.
  
  In the same process we're also going to roll out 2 pods on 2 virtual machines, with other software,
  
  so the choice whether we do or don't use Kubernetes doesn't depend on this part of the implementation alone.
  
  **Tags:** kubernetes
  
  > **Comments:**
  > **username_1**: If you do single installation without kubernetes, do you have automatic restart if it does go down? (eg linux or windows services can have auto-restart as can anything in a webserver).  If you have, what value would kubernetes still add?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2021-02-06. Score: 2 | Accepted answer
  
  ## Is the app stateless
  
  > The software is stable as such but my concern is pods, by nature, are meant to be replaceable
  
  This is your primary concern. Is the app *stateless* (e.g. can the requests be served by any of multiple instances without problem?). If **not** - be very careful to run it on Kubernetes (e.g. don't use rolling-deployment) and don't run the app in the cloud :)
  
  Apps running on Kubernetes or cloud should follow [The Twelve Factor principles](https://12factor.net/)
  
  ## Number of Servers
  
  It would be good to be able to use two or more servers. This reduce the Single-Point-Of-Failure, and you can e.g. take down one server for maintenance but still serve your users.
  
  ## App directly on Server or in Container
  
  > pods (on the same server) or 1 standalone application?
  
  An application runs as a *process* on the Operating System, whether you run it on a container or as non-container process. There is almost no runtime overhead, what you get with containers is *repeatability* and *maintainability*.
  
  A container is designed to be *hermetically sealed*, so it is not sensitive to your servers configuration e.g. what language-settings or character encoding. This was a bigger problem before containers was used. With containers the app runs in an identical environment every time, except the *kernel*. In addition it is easier to maintain and manage processes when run as containers, you can e.g. set limits for CPU usage, Memory limit and they get its own network e.g. multiple containers on the same server can listen to port 8080 (from the applications standpoint).
  
  If your apps run as containers on a server cluster, you can also easyli scale out or in by adding or removing servers.
  
  ## Control of resources
  
  > My guess is that once 1 pod gets into to much trouble (memory pressure to name a thing) Kubernetes is going to restart it, as pods are meant to be replaceable.
  
  Yeah, but this is a good thing. Kubernetes is mostly *self-healing*. If you don't have such "control-loops", you will need manual internvention - since it is the same app that e.g. may have memory leaks.
  
  ## Run app on Kubernetes or not
  
  > whether we do or don't use Kubernetes doesn't depend on this part of the implementation alone
  
  The first thing to check: **Is the app stateless?**
  and also, you should use **two or more servers** otherwise you get little advantage of running it in Kubernetes.
  
  There is a cost to maintain Kubernetes. You need skills and you need to maintain an addition system. Make sure it adds enough value for you.
  
  > **Comments:**
  > **username_3**: I'll add to this, it's only worth considering deploying it in Kubernetes if you already have a cluster running.  Otherwise, it's way too much effort to deploy it for a single app that can run just fine on a standalone server.  
  
  ---
  
  