Steps of creating and deleting a pod

5/8/2019

I'm studying the main components of kubernetes. I was momentarily stuck regarding the concept of creating (deleting) a pod. In many charts or figures the pods are depicted inside the worker nodes and for this reason I was convinced that they were objects created directly in the worker node.

In depth this concept I came across some pages that see the pod as a simple placeholder in the API server instead.

In this reference link it is said that in the first point the pod is created and in the fourth point that the pod is associated with the node from the API server.
In this reference link it is said that "a new Pod object is created on API server but is not bound to any node."
In this reference link it is said that "A Pod has one container that is a placeholder generated by the Kubernetes API"

All this makes me think that a pod is not actually created in a worker node. Could someone give me an explanation to clarify this idea for me?

-- Humbrum
kubernetes
kubernetes-apiserver
kubernetes-pod

2 Answers

5/10/2019

There is a good explanation by @Vasily Angapov about the creation and scheduling of a pod, but I think it is important to also add some context of what Pods and containers actually are - if you would like to read more about it you can find a good additional information here.

In essence Pods are created and later on scheduled. So they are not created on a worker node but they are running on node and they are considered easily replaceable and not a durable entity . Therefore whenever something happens to them which results in their termination or deletion they might be started again on different node because of the reasons mentioned in Vasilys answer.

Some more information here.

-- aurelius
Source: StackOverflow

5/9/2019

Simply speaking the process of running pod is the following:

  1. User makes API request to create pod in namespace.
  2. API server validates the request making sure that user has necessary authorization to create pod in given namespace and that request conforms to PodSpec.
  3. If request is valid API server creates API object of kind "Pod" in its Etcd database.
  4. Kube-scheduler watches Pods and sees that there is new Pod object. It then evaluates Pod's resources, affinity rules, nodeSelectors, tolerations and so on and finally makes a decision on which node the pod should run. If there are no nodes available due to lack of resources or other constraints - Pod remains in state Pending. Kube-scheduler periodically retries scheduling decisions for Pending pods.
  5. After Pod is scheduled to node kube-scheduler passes the job to kubelet on selected node.
  6. Kubelet is then responsible for actually starting the pod.
-- Vasily Angapov
Source: StackOverflow