Please visit these pages for more details about Pods:
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/
https://kubernetes.io/docs/concepts/security/controlling-access/
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

Pods are the atomic units of deployment in Kubernetes.
A Pod is a special container that defines one or more containers that can run inside of it.
Containers, running inside a Pod, share the Pod's resources: IP address, ports, hostname, volumes, ...
They can communicate with each other using localhost interface.

To share resources, containers leverage Linux features: Control groups (cgroups) and kernel namespaces.
Control groups (cgroups) allow containers to use only their assigned resources: cpu, ram, and iops.
Kernel namespaces (Network, UTS, IPC, ...) allow containers to have their own unique and limited view of the system resources (filesystem, network interfaces, disk, ...):

It's recommended to have only one container inside a Pod.
But there might be use cases where it will be acceptable to have more than one container running inside a Pod. For example, it's possible to co-locate multiple containers that provide services that are tightly coupled and/or they need to share the Pod's resources.
It's also possible to have one main container inside the Pod and add one or more sidcar containers that provide additional features to the main container (for example: logging, monitoring, ...).

To create/deploy a Pod, you need first to create a manifest file (YAML). The manifest file describe the Pod and its components (name, image, port, ...). You can use kubectl (or any rest client tool) to post the manifest file to the API server. If applicable, the API server verifies that the request is authenticated, validates it's authorized, and runs the admission controllers on it. The API server verifies the manifest file and, if no issues, it writes a record for that manifest in the cluster store (etcd). The scheduler will then read the record and deploy it to a healthy worker node with enough available resources.

You can also use imperative commands (kubectl command-line tool) to create and manage Pods.

Here's the list of events that leads to the creation of a Pod:

• You define a Pod in a manifest file (YAML)
  
  
• You post the manifest file to the API server.
  
  
• The API server validates the manifest and persist it in the cluster store (etcd) as record of intent (desired state)
  
  
• The scheduler reads the record, converts it into a PodSpec, and schedules the PodSpec to healthy worker node with enough available resources.
  
  
• The kubelet (a Kubernetes agent) accepts the PodSpec and start the creation of the Pod.
  
  
• The Pod enters the Pending state while the container runtime, on the worker node, download the images and starts the containers.
  
  
• The Pod remains in the Pending state until all of its containers are created.
  
  
• The Pod enters the running state, if its containers are created successfully.
  
  
• The Pod enters the succeeded state, if it successfully finishes its tasks.
  
  
• The Pod enters the failed state, if one or more container failed. The Pod won't be rescheduled.
  

The hello-busybox-pod.yaml file provides a declarative configuration of a Pod:
apiVersion: v1 kind: Pod metadata: name: hello-busybox labels: product: mtitek stage: dev spec: containers: - name: hello-busybox image: busybox:latest command: ['sh', '-c', 'echo "hello, busybox!"; sleep 300;']
The "hello-busybox-pod.yaml" file defines the following fields:

• The .apiVersion field defines the Kubernetes API group and the Kubernetes API version.
  Its value is written as following: <api-group>/<api-version>
  Example: storage.k8s.io/v1
  The Pods are defined in the core API group, which is the default if the api-group is not set.
  So in the case of Pods, only the api version needs to be provided.
  
  
• The .kind field defines the type of the Kubernetes object defined in the manifest file.
  
  
• The .metadata field defines the Pod metadata (name, labels, namespace, ...).
  
  
• The .spec field defines the containers information (name, image, command, ports, ...).
  

Note: The command field can also be written as following:
command: ['sh'] args: ['-c', 'echo "hello, busybox!"; sleep 300;'] command: - sh - -c - echo "hello, busybox!"; sleep 300; command: - sh - -c - | echo "hello, busybox!"; sleep 300;
Note:
Managing Pods using the Manifest Yam file (declarative) is the recommended way, but in some cases you might want to use the "kubectl create" command to create a Pod (imperative command).
The following creates a Pod using the busybox image and opens an interactive shell:
$ kubectl run -i -t hello-busybox --image=busybox:latest -- sh
-i, --stdin=false: Keep stdin open on the container(s) in the pod, even if nothing is attached.
-t, --tty=false: Allocated a TTY for each container in the pod.

• To deploy the hello-busybox-pod.yaml file:
  $ kubectl apply -f hello-busybox-pod.yaml pod/hello-busybox created
  
• To list all Pods (kubectl get pods):
  $ kubectl get pods NAME READY STATUS RESTARTS AGE hello-busybox 1/1 Running 0 18s
  
• To list detailed information about all Pods (-o wide):
  $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-busybox 1/1 Running 0 80s 10.1.0.9 docker-desktop <none> <none>
  
• To see the info of a specific Pod (kubectl get pod <POD-NAME>):
  $ kubectl get pod hello-busybox NAME READY STATUS RESTARTS AGE hello-busybox 1/1 Running 0 18s
  
• To see detailed information about a specific Pod (-o wide):
  $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-busybox 1/1 Running 0 80s 10.1.0.9 docker-desktop <none> <none>
  
