<p>I'm confused with one behavior of pod in k8s. I pulled and run my alpine container and it is working fine when I see the docker ps -a command, but when I run it through k8s the output of the kubectl get pod shows complete. although in the Dockerfile I typed
CMD [&quot;sleep&quot;, &quot;3600&quot;], it is not going to sleep in k8s. I can send it to sleep mode with the kubectl run myalpine --image=myalpine -- sleep infinity and pod is working fine, But I don't want to use that command I expect that when I clearly type the sleep command in the Dockerfile and build it, k8s should run it as well.
I really appreciate it if someone explain the behavior of the pod.</p>

<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/" rel="nofollow noreferrer">The documentation</a> has some useful explanations:</p>
<blockquote>
<p>Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.</p>
</blockquote>
<p>Think of such as the unit of “deployment”—And excuse the abuse of terminology here, since <em>deployment</em> itself is a very well defined and precise concept in k8s as well, namely another type of workload. Pods are classified as a workload.</p>
<blockquote>
<p>A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. A Pod's contents are always co-located and co-scheduled, and run in a shared context. A Pod models an application-specific &quot;logical host&quot;: it contains one or more application containers which are relatively tightly coupled. In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.</p>
</blockquote>
<p>So that’s one part of the answer you’re looking for: a pod models a “logical host” where you can assemble fairly-fully-functional applications (“microservices” if you want, that do 1 basic thing, but do it well) out of one or several containers together.</p>
<p>I like to think of this as some form of composition but brought up to the application level via patterns such as <em>sidecar</em> and <em>adapter</em>. Similar to how you implement cross-cutting concerns in DDD, such as logging, by abstracting them and providing a generic implementation that ought to work the same when used by any class (“attached” to any main container) albeit some wiring work being required. It is precisely that PodSpec that wires these containers up.</p>
<blockquote>
<p>As well as application containers, a Pod can contain init containers that run during Pod startup. You can also inject ephemeral containers for debugging if your cluster offers this.</p>
</blockquote>
<p>Continues supporting the analogy I gave above to composition in OOP/DDD.</p>
<p>The official documentation continues adding more explanations along those lines.</p>
<blockquote>
<p>In terms of Docker concepts, a Pod is similar to a group of Docker containers with shared namespaces and shared filesystem volumes.</p>
</blockquote>
<p>Lastly, when you want to run a container in Kubernetes (necessarily through a pod) via <code>kubectl run</code> be careful you are not overriding the container entrypoint/command-args:</p>
<blockquote>
<p>When you override the default Entrypoint and Cmd, these rules apply:</p>
<ul>
<li>If you do not supply <code>command</code> or <code>args</code> for a Container, the defaults defined in the Docker image are used.</li>
<li>If you supply a <code>command</code> but no <code>args</code> for a Container, only the supplied <code>command</code> is used. The default EntryPoint and the default Cmd
defined in the Docker image are ignored.</li>
<li>If you supply only <code>args</code> for a Container, the default Entrypoint defined in the Docker image is run with the <code>args</code> that you supplied.</li>
<li>If you supply a <code>command</code> and <code>args</code>, the default Entrypoint and the default Cmd defined in the Docker image are ignored. Your <code>command</code> is
run with your <code>args</code>.</li>
</ul>
</blockquote>
