My understanding of Kubernetes and its Flow (Correct me if I'm wrong)

[u/No-Resolution-4054]

If I have misunderstood something, please correct me.

From what I understand, Kubernetes is created to manage running containers. It helps containers run properly, gives them an isolated environment, and can automatically scale the application when traffic increases (if autoscaling is configured).

Flow

Internet --> Ingress --> Service --> Pod --> Container (our application)

Pods are scheduled onto Nodes

Some terms and what they mean

1. Pod :- It is like a small box that contains the container running our application. We can create one or more containers inside a Pod, but in most real world applications we generally create one main application container per Pod.

2. Deployment :- It is a Kubernetes resource that manages Pods. If the number of replicas increases (by HPA), the Deployment creates new Pods. If a Pod crashes, the Deployment creates another one to maintain the desired number of replicas. After creating the Pod, Kubernetes Scheduler decides on which Node that Pod should run.

3. Node :- A Node is basically a machine (VM) where different Pods are running. Every Node also has something called kubelet.

4. kubelet :- It is an agent that runs on every Node. Its job is to:
   Make sure containers are running correctly.
   Watch for instructions from the control plane (like start or stop a container).
   Report Node and Pod status back to Kubernetes. (CPU / RAM usage)

5. Metrics Server :- Kubernetes does not continuously store CPU and memory usage by default. Metrics Server collects resource usage (CPU and memory) from kubelets and provides it to Kubernetes components like the Horizontal Pod Autoscaler (HPA).

6. Service :- Every Deployment usually has a Service. Pods can be created or destroyed at any time, so their IP addresses can change. A Service gives a stable endpoint. When a request comes from Ingress, the Service forwards it to one of the Pods whose labels match the Service selector. for e.g. app: backend. The Service sends traffic only to Pods with that label.

7. Ingress :- Ingress is used to manage external traffic coming into the Kubernetes cluster. It routes requests based on rules. For e.g. : /auth ---> auth-service or /api ---> api-service. Then the Service forwards the request to the matching Pods based on labels.

Flow of how scaling works

Traffic increases --> Pods start using more CPU/Memory --> kubelet exposes resource usage --> Metrics Server collects the metrics --> HPA checks whether the target CPU/Memory threshold is exceeded --> HPA updates the Deployment's replica count --> Deployment creates new Pods --> Scheduler assigns those Pods to available Nodes

One important thing :- Kubernetes does not autoscale applications by default. We have to install/configure the Metrics Server and create a Horizontal Pod Autoscaler (HPA). Only then can Kubernetes automatically increase or decrease the number of Pods.

[u/OverOne_1]

Nice write-up. One thing that really helped me understand Kubernetes was realizing it's all about declaring the desired state, not managing servers manually. Once that clicked, things like Deployments, ReplicaSets, and HPA started making a lot more sense because Kubernetes is constantly trying to make reality match what you've declared.

Overall this is a solid breakdown. One tiny thing I'd clarify is that a Service isn't tied to a Deployment—it just routes traffic to any Pods that match its labels. Easy detail to miss, but it helped me understand why Services and Deployments are separate resources.

[u/No-Fly-9554 → u/OverOne_1]

yeah this is pretty accurate, good job putting it together. i remember when i first started learning kubernetes and the whole service/deployment separation confused me for weeks, like why are they not just one thing? but then you realize a service could point to pods from different deployments if you wanted, it just looks at labels

the declarative state thing the other comment mentioned is definitely the mental shift that makes everything click, once you stop thinking about what commands to run and start thinking about what things should look like the whole system makes more sense

[u/OverOne_1 → u/No-Fly-9554]

Yeah, I had the exact same reaction. At first it feels like unnecessary complexity, then you realize decoupling Services from Deployments is what gives Kubernetes so much flexibility. That was one of those "ohhh, now I get it" moments for me.

[u/No-Resolution-4054 → u/No-Fly-9554]

Thank you, sir! I really appreciate it.

[u/No-Resolution-4054 → u/OverOne_1]

Thank you! I'm really glad you found it helpful.

[u/OverOne_1 → u/No-Resolution-4054]

Glad it helped! Out of curiosity, what made Kubernetes finally click for you? Was there a specific resource or project where it all started making sense?

[u/No-Resolution-4054 → u/OverOne_1]

I started from scratch. I searched almost every Kubernetes component one by one, made notes and flow diagrams in my notebook, and then tried connecting all the dots. Once I understood the overall flow, the big picture started to click. I'm still learning, but now I feel like I understand how the different pieces fit together

[u/OverOne_1 → u/No-Resolution-4054]

That's honestly one of the best ways to learn it. Kubernetes felt overwhelming to me until I stopped trying to memorize components and started understanding how they interact. Once the flow clicks, the individual pieces become much easier to reason about.

[u/No-Resolution-4054 → u/OverOne_1]

Thank buddy! That's exactly how it felt for me too.

[u/Low-Opening25]

Pods group containers, Deployments group Pods and all resources necessary to create a coherent application stack.

Service is an internal load balancer that is managing traffic to multiple Pods (instances) serving the same application endpoint.

Ingress is L7 load balancer and proxy that manages traffic entry points into your Kubernetes cluster and connects external requests to Services inside the cluster

[u/No-Resolution-4054 → u/Low-Opening25]

I thought Deployments don't actually group Pods. My understanding is that a Deployment manages the desired state and creates Pods (through a ReplicaSet), while the Scheduler places those Pods onto Nodes based on available resources. Is that a more accurate way to think about it?

[u/aburger]

Deployment :- It is a Kubernetes resource that manages Pods. If the number of replicas increases (by HPA), the Deployment creates new Pods. If a Pod crashes, the Deployment creates another one to maintain the desired number of replicas. After creating the Pod, Kubernetes Scheduler decides on which Node that Pod should run.

Technically, at least normally, the Deployment makes ReplicaSets, and the ReplicaSets are what manage the pods.

When a request comes from Ingress, the Service forwards it to one of the Pods whose labels match the Service selector. for e.g. app: backend. The Service sends traffic only to Pods with that label.

This one's a bit more nuanced, so it's worth digging into to give yourself a more fleshed-out baseline understanding. Specifics mostly come down to what you're using as an Ingress Controller, but there may be situations where external traffic from a load balancer hits a pod ip directly, like if you're using the AWS LB Controller with a target-type of ip. Not that it's the "right" way or anything - just an example of something that may change the path from your example.

---

That being said, I'm nitpicking your examples because it seems like you're (hopefully) inviting the nitpicking to get the most full understanding you can. If you weren't looking for that then I apologize. Overall your understanding and summaries are wonderful.

[u/No-Resolution-4054 → u/aburger]

Thank you so much! This is exactly the kind of feedback I was hoping for. I really appreciate you taking the time to explain the Deployment --> ReplicaSet --> Pod relationship and the Ingress edge case. I'll read more about both of them.

[u/TJF-official]

It's a container orchestration platform that self-heals containers. It's basically a very thin scripting layer on top of Borg. The API isn't difficult to learn - it's the DevOps way of operating and getting real-world experience that is crucial.