OpenShift Container Platform (OCP) is Kubernetes: a conformant distribution, with the upstream API server, scheduler and controllers. What makes it different is everything layered around that core. This chapter gives you the mental model; the rest of the book is the practice.
What OpenShift adds
Area |
Upstream Kubernetes |
OpenShift |
Tenancy unit |
Namespace |
Project (a namespace plus request workflow and template) |
CLI |
kubectl |
oc (superset of kubectl, plus oc adm) |
External HTTP access |
Ingress, Gateway API |
Route (Ingress also supported, converted to routes) |
Image management |
Registry only |
ImageStreams, internal registry, image triggers |
Pod security |
Pod Security Admission |
Security Context Constraints (SCC) plus PSA |
Authentication |
External (OIDC, certs) |
Built-in OAuth server with identity providers |
Cluster config |
Files on control plane |
Config CRs reconciled by cluster operators |
Node OS |
Your choice |
RHCOS, managed by the Machine Config Operator |
Add-ons |
Helm, manual |
Operator Lifecycle Manager (OLM), OperatorHub |
Upgrades |
Manual, per component |
Cluster Version Operator, over-the-air |
Everything is an operator
The single most important idea for an administrator: in OCP 4.x, almost every piece of the platform is managed by a cluster operator. The Cluster Version Operator (CVO) installs and upgrades about thirty of them. Each cluster operator watches a cluster-scoped config resource and reconciles the real components to match it.
oc get clusteroperators # short name: co
NAME VERSION AVAILABLE PROGRESSING DEGRADED
authentication 4.16.8 True False False
console 4.16.8 True False False
dns 4.16.8 True False False
image-registry 4.16.8 True False False
ingress 4.16.8 True False False
kube-apiserver 4.16.8 True False False
machine-config 4.16.8 True False False
network 4.16.8 True False False
...The pattern for changing platform behaviour is therefore always the same: find the config CR, edit it, wait for the owning operator to roll the change out. You will do this for OAuth (oauth.config.openshift.io/cluster), projects (project.config.openshift.io/cluster), ingress (ingresscontroller/default in openshift-ingress-operator), the image registry, scheduling defaults, and cluster updates.
oc api-resources --api-group=config.openshift.io
NAME SHORTNAMES APIVERSION NAMESPACED KIND
apiservers config.openshift.io/v1 false APIServer
authentications config.openshift.io/v1 false Authentication
clusteroperators co config.openshift.io/v1 false ClusterOperator
clusterversions config.openshift.io/v1 false ClusterVersion
images config.openshift.io/v1 false Image
ingresses config.openshift.io/v1 false Ingress
oauths config.openshift.io/v1 false OAuth
projects config.openshift.io/v1 false Project
schedulers config.openshift.io/v1 false Scheduler
...Architecture recap
A standard cluster has three control plane nodes (etcd, API server, controller manager, scheduler, plus OpenShift's own API server and OAuth server running as pods) and two or more compute nodes. Compact clusters run workloads on the three control plane nodes; single-node OpenShift (SNO) collapses everything onto one machine. Nodes run Red Hat Enterprise Linux CoreOS (RHCOS) with CRI-O as the container runtime. You never SSH to configure nodes; you use oc debug node/<name> for inspection and MachineConfig objects for persistent change.
Key namespaces worth recognising:
Namespace |
What lives there |
openshift-config |
Inputs to cluster config: IdP secrets, CA config maps, project template |
openshift-authentication |
The OAuth server pods |
openshift-ingress |
Router (HAProxy) pods for the default ingress controller |
openshift-ingress-operator |
IngressController CRs |
openshift-image-registry |
Internal registry |
openshift-monitoring |
Prometheus, Alertmanager, Thanos querier |
openshift-marketplace |
CatalogSources (redhat-operators, community-operators ...) |
openshift-operators |
Default namespace for all-namespace operators |
openshift-dns, openshift-ovn-kubernetes |
DNS and the cluster network |
oc versus kubectl
oc contains all of kubectl. Anything you know works unchanged: oc get, oc apply, oc rollout, oc logs. On top of that, oc adds three families of commands you will use constantly:
• OpenShift resource helpers: oc new-project, oc new-app, oc expose, oc create route, oc import-image, oc tag, oc process, oc set .... • Session commands: oc login, oc whoami, oc project, oc whoami --show-console. • Administrative commands under oc adm: policy, groups, top, must-gather, upgrade, taint, cordon, drain, node-logs, create-bootstrap-project-template, new-project.Logging in
oc login -u kubeadmin -p <password> https://api.ocp4.example.com:6443
oc whoami # current user
oc whoami --show-server # API URL
oc whoami --show-console # web console URL
oc whoami -t # current OAuth token
oc config get-contexts # one context per user/cluster/projectOn the exam you will typically find a kubeconfig already present for an admin user, or credentials in the task sheet. Logging in as other users to verify your work is a good habit (and quick), as long as you remember to log back in as admin before continuing.
The web console
The objectives require you to manage the cluster through the web console too. Practically, anything you can do in the console you can do in the CLI, and graders only check end state. Still, know where things are:
• Administrator perspective: Home (projects, search, events, API explorer), Operators (OperatorHub, Installed Operators), Workloads, Networking (services, routes, ingresses, network policies), Storage, Builds, Observe (alerts, metrics, dashboards), Compute (nodes, machines), User Management (users, groups, service accounts, roles, role bindings), Administration (cluster settings, namespaces, resource quotas, limit ranges, CRDs). • Developer perspective: Topology, +Add (import from Git, container image, Helm chart, YAML), Observe, project-level access management. • Cluster Settings (Administration): update channel and updates, plus Configuration, the friendliest way to reach the OAuth CR and add an HTPasswd provider by uploading a file.The console is genuinely faster for two jobs: browsing OperatorHub to see channels and install modes, and looking at firing alerts in Observe → Alerting.