I'm trying to understand how Kubernetes manages containers. Is the usual request path Internet to Ingress to Service to Pod to container? And is it right that a Deployment maintains Pods while the scheduler places them on nodes?
Am I understanding the Kubernetes flow correctly?
Asked by
q.742~parcelwrench
Answers
That's a useful starting model. The big idea is desired state: you declare what you want, and Kubernetes controllers work to make the actual state match it.
A Deployment manages ReplicaSets, which in turn maintain the desired number of Pods. If a Pod disappears, the ReplicaSet can create a replacement. The scheduler then selects a suitable node for an unscheduled Pod. A Deployment doesn't group every resource needed for an application stack.
Reply to this answer
The traffic path you wrote is common, but it's not the only possible path. Ingress handles HTTP or HTTPS routing when an Ingress controller is set up, and a Service provides a stable endpoint for reaching backend Pods.
Keep Services and Deployments separate in your head. A Service typically selects Pods by label, not by which Deployment owns them. It can even select matching Pods from different Deployments.
Reply to this answer
A Pod is the scheduling unit and can contain one or more containers. A node can be a VM or another machine, and its kubelet works with the control plane to run the assigned Pods and report their status.
For scaling, an HPA can change the desired replica count when configured to do so. Metrics Server supplies recent CPU and memory usage from kubelets for resource metrics. It isn't a long-term metrics database.
Reply to this answer
Add your answer
Answers are reviewed before publication.
q.742~parcelwrench:
So the Deployment manages Pods indirectly through a ReplicaSet, rather than placing them on nodes itself?
m.416~sievehandle:
Right. Placement is the scheduler's job, while the controllers handle the desired workload state.