Kubernetes Foundations Through a Shopping Mall Mental Model

02 · Kubernetes architecture

The cluster is the mall ecosystem. The control plane operates it.

A Kubernetes cluster consists of a control plane and worker nodes. Users and automation submit desired state through the Kubernetes API. The control plane records that state, selects suitable nodes for unscheduled Pods and runs controllers that continuously reconcile actual state toward desired state.

• API server = management reception desk: all Kubernetes API requests and administrative instructions enter through it. Application traffic does not.
• etcd = official records: the consistent key-value store used for Kubernetes API data.
• Scheduler = space-allocation team: assigns unscheduled Pods to suitable worker nodes.
• Controller manager = operations supervisors: runs control loops that reconcile observed and desired state.

The control plane does not invent business intent. The desired number of replicas, Pod template and policy are declared by users or higher-level automation; Kubernetes works to realise that declaration.

04 · Deployments, ReplicaSets, Pods and containers

The operating plan creates and maintains the stores where the application runs.

In the mall, the business team does not manually create and watch every store instance. It defines an operating plan: how many stores should be open, what setup each store should use, and how changes should be introduced. In Kubernetes, that operating plan is the Deployment.

A Deployment declares the desired state and rollout strategy for a set of application Pods.

The Deployment manages ReplicaSets. A ReplicaSet is like the mall operations team that continuously works to maintain the requested number of store instances.

If a Deployment specifies replicas: 3, the desired state is three Pod replicas. That does not guarantee that exactly three are ready at every instant: startup, failure and rolling-update conditions can temporarily produce different desired, current, ready and available counts.

A Pod is the smallest deployable unit that Kubernetes can create and manage. In the mall analogy, each Pod is an individual store instance. Most application Pods contain one main container, but a Pod can contain multiple tightly coupled containers that share networking and storage context.

A container is the packaged application process running inside the Pod, together with its runtime dependencies.

05 · Services, Ingress and Gateway

Use a stable directory entry, not a temporary Pod address.

Pods can be replaced and their IP addresses can change. A Service provides a stable network identity for a logical set of backends, commonly selected Pods.

A request typically reaches a load balancer, then an Ingress controller or Gateway implementation. Routing configuration selects a Service, and the Service directs traffic toward one of its current backend Pods. The application process inside the selected Pod handles the request.

06 · Storage fundamentals

The store requests storage; the mall fulfils it using an agreed storage class.

A mall tenant may need storage space for stock, equipment or records. The mall first defines the available storage categories and fulfilment rules. The tenant submits a request, and the mall allocates a suitable storage space. Kubernetes follows a similar pattern.

A PersistentVolumeClaim expresses the workload's storage request, such as required capacity and access mode. A StorageClass can describe how a class of storage should be dynamically provisioned and managed. A PersistentVolume is the Kubernetes object representing the resulting storage capacity.

With dynamic provisioning, a PVC can trigger a provisioner, guided by a StorageClass, to create a backing volume and corresponding PV. Static provisioning remains possible when storage and PV objects are prepared in advance.

07 · NetworkPolicy

NetworkPolicy is the mall's access-control plan for communication between stores.

A mall does not allow every visitor or employee to enter every area. Customers can enter public stores, delivery staff can use loading areas, and only authorised staff can access restricted rooms. NetworkPolicy applies a similar idea to Pod-to-Pod communication.

NetworkPolicy objects describe permitted ingress and egress traffic for selected Pods at IP and port level. For example, a policy can permit frontend Pods to reach backend Pods while preventing direct frontend access to database Pods.

The cluster networking implementation must support and enforce NetworkPolicy. Creating a NetworkPolicy object in a cluster whose network plugin does not enforce it does not create effective isolation.

08 · Resource requests and limits

Requests help the mall place the store. Limits constrain what it may consume.

Before a store opens, mall management needs to know the minimum space, power and facilities it requires. That is the request used for planning and placement. The mall may also define the maximum capacity the store is allowed to consume. That is the limit.

In the example, a container requests 1 CPU and 2 GiB of memory. Kubernetes uses the Pod's effective resource request when selecting a node with sufficient allocatable capacity. One Kubernetes CPU unit may map to a virtual core, physical core or hardware thread depending on the node.

CPU use above a limit can be throttled. Memory enforcement is reactive: if a container exceeds its memory limit and the operating system encounters memory pressure, the container may be terminated and reported as OOMKilled. Restart behaviour follows the Pod's restart policy.

09 · Configuration, Secrets and probes

Every store needs instructions, protected credentials and opening checks.

A mall store needs operating instructions, restricted credentials and checks that confirm whether it is ready and functioning. Kubernetes separates those concerns into ConfigMaps, Secrets and probes.

ConfigMaps hold non-confidential configuration such as endpoints, feature flags and environment-specific settings. Secrets are intended for confidential values, but creating a Secret does not automatically guarantee strong protection. Security depends on RBAC, encryption at rest, access controls and operational configuration.

A readiness probe asks whether the application can serve traffic now. A failed readiness probe removes the Pod from matching Service endpoints without necessarily restarting the container. A liveness probe detects a stuck or unhealthy process; repeated liveness failure causes the kubelet to restart the affected container. A startup probe can protect slow-starting applications during initialisation.

10 · Hands-on example

Read the YAML like a mall operating plan.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: payments
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: payment-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: payment-api
        app.kubernetes.io/part-of: payments
    spec:
      containers:
      - name: payment-api-demo
        image: nginx:1.27-alpine
        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:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: payment-api
  ports:
  - port: 80
    targetPort: 80

This uses a pinned NGINX image as a placeholder web application. The containerPort documents the application port; it does not independently expose the workload.

11 · Knowledge reinforcement

Test the mental model.

13 · Key takeaways

The mental model is memorable when its boundaries are explicit.

• A cluster combines a control plane and worker nodes.
• The control plane reconciles declared desired state; it does not invent business intent.
• Worker nodes are runtime locations. Namespaces are logical scopes for grouping and naming resources.
• A Pod is the smallest deployable unit and can contain one or more tightly coupled containers.
• A Deployment manages ReplicaSets; ReplicaSets work to maintain requested Pod replicas.
• A Service provides stable access to changing backend Pods.
• Ingress routing rules require an implementation such as an Ingress controller.
• PVCs request storage, PVs represent storage and StorageClasses can guide dynamic provisioning.
• NetworkPolicy requires an enforcing network implementation.
• CPU limits can throttle; memory-limit violations may result in OOM termination.
• Secrets require proper encryption, RBAC and operational controls.