<p>I have been creating pods with <code>type:deployment</code> but I see that some documentation uses <code>type:pod</code>, more specifically <a href="http://kubernetes.io/docs/user-guide/pods/multi-container/" rel="noreferrer">the documentation for multi-container pods</a>:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~
</code></pre>

<p>But to create pods I can just use <a href="http://kubernetes.io/docs/user-guide/deployments/" rel="noreferrer">a deployment type</a>:</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc
</code></pre>

<p>I noticed the pod documentation says:</p>

<blockquote>
  <p>The create command can be used to create a pod directly, or it can
  create a pod or pods through a Deployment. It is highly recommended
  that you use a Deployment to create your pods. It watches for failed
  pods and will start up new pods as required to maintain the specified
  number. If you don’t want a Deployment to monitor your pod (e.g. your
  pod is writing non-persistent data which won’t survive a restart, or
  your pod is intended to be very short-lived), you can create a pod
  directly with the create command.</p>
  
  <p>Note: We recommend using a Deployment to create pods. You should use
  the instructions below only if you don’t want to create a Deployment.</p>
</blockquote>

<p>But this raises the question of what <code>kind:pod</code> is good for? Can you somehow reference pods in a deployment? I didn't see a way. It looks like what you get with pods is some extra metadata but none of the deployment options such as <code>replica</code> or a restart policy. What good is a pod that doesn't persist data, survives a restart? I think I'd be able to create a multi-container pod with a deployment as well.</p>

<p>Radek's answer is very good, but I would like to pitch in from my experience, you will almost never use an <strong>object</strong> with the <strong>kind</strong> <strong>pod</strong>, because that doesn't make any sense in practice. </p>

<p>Because you need a <strong>deployment</strong> object - or other Kubernetes API objects like a <strong>replication controller</strong> or <strong>replicaset</strong> - that needs to keep the <strong>replicas</strong> (pods) alive (that's kind of the point of using kubernetes).</p>

<p>What you will use in practice for a typical application are:</p>

<ol>
<li><p><strong>Deployment object</strong> (where you will specify your apps container/containers) that will host your app's container with some other specifications.</p></li>
<li><p><strong>Service object</strong> (that is like a grouping object and gives it a so-called virtual IP (cluster IP) for the <code>pods</code> that have a certain label - and those <code>pods</code> are basically the app containers that you deployed with the former <strong>deployment</strong> object).</p></li>
</ol>

<p>You need to have the <strong>service</strong> object because the <code>pods</code> from the deployment object can be killed, scaled up and down, and you can't rely on their IP addresses because they will not be persistent.</p>

<p>So you need an object like a <strong>service</strong>, that gives those <code>pods</code> a stable IP.</p>

<p>Just wanted to give you some context around <code>pods</code>, so you know how things work together.</p>

<p>Hope that clears a few things for you, not long ago I was in your shoes :)</p>
