Kubernetes Foundations Through a Shopping Mall Mental Model

02 · Kubernetes architecture

The cluster is the entire mall. The control plane manages it.

A Kubernetes cluster is the full environment where applications run. It includes the management system, the machines, the applications, the network, the storage, and the policies. In our analogy, the Kubernetes cluster is the entire shopping mall.

Every mall needs a management office. The management office does not sell coffee, clothes or electronics. It manages the mall. The Kubernetes control plane works in the same way. It decides what should run, where it should run, how many copies should exist, and what to do when something fails.

The scheduler is like the leasing and space allocation team. If a brand wants a new counter, the mall checks which floor has space, power, and the right conditions. Kubernetes does the same when placing a Pod on a worker node.

The controller manager is like the operations supervisor. If the desired plan says three counters should be open and only two are running, Kubernetes works to restore the expected state.

04 · Pods, containers and Deployments

The counter is the Pod. The business inside it is the container.

A Pod is the smallest deployable unit in Kubernetes. Most of the time, one Pod runs one main container. In the mall analogy, the Pod is the outlet or counter. The container is the business function running inside that counter.

A Deployment is not a single Pod. A Deployment is a plan. It creates a behind-the-scenes manager called a ReplicaSet. This ReplicaSet ensures that if the Deployment says replicas: 3, exactly three Pods stay running.

Think of the Payments business unit saying: during normal hours, keep three Payments counters open. During a campaign, increase to five counters. When upgrading the counter setup, replace counters gradually so service does not stop.

05 · Services and Ingress

Use the mall directory, not the temporary counter location.

Pods are temporary. They can be created, deleted, moved or replaced. Their IP addresses can change. A Service gives a stable way to reach those changing Pods, just like a fixed mall directory number points visitors to the right counter even when staff or counters change.

Ingress is the main mall entrance. A user enters from outside, Ingress receives the request, the Service routes it to the right set of Pods, and the container handles the actual application logic.

06 · Storage fundamentals

StorageClass is the blueprint. PVC is the request. PV is the room.

Not every application is stateless. Databases, file upload services, message queues and stateful applications need data to survive even if a Pod restarts. Kubernetes uses StorageClass, PersistentVolumeClaim and PersistentVolume to make storage consumable.

The important idea is dynamic provisioning. Without a StorageClass, a platform admin may need to prepare storage manually ahead of time. That is like the mall admin building every storage room before any tenant asks for it.

With a StorageClass, the platform has a blueprint. When a tenant submits a request through a PVC, Kubernetes can dynamically provision a suitable PersistentVolume. In mall language, the storage room is created or assigned when the tenant submits the request.

07 · Networking fundamentals

Kubernetes networking is about reachability and control.

Kubernetes networking answers four simple questions: how Pods talk to each other, how applications find changing Pods, how outside traffic enters the cluster, and how we control who can talk to whom.

NetworkPolicy is like mall access control. Customers can enter public shops. Delivery staff can access loading bays. Vendors can enter approved areas. Visitors cannot enter the mall control room. In Kubernetes, policies can allow frontend Pods to talk to backend Pods, while preventing frontend Pods from directly reaching the database.

08 · Resource requests and limits

Requests help placement. Limits protect shared capacity.

Every Pod needs CPU and memory. But a Kubernetes cluster has limited capacity. If one workload consumes too much, it can affect others. That is why Kubernetes uses resource requests and limits.

A request tells Kubernetes what the Pod needs for placement. In the image, the Pod requests 1 vCPU and 2Gi memory. Kubernetes uses this information to decide which worker node has enough space.

A limit controls maximum usage. CPU and memory behave differently when they hit limits. If a Pod tries to use too much CPU, Kubernetes throttles it, which means it slows down. If it tries to pass its memory limit, the container is terminated with an OOMKilled error to protect the rest of the node.

09 · Config, secrets and health checks

Not everything belongs inside the application image.

Applications need configuration: environment names, API endpoints, feature flags, passwords, tokens and certificates. Kubernetes separates normal configuration from sensitive configuration. ConfigMaps are like mall notice boards. Secrets are like secure lockers.

Kubernetes can also check whether an application is healthy. A liveness probe asks, “Is it alive?” A readiness probe asks, “Can it serve traffic now?” A counter may be open but not ready to serve customers. A Pod may be running but not ready to receive traffic.

10 · Hands-on example

Read the YAML like a mall story.

This example creates a namespace, a Deployment and a Service. The names are intentionally consistent so the story is easy to follow.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: payments
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      containers:
      - name: payment-api
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "1"
            memory: "2Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
---
apiVersion: v1
kind: Service
metadata:
  name: payment-api-service
  namespace: payments
spec:
  selector:
    app: payment-api
  ports:
  - port: 80
    targetPort: 80

11 · Knowledge reinforcement

Test the mental model.

12 · Key takeaways

The foundation stays the same when we move to VKS.

• Kubernetes is easier to understand when concepts are connected together.
• A Kubernetes cluster is like a smart shopping mall.
• The control plane is the mall management office.
• Worker nodes are the physical floors or zones where workloads run.
• Namespaces are brand or tenant accounts, not physical locations.
• Pods are outlets or counters where containers run.
• A Deployment creates a ReplicaSet, and the ReplicaSet keeps the requested Pods running.
• Services provide stable access to changing Pods.
• StorageClass, PVC and PV make storage consumable through static or dynamic provisioning.
• CPU limits can throttle. Memory limits can cause OOMKilled restarts.
• Kubernetes is a desired-state system, not just a container launcher.