📌 The <COMMAND> has to be the literal command as you would type it on a command line. After the -- only the command line shall appear
📌 <PORT> is purely informative.
An example of the above is the following:
📌 busybox is one of your best allies when it comes to creating testing/dummy Pods. Another option is alpine.
📌 By default a Pod’s container will always be restarted by K8s once it dies.
We can easily execute a process inside the former Pod, for instance we can check environment variables:
Running a “casual”, temporal Pod inside a Cluster:
📌 -it allows to attach your container to the local console.
📌 run is for running Pods and exec is for executing commands on Pods (or, more precisely, containers pertaining to Pods)
If you need to customize a Pod manifest you can start with a YAML boilerplate, edit it and finally apply it.
The --dry-run=client and -o=yaml are the key options when it comes to creating a boilerplate, for instance:
will generate a b2.yaml file containing:
then you can edit the file b2.yaml adding the custom directives you may need and finally
To check the logs of a Pod
📌 If a Pod executes more than one container you can always select the target container with -c <CONTAINER_NAME>
📌 Use --previous to get logs of a previous execution. -f can be used to stream logs.
🧰 Pod manifest examples
Hereby you will find some Pod manifest examples highlighting different features related to Pods.
Pod with a custom Service Account
📌 A Service Account allows service within a Namespace to call the K8s API Server.
Pod with liveness probe
📌 There are thresholds to consider the process as dead.
Pod with readiness probe
📌 There are thresholds to consider the process as ready.
Pod with security context
📌 A Security Context allows to set up a UID and GID under which the container process will execute.
Pod with resource declaration
📌 If a Namespace defines quotas then resource declaration is mandatory.
Pod with main and Sidecar containers
📌 There are other multi-container patterns such as Ambassador or Adapter.