Red Hat OpenShift Administration I · DO180

Chapter 6

Orchestration Using Kubernetes and Red Hat OpenShift

Architecture · Core resources · Declarative YAML · Services and routes · S2I · Web console
CIS271RH — Mesa Community College
Describe Kubernetes and OpenShift architecture and core resources, create applications declaratively and with oc new-app, and expose them outside the cluster.

Key Commands

  • oc login
  • oc apply -f
  • oc get
  • oc new-app
  • oc expose
  • Starting containers one at a time with podman run doesn't scale.
  • In Kubernetes and OpenShift, you declare the desired state: "run 2 copies of this image."
  • The cluster continually reconciles reality with that state: if a pod dies, it starts another.
ComponentResponsibility
API serverThe front door: every oc command and console action goes through it
etcdThe database that stores the cluster's state
SchedulerChooses which node each new pod runs on
Controller managerRuns the loops that make actual state match desired state

Those run on control plane nodes. Worker nodes run the application pods. OpenShift adds a web console, an image registry, and its own controllers.

ResourcePurpose
PodThe smallest deployable unit: one or more co-located containers
DeploymentManages replicas of a pod, and rolls out new versions
ServiceA stable internal address that load-balances across matching pods
Route (OpenShift)Exposes a Service outside the cluster, under a host name
ConfigMap / SecretExternal configuration / sensitive data
NoteYou may also see DeploymentConfig, OpenShift's older equivalent of a Deployment. It's deprecated; use Deployments.
# 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
$ oc apply -f deployment.yaml
$ oc get deployment mysite           # READY 2/2
$ oc delete pod mysite-7d9c6-abcde   # simulate a failure
$ oc get pods                        # a replacement is already starting
$ oc scale deployment/mysite --replicas=3
Tip — Desired State, Not Imperative StepsA Deployment describes the end state. The cluster keeps maintaining it, restarting or replacing pods as needed.
# A Service gives the pods one stable internal address
$ oc expose deployment mysite --port=8080

# A Route makes that Service reachable from outside the cluster
$ oc expose service mysite
$ oc get route mysite

# Or create a TLS-terminated route instead
$ oc create route edge mysite-tls --service=mysite
Warning — A Service Alone Isn't External AccessServices are internal to the cluster. You still need a Route, or an Ingress, for users outside it.

S2I builds a runnable image from your source code plus a builder image, with no Containerfile needed.

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

oc new-app detects the language, runs an S2I build, then creates the Deployment and Service.

Tip — oc new-app Is a Fast PathGreat for getting started. Production usually relies on version-controlled YAML.
  • A browser interface to most of what oc can do.
  • Strengths: the Topology view, built-in metrics and logs, and guided forms.
  • The CLI's strengths: scripting, automation, and repeatable YAML.
  • Both talk to the same API, so a change made in one appears in the other.
Common Pitfall — Service Without a RouteThe application works inside the cluster, but users can't reach it. Check oc get route before debugging the app.
NoteMake changes in your YAML and re-apply it. Edits made directly in the cluster are lost the next time someone applies the file.
pod
The smallest deployable unit, with one or more co-located containers
Service
A stable internal endpoint that load-balances across matching pods
Route
An OpenShift resource that exposes a Service outside the cluster via a host name
Source-to-Image (S2I)
A build strategy that produces an image directly from source code
control plane
The components (API server, etcd, scheduler, controller manager) that manage cluster state
  1. What is the difference in scope between a Service and a Route?
  2. What does a Deployment's replicas field guarantee, and how does the cluster enforce it?
  3. What happens at a high level when you run oc new-app against a Git repository using S2I?
  4. What are the main control-plane components, and what is each responsible for?
  5. What can the web console do that the CLI cannot, and vice versa?