Steps in creating a new pod: 1. A user submits a new configuration with kubectl to kube-API Server 2. Kube-API Server writes the configuration to etcd 3. Scheduler compares the configuration to actual state 4. Scheduler informs kube-API Server of which compute node(s) to schedule the workload 5. Kube-API Server requests corresponding Kubelets to create the new pod 6. Kubelet creates a new pod 7. Kubelets report latest status to kube-API Server 8. Kube-API Server updates the actual state in etcd
Nice summary! I also listed the pod state during the process, in a comment below: ruclips.net/video/BgrQ16r84pM/видео.html&lc=UgwWzlBMj4ka5IJsxE54AaABAg
I have been learning about Kubernetes for past one week and came across your video and it gave me an deep understanding about various stages of pod creation. Thanks much.
I noticed you didn't mention the Pod state during this process. Here it is: 1. After Kube-API server returned "created" response to user, the pod's state will be "pending" 2. After scheduler set the node for that pod, Pod's state will be "creating" 3. After Kubelet created the pod, state will be "running" 4. If the pod is failing and restarting, state will be "Crash loop back off"
Great explanation...thanks. this video. Would it be a bad idea if this video can be used in the IBM Cognitive Class Course called Introduction to Containers, Kubernetes, and OpenShift V2? (it's easier to conceptualize)
The Scheduler & Control Manager relies entirely on the information supplied by the API server to execute their functions. In the event of the API server being unavailable, these components would also cease to function. The question arises: in a loosely coupled microservices environment, why do we have separate components that are dependent on others? Why can't the API server itself handle the tasks of both Control and Scheduler, eliminating the need for additional components with interdependencies?
With k8s the atomic unit is the pod. If you just want to run a single instance of a container image you'd just have to create a pod referencing that image.
So I am a data scientist and hence mostly an end user of the pods.. thanks for the explanation. So when we create a pod it assigns a random generated (available) ip that I should use for the compute. In my case I was using a jupyter notebook. Since pods are ephemeral like you mentioned, we need to attach a disk to the vm/pod which is always available to me. One time while running some python commands, my pod crashed and I got assigned another vm ip but the person who got assigned the vm ip I was using until then got my jupyter notebook saved on his disk. What could have happened? I am intrigued.
Seems like a race condition... your pod got killed but respawned just fine due to restartPolicy = always (by default) the that same pod got assigned to someone else To avoid that I suggest set the restartPolicy to never or create a control plane that control the lifecycle of your pod so you always get the same pod until you dont need it anymore makes sense?
i think replication controller will talk to kube-api and kube-api to kubelet , to recreate the new pod with same config. it will not restart the same pod as pods are ephemeral. Also there will be small role of scheduler as well, as it will tell on which node that new pod will be recreated, either same node or new node, depending on node availability.
ETCD contain the desired state of the pod. as control manager has the health status of the node, when the pod dies , control manager -> write to api-> api will checks and write to ETCD and back to API-> when scheduler gets to know pod need to be created from API -> it starts the process.
When the pod dies who lets API server know the pod is dead? Is it kubelet? The video moves to controller manager and says that controller manager goes to Kube API server and gets to know the pod is down. But the state of the pod on the Compute node need to be conveyed back to the API server, isn't it?
yeah ofcourse, not only does the kubelet convey the state of pods in the node, but also informs the controller about the CPU and memory resources of the node
Then Controlller will communicate to kubectl through KubeAPI to create that pod to ensure replica set is satisfied. To ensure desired no# of pods == actual no# of pods.
Hi there! Depending upon where Kubernetes is deployed, you can integrate with different load balancers that the infrastructure provides to expose pods as Services running on k8s. Different Service types take advantage of different networking patterns to access the pods running on the underlying infrastructure. NodePort-based Services leverage existing IP addresses of compute nodes and are accessed via a Node-level proxy. LoadBalancer-based Services create new Load Balancer instances and handle traffic directly through the infrastructure-based LoadBalancer. So the answer to the question is “it depends on how you want to access it”. 🙂
it is from the back of the glass, and the video is mirrored. Do you notice that most instructors use their left hands to write? That's because the video is left-right mirrored.
The camera is at the back of the glass, and the video is mirrored. Do you notice that most instructors use their left hands to write? That's because the video is left-right mirrored.
This is the best video (that I have seen) on Kubernetes. Thank you!
Great description. I really like that you chose a specific, isolated use case (pod creation), and then you describe exactly what's involved.
This is the greatest video of all time for beginners in Kubernetes.
Steps in creating a new pod:
1. A user submits a new configuration with kubectl to kube-API Server
2. Kube-API Server writes the configuration to etcd
3. Scheduler compares the configuration to actual state
4. Scheduler informs kube-API Server of which compute node(s) to schedule the workload
5. Kube-API Server requests corresponding Kubelets to create the new pod
6. Kubelet creates a new pod
7. Kubelets report latest status to kube-API Server
8. Kube-API Server updates the actual state in etcd
Nice summary! I also listed the pod state during the process, in a comment below: ruclips.net/video/BgrQ16r84pM/видео.html&lc=UgwWzlBMj4ka5IJsxE54AaABAg
The Best video which explained the Pod creation
I have been learning about Kubernetes for past one week and came across your video and it gave me an deep understanding about various stages of pod creation. Thanks much.
I noticed you didn't mention the Pod state during this process.
Here it is:
1. After Kube-API server returned "created" response to user, the pod's state will be "pending"
2. After scheduler set the node for that pod, Pod's state will be "creating"
3. After Kubelet created the pod, state will be "running"
4. If the pod is failing and restarting, state will be "Crash loop back off"
i was looking for a simple explanation and it was soo difficult to find out. Thank you soo much for this video and the quality of your explanations!!
honestly the best explanation over web!!
Surely one of the coolest way to explain k8s pod creation 👍👍
Best and simple way how pod is created
Thanks a lot
kubelet does a few things:
1. register compute nodes
2. report status
3. start/stop workload
thanks for your explanation. But i am still confused about pod and container. can you explain?
I think one more thing needs to addressed here ,that is CNI for communication between pods , we have several of them like weave ,calico, flannel etc
Great explanation
excellent presentation !
A great explanation, good didatic. Thanks for your contribution 👏
Great introduction to the architecture of k8s. Well explained and clear.
very good explanation....
Is the actual state also stored in etcd ? How are the components aware of the actual state ?
Great explanation...thanks. this video. Would it be a bad idea if this video can be used in the IBM Cognitive Class Course called Introduction to Containers, Kubernetes, and OpenShift V2? (it's easier to conceptualize)
I was prepared for the question explain K8s architecture. But this question came in interview🙂
Perfect, all i needed !
5:12 CRI = Container Runtime Interface
I think you are confusing it with OCI: Open Container Initiative.
may be she just want to say container runtime -containerD
The Scheduler & Control Manager relies entirely on the information supplied by the API server to execute their functions. In the event of the API server being unavailable, these components would also cease to function. The question arises: in a loosely coupled microservices environment, why do we have separate components that are dependent on others? Why can't the API server itself handle the tasks of both Control and Scheduler, eliminating the need for additional components with interdependencies?
Great overview. Is it same flow while creating a deployment or any differences?
kube-proxy is for communication between compute nodes
I love the logical processes you showcase.......damn cool!
Can anyone tell me in detail how the scheduler will know when to assign the pod to a node
Wonderful description
Can we just take a moment to appreciate how well Whitney can effortlessly write in mirror image 🙂
Then what is the role for istio service mesh..... And also provide full video on kubernetes security of nodes
You should browse the channel for Sai Vennam's videos (among others). He's made plenty about k8s-related technologies.
How we restore back any pod that went to crashloopback off? This process is auto or manual?
How can a single container (host) be run using this method and also run multiple pods with containers in them ?
With k8s the atomic unit is the pod. If you just want to run a single instance of a container image you'd just have to create a pod referencing that image.
To run multiple container in a single pod you have to define them usually on a deployment
How do they make these videos? Do they have to learn how to write backwards? I don't think so... Do they?
I imagine they just flip the image
They write on a transparent wall, and then just flip the video horizontally so that the text is presented the correct way for the viewer.
Nicely explained
ty
Nicely explained 👌
So I am a data scientist and hence mostly an end user of the pods.. thanks for the explanation. So when we create a pod it assigns a random generated (available) ip that I should use for the compute. In my case I was using a jupyter notebook. Since pods are ephemeral like you mentioned, we need to attach a disk to the vm/pod which is always available to me. One time while running some python commands, my pod crashed and I got assigned another vm ip but the person who got assigned the vm ip I was using until then got my jupyter notebook saved on his disk. What could have happened? I am intrigued.
Seems like a race condition... your pod got killed but respawned just fine due to restartPolicy = always (by default) the that same pod got assigned to someone else
To avoid that I suggest set the restartPolicy to never or create a control plane that control the lifecycle of your pod so you always get the same pod until you dont need it anymore
makes sense?
doesn't ETCD store dns / ip for pod communication? and one more question is that which component generate full DNS name for pod?
coreDNS is another plugin which does this job. it stores the FQDN for services created within same k8 cluster.
it`s cool !!! thanks!
Can replication controller recreate the pod by itself or does it talk to kubelet to restart the pod?
i think replication controller will talk to kube-api and kube-api to kubelet , to recreate the new pod with same config. it will not restart the same pod as pods are ephemeral. Also there will be small role of scheduler as well, as it will tell on which node that new pod will be recreated, either same node or new node, depending on node availability.
ETCD contain the desired state of the pod. as control manager has the health status of the node, when the pod dies , control manager -> write to api-> api will checks and write to ETCD and back to API-> when scheduler gets to know pod need to be created from API -> it starts the process.
Labs wont work for me. Error: Service is currently restricted and is available only to certain users
great content. awesome video..
When the pod dies who lets API server know the pod is dead? Is it kubelet?
The video moves to controller manager and says that controller manager goes to Kube API server and gets to know the pod is down.
But the state of the pod on the Compute node need to be conveyed back to the API server, isn't it?
yeah ofcourse, not only does the kubelet convey the state of pods in the node, but also informs the controller about the CPU and memory resources of the node
what happens after the controller manager identifies that there is pod which has to be reschedule? i mean what exactly happens after that.
Then Controlller will communicate to kubectl through KubeAPI to create that pod to ensure replica set is satisfied. To ensure desired no# of pods == actual no# of pods.
Doesn’t Kubernetes need a load balancer in front of compute nodes?
Hi there! Depending upon where Kubernetes is deployed, you can integrate with different load balancers that the infrastructure provides to expose pods as Services running on k8s. Different Service types take advantage of different networking patterns to access the pods running on the underlying infrastructure. NodePort-based Services leverage existing IP addresses of compute nodes and are accessed via a Node-level proxy. LoadBalancer-based Services create new Load Balancer instances and handle traffic directly through the infrastructure-based LoadBalancer.
So the answer to the question is “it depends on how you want to access it”. 🙂
How do you write backwards like that? Good video too!
I just couldn't concentrate coz of it lol thats freaky
it is from the back of the glass, and the video is mirrored. Do you notice that most instructors use their left hands to write? That's because the video is left-right mirrored.
Awesome
…I’m not supposed to be In this class.
What are nodes? API server? Clusters?
A Kubernetes Node is a unit of computation (i.e. a physical or virtual machine)
Controller managers takes care of runtime failures of pods
To this day I could not understand how do they write backwards?
Bro, WTF. Now that you pointed that out, I can't unsee.
basically they shoot and mirror invert
ruclips.net/video/wCOuu0-o5YI/видео.html
The camera is at the back of the glass, and the video is mirrored. Do you notice that most instructors use their left hands to write? That's because the video is left-right mirrored.
🥰❤️
Thank a lot!