<p>So I'm trying to wrap my head around what exactly a typical Kubernetes pod looks like. According to <a href="http://kubernetes.io/v1.0/docs/user-guide/pods.html" rel="nofollow">their docs</a>, a <em>pod</em>:</p>

<blockquote>
  <p>"<em>A pod (as in a pod of whales or pea pod) corresponds to a colocated group of applications running with a shared context.</em>"</p>
</blockquote>

<p>Later in that same article:</p>

<blockquote>
  <p>"<em>Pods can be used to host vertically integrated application stacks, but their primary motivation is to support co-located...</em>"</p>
</blockquote>

<p>OK, so you <em>can</em> organize a single pod as your entire vertical stack (from DB to web app). But apparently that's not typically how it's organized, so I assume that typically a "<em>horizontal</em>" organization is preferred (<strong>why??</strong>).</p>

<p>But to me, horizontal layering/stratification implies that you'll only have one container in a pod, because typically in each tier of service (web, app, cache, db, etc.) you'll have one type of component.</p>

<p>Let's take a concrete example. Say we have the following vertical stack of tiers:</p>

<ul>
<li>Web frontend containers; Grails or Spring MVC web/app server</li>
<li>Microservices containers; RESTful web services where core business logic lives</li>
<li>Message broker (say RabbitMQ) containers</li>
<li>Microservice cache (some services have distributed Hazelcast cache clusters sitting between them and their DB/backing store) containers</li>
<li>MySQL DB cluster containers</li>
<li>MongoDB cluster containers</li>
<li>3rd party RESTful cloud API (say SalesForce or Stripe or something similar)</li>
</ul>

<p>These are fairly typical components in an app stack. If we went against Kubernetes' own advice, and created "vertically-aligned" pods, each pod would consist of 1 type of container for each tier (the web/app server, each microservice, each DB, etc.).</p>

<p><strong>But how would a horizontally-aligned pod be organized? What containers would go in which pods?</strong></p>

<p>A Pod is the basic scheduling unit in Kubernetes. It is the common case that a pod will only have a single container running in it, as most containers can be scheduled independently (i.e. they do not need to be co-located on the same machine).</p>

<p>With regards to your example, you could put most containers in individual pods, and use a <strong>Replication Controller</strong> to horizontally scale the number of replicas of each Pod (and therefore container) as needed. Along with your replication controller, you'll also want a <strong>Service</strong> to load balance between the replicas. Vertical tiers could be organized using labels on the pods/replication controllers/services, such as <code>tier=message_broker</code>.</p>

<p><em>Edit:</em></p>

<p>The reason it's not a good idea to put your entire stack in a single pod is it limits your flexibility:</p>

<ul>
<li>It forces your entire stack to be scheduled on a single machine, which could make scheduling more difficult if machines lack some of the necessary resources.</li>
<li>Individual components cannot be scaled independently (e.g. if you need more frontend replicas to handle traffic, but your DB is only used for a small number of queries)</li>
<li>All the containers would need to agree on which ports to use. Each pod has a unique IP, so containers running in separate pods can use the same ports.</li>
</ul>
