Kubernetes Fundamentals

Why Kubernetes Matters for OpenShift

OpenShift is built on top of Kubernetes. To understand OpenShift, you must understand the core ideas, terminology, and behavior of Kubernetes. OpenShift adds opinionated defaults, security features, and additional components, but it does not replace the underlying Kubernetes model.

In this chapter you will:

• Learn the basic concepts and vocabulary of Kubernetes.
• Understand how Kubernetes organizes and runs containerized applications.
• See where OpenShift aligns with “vanilla” Kubernetes and where it extends it.

Later chapters will dive into OpenShift-specific architecture and tools; here we focus on the Kubernetes foundation they rely on.

High-Level View of Kubernetes

Kubernetes is an orchestration platform for containers. At a high level, it provides:

• Scheduling – deciding where containers (pods) run across a cluster of machines.
• Lifecycle management – starting, stopping, and restarting workloads to match the desired state.
• Service discovery & networking – giving containers stable network identities and ways to talk to each other.
• Configuration & secrets distribution – injecting configuration into running workloads in a controlled way.
• Scaling – running multiple replicas, scaling up and down based on load.
• Self-healing – automatically replacing failed containers and keeping the system aligned with the desired state.

OpenShift exposes all of this Kubernetes functionality, then adds:

• Opinionated defaults (e.g. built-in registry, integrated auth).
• Security hardening (e.g. Security Context Constraints).
• Integrated developer workflows (e.g. Source-to-Image, web console).
• Operator-based cluster management.

When you interact with OpenShift (via the web console or oc CLI), you are ultimately working with Kubernetes concepts such as Pods, Deployments, Services, and the Kubernetes API.

The Cluster and Its Components (Conceptual Overview)

A Kubernetes cluster is a collection of machines (physical or virtual) that run two broad categories of components:

• Control plane – the “brain” of the cluster that makes global decisions.
• Worker nodes – the machines that run your application workloads.

Later sections of the course will unpack the control plane and worker node components in detail. For now, you only need a conceptual picture:

• The control plane exposes the Kubernetes API.
• Users and automation talk to the API (not directly to nodes) to declare what they want to run.
• The control plane continuously ensures the actual state of the cluster matches the desired state.

OpenShift’s control plane is a specific, opinionated distribution of the Kubernetes control plane, with additional components and integrations.

Declarative Model and Desired State

A key idea in Kubernetes (and therefore OpenShift) is the declarative configuration model:

• You describe what you want: “I want 3 replicas of this web app running with this container image and this configuration.”
• Kubernetes figures out how to make that true and keep it true over time.

This is called desired state. The actual cluster state may drift (pods fail, nodes disappear, images are updated), but the control plane constantly works to drive the actual state back toward the desired state.

You express desired state using YAML or JSON resources that you submit to the API (e.g. via kubectl apply in Kubernetes or oc apply in OpenShift). Examples of desired state:

• A Deployment that says: run 3 replicas of this container.
• A Service that says: expose these pods on a stable virtual IP.
• A ConfigMap that says: provide these configuration key-value pairs to applications.

This declarative pattern underlies many OpenShift features like GitOps, pipelines, and Operators.

Kubernetes Objects and the API

Everything you manage in Kubernetes is represented as an API object (often just called a “resource”). Some common object types you will encounter in OpenShift include:

• Workload objects
• Pod – smallest deployable unit; one or more containers that share networking and storage.
• ReplicaSet – ensures a specified number of pod replicas are running.
• Deployment – manages ReplicaSets and supports rolling updates.
• StatefulSet, DaemonSet, Job, CronJob – specialized workload patterns.
• Networking objects
• Service – stable network endpoint that load balances to a set of pods.
• Ingress (in Kubernetes) / Route (in OpenShift) – external HTTP/HTTPS access.
• Storage objects
• PersistentVolume (PV) – a piece of storage in the cluster.
• PersistentVolumeClaim (PVC) – a request for storage by a workload.
• StorageClass – describes classes of storage with different properties.
• Configuration & security objects
• ConfigMap, Secret – supply configuration and sensitive data.
• RBAC resources like Role, ClusterRole, RoleBinding, ClusterRoleBinding.

Each object has:

• API version – the group and version, e.g. apps/v1.
• Kind – the type of object, e.g. Deployment.
• Metadata – name, namespace, labels, annotations.
• Spec – what you want (desired state).
• Status – what is currently true (actual state), filled in by the system.

In YAML, a typical resource looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  labels:
    app: example
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example
        image: quay.io/example/app:1.0
        ports:
        - containerPort: 8080

OpenShift fully understands these standard Kubernetes objects and adds its own custom resource types for platform-specific features.

Pods: The Basic Execution Unit

While you may think in terms of containers, Kubernetes thinks in terms of Pods:

• A pod is one or more containers that are:
• Scheduled together on the same node.
• Share the same network namespace (same IP, same ports).
• Can share storage volumes.

Common patterns:

• Single-container pod – the most typical; one main workload container in the pod.
• Sidecar containers – additional containers providing supporting functionality (e.g. logging agent, proxy, metrics collector).

Kubernetes generally does not create pods directly in production; instead, higher-level controllers (such as Deployments) manage them. However, you can create a pod directly for simple tests or debugging.

In OpenShift, everything that runs in your project is ultimately a pod (including builds, Jobs, Deployments, etc.). Understanding pod behavior (scheduling, restart policies, status phases) is crucial for troubleshooting.

