From aecd481e4cdad019cdcf1bcc2b4d94012d4e1336 Mon Sep 17 00:00:00 2001 From: Qiming Date: Thu, 26 Oct 2017 05:22:49 +0800 Subject: [PATCH] Add a simple pod manifest to pod overview (#5986) --- docs/concepts/workloads/pods/pod-overview.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/concepts/workloads/pods/pod-overview.md b/docs/concepts/workloads/pods/pod-overview.md index 760678fc70984..02f2531e9efb7 100644 --- a/docs/concepts/workloads/pods/pod-overview.md +++ b/docs/concepts/workloads/pods/pod-overview.md @@ -74,6 +74,22 @@ In general, Controllers use a Pod Template that you provide to create the Pods f Pod templates are pod specifications which are included in other objects, such as [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/), and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Controllers use Pod Templates to make actual pods. +The sample below is a simple manifest for a Pod which contains a container that prints +a message. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] +``` Rather than specifying the current desired state of all replicas, pod templates are like cookie cutters. Once a cookie has been cut, the cookie has no relationship to the cutter. There is no quantum entanglement. Subsequent changes to the template or even switching to a new template has no direct effect on the pods already created. Similarly, pods created by a replication controller may subsequently be updated directly. This is in deliberate contrast to pods, which do specify the current desired state of all containers belonging to the pod. This approach radically simplifies system semantics and increases the flexibility of the primitive.