Objective: Describe Kubernetes and Red Hat OpenShift architecture, create Kubernetes resources, create routes, and create applications using source-to-image (S2I) and the OpenShift web console.

Overview

Running one container by hand doesn't scale. Kubernetes and OpenShift take a declarative description of the desired state — how many replicas, what image, what resources — and continuously work to make the cluster match it.

Key Concepts

Kubernetes/OpenShift architecture

A cluster has control plane nodes (running the API server, scheduler, and controller manager, which together decide and enforce desired state) and worker nodes (where application pods actually run). OpenShift adds a web console, an integrated container registry, and additional controllers on top of upstream Kubernetes.

Core resources

Applications are described as a set of API objects (resources) stored in the cluster.

Resource	Purpose
Pod	The smallest deployable unit: one or more containers sharing network/storage
Deployment / DeploymentConfig	Manages replica count and rollout of a set of pods
Service	A stable internal name/IP that load-balances traffic across matching pods
Route (OpenShift)	Exposes a Service outside the cluster via a hostname
ConfigMap / Secret	Externalized, non-image configuration and sensitive data

Creating resources declaratively

Resources are usually defined in YAML and applied with the CLI (oc, the OpenShift client, or kubectl), rather than created ad hoc — keeping the desired state in version control.

# deployment.yaml (excerpt)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysite
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mysite
  template:
    metadata:
      labels:
        app: mysite
    spec:
      containers:
        - name: mysite
          image: quay.io/myorg/mysite:1.0
          ports:
            - containerPort: 8080

Exposing applications with routes

A Service only provides connectivity inside the cluster. To reach an application from outside, OpenShift uses a Route (oc expose service <name>) that maps an externally-resolvable hostname to a Service, optionally with TLS termination.

Source-to-Image (S2I)

S2I builds a runnable container image directly from application source code and a matching S2I builder image, without requiring the developer to write a Containerfile: oc new-app can point at a Git repository and a builder image, and OpenShift handles fetching the source, injecting it into the builder, and producing a final image.

The OpenShift web console

The web console provides the same capabilities as the CLI — creating applications from Git repositories, container images, or the developer catalog, viewing pod logs, scaling deployments, and managing routes — through a browser-based UI, useful for visualizing cluster state and for developers who prefer a graphical workflow.

Working with It

Desired State, Not Imperative Steps

A Deployment doesn't describe steps to take; it describes the end state the cluster should continuously try to maintain, including restarting failed pods automatically.

oc new-app Is a Fast Path

oc new-app is convenient for demos and quick starts; production workflows typically move to explicit YAML manifests kept in version control once the application's shape is understood.

A Service Alone Isn't External Access

Creating a Service does not make an application reachable from outside the cluster — a Route (or equivalent Ingress) is also required.

Creating and exposing an application with oc

$ oc new-app https://github.com/example/mysite.git --name=mysite
$ oc get pods
$ oc expose service mysite
$ oc get route mysite

Watch Out For

Common Pitfall

Creating a Service does not make an application reachable from outside the cluster — a Route (or equivalent Ingress) is also required.

Key Terms

Pod: The smallest deployable unit in Kubernetes; one or more co-located containers.
Service: A stable internal endpoint that load-balances traffic across matching pods.
Route: An OpenShift resource that exposes a Service outside the cluster via a hostname.
Source-to-Image (S2I): A build strategy that produces a container image directly from application source code.
Control plane: The set of components (API server, scheduler, controller manager) that manage cluster state.

Review Questions

What is the difference in scope between a Service and a Route?
What does a Deployment's replicas field actually guarantee, and how does the cluster enforce it?
Describe, at a high level, what happens when you run oc new-app against a Git repository using S2I.
Name the three main control-plane components mentioned and what each is responsible for.
What can the OpenShift web console do that the CLI cannot, and vice versa?