Controllers and Reconciliation

Most Kubernetes resources that represent “running things” are managed by controllers. A controller is a control loop that:

1. Watches the desired state (spec) of objects.
2. Observes the current state of the cluster.
3. Takes actions to move current state toward desired state.

Examples:

• A Deployment controller ensures the specified number of replicas are running with the right pod template, and handles rollouts and rollbacks.
• A ReplicaSet controller ensures the correct number of pod replicas are alive.
• A Job controller ensures a specified number of pods complete successfully.

This pattern of continuous reconciliation is fundamental. OpenShift extends it via Operators, which are essentially specialized controllers for more complex applications and platform components.

Key implications:

• You do not manually restart pods after failures; controllers do that.
• You do not manually scale pods one by one; controllers adjust replica counts.
• Editing the spec of a controller resource (e.g. changing the image in a Deployment) drives a rollout.

Namespaces and Multi-Tenancy

Kubernetes clusters are typically multi-tenant. Namespaces are a logical partitioning mechanism:

• They group resources (pods, services, config, etc.) into separate scopes.
• Resource names must be unique within a namespace, but can be reused across namespaces.
• Many policies (quotas, RBAC) are applied at the namespace level.

In OpenShift, a Project is a namespace with some extra metadata and management behaviors. When you create a project, you’re essentially creating a Kubernetes namespace with additional OpenShift integrations (like default network policies, quotas, etc.).

This isolation is central to how OpenShift supports multiple teams or applications on the same cluster.

Workload Patterns: Stateless vs Stateful, Batch vs Long-Running

Kubernetes supports several workload patterns, which OpenShift surfaces directly:

• Stateless, long-running services
• Typically managed with Deployment and Service.
• Pods can be freely replaced and scaled; no persistent identity.
• Stateful services
• Use StatefulSet along with persistent storage (PVs and PVCs).
• Each pod has a stable identity and associated storage.
• Daemon-like workloads
• Use DaemonSet to run one pod per node (or per subset), often for monitoring, logging, or networking agents.
• Batch/finite workloads
• Use Job for single-run or finite tasks.
• Use CronJob for scheduled jobs (e.g. nightly backups).

In the OpenShift context, these patterns map to typical application and infrastructure use cases, and later chapters (especially around HPC and batch, or stateful apps) build directly on these primitives.

Scheduling and Placement (Conceptual)

Kubernetes includes a scheduler that decides on which node each pod runs. The basic behavior:

• The scheduler looks at unscheduled pods and available nodes.
• It filters out nodes that do not meet requirements (e.g. insufficient resources, missing labels).
• It scores remaining nodes and chooses a good fit.

Tools you can use to influence scheduling (all fully supported in OpenShift):

• Resource requests and limits – define minimum and maximum CPU/memory per container; these affect placement.
• Node selectors and node affinity – constrain pods to certain nodes.
• Taints and tolerations – keep “special” nodes reserved unless pods explicitly tolerate them.
• Pod affinity/anti-affinity – express soft or hard rules about co-locating or separating pods.

OpenShift adds opinionated defaults and policies (e.g. additional scheduling constraints from Operators), but the underlying scheduling model is pure Kubernetes.

Declarative Management Tools

In upstream Kubernetes, you commonly manage resources with the kubectl CLI and YAML manifests. In OpenShift:

• The oc CLI is largely compatible with kubectl for core Kubernetes operations.
• The OpenShift web console offers a visual interface on top of the same Kubernetes API.
• GitOps tools (like Argo CD) also talk to the Kubernetes API and manage these same objects.

Regardless of tool, the key pattern is:

1. Define or edit a resource manifest (Deployment, Service, etc.).
2. Apply it to the cluster.
3. Kubernetes reconciles the cluster to match that definition.

This is the basis for CI/CD, GitOps, and many operational workflows you will encounter later in the course.

How Kubernetes Fundamentals Map to OpenShift

To connect these ideas back to OpenShift:

• OpenShift projects are Kubernetes namespaces.
• OpenShift Deployments / DeploymentConfigs run pods via standard controllers (Deployments use native Deployment and ReplicaSets).
• OpenShift Routes provide HTTP(S) ingress for services using underlying Kubernetes networking primitives.
• OpenShift Operators are advanced controllers that use the same reconciliation model you’ve seen for basic resources.
• OpenShift security, quotas, and policies are layered on top of Kubernetes RBAC, namespaces, and admission control.

Once you’re comfortable with the Kubernetes mental model—API objects, pods, controllers, namespaces, and desired state—you’ll find that OpenShift’s added features are extensions rather than a completely different system.

Summary of Key Takeaways

By the end of this chapter, you should be able to:

• Explain that OpenShift is built on Kubernetes and uses its API and object model.
• Describe the difference between the control plane and worker nodes at a high level.
• Understand the idea of declarative configuration and desired vs actual state.
• Recognize key Kubernetes object types (Pods, Deployments, Services, PVs, PVCs, ConfigMaps, Secrets, Namespaces).
• Understand that controllers continuously reconcile desired and actual state.
• See how Kubernetes workload patterns (Deployments, StatefulSets, Jobs, etc.) map to common application types.
• Appreciate that OpenShift tools (oc, web console, Operators) are interfaces to the same Kubernetes engine.

Subsequent chapters will drill deeper into architecture details, specific components of the control plane and worker nodes, and how OpenShift extends these Kubernetes foundations.