• To print the manifest file of a specific Pod as stored in the cluster store (etcd):
  $ kubectl get pod hello-busybox -o yaml
  Note:
  The printed yaml object contains more settings than what it was defined in the original manifest file.
  Some of the settings are the default values that Kubernets gives to the missing field in the manifest file.
  Some of the settings are runtime information set by Kubernets (node IP address, Pod IP address, container info, status, ...).
  
  The status field provides detailed information about the different transitional states of the Pod.
  
  $ kubectl get pod hello-busybox -o yaml apiVersion: v1 kind: Pod metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"product":"mtitek","stage":"dev"},"name":"hello-busybox","namespace":"default"},"spec":{"containers":[{"args":["-c","echo \"hello, busybox!\"; sleep 300;"],"command":["sh"],"image":"busybox:latest","name":"hello-busybox"}]}} creationTimestamp: "2021-05-30T07:27:15Z" labels: product: mtitek stage: dev managedFields: - apiVersion: v1 ... manager: kubelet operation: Update time: "2021-05-30T07:27:17Z" name: hello-busybox namespace: default resourceVersion: "207330" selfLink: /api/v1/namespaces/default/pods/hello-busybox uid: 37bd1089-51b2-4d9f-b34e-9331fc960a0a spec: containers: - args: - -c - echo "hello, busybox!"; sleep 300; command: - sh image: busybox:latest imagePullPolicy: Always name: hello-busybox resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: default-token-qvt58 readOnly: true dnsPolicy: ClusterFirst enableServiceLinks: true nodeName: docker-desktop preemptionPolicy: PreemptLowerPriority priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 30 tolerations: ... volumes: - name: default-token-qvt58 secret: defaultMode: 420 secretName: default-token-qvt58 status: conditions: - lastProbeTime: null lastTransitionTime: "2021-05-30T07:27:15Z" status: "True" type: Initialized - lastProbeTime: null lastTransitionTime: "2021-05-30T07:27:17Z" status: "True" type: Ready - lastProbeTime: null lastTransitionTime: "2021-05-30T07:27:17Z" status: "True" type: ContainersReady - lastProbeTime: null lastTransitionTime: "2021-05-30T07:27:15Z" status: "True" type: PodScheduled containerStatuses: - containerID: docker://dacd7d6f411764b02b26884ef48c5ceec1d60faace4a8fbbc670638e2a6cb806 image: busybox:latest imageID: docker-pullable://busybox@sha256:b5fc1d7b2e4ea86a06b0cf88de915a2c43a99a00b6b3c0af731e5f4c07ae8eff lastState: {} name: hello-busybox ready: true restartCount: 0 started: true state: running: startedAt: "2021-05-30T07:27:16Z" hostIP: 192.168.65.4 phase: Running podIP: 10.1.0.15 podIPs: - ip: 10.1.0.15 qosClass: BestEffort startTime: "2021-05-30T07:27:15Z"
  
• To describe a Pod (kubectl describe pod).
  
  The command provides detailed information about the Pod (node IP address, Pod IP address, container info, ...) and its current state.
  It also provide the list of the events (Scheduled, Pulled, Created, Started, ...) occurred while creating and running the Pod.
  
  $ kubectl describe pod hello-busybox Name: hello-busybox Namespace: default Priority: 0 Node: docker-desktop/192.168.65.4 Start Time: Sun, 30 May 2021 03:27:15 -0400 Labels: product=mtitek stage=dev Annotations: <none> Status: Running IP: 10.1.0.15 IPs: IP: 10.1.0.15 Containers: hello-busybox: Container ID: docker://dacd7d6f411764b02b26884ef48c5ceec1d60faace4a8fbbc670638e2a6cb806 Image: busybox:latest Image ID: docker-pullable://busybox@sha256:b5fc1d7b2e4ea86a06b0cf88de915a2c43a99a00b6b3c0af731e5f4c07ae8eff Port: <none> Host Port: <none> Command: sh Args: -c echo "hello, busybox!"; sleep 300; State: Running Started: Sun, 30 May 2021 03:27:16 -0400 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-qvt58 (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: default-token-qvt58: Type: Secret (a volume populated by a Secret) SecretName: default-token-qvt58 Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m13s default-scheduler Successfully assigned default/hello-busybox to docker-desktop Normal Pulling 3m12s kubelet Pulling image "busybox:latest" Normal Pulled 3m12s kubelet Successfully pulled image "busybox:latest" in 448.2757ms Normal Created 3m12s kubelet Created container hello-busybox Normal Started 3m12s kubelet Started container hello-busybox
  
• To monitor the status of the Pods (--watch):
  $ kubectl get pods --watch NAME READY STATUS RESTARTS AGE hello-busybox 0/1 ContainerCreating 0 2s hello-busybox 1/1 Running 0 17s
  
• To run a commands in a Pod (kubectl exec):
  $ kubectl exec hello-busybox -- ps PID USER TIME COMMAND 1 root 0:00 sleep 300 8 root 0:00 ps
  
• To login into a Pod:
  $ kubectl exec -it hello-busybox -- sh / # ps PID USER TIME COMMAND 1 root 0:00 sleep 300 7 root 0:00 sh 13 root 0:00 ps / #
  If more than one container are running in the Pod, then the command will be executed against the first container in the Pod (see the command: kubectl describe pod hello-busybox). To login to a specific container, you need to use the --container (-c) flag and give it the name of the container:
  $ kubectl exec -it hello-busybox --container hello-busybox -- sh
  As you will see later, the --container (-c) flag apply also to init containers.
  
  
• To print the logs of a Pod (kubectl logs):
  $ kubectl logs hello-busybox hello, busybox!
  If more than one container are running in the Pod, then the command will be executed against the first container in the Pod (see the command: kubectl describe pod hello-busybox). To print the logs of a specific container, you need to use the --container (-c) flag and give it the name of the container:
  $ kubectl logs hello-busybox --container hello-busybox
  As you will see later, the --container (-c) flag apply also to init containers.
  

To delete a Pod: using manifest file (kubectl delete):
$ kubectl delete -f hello-busybox-pod.yaml pod "hello-busybox" deleted
To delete a Pod using its name:
$ kubectl delete pod hello-busybox pod "hello-busybox" deleted
To delete a Pod immediately (by default the Pod takes 30 seconds to gracefully shut down.):
$ kubectl delete pod hello-busybox --grace-period=0 pod "hello-busybox" deleted