What is Kubernetes

A High-Level View of Kubernetes

Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. It acts as a control system that continuously works to make the actual state of your applications and infrastructure match the desired state you define.

At its core, Kubernetes:

• Runs and coordinates containers across a cluster of machines.
• Provides common patterns for deploying, updating, and scaling applications.
• Offers a consistent API so you manage applications the same way, regardless of where the cluster runs (on-prem, cloud, hybrid).

You do not manage individual containers directly in most cases; instead, you declare how your applications should run, and Kubernetes figures out where and how to run them.

Key Problems Kubernetes Solves

Kubernetes addresses several challenges that appear once you move beyond running a few containers on a single host:

• Scheduling and placement
  Decides which node in a cluster should run each workload based on available resources and constraints.
• High availability and self-healing
  Restarts failed containers, replaces them, and reschedules them if a node fails. If you say you want 5 instances of an application, Kubernetes keeps 5 running.
• Scaling up and down
  Adjusts how many copies (replicas) of your application are running, either manually or automatically, to handle changes in load.
• Service discovery and stable addressing
  Gives each application a stable network identity inside the cluster, even if the underlying containers come and go.
• Configuration and secrets distribution
  Lets you supply configuration data and sensitive values (like passwords) to applications without baking them into images.
• Rolling updates and rollbacks
  Lets you upgrade applications gradually, without downtime, and roll back quickly if something goes wrong.
• Resource sharing and isolation
  Allows many applications and teams to share a cluster while controlling how much CPU, memory, and storage each can use.

Core Ideas and Terminology

In this chapter, the goal is to understand Kubernetes conceptually, not the full architecture or object details.

Cluster

A Kubernetes cluster is a set of machines (physical or virtual) on which Kubernetes runs and where your applications are scheduled. Internally, some nodes run control-plane components and others run workloads, but at this level you can think of the cluster as:

• A pool of compute, storage, and networking resources
• Managed through a single, unified Kubernetes API

Node

A node is a single machine in the cluster, usually:

• A virtual machine (in cloud environments) or
• A physical server (often in on-prem or HPC environments)

Nodes run:

• A container runtime (e.g., CRI-O, containerd) to run containers
• An agent that communicates with the Kubernetes control plane

From a user perspective, you usually don’t care which node runs your workload; Kubernetes decides that for you.

Pod

The pod is the smallest deployable unit in Kubernetes.

Conceptually:

• A pod groups one or more containers that should run together on the same node.
• Containers in the same pod share:
• Network namespace (same IP address, ports)
• Storage volumes (e.g., shared files)

You almost never run “bare” containers directly in Kubernetes; instead, you run pods that contain containers.

Desired State vs. Actual State

A central concept in Kubernetes is desired state:

• You describe in a YAML or JSON manifest what you want:
• How many replicas of a pod
• Which container images to run
• What resources to allocate, etc.
• You submit this description to the Kubernetes API.
• Kubernetes’ control loops continuously work to drive the actual state of the cluster toward the desired state.

For example, if you declare:

• “I want 3 replicas of this pod”

and one fails, Kubernetes automatically starts a new one to restore the count to 3.

This “control loop” behavior is fundamental: Kubernetes constantly reconciles reality with your specifications.

Kubernetes as a Platform, Not Just an Orchestrator

Kubernetes started as a container orchestration system—something that just schedules and monitors containers—but it has grown into a platform for building platforms:

• It provides a consistent API and object model.
• Additional components (like Operators, service meshes, pipelines, etc.) build on top of this model.
• Cloud providers offer managed Kubernetes services that keep the same API, so tooling and skills are portable.

From an application developer or operator perspective, Kubernetes is:

• A common layer that abstracts away most of the underlying infrastructure details.
• A programmable platform: you can store, update, and observe almost everything through its API.

Why Kubernetes Matters in an OpenShift Context

This course is about OpenShift, but OpenShift is built on top of Kubernetes. Understanding “What is Kubernetes” is crucial because:

• OpenShift extends and enhances Kubernetes but does not replace it.
• Most concepts you use in OpenShift—pods, services, deployments, namespaces, labels—are Kubernetes concepts.
• Kubernetes compatibility means:
• Many Kubernetes tools and manifests can work on OpenShift with little or no modification.
• Skills you gain with OpenShift are largely transferable to any Kubernetes environment.

In practice:

• Kubernetes provides the core orchestration and API layer.
• OpenShift adds:
• Opinionated defaults and security hardening
• Integrated build, CI/CD, registry, and developer tooling
• Enterprise support and lifecycle management

Understanding Kubernetes as the foundation helps you see which behaviors come “for free” from Kubernetes and which are specific to OpenShift.

Conceptual Workflow at a High Level

While the detailed mechanics will be covered later, a typical interaction with Kubernetes looks like this:

1. Describe
   You write a manifest (usually YAML) describing your application’s desired state. For example:
• Run a container from image myapp:1.0
• Keep 3 replicas running
• Expose it on an internal cluster port
2. Submit
   You apply this manifest to the cluster via:
• kubectl (the Kubernetes CLI) in generic Kubernetes
• oc (OpenShift CLI), which also talks to the Kubernetes API in OpenShift
3. Reconcile
   Control loops inside Kubernetes:
• Create the requested pods
• Place them on appropriate nodes
• Monitor them and replace them if they fail
4. Access
   You access your application via:
• Internal networking (services)
• External access mechanisms (like routes/ingress; detailed later)

From your point of view, you think in terms of “what should be running” and “how it should be reachable,” not “launch container X on node Y and restart it if it fails.”

Summary

Kubernetes is:

• A cluster-based platform for running containerized applications reliably at scale.
• Driven by a declarative model: you state what you want; it works to make that true.
• Built around pods, nodes, and the Kubernetes API.
• The foundational technology on which OpenShift builds additional enterprise features.

With this conceptual understanding in place, the following chapters will look at the specific architecture, components, and object types that make up Kubernetes in more detail.