Device plugins register GPUs in the cluster and can be deployed manually or as DaemonSets.
PV access modes are ReadWriteOnce (RWO), ReadWriteOncePod (RWOP), ReadOnlyMany (ROX), and ReadWriteMany (RWX); these describe capabilities, not enforced constraints.
Audit logging for network policies is enabled via the k8s.ovn.org/acl-logging annotation on namespaces (for NetworkPolicy/EgressFirewall) or directly on ANP/BANP CRs.
The default audit log rate limit is 20 messages per second per node.
Valid audit log destination values are: null (default), libc, udp:<host>:<port>, and unix:<file>.
Audit logs are always written to /var/log/ovn/acl-audit-log.log on each OVN-Kubernetes pod, regardless of additional destination configuration.
Network policy audit logging is only available with the OVN-Kubernetes network plugin.
The additionalTrustedCA ConfigMap referenced by image.config.openshift.io/cluster must be in the openshift-config namespace
AdminNetworkPolicy and BaselineAdminNetworkPolicy (policy.networking.k8s.io/v1alpha1) are cluster-scoped network policy resources
AdminPolicyBasedExternalRoute is a cluster-scoped CRD in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes
BFD (Bidirectional Forwarding Detection) defaults to false on both static and dynamic hops in AdminPolicyBasedExternalRoute
When networkAttachmentName is empty on a dynamic hop, the system assumes the pod uses HostNetwork and the node IP is used as the gateway
Dynamic hops in AdminPolicyBasedExternalRoute require both podSelector and namespaceSelector
AdminPolicyBasedExternalRoute supports two next-hop types: static (fixed IP) and dynamic (IP derived from gateway pods selected by podSelector and namespaceSelector)
Admission plugins run sequentially in an admission chain; if any plugin rejects a request, the entire chain aborts and returns an error.
"IgnoredDuringExecution" in affinity rules means pods are not evicted if labels change after scheduling — the pod continues running on its current node
Pod affinity/anti-affinity label selector operators are: In, NotIn, Exists, DoesNotExist
The topologyKey field is mandatory for pod affinity and anti-affinity rules
Preferred affinity/anti-affinity rules use a weight value ranging from 1 to 100
The Agent-based Installer and Assisted Installer also support bare metal as an installation target, in addition to the standard IPI and UPI methods.
The agent-based installer shares the Assisted Installer's discovery ISO approach but runs fully disconnected without needing a service endpoint.
The Agent-based Installer is the disconnected-environment equivalent of the Assisted Installer
OpenShift alerting operates as a multi-stage pipeline: PrometheusRules define both recording and alerting rules (evaluated at 30s default intervals), AlertRelabelConfigs modify alerts before routing (supporting Replace/Keep/Drop/HashMod/LabelMap actions), Alertmanager routes and groups alerts (with inhibit rules suppressing targets when sources fire), and silences persist across pod restarts only with persistent storage — each stage transforms or filters the alert stream.
AlertingRule and AlertRelabelConfig resources must be created in the openshift-monitoring namespace; they use apiVersion monitoring.openshift.io/v1.
AlertingRule resources for Network Observability alerts must be created in the openshift-monitoring namespace
AlertingRule is an OpenShift-specific CRD (monitoring.openshift.io/v1) that only supports alerting rules (NOT recording rules) and auto-creates a corresponding PrometheusRule in the openshift-monitoring namespace.
AlertmanagerConfig is at API version monitoring.coreos.com/v1beta1 (still beta), unlike most other monitoring CRDs which are v1.
AlertRelabelConfig modifies alerts before Alertmanager routes them, not after.
Alibaba Cloud is a supported installation target for OpenShift Container Platform.
For AllNamespaces install mode, the openshift-operators namespace has a default OperatorGroup called global-operators; no additional OperatorGroup is needed.
AllNamespaces install mode uses namespace openshift-operators; SingleNamespace mode requires creating an OperatorGroup in the target namespace
For AllNamespaces install mode, the Subscription goes in the openshift-operators namespace which already has the global-operators OperatorGroup — no manual OperatorGroup creation needed.
allowedRegistries and blockedRegistries in image.config.openshift.io/cluster are mutually exclusive — you cannot set both
When using allowedRegistries, you must explicitly include registry.redhat.io, quay.io, and the internal registry (image-registry.openshift-image-registry.svc:5000) — otherwise pods will fail
The allowVolumeExpansion: true field on a StorageClass is a prerequisite for all PVC expansion and defaults to false.
Both hosted control planes and edge/SNO deployments require fundamentally different operational models from standard HA clusters: HCP separates control and data planes across clusters with distinct APIs (NodePool, HyperShift), while edge uses ZTP/TALM fleet management with reduced capability profiles — neither follows the standard MachineSet/MHC/in-cluster-control-plane pattern.
The AMD GPU Operator is a community release, not a Red Hat-certified/supported Operator.
AMD GPU Operator installation requires three Operators in sequence: Node Feature Discovery (NFD) Operator, then Kernel Module Management (KMM) Operator, then AMD GPU Operator.
The AMD GPU resource identifier for Kubernetes resource requests and limits is amd.com/gpu.
The gfx90a architecture identifier corresponds to AMD Instinct MI210 GPUs.
AdminNetworkPolicy and BaselineAdminNetworkPolicy use API group policy.networking.k8s.io/v1alpha1
AdminNetworkPolicy is cluster-scoped while NetworkPolicy is namespace-scoped
AdminNetworkPolicy (ANP) is a cluster-scoped resource using API version policy.networking.k8s.io/v1alpha1
Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy
Host-networked pods are excluded from ANP subject and peer selection
ANP ingress peers support only namespaces and pods; egress additionally supports nodes and networks (CIDR)
ANP allows a maximum of 100 ingress rules and 100 egress rules per instance
AdminNetworkPolicy nodes and networks peer types are valid for egress rules only
ANP Pass action delegates the traffic decision to namespace-scoped NetworkPolicy, then to BANP if no NetworkPolicy matches
In ANP rules, when no port protocol is specified, the default is TCP; when no ports are specified, the rule matches all ports
ANP priority is an integer 0–1000 where lower values mean higher precedence, and two ANPs must not share the same priority
AdminNetworkPolicy priority range is 0–99 (maximum 100 ANP policies); lower value = higher precedence
AdminNetworkPolicy (ANP) supports three actions in audit logging: allow, deny, and pass; the pass action delegates evaluation to NetworkPolicy or BANP.
ANP rules support three actions: Allow (overrides NetworkPolicy denials), Deny (blocks traffic), and Pass (delegates to NetworkPolicy then BaselineAdminNetworkPolicy)
Ansible-based and Helm-based Operator base images are NOT deprecated in OCP 4.17 — only the SDK CLI tooling is deprecated.
OpenShift supports "any platform" (platform-agnostic) installation for infrastructure without a dedicated installation method, requiring the administrator to manually provision all infrastructure components (DNS, load balancers, compute, networking).
OpenShift API governance operates through two complementary enforcement mechanisms: a tiered stability model (Level 1–4) with webhook admission control governs API behavioral contracts, while resource-field and platform-level immutability prevents destructive drift after creation — together ensuring that both the API surface and its instantiated resources maintain consistency.
OpenShift API governance operates across two dimensions: a tiered stability model (Level 1 through Level 4) defines compatibility guarantees and deprecation timelines, while the webhook admission system (TLS-required, 13s hard timeout, CEL match conditions) enforces runtime policy — together they govern both the evolution and the enforcement of the API surface.
OpenShift APIs follow a tiered stability model: Level 1 provides 12-month/3-release stability (ConsolePlugin, SCC), Level 4 has no guarantees (ICSP), and unassigned groups default to Tier 3.
API Tier 1 is stable within a major release and cannot be removed until a subsequent major release.
API Tier 2 is stable for at least 9 months or 3 minor releases from deprecation announcement, whichever is longer.
API Tier 3 is the default tier for API groups without an explicit tier assignment; OperatorHub operators fall into this tier.
The default value for numberOfUsersToReport in APIRequestCount spec is 10.
APIRequestCount (apiserver.openshift.io/v1) instance names must follow the pattern resource.version.group (e.g., pods.v1). This is an OpenShift-specific resource.
APIRequestCount last24h is indexed by hour of day (0–23), where index 0 = 12:00AM–12:59AM, not a rolling window.
APIRequestCount instances are named using the format resource.version.group (e.g., deployments.v1.apps).
APIRequestCount is an OpenShift-specific resource (apiserver.openshift.io/v1), not part of upstream Kubernetes.
The removedInRelease status field on APIRequestCount indicates in which OpenShift release the tracked API will be removed, used for deprecated API migration planning before upgrades.
The APIServer clientCA ConfigMap must reside in the openshift-config namespace with key ca-bundle.crt; serving certificate Secrets must be kubernetes.io/tls type in openshift-config.
Etcd encryption covers: secrets, configmaps, routes, oauthaccesstokens, and oauthauthorizetokens.
The APIServer supports four audit profiles: Default, WriteRequestBodies, AllRequestBodies, and None.
The APIServer resource (config.openshift.io/v1) is cluster-scoped and the canonical instance is always named cluster.
The APIServer config object holds shared settings consumed by kube-apiserver, openshift-apiserver, and oauth-apiserver.
The Modern TLS security profile (TLS 1.3) is not currently supported on the APIServer; maximum available minTLSVersion is VersionTLS12.
APIServer TLS profiles follow Mozilla Server Side TLS: Old (TLS 1.0), Intermediate (TLS 1.2, recommended), Modern (TLS 1.3, unsupported), Custom (user-defined).
The APIService resource name must follow the format "version.group" (e.g., v1.apps).
APIService only supports HTTPS for communication with backing API servers; insecureSkipTLSVerify exists but caBundle is strongly preferred.
Recommended APIService priority values: core *.k8s.io groups at 18000, PaaS platforms like OpenShift at 2000s.
APIService has two required spec fields: groupPriorityMinimum and versionPriority.
The APIService .spec.service.port defaults to 443 if not specified.
Application packaging and delivery (Helm/Templates → build systems → ImageStreams → registry) operates entirely within the operator-driven immutable platform: applications are built on nodes managed by MCO, stored in registries managed by the Image Registry Operator, and deployed through operators managed by OLM — the application lifecycle never escapes operator governance
OpenShift application delivery spans packaging and image production: Helm charts and Templates define application structure with two parallel packaging mechanisms, while dual build systems (Shipwright/BuildConfig) produce container images through ImageStreams and the internal registry — creating a complete define→build→store pipeline.
AppliedClusterResourceQuota belongs to the OpenShift-specific API group quota.openshift.io/v1.
AppliedClusterResourceQuota is an OpenShift-specific extension beyond upstream Kubernetes that enforces resource quotas across multiple namespaces.
Project administrators can view AppliedClusterResourceQuota objects in their project without cluster-admin privileges, providing project-scoped visibility of cluster-wide quotas.
AppliedClusterResourceQuota is a read-only projection of ClusterResourceQuota into a project namespace — only GET operations are available, and it is not created directly by users.
AppliedClusterResourceQuota (quota.openshift.io/v1) is a read-only, project-scoped projection of ClusterResourceQuota that lets project admins see which cluster-level quotas apply to their project and current usage.
Approve a pending InstallPlan: oc patch installplan <name> -n <namespace> --type merge --patch '{"spec":{"approved":true}}'
The argocd CLI installation docs live under the OpenShift GitOps documentation, not the core OCP documentation.
Each ArgoCD application can manage a maximum of 300 SiteConfig CRs.
JWT tokens for the Assisted Installer REST API are valid for 15 minutes only.
The Assisted Installer performs pre-flight host validation (CPU, memory, disk, networking) before allowing installation to proceed.
The Assisted Installer can run as a hosted SaaS service at console.redhat.com or be self-hosted via the Assisted Installer Operator for disconnected/restricted environments.
The Assisted Installer uses a discovery ISO that is booted on target hosts to register them with the installer service.
Assisted Installer and Agent-based Installer are two distinct on-premise installation methods for OpenShift.
The auth/ directory under the install assets directory contains both kubeconfig and kubeadmin-password files
The Authentication resource (config.openshift.io/v1) has a canonical instance name of cluster and is a cluster-scoped singleton.
The default authentication type (spec.type) for the Authentication resource is IntegratedOAuth.
OpenShift enforces a comprehensive governance model: dual authorization systems (OpenShift auth + K8s RBAC) control access to resources, while resource quotas force explicit declarations — together creating a contract where both access and consumption are strictly governed.
All authorization review APIs (LocalResourceAccessReview, LocalSubjectAccessReview, ResourceAccessReview, SelfSubjectRulesReview) only support POST — they are create-only resources with no GET/LIST/DELETE operations.
Automated etcd backups are a Technology Preview feature requiring the TechPreviewNoUpgrade feature gate, which is irreversible and blocks minor version updates.
The default cluster autoscaler expander strategy is Random; other options are LeastWaste and Priority.
The default autoscaler utilization threshold for scale-down is "0.5" (50%), expressed as a string value.
The maxNodesTotal setting in ClusterAutoscaler must account for all machines including control plane nodes, not just autoscaled compute nodes.
MachineAutoscaler minReplicas can be set to 0 on AWS, GCP, Azure, RHOSP, and vSphere only.
The priority expander ConfigMap must be named cluster-autoscaler-priority-expander in the openshift-machine-api namespace; higher integer means higher priority.
The ClusterAutoscaler requires at least one MachineAutoscaler to be deployed; without it, the cluster autoscaler will never scale.
HorizontalPodAutoscaler scales pod replicas, ClusterAutoscaler sets cluster-wide node scaling policy, and MachineAutoscaler scales specific MachineSets
OpenShift workload resource management spans two complementary systems: multi-level autoscaling (ClusterAutoscaler→HPA/KEDA→VPA) adjusts capacity at infrastructure and pod levels, while multi-dimensional scheduling (selectors, taints, affinity, topology, gates) places workloads within that capacity — together forming the complete resource allocation model.
Workload resource management (multi-level autoscaling + scheduling + storage placement) operates within the governance model: quotas force explicit resource declarations that autoscalers must respect, RBAC controls who configures scaling policies, and project-level self-provisioning governance determines which namespaces workloads can scale into.
IP traffic mode is disabled on OCP for the AWS Load Balancer Controller (only works on EKS).
The AWS Load Balancer Operator runs in the aws-load-balancer-operator namespace.
AWS Outposts supports ALB but not NLB with the AWS Load Balancer Operator.
The AWS Load Balancer Operator requires service type NodePort — not LoadBalancer or ClusterIP.
The ROLEARN environment variable is set in the Subscription spec to configure STS for the AWS Load Balancer Operator.
STS clusters require two separate IAM roles for the AWS Load Balancer Operator: one for the Operator and one for the Controller.
The AWS Load Balancer Operator only supports x86_64 architecture and does not support AWS GovCloud.
AWS tag kubernetes.io/cluster/<clusterid>=owned means the resource is destroyed with the cluster; shared means it persists after cluster deletion.
Default AWS load balancer type for OpenShift is Classic; NLB must be explicitly set via lbType: NLB in install-config.yaml.
AWS EFS and GCP Filestore CSI drivers are NOT installed by default in OCP 4.17 — they must be installed manually.
AWS EFS volume metrics in ClusterCSIDriver are disabled by default; the RecursiveWalk option can cause high CPU/memory usage.
On AWS, the Ingress load balancer type defaults to Classic; can be set to NLB for network load balancing
For AWS Local Zone deployments, deletion order is: cluster first, then Local Zone CloudFormation stack, then VPC stack
MTU between AWS Local Zone / Wavelength Zone EC2 instances and Region instances is typically 1300.
OpenShift on AWS allows up to 25 user-defined tags; 25 additional tags are reserved for OpenShift (50 total).
Red Hat's AWS account ID for RHEL AMI images is 309956199498.
AWS STS and Microsoft Entra Workload ID clusters must use Manual approval strategy for Operator subscriptions.
Azure disk encryption set configuration in ClusterCSIDriver requires three fields: name, resourceGroup, and subscriptionID.
Azure Disk only supports kind: Managed in OpenShift; Shared and Dedicated create unmanaged disks that cannot attach to OCP nodes.
Azure File does not support symlinks, hard links, extended attributes, sparse files, or named pipes by default; symlinks can be enabled with the mfsymlinks mount option.
Azure File uses the SMB (Server Message Block) protocol and supports ReadWriteMany (RWX) access mode.
Azure Stack Hub is a distinct installation target from standard Azure, with different API endpoints, available VM sizes, and networking constraints.
OpenShift on Azure supports both Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI) installation methods.
OVS balance-slb mode cannot load-balance OVN-Kubernetes pod traffic because all pods share the same MAC and VLAN; it only benefits VM workloads with distinct MACs.
BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass action, which is ANP-only)
BaselineAdminNetworkPolicy applies only when no AdminNetworkPolicy or NetworkPolicy matches the traffic — it is the lowest-priority policy layer
BANP allows maximum 100 rules per direction (ingress/egress), and host-networked pods are excluded from subject and peer selection
The networks CIDR peer in BANP/ANP supports up to 25 CIDRs and affects all traffic including cluster-internal (e.g., 0.0.0.0/0 affects pod-to-pod traffic)
BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass)
BaselineAdminNetworkPolicy is a singleton resource that must be named default
Bare metal edge deployments represent the maximum divergence from the standard OpenShift operational model: they combine full-stack infrastructure specialization (BMC, Ironic, MetalLB) with topology-specific constraints (SNO limitations, ZTP fleet management, TALM update gating), requiring the most specialized operational playbook of any deployment pattern.
Bare metal edge deployments require specialized infrastructure at every layer AND fleet-scale lifecycle management: provisioning uses BMC+Ironic+MetalLB (not cloud APIs), while ZTP+TALM handle provisioning and updates at scale with canary failure gating — making bare metal edge the most infrastructure-demanding deployment topology.
Bare metal hosts in the Cluster Inventory dashboard card are only visible in metal3 environments
Bare metal IPI installation requires Redfish or IPMI-capable hardware for automated provisioning.
Bare metal IPI (Installer-Provisioned Infrastructure) automates hardware provisioning via baseboard management controllers (BMC) using Redfish or IPMI protocols.
Bare metal IPI installations use Baseboard Management Controller (BMC) protocols such as IPMI and Redfish to manage host provisioning.
Bare metal installations run directly on physical hardware without a virtualization/hypervisor layer.
Bare metal IPI uses BMC for hardware automation, BareMetalHost resources with root device hints for disk selection, and a Provisioning CR consumed by the cluster-baremetal-operator to manage the metal3 lifecycle.
Bare metal MachineHealthCheck has two mutually exclusive remediation strategies: annotation-based (external-baremetal) and metal3-based (Metal3RemediationTemplate), both using power-cycle rather than reprovisioning.
Bare metal clusters require platform-specific infrastructure at both provisioning (BMC automation, BareMetalHost CRs with root device hints, Ironic-backed Provisioning CR) and runtime networking (MetalLB with L2 gratuitous ARP failover or BGP with single-ASN constraint) — neither layer has a cloud-provider equivalent that works automatically.
Bare metal is a first-class supported platform for OpenShift Container Platform installation, deploying directly on physical hardware without a cloud provider or virtualization layer.
Bare metal UPI (User-Provisioned Infrastructure) requires the administrator to manually prepare machines, networking, DNS, and load balancers before running the OpenShift installer.
On bare metal, Nutanix, and vSphere, the Image Registry Operator bootstraps as Removed; admin must manually switch to Managed and configure storage.
Bare pods (not managed by a replication controller) are NOT rescheduled upon node failure.
BareMetalHost resources live in the openshift-machine-api namespace by default.
OpenShift batch workloads follow a unified retry and scheduling model: Jobs default to 6 retries with exponential backoff capped at 6 minutes, CronJobs add timezone-aware scheduling with three concurrency policies (Allow/Forbid/Replace), and pods default to Always restart with exponential backoff capped at 5 minutes.
Batch workloads in OpenShift must navigate two independent constraint systems: the retry/failure model (backoff limits, pod failure policies, concurrency policies, restart restrictions) governs temporal behavior, while multi-dimensional scheduling constraints (node selectors, taints, affinity, topology, NUMA policy) govern spatial placement — both must be satisfied for a batch job to complete successfully
The Binding (v1) resource is deprecated since Kubernetes v1.7; pod-to-node binding should use the bindings subresource of pods instead.
Bindings are namespace-scoped resources; the namespace appears in all endpoint paths.
Bindings support only POST operations — they are write-once and not updatable.
The only required field on a Binding object is target (an ObjectReference).
The Binding v1 API object has been deprecated since Kubernetes 1.7; the recommended replacement is the bindings subresource of pods.
Block volumes use volumeMode: Block on PV and PVC, and pods use volumeDevices/devicePath instead of volumeMounts/mountPath, requiring privileged containers.
Switching NVIDIA Bluefield-2 from DPU mode to NIC mode is supported, but switching from NIC back to DPU mode is unsupported (one-way only)
If multiple Bluefield-2 devices exist on a node, the PCI address must be explicitly specified and must be consistent across all nodes being switched
Switching Bluefield-2 from DPU to NIC mode requires the SR-IOV Network Operator and uses a MachineConfig-deployed systemd service (dpu-switch.service) that triggers a node reboot
BMCEventSubscription is a namespaced resource (not cluster-scoped).
BMCEventSubscription (metal3.io/v1alpha1) forwards BMC hardware events to a user-specified webhook URL, with optional custom HTTP headers stored in a Secret.
BareMetalHost is a Custom Resource with API group metal3.io/v1alpha1, used to manage physical bare-metal servers in OpenShift.
BMC credentials Secret for BareMetalHost must contain keys named exactly username and password.
The default boot mode for BareMetalHost is UEFI.
The hardwareProfile field on BareMetalHost is deprecated; use architecture and rootDeviceHints instead.
For BareMetalHost image format live-iso, checksum fields are ignored; the ISO is live-booted, not written to disk.
The only required spec field on a BareMetalHost resource is online (boolean), which controls whether the server should be powered on.
In BareMetalHost rootDeviceHints, the model and vendor fields support substring matching; all other fields require exact match.
BareMetalHost software RAID supports max 2 devices; the first must be RAID-1, the second can be RAID-0, RAID-1, or RAID-1+0.
failOverMac must be set to 1 (mandatory) when using active-backup mode with Bond-CNI in OpenShift.
linksInContainer must be set to true in the Bond-CNI NetworkAttachmentDefinition to find interfaces inside the container rather than on the host.
OpenShift Bond-CNI is only supported with SR-IOV virtual functions — other CNI types or interface types are not supported for pod-level bonding.
The Bond CNI plugin only supports SR-IOV Virtual Functions (VFs) for bonding; it cannot bond arbitrary interfaces.
OpenShift Bond-CNI supports only three bonding modes: balance-rr (0), active-backup (1), and balance-xor (2).
SR-IOV VF trust mode must be set to on when using balance-rr or balance-xor bonding modes.
A pod using SR-IOV bonding must list all three networks in the k8s.v1.cni.cncf.io/networks annotation: two SR-IOV networks plus one bond network.
During bootstrap, bootkube.service etcd "connection refused" errors are normal and expected — they resolve once control plane nodes join.
The bridge CNI plugin only enables communication between pods on the same host and with the host itself.
BrokerTemplateInstance is an experimental, cluster-scoped resource in the template.openshift.io/v1 API group that links the Template Service Broker to TemplateInstance objects.
spec.additionalTrustedCA on the Build config resource is deprecated — the correct approach is to use image.config.openshift.io/cluster instead.
OpenShift provides an end-to-end image delivery pipeline: dual build systems (Shipwright + BuildConfig) produce images, ImageStreams provide controlled access with immutable content-addressed storage, and the internal registry can be exposed externally with re-encrypt TLS — connecting build, storage, and distribution.
completionDeadlineSeconds is counted from when the build pod is scheduled, not from when it is created
spec.buildDefaults values can be overridden by individual BuildConfig objects; spec.buildOverrides values cannot be overridden and are forced on all builds.
gitProxy overrides defaultProxy for git operations in the Build config; unset gitProxy fields inherit from defaultProxy.
When mountTrustedCA is enabled, changes to /etc/pki/ca-trust inside the build are NOT persisted in the output image
Build nodeSelector: nil inherits cluster defaults; empty map {} overrides/ignores cluster defaults; map with values uses those values and ignores defaults
Build output to kind must be either ImageStreamTag or DockerImage — no other kinds are valid
buildOverrides.imageLabels overwrites user-provided labels with the same name; buildDefaults.imageLabels are overridden by user-provided labels.
Post-commit hooks run after the last image layer is committed but before pushing to the registry; a non-zero exit code fails the entire build
Post-commit hooks cannot specify both script and command simultaneously — this is invalid
Build-injected secrets are truncated to zero length after the Source-to-Image (S2I) assemble script completes as a security measure
OpenShift BuildConfig supports three active build strategies: Docker (Dockerfile), Source-to-Image (S2I), and Custom
spec.strategy is the only required field in a Build or BuildConfig .spec
OpenShift maintains two coexisting build systems (Shipwright and BuildConfig), both of which are OpenShift-native with no upstream Kubernetes equivalents, and both tightly coupled to ImageStreams — another OpenShift-native concept — creating an OpenShift-specific build-to-image pipeline that diverges entirely from vanilla Kubernetes patterns.
BuildConfig can be triggered by webhooks, base image changes, or manual requests.
Trusted CA ConfigMaps for builds must use the key ca-bundle.crt and reside in the openshift-config namespace.
buildah, podman, and skopeo are daemonless, rootless container tools preferred over Docker in the OCP ecosystem; they produce OCI-standard images.
BuildConfig uses the API group build.openshift.io/v1.
BuildConfig failedBuildsHistoryLimit and successfulBuildsHistoryLimit default to retaining the 5 most recent builds; removing the field retains all
BuildConfig default RunPolicy is Serial — builds execute one at a time unless changed
OpenShift BuildConfig supports four build strategies: Source-to-Image (S2I), Docker, Custom, and Pipeline (deprecated, replaced by Tekton).
BuildConfig is a first-class OpenShift API resource for defining builds; it is not present in upstream Kubernetes.
BuildConfig objects support three build strategies: Docker, Source-to-Image (S2I), and custom.
BuildConfig supports three trigger types: ConfigChange (rebuild on BC edit), ImageChange (rebuild when base image updates), and Webhook (rebuild on git push from GitHub, GitLab, Bitbucket, or generic).
The builder service account runs builds and needs appropriate permissions.
Build logs are retrieved via CLI using oc logs build/<build-name> -n <namespace>
BuildLog (build.openshift.io/v1) is Compatibility Level 1, guaranteed stable within a major release for at least 12 months or 3 minor releases
BuildLog is a sub-resource of Build, not an independently created resource — its API endpoint is nested under /apis/build.openshift.io/v1/namespaces/{namespace}/builds/{name}/log
BuildRequest clone endpoint is POST /apis/build.openshift.io/v1/namespaces/{namespace}/builds/{name}/clone; instantiate endpoint is POST /apis/build.openshift.io/v1/namespaces/{namespace}/buildconfigs/{name}/instantiate
dockerStrategyOptions.buildArgs passes Docker ARG values at build request time; sourceStrategyOptions.incremental overrides incremental build setting per-request
BuildRequest supports four webhook trigger types: GitHub, GitLab, Bitbucket, and Generic
BuildRequest lastVersion field provides optimistic concurrency — if the BuildConfig's version doesn't match, the build won't be generated
BuildRequest is the mechanism behind oc start-build — it is a transient request object (not persistent) used to pass parameters to the build generator
When a build/deployment references an image stream tag, OpenShift resolves it to an exact image SHA at build/deploy time, providing deterministic deployments.
Builds for Red Hat OpenShift is distinct from the legacy OpenShift Build/BuildConfig API (S2I, Docker, Custom strategies) and is a modern replacement/alternative.
Builds for Red Hat OpenShift is the Red Hat productized version of the upstream Shipwright project, installed as a separate operator via OLM.
Builds run as pods in the namespace — they consume cluster resources and are subject to quotas.
Builds for Red Hat OpenShift uses Tekton TaskRuns under the hood to execute builds.
An Operator bundle must contain exactly one ClusterServiceVersion (CSV) and at least one channel.
You cannot add or edit health checks for an existing pod via the CLI — you must edit the DeploymentConfig object or use the Developer web console.
The br-ex bridge and its interfaces cannot be modified via NodeNetworkConfigurationPolicy after cluster installation.
Capacity-aware scheduling must be explicitly enabled via CSIDriverSpec.StorageCapacity on the CSI driver.
When the same package exists in multiple CatalogSources, higher spec.priority value wins (default is 0)
CatalogSources are typically created in the openshift-marketplace namespace
For grpc CatalogSources, the image field takes precedence over address — if both are set, address is ignored
CatalogSource spec.sourceType: grpc with spec.image is the standard way to add custom operator catalogs
CatalogSource priority field (int32, default 0) controls dependency resolution preference — higher value wins; ties broken lexicographically by name
CatalogSource grpcPodConfig.securityContextConfig accepts legacy or restricted values; use legacy for older catalog images that cannot run non-root
sourceType is the only required spec field for CatalogSource (operators.coreos.com/v1alpha1); valid types are grpc and configmap
CatalogSources can be of type grpc (index image) or configmap.
Default CatalogSources are located in the openshift-marketplace namespace.
The Cloud Credential Operator (CCO) credentialsMode field supports four values: "" (Default), "Mint", "Passthrough", and "Manual".
The Cloud Credential Operator mode is set via credentialsMode in install-config.yaml.
CCO Default mode ("") dynamically probes the root credential's capabilities and is only supported on AWS, Azure, and GCP.
CCO Manual mode is required for short-lived token approaches such as AWS STS, GCP Workload Identity, and Azure Managed Identity.
When CCO is in Manual mode, cloud credentials must be manually reconciled with every cluster upgrade.
Non-AWS/Azure/GCP platforms only support "Passthrough" credential mode in the Cloud Credential Operator.
The Cloud Credential Operator Upgradable status defaults to False for clusters with manually maintained credentials; z-stream updates are not blocked but minor version updates are.
ccoctl aws delete --name=<name> --region=<region> is a separate cleanup step from openshift-install destroy cluster, removing IAM roles, policies, OIDC provider, and S3 bucket created for STS
The ccoctl utility is a Linux-only binary that must match the release image architecture of the target cluster.
The ccoctl utility supports cloud subcommands for aws, azure, gcp, ibmcloud, and nutanix.
The cert-manager Operator for Red Hat OpenShift is a cluster-wide service; it must not be installed in multiple namespaces, and the community cert-manager must never run simultaneously with the Red Hat operator.
cert-manager webhook and cainjector expose Prometheus metrics on port 9402 at the /metrics endpoint.
cert-manager NetworkPolicy hardening is disabled by default and must be explicitly enabled in the CertManager CR.
cert-manager Operator supports seven issuer types: ACME, CA, Self-signed, Vault (fully tested), and Venafi, NCM, Google CAS (partially tested).
cert-manager has two certificate request methods: CertificateRequest (requires admin approval) and Certificate (automatic issuance from a referenced Secret via issuerRef).
The command oc get cloudcredentials cluster -o=jsonpath={.spec.credentialsMode} determines the CCO credential mode.
The command to check current cluster network MTU is oc describe network.config cluster.
The command to check cluster platform type is oc get infrastructure cluster -o jsonpath='{.status.platform}'.
OpenShift CI/CD is in active strategic transition: Jenkins is deprecated in favor of OpenShift Pipelines (Tekton), but the platform still provides multiple CI/CD solutions simultaneously (Pipelines, GitOps, Shipwright builds) rather than a single integrated pipeline, reflecting a deliberate multi-tool strategy during the transition period
GA CLI flags/commands are Tier 1; Tech Preview CLI elements are Tier 3; Developer Preview CLI elements are Tier 4.
The CLI Manager custom Krew index URL pattern is https://$ROUTE/cli-manager.
The CLI Manager Operator requires the namespace openshift-cli-manager-operator.
The CLI Manager Operator is a Technology Preview feature, not supported for production use.
CLI Manager plugins are defined as custom resources with API group config.openshift.io/v1alpha1, kind Plugin.
CloudPrivateIPConfig is internally managed by the network plugin; manual changes by cluster-admins are overwritten on the next reconciliation cycle
CloudPrivateIPConfig (cloud.network.openshift.io/v1) is the underlying implementation mechanism for EgressIP on cloud platforms
CloudPrivateIPConfig CR name must be the requested private IP address itself, and it supports both IPv4 and IPv6
The CloudCredential resource is cluster-scoped (not namespaced) and is typically named cluster.
cluster-admin role is required to install Operators from OperatorHub
The Cluster API cannot manage control plane machines — only compute machines.
The Cluster API IPAM resources (IPAddress and IPAddressClaim) use the API group ipam.cluster.x-k8s.io/v1beta1 in OpenShift 4.17.
Cluster API resources live in the openshift-cluster-api namespace, managed by the Cluster CAPI Operator.
Enabling Cluster API requires the TechPreviewNoUpgrade feature set, which is irreversible and blocks minor version updates.
Cluster API in OCP 4.17 supports AWS, Google Cloud, RHOSP, and VMware vSphere.
The Cluster API is a Technology Preview feature in OCP 4.17, providing an alternative to the Machine API for compute machine management.
OpenShift is transitioning toward upstream Cluster API (CAPI), which may coexist with or replace the traditional Machine API.
ClusterAutoscaler uses API version autoscaling.openshift.io/v1; MachineAutoscaler uses autoscaling.openshift.io/v1beta1.
The ClusterAutoscaler resource name must be "default" and only one can exist per cluster.
Cluster certificates expire one year after installation; expired control plane certs are auto-retrieved but CSRs must still be manually approved.
OpenShift cluster configuration resources (APIServer, Infrastructure, Network, OAuth, Proxy, Scheduler, DNS, Authentication, Ingress) are managed via the config.openshift.io/v1 API group.
Cluster ID is retrieved via oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
Cluster ID is visible in the web console at Home → Overview → Details → Cluster ID
Cluster-level backup uses etcd snapshots to protect cluster state (API objects, configuration); application-level backup uses OADP/Velero to protect workloads and persistent volumes.
clusterNetwork, serviceNetwork, and networkType on the Network config are immutable after installation
OpenShift cluster networking operates across two complementary layers: the DNS discovery layer (CoreDNS DaemonSet with deterministic 10th-address allocation and strict forwarding zone rules) and the multi-CNI data plane (OVN-Kubernetes primary + Multus secondary with NAD-based pod attachment) — both must be healthy for workloads to communicate.
The cluster-node-tuning-operator distributes Tuned rules to containerized TuneD daemons running as a DaemonSet on every node.
The Cluster Observability Operator (COO) is a separate, independently installable operator distinct from the built-in OpenShift monitoring stack (Prometheus, Alertmanager).
Cluster Operators are managed by the Cluster Version Operator (CVO), not by OLM. OLM handles optional add-on Operators only.
The Cluster Resource Override Operator now uses a Deployment instead of a DaemonSet, and its pods can be moved to infrastructure nodes.
ClusterResourceQuota applies quotas across multiple projects selected by annotation (openshift.io/requester) or label selector.
The Cluster Samples Operator is deprecated as of OCP 4.17; only existing S2I builder image streams and templates continue receiving updates
The Cluster Samples Operator manages sample image streams and templates in the openshift namespace.
The Cluster Storage Operator may install a default storage class depending on the platform; this operator-owned class cannot be deleted or modified beyond annotations/labels.
Cluster backup (etcd/control plane) and application backup (OADP/Velero) are distinct procedures in OpenShift.
ClusterAutoscaler is a cluster-scoped resource (one per cluster) that controls node-level autoscaling.
ClusterAutoscaler default expander is Random; available options are LeastWaste, Priority, and Random
ClusterAutoscaler GPU limits match GPU type via the cluster-api/accelerator node label
ClusterAutoscaler ignoreDaemonsetsUtilization defaults to false — DaemonSet pod resources are included in scale-down calculations by default
ClusterAutoscaler is a cluster-scoped singleton resource that controls cluster-level autoscaling decisions (adding/removing nodes).
ClusterAutoscaler can set scaling limits on cores, nodes, memory, and GPU, and can be configured to scale up only (not down).
ClusterAutoscaler must exist before MachineAutoscalers can function
scaleDown.enabled is the only required field under .spec.scaleDown in ClusterAutoscaler
ClusterAutoscaler is a cluster-scoped singleton resource — only one instance per cluster, not namespaced
The ClusterAutoscaler is a singleton resource — it only responds to a resource named default. MachineAutoscaler targets MachineSets.
ClusterAutoscaler skipNodesWithLocalStorage defaults to true — nodes with EmptyDir/HostPath pods are protected from scale-down by default
The ClusterCSIDriver object name must equal the CSI driver name it manages — this is a hard constraint.
ClusterCSIDriver storageClassState has three values: Managed (default, continuously reconciles), Unmanaged (stops reconciling), and Removed (deletes previously created storage classes).
ClusterExtension (olm.operatorframework.io/v1alpha1) is a single cluster-scoped API object that replaces the previous Subscription + OperatorGroup multi-object approach from classic OLM
ClusterExtension supports three version strategies: channel (auto-update), exact version (pinned, requires manual CR edit to update), and version range (comparison string like ">1.11.1")
ClusterGroupUpgrade CRs (via TALM) are used to remediate and roll out policy changes to managed spoke clusters.
The ClusterLogForwarder custom resource controls where logs are forwarded/sent.
The oc get clusteroperators command (short name co) lists all cluster operators and their status.
The three standard ClusterOperator condition types are Available, Progressing, and Degraded.
An operator reports a new version in its ClusterOperator resource only after it has finished rolling out to all operands, not when the rollout starts.
ClusterResourceQuota is an OpenShift-specific resource (quota.openshift.io/v1), not available in vanilla Kubernetes.
ClusterResourceQuota spec requires two fields: quota (resource limits) and selector (which projects are affected).
ClusterResourceQuota selectors should target active projects on the scale of dozens — performance degrades with too many actively-creating projects contending on the resource.
When a ClusterResourceQuota selector specifies both label and annotation selectors, a project must match both to be subject to the quota.
ClusterResourceQuota is an OpenShift object that defines resource quotas across multiple namespaces via label or annotation selectors.
ClusterRoles support aggregation rules that dynamically compose permissions by selecting other ClusterRoles via label selectors; built-in roles like admin, edit, and view use this mechanism.
When a ClusterRole has an AggregationRule set, direct edits to the rules field are overwritten by the controller — rules become controller-managed.
ClusterRole (rbac.authorization.k8s.io/v1) is a cluster-scoped resource — it is not created within a namespace.
In an OpenShift PolicyRule, an empty apiGroups field means both Kubernetes and OpenShift API groups are assumed (permits actions in either).
The nonResourceURLs field in a ClusterRole PolicyRule only takes effect when the ClusterRole is referenced from a ClusterRoleBinding, not from a namespaced RoleBinding.
OpenShift has its own ClusterRole API at authorization.openshift.io/v1, distinct from the Kubernetes rbac.authorization.k8s.io/v1 ClusterRole API.
In a ClusterRole PolicyRule, verbs is the only required field.
Setting the namespace field on a User or Group subject in a ClusterRoleBinding is an error; namespace is only valid for ServiceAccount subjects.
A ClusterRoleBinding requires both subjects and roleRef fields; userNames and groupNames are legacy backward-compatibility fields that newer clients should not use.
The roleRef field on a ClusterRoleBinding is required and immutable — to change the referenced role, you must delete and recreate the binding.
In a ClusterRoleBinding subject, ServiceAccount uses apiGroup "" (core API group), while User and Group use rbac.authorization.k8s.io.
ClusterTask functionality is deprecated as of OpenShift Pipelines 1.10 and planned for removal.
The architecture field in ClusterVersion desiredUpdate only supports transitioning from single architecture to Multi; it cannot be reversed.
The baselineCapabilitySet in ClusterVersion defaults to vCurrent.
The channel field on ClusterVersion controls which update stream the cluster subscribes to (e.g., stable-4.17, fast-4.17, candidate-4.17).
availableUpdates are unconditionally recommended; conditionalUpdates are recommended only if the cluster meets specific conditions (evaluated via PromQL).
ClusterVersion (config.openshift.io/v1) tracks the cluster's current and desired version — key for upgrades.
The force flag on desiredUpdate in ClusterVersion bypasses image verification and upgradeable checks.
ClusterVersion history is viewed with oc describe clusterversions/version or via the web console at Administration → Cluster Settings → Details tab.
ClusterVersion history has a size limit — oldest z-stream updates in previous minor versions are pruned first.
ClusterVersion update history entries have state Completed (fully applied) or Partial (not fully applied or failed).
When image is specified in desiredUpdate on ClusterVersion, the version field is silently ignored.
Querying the ClusterVersion resource requires cluster-admin privileges.
The ClusterVersion resource is in the config.openshift.io/v1 API group with Kind ClusterVersion and is cluster-scoped (no namespace).
There is only one ClusterVersion object per cluster and its resource name is version.
The cmdlinecrash nohzfull CPU set must match cpu.isolated in the PerformanceProfile.
The Cluster Monitoring Operator (CMO) is configured via ConfigMaps, not CRDs.
Default cluster network CIDR is 10.128.0.0/14 with hostPrefix 23; default service network is 172.30.0.0/16.
The gatewayConfig field is the exception to post-install immutability — it can be changed at runtime.
IP forwarding defaults to Restricted for new OCP 4.14+ installs and Global for upgrades to 4.14+.
IPsec configuration supports three modes: Disabled, External (external traffic only), and Full (pod traffic and external traffic).
The Cluster Network Operator runs in the openshift-network-operator namespace.
The Cluster Network Operator configuration object is always named cluster.
OVN-Kubernetes is the only supported network plugin for new OpenShift Container Platform installations.
OVN-Kubernetes uses Geneve (Generic Network Virtualization Encapsulation) as the overlay network on default port 6081.
After installation, only the clusterNetwork IP address range can be modified; serviceNetwork and networkType are read-only.
OpenShift Virtualization is based on the KubeVirt upstream open-source project
VMs should not be created in openshift-* namespaces; use custom namespaces without the openshift prefix
EUS-to-EUS update procedure: (1) pause worker MCP, (2) disable workload updates, (3) update OCP to odd version, (4) update OpenShift Virt, (5) update OCP to target EUS, (6) update OpenShift Virt again, (7) re-enable workload updates, (8) unpause MCP
Golden images are stored in the openshift-virtualization-os-images namespace by default, customizable via spec.commonBootImageNamespace in the HyperConverged CR
Guest system serial console log access is disabled by default in OpenShift Virtualization, controlled via spec.virtualMachineOptions.disableSerialConsoleLog in the HyperConverged CR
VMs using hostpath provisioner storage cannot be live migrated; workaround is setting evictionStrategy: None and runStrategy: Always
OpenShift Virtualization is installed as an Operator via OperatorHub, not built into the base platform
Instance type cpu and memory are required attributes and cannot be overridden when creating a VM from an instance type
VirtualMachineInstancetype is namespaced and VirtualMachineClusterInstancetype is cluster-wide; same pattern for preferences (VirtualMachinePreference vs VirtualMachineClusterPreference)
Pre-defined instance type naming convention: <series><version>.<size> (e.g., u1.medium, cx1.2xlarge)
Pre-defined instance type series: U (Universal, burstable, 1:4), O (Overcommitted, 1:4), CX (Compute-exclusive, dedicated CPU, 1:2), GN (NVIDIA GPU, 1:4), M (Memory-intensive, 1:8), N (Network-intensive, dedicated CPU, 1:2)
OpenShift Virtualization live migration requires shared storage with RWX (ReadWriteMany) access mode
LiveMigrate is the default and only enabled workload update method for OpenShift Virtualization; Evict must be explicitly added
OpenShift Virtualization log verbosity is configured per-component in the HyperConverged CR at spec.logVerbosityConfig.kubevirt with values 1–9
VM machineType is not automatically changed during OpenShift Virtualization updates; the VM must be shut down before changing it
During workload updates, VMI migration times out after 5 minutes if Unschedulable and 15 minutes for any other pending reason
The default number of parallel processes for OpenShift Virtualization must-gather is 5, controlled by the PROS environment variable
The must-gather image for OpenShift Virtualization is registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v<version>
Instance types information is not collected by default with must-gather; it requires the explicit --instancetypes flag
The NS environment variable is mandatory when using the VM variable with must-gather for OpenShift Virtualization
Per-VM guest log settings take precedence over cluster-wide defaults in OpenShift Virtualization
OpenShift Virtualization pods (virt-api, virt-controller, virt-handler, virt-launcher, virt-operator) run in the openshift-cnv namespace
Prometheus retention should be set to a minimum of 7 days before collecting OpenShift Virtualization support data
OpenShift Virtualization requires bare-metal or supported nested-virtualization infrastructure; not supported on all cloud providers without specific enablement
runStrategy and spec.running are mutually exclusive on a VirtualMachine resource
VirtualMachine runStrategy values: Always (restarts if stopped), Halted (VM stopped), RerunOnFailure (restarts only on failure), Manual (manual start/stop via virtctl)
The recommended update settings for OpenShift Virtualization are the stable channel with Automatic approval strategy
OpenShift Virtualization cannot be updated to the next minor version without first updating OCP to that minor version
OpenShift Virtualization minor version must match the OpenShift Container Platform minor version (e.g., 4.17 on 4.17)
Compatibility Level 1 means an API is stable for at least 12 months or 3 minor releases, whichever is longer
Compatibility Level 1 APIs in OpenShift are stable for a minimum of 12 months or 3 minor releases within a major release
OpenShift Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.
Compatibility Level 1 on OpenShift-specific APIs means stable for at least 12 months or 3 minor releases.
Compatibility Level 1 APIs in OpenShift are stable within a major release for at least 12 months or 3 minor releases.
Compatibility Level 1 OpenShift APIs are stable within a major release for at least 12 months or 3 minor releases.
Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.
Compatibility Level 1 means stable for 12 months or 3 minor releases (whichever is longer); Compatibility Level 2 means stable for 9 months or 3 minor releases.
OpenShift networking is a unified three-layer architecture: DNS discovery (CoreDNS DaemonSet with deterministic IP allocation), multi-CNI data plane (OVN-Kubernetes + Multus for secondary interfaces), and dual-stack IPv4/IPv6 addressing — where the addressing layer imposes platform-specific constraints back onto the data plane.
OpenShift provides a unified software delivery model covering both application and operator lifecycles: application images flow through build systems → ImageStreams → registry → deployment, while operators flow through FBC catalogs → OLM chain → CSV → deployment, and both terminate in console UI integration via plugins.
Serving certificate secrets for component routes must be type kubernetes.io/tls in the openshift-config namespace
ComponentStatus is deprecated since Kubernetes v1.19 and remains only for backward compatibility.
ComponentStatus (v1) is deprecated since Kubernetes v1.19.
The only valid condition type for ComponentStatus is "Healthy", with status values "True", "False", or "Unknown".
ComponentStatus is a read-only, cluster-scoped resource with only GET endpoints (no create, update, or delete).
Conditional (not-recommended) updates can be viewed with oc adm upgrade --include-not-recommended and applied with --allow-not-recommended
Confidential containers extend sandboxed containers with hardware-level trusted execution environments (TEEs) such as AMD SEV and Intel TDX for data protection.
The Config APIs in OpenShift 4.17 contain approximately 23 cluster-wide configuration resources under config.openshift.io/v1 (and helm.openshift.io/v1beta1).
Changes to Config API resources trigger reconciliation by Cluster Operators
The primary API group for OpenShift cluster configuration resources is config.openshift.io.
Config API objects under config.openshift.io are cluster-scoped (not namespaced) and apply platform-wide.
Config API objects include Infrastructure, Ingress, DNS, Proxy, Network, OAuth, Scheduler, APIServer, and FeatureGate
Config API objects in OpenShift live under the config.openshift.io API group and are typically cluster-scoped singletons named cluster
Configuration drift (when a node's actual config doesn't match its MCP's machine config) causes the MCD to mark the node degraded; the node remains online but cannot be updated.
Cluster-wide configuration resources live under the config.openshift.io API group
The Config Operator (operator.openshift.io/v1) is a bootstrap-level operator that creates the initial configuration of other cluster components.
The Config Operator handles cloud configuration migration and synchronization specifically for AWS and Azure (not all cloud providers).
ConfigMaps use the binaryData field for non-UTF8 content, stored as Base64-encoded values.
ConfigMap binaryData field requires apiserver and kubelet v1.10 or later.
Keys in a ConfigMap's data and binaryData fields must not overlap; this is enforced at validation.
Using envFrom with configMapRef injects all keys from a ConfigMap as environment variables, while env with configMapKeyRef injects individual keys.
Setting immutable: true on a ConfigMap prevents updates to data and binaryData; the ConfigMap must be deleted and recreated to change data.
ConfigMap keys must contain only alphanumeric characters, -, _, or ..
ConfigMaps must be created before pods that reference them, unless the reference is marked optional: true.
ConfigMaps in OpenShift/Kubernetes are namespace-scoped and can only be referenced by pods in the same project.
ConfigMaps do not provide encryption; Secrets should be used for sensitive data.
Only pods created via the API server (CLI, replication controllers) can use ConfigMaps — not pods from --manifest-url, --config flag, or node REST API.
When a ConfigMap is mounted as a volume, each key becomes a filename and each value becomes the file content.
A "connected cluster" is one that reports data to Red Hat via Telemetry and the Insights Operator
Console API CRD changes are picked up dynamically — no console restart is needed
ConsolePlugin and ConsoleSample have Compatibility Level 1 (stable 12 months or 3 minor releases)
Console API resources at Compatibility Level 2 are stable for a minimum of 9 months or 3 minor releases within a major release
Eight Console API CRDs exist: ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample
The Console config API group is config.openshift.io/v1, not console.openshift.io.
The console.openshift.io/v1 API group includes ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample, ConsoleLink, ConsoleExternalLogLink, and ConsoleCLIDownload resources.
All Console API resources that accept URLs (ConsoleLink, ConsoleCLIDownload, ConsoleExternalLogLink) require HTTPS — HTTP URLs are not allowed
Console API resource types include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, and ConsoleYAMLSample
Key Console API resources include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, and ConsoleYAMLSample
All Console API custom resources belong to the console.openshift.io/v1 API group
Console API resources belong to the console.openshift.io/v1 API group and are OpenShift-specific (not in upstream Kubernetes)
Console APIs are OpenShift-specific and do not exist in upstream Kubernetes
The Console resource (config.openshift.io/v1) is a cluster-scoped singleton always named cluster.
Custom console logos are stored in a ConfigMap in the openshift-config namespace, not in the operator spec directly.
Custom console route TLS secrets must contain keys tls.crt and tls.key and be stored in the openshift-config namespace.
Console customization uses resources ConsoleLink, ConsoleNotification, and ConsoleCLIDownload along with the Console operator config (operator.openshift.io/v1)
The default administrative user after installation is kubeadmin with a generated password stored in auth/kubeadmin-password
The default console route follows the pattern https://console-openshift-console.apps.<cluster_domain>
The web console is served by the console-openshift-console deployment in the openshift-console namespace
The spec.authentication.logoutRedirect field on the Console config is required when using SSO identity providers (OpenID, RequestHeader, OAuth) to enable single logout (SLO).
console.openshift.io/v1 is Tier 2, not Tier 1.
The Console Operator can be disabled without affecting cluster supportability or upgradeability.
The Console operator resource is a singleton cluster-scoped resource named cluster.
Console perspective visibility can be set to Enabled, Disabled, or AccessReview (gated on RBAC access review checks).
Console extensibility follows a defined model: plugins must use HTTPS backends, register via OLM, respect the singleton Console config resource, and maintain Level 1 API stability.
Console plugins are enabled by adding their name to the spec.plugins array on the Console operator resource.
Operator bundles can declare ConsolePlugin resources to register UI extensions through OLM integration
The web console runs as pods on control plane nodes in the openshift-console project, managed by the console-operator pod
The Console operator spec.route field is deprecated; spec.ingress is the modern alternative for custom console URLs.
The web console has two main perspectives: Administrator and Developer, each tailored to different user roles
The console URL is found in status.consoleURL and is derived from the console route — it is not user-configurable.
The web console URL can be retrieved with oc whoami --show-console
ConsoleCLIDownload is a cluster-scoped resource (no namespace) used to register CLI tool download links in the web console
ConsoleCLIDownload link href values must use HTTPS (absolute secure URLs)
ConsoleCLIDownload requires three spec fields: description, displayName, and links
ConsoleExternalLogLink namespaceFilter uses JavaScript RegExp syntax (not Go or POSIX regex)
ConsoleExternalLogLink links appear on the Logs tab of the pod details page in the web console
ConsoleExternalLogLink hrefTemplate supports variables: ${resourceName}, ${resourceUID}, ${containerName}, ${resourceNamespace}, ${resourceNamespaceUID}, and ${podLabels} (JSON-encoded)
When ConsoleLink location is ApplicationMenu, the applicationMenu.section field is required to determine the menu grouping
ConsoleLink is a cluster-scoped resource, even when targeting specific namespace dashboards
ConsoleLink supports four valid location values: ApplicationMenu, HelpMenu, UserMenu, NamespaceDashboard
When ConsoleLink location is NamespaceDashboard and no namespaceDashboard filter is specified, the link appears in all namespaces
ConsoleLink can add links at three scopes: cluster-level, namespace-level, or application menu
ConsoleNotification is a cluster-scoped custom resource (no namespace required) in the console.openshift.io/v1 API group.
ConsoleNotification has Compatibility Level 2: stable within a major release for at least 9 months or 3 minor releases.
ConsoleNotification link href must be an absolute secure URL (HTTPS).
ConsoleNotification valid location values are exactly three: BannerTop, BannerBottom, BannerTopBottom.
The only required field in the ConsoleNotification spec is text.
ConsolePlugin backend services must use HTTPS with service serving certificates.
ConsolePlugin has Compatibility Level 1: stable for at least 12 months or 3 minor releases within a major release.
The ConsolePlugin custom resource uses API group console.openshift.io/v1 to register dynamic plugins with the web console
ConsolePlugin displayName is required and must be 1-128 characters.
ConsolePlugin is the primary mechanism for extending the web console with dynamic plugins, introduced in OCP 4.10+ and GA in 4.12+
ConsolePlugin dynamically loads code from an in-cluster service to extend the OpenShift web console
ConsolePlugin localization loadType values are Preload, Lazy, or empty string (defaults to Lazy).
ConsolePlugin only supports Service as a backend type.
The ConsolePlugin resource is the primary mechanism for extending the OpenShift web console with dynamic plugins (OCP 4.12+)
ConsolePlugin proxy URL pattern is /api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>.
ConsoleQuickStart quick starts are hidden (not just disabled) when accessReviewResources checks fail.
ConsoleQuickStart is a cluster-scoped resource in the console.openshift.io/v1 API group.
ConsoleQuickStart has Compatibility Level 2: stable for 9 months or 3 minor releases within a major release.
ConsoleQuickStart required spec fields are description, displayName, durationMinutes, introduction, and tasks.
ConsoleSample has Compatibility Level 1: stable for at least 12 months or 3 minor releases.
ConsoleSample default HTTP service port is 8080 unless overridden via targetPort.
ConsoleSample Git imports are limited to public repositories on GitHub, GitLab, and Bitbucket only.
ConsoleSample required spec fields are abstract, description, source, and title.
ConsoleSample supports two source types: GitImport (from a Git repo) and ContainerImport (from a container image).
ConsoleYAMLSample is a cluster-scoped resource in the console.openshift.io/v1 API group.
ConsoleYAMLSample required spec fields are description, targetResource, title, and yaml.
ConsoleYAMLSample snippet boolean field distinguishes between complete resource definitions (false) and insertable fragments (true) in the web console editor.
Container image versions must match the OCP version — newer container images are not backward compatible with earlier OCP versions.
All container logging in OpenShift should go to stdout for collection by the centralized logging system
A container runtime must be installed on each node for pods to run.
containerRuntimeSearchRegistries works only with Podman and CRI-O, and only in pod specs (not builds or image streams)
The Container Security Operator is installed in the openshift-operators namespace by default.
The Container Security Operator does not scan images itself — it queries the source container registry (which must run Clair scanning) for vulnerability information.
ContainerRuntimeConfig belongs to API group machineconfiguration.openshift.io/v1 and is a cluster-scoped resource.
ContainerRuntimeConfig is the declarative, supported approach to customize CRI-O settings on cluster nodes without writing raw MachineConfig resources.
ContainerRuntimeConfig default overlaySize (max container image size) is 10GB.
ContainerRuntimeConfig is the dedicated CR for managing CRI-O container runtime settings (e.g., pidslimit, logsize_max), separate from MachineConfig.
ContainerRuntimeConfig valid logLevel values are: fatal, panic, error, warn, info, debug.
ContainerRuntimeConfig logSizeMax must be >= 8192 if set to a positive value (to match conmon's read buffer); negative values mean no limit.
A nil machineConfigPoolSelector in ContainerRuntimeConfig selects no pools — you must explicitly label-match to apply the config.
ContainerRuntimeConfig pidsLimit parameter controls per-container process limits for workload isolation and security.
Control plane machines must not be deleted unless the cluster uses a control plane machine set (CPMS).
Control plane machines cannot be managed by compute machine sets; they require control plane machine sets instead.
Control plane machines are not scaled via MachineSets; they are managed by the ControlPlaneMachineSet.
KubeAPIServer, KubeControllerManager, and KubeScheduler operators all use the same revision-based static pod deployment model on control plane nodes
Control plane nodes run the API server, etcd, and controllers; worker nodes run application workloads.
The additionalTrustBundle field in ControllerConfig propagates custom CA certificates to all node trust stores (e.g., for proxied environments or private registries).
The ControllerConfig resource belongs to the machineconfiguration.openshift.io/v1 API group and is cluster-scoped.
The baseOSContainerImage field is the required new-format OS update image in ControllerConfig; osImageURL is deprecated.
ControllerConfig deprecated fields: etcdDiscoveryDomain (use Infra.Status.EtcdDiscoveryDomain), platform (use Infra.Status.PlatformStatus.Type), osImageURL (use baseOSContainerImage).
ControllerConfig required spec fields are: baseOSContainerImage, cloudProviderConfig, clusterDNSIP, images, ipFamilies, kubeAPIServerServingCAData, releaseImage, rootCAData.
ControllerRevision is in the apps/v1 API group and is a namespaced resource.
ControllerRevision's data field is immutable after creation; the API server rejects mutation attempts.
ControllerRevision (apps/v1) is immutable after creation — the API server rejects mutations to the Data field. Used by DaemonSet and StatefulSet controllers for update and rollback.
The revision field (integer) is the only required field on a ControllerRevision.
ControllerRevisions are used by DaemonSet and StatefulSet controllers for update/rollback; Deployments use ReplicaSets for revision tracking instead.
The Cluster Observability Operator introduces its own custom resources (CRDs) and API surface for managing observability configuration.
The Cluster Observability Operator has its own independent versioning separate from the OpenShift platform version.
The Cluster Observability Operator is installed via OLM (Operator Lifecycle Manager) through OperatorHub.
The Cluster Observability Operator (COO) is the central operator for configuring and managing observability features on OCP 4.20+.
The Cluster Observability Operator provides UI plugins that extend the OpenShift web console with observability dashboards and views.
The Cluster Observability Operator (COO) is a separate, optional operator from the built-in Cluster Monitoring Operator (CMO) and is not part of the default OpenShift installation.
The Cluster Observability Operator (COO) is a separate operator that must be explicitly installed; it is not part of the default OpenShift monitoring stack.
The Cluster Observability Operator (COO) is a separately installable operator, not part of the default OpenShift cluster monitoring stack.
The Cluster Observability Operator supports UI plugins that extend the OpenShift web console with observability views and dashboards.
Core v1 resources (Pod, Service, ConfigMap, Secret, Namespace, Node, PV, PVC) have no API group prefix.
CORS additional allowed origins are configured on the apiserver.config.openshift.io/cluster resource via spec.additionalCORSAllowedOrigins, which accepts a list of Golang regular expressions.
The additionalCORSAllowedOrigins setting applies to both the API server and the OAuth server.
By default, only the OpenShift web console hostname is allowed to make cross-origin JavaScript requests to the API server.
Once a ControlPlaneMachineSet state is set to Active, it cannot be made Inactive — the resource must be deleted instead.
The ControlPlaneMachineSet API is machine.openshift.io/v1, while the Machines it manages are machine.openshift.io/v1beta1.
ControlPlaneMachineSet failure domains are supported on AWS, Azure, GCP, OpenStack, vSphere, and Nutanix.
ControlPlaneMachineSet lifecycle hooks: preDrain blocks draining and all subsequent events; preTerminate blocks termination only (actioned after drain completes).
ControlPlaneMachineSet replicas field is immutable after cluster installation and only supports values of 3 or 5.
The ControlPlaneMachineSet selector is immutable after creation and must match template labels.
ControlPlaneMachineSet supports two update strategy types: RollingUpdate (default) and OnDelete.
CPU limits are enforced via throttling (pods are NOT terminated for exceeding CPU); memory limits are enforced via kernel OOM kill.
CPU Manager default policy is none, which uses shared CFS quota scheduling.
CPU Manager static policy grants exclusive CPUs only to Guaranteed QoS pods with integer CPU requests; fractional CPU pods fall back to the shared pool.
Workload partitioning (cpuPartitioningMode: AllNodes) can only be enabled at OpenShift install time and cannot be enabled later.
CRD additionalPrinterColumns requires name, type, and jsonPath fields to customize kubectl get table output.
CRD conversion strategies are None (only changes apiVersion) or Webhook (calls external webhook); webhook requires preserveUnknownFields: false.
Exactly one CRD version must have storage: true; this is the version used when persisting to etcd.
CRDs allow a maximum of 8 selectable fields per version, which must be string, boolean, or integer types.
CRD name must follow the format <plural>.<group> (e.g., crontabs.stable.example.com); this is enforced.
CRD scope can only be Cluster or Namespaced.
The CRD status subresource ensures PUT/POST/PATCH to the main resource ignores .status changes, and PUT to /status ignores everything except .status.
When AWS account has SCPs (Service Control Policies) enabled, credentialsMode must be explicitly set to Mint, Passthrough, or Manual in install-config.yaml.
CredentialsRequest (cloudcredential.openshift.io/v1) is an OpenShift-specific CRD for managing cloud provider credentials, connected to the Cloud Credential Operator (CCO)
CRI-O is the only container engine in OpenShift clusters (not Docker); it can use runC or crun as the container runtime.
CRI-O is the container engine running on every worker and control plane node in OpenShift Container Platform clusters.
CRI-O (not Docker) is the container runtime engine on all OpenShift Container Platform cluster nodes.
CRI-O supports multiple OCI runtimes including runc (default) and kata, allowing per-workload runtime selection.
Job backoffLimit defaults to 6 retries before marking a Job as failed
CronJob is batch/v1 (fully GA since Kubernetes 1.21 / OCP 4.8+), not batch/v1beta1
CronJob concurrencyPolicy defaults to Allow; other values are Forbid (skip if previous running) and Replace (cancel running and start new)
CronJob concurrencyPolicy accepts three values: Allow (default), Forbid, or Replace.
CronJob history limits default to 3 successful jobs (successfulJobsHistoryLimit) and 1 failed job (failedJobsHistoryLimit).
CronJob failedJobsHistoryLimit defaults to 1; successfulJobsHistoryLimit defaults to 3
Setting suspend: true on a CronJob prevents new Jobs from being created but does NOT stop already-running Jobs
CronJob timeZone field uses IANA tz database names; if the timezone becomes invalid, the controller stops creating Jobs and emits an UnknownTimeZone event
ttlSecondsAfterFinished: 0 means the Job is eligible for deletion immediately after finishing
CronJobs may fail to create a job or create duplicates, so jobs must be idempotent.
Cross-project image access is granted by binding system:image-puller role to system:serviceaccount:<project>:<sa> in the target namespace.
CSI controller containers and driver containers communicate via UNIX Domain Sockets — no CSI traffic leaves the pod.
The external CSI controller is a Deployment with 5 containers: snapshotter, resizer, attacher, provisioner, and the CSI driver itself.
CSI controller pods should run on infrastructure nodes to protect storage credentials.
Without the security.openshift.io/csi-ephemeral-volume-profile label on a CSIDriver, the driver defaults to privileged profile, meaning ephemeral volumes only work in privileged namespaces.
CSI inline ephemeral volumes are supported only by Shared Resource, Azure File, and Secrets Store CSI drivers.
CSI automatic migration from in-tree plugins: AWS EBS (OCP 4.12+), Azure Disk (4.11+), Azure File (4.13+), GCE PD (4.14+), vSphere (4.14+).
CSI (Container Storage Interface) is the standard vendor-agnostic API for storage in OCP, replacing in-tree volume plugins.
CSIStorageCapacity is a namespaced resource in the storage.k8s.io/v1 API group.
The nodeTopology field on CSIStorageCapacity is immutable; if unset, storage is inaccessible; if empty, storage is accessible from all nodes.
The storageClassName field on CSIStorageCapacity is required and immutable.
The attachRequired and volumeLifecycleModes fields on CSIDriver are immutable after creation.
The CSIDriver resource (storage.k8s.io/v1) is a cluster-scoped (non-namespaced) Kubernetes object.
The default fsGroupPolicy for CSIDriver is ReadWriteOnceWithFSType — fsGroup is only applied when fstype is defined and access mode is ReadWriteOnce.
CSIDriver supports two volume lifecycle modes: Persistent (default, standard PV/PVC) and Ephemeral (inline volumes tied to pod lifecycle).
The CSINode allocatable.count field sets the maximum number of unique volumes a node can use for a given CSI driver; if unset, it is unbounded.
CSINode objects are automatically created by the kubelet via the node-driver-registrar sidecar — CSI drivers do not create them directly.
CSINode name must match the Kubernetes node name, and the CSINode has an OwnerReference to the corresponding Node object.
The CSINode nodeID field allows Kubernetes to map its node names to storage system node identifiers (e.g., "node1" in Kubernetes maps to "nodeA" in the storage backend).
The CSISnapshotController operator manages CSI volume snapshot functionality and works with VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent resources.
The CSISnapshotController operator resource canonical instance is named cluster in the operator.openshift.io/v1 API group.
CertificateSigningRequests have three signer names: kubernetes.io/kube-apiserver-client-kubelet (kubelet client certs), kubernetes.io/kubelet-serving (kubelet serving TLS certs), and kubernetes.io/kube-apiserver-client (generic API server client certs)
The ClusterServiceVersion (CSV) resource belongs to the operators.coreos.com/v1alpha1 API group.
The CSV install strategy type is typically "deployment", with the install spec containing deployments, permissions, and clusterPermissions.
CSV installModes supports four types: OwnNamespace, SingleNamespace, MultiNamespace, and AllNamespaces.
RBAC rules are embedded in the CSV under spec.install.spec.permissions (namespace-scoped) and spec.install.spec.clusterPermissions (cluster-scoped).
The relatedImages field in a CSV must use digest (SHA) references, not tags — important for disconnected/air-gapped environments.
The CSV replaces field names the CSV version being replaced (establishing upgrade path), while skips allows skipping intermediate versions in the upgrade graph.
The required spec fields for a ClusterServiceVersion are displayName and install; the install block requires a strategy field.
For AllNamespaces install mode, the CSV status shows Succeeded in openshift-operators and Copied in other namespaces.
A ClusterServiceVersion (CSV) in Succeeded phase means the Operator is installed and running
Custom MCPs inherit from the worker pool; non-inheriting custom pools are unsupported by the MCO.
The Custom Metrics Autoscaler Operator is built on KEDA (Kubernetes-based Event Driven Autoscaler) and extends the HPA — it does not replace HPA
The Custom Metrics Autoscaler Operator is an optional, separately installed Operator with its own version lifecycle distinct from core OpenShift
Cluster admins can configure a custom project request template to control default resources (quotas, limit ranges, network policies) provisioned with every new project
The CVO applies release image manifests in separate stages called Runlevels, proceeding only when all manifests and Operators in the active Runlevel reach a stable condition.
The Cluster Version Operator (CVO) comes online during bootstrap and installs the etcd Operator and other cluster components
Two separate Operator management systems exist: the CVO manages cluster Operators (installed by default), and OLM manages add-on Operators (optional, via OperatorHub). OLM does not manage cluster Operators.
DaemonSets belong to the apps/v1 API group (not the deprecated extensions group)
DaemonSet default update strategy is RollingUpdate (not OnDelete); maxSurge defaults to 0, maxUnavailable defaults to 1, and they cannot both be 0
DaemonSet pods get default tolerations for unreachable and not-ready with no tolerationSeconds, meaning they are never evicted.
DaemonSets require disabling the default project node selector (openshift.io/node-selector: "") on the namespace, or pods will be incorrectly scheduled with frequent recreates.
The only allowed restartPolicy for DaemonSet pod templates is "Always"
DaemonSet revisionHistoryLimit defaults to 10
A DaemonSet ensures a Pod runs on every (or selected) node(s) in the cluster.
Updating a DaemonSet pod template does not affect existing pod replicas — old pods must be deleted manually.
DaemonSets ensure a pod runs on every node (or a subset via node labels); used for DNS, monitoring, and similar infrastructure.
DaemonSets ensure a copy of a Pod runs on all (or selected) nodes, commonly used for node-level agents like logging, monitoring, and networking.
The cluster dashboard has five cards: Details, Cluster Inventory, Status, Cluster Utilization, and Activity
The OCP cluster dashboard is accessed at Home → Overview in the web console
Cluster Utilization card tracks five metrics: CPU time, memory, storage, network, and pod count
DataImage is specific to bare-metal provisioning and does not apply to cloud-based or virtualized deployments.
The DataImage resource (metal3.io/v1alpha1) has only one required spec field: url, specifying the data image to attach to a BareMetalHost.
If no triggers are defined on a DeploymentConfig, a ConfigChange trigger is added by default; an empty triggers field (triggers: []) means manual-only deployments.
The default catalog source namespace for OperatorHub catalogs is openshift-marketplace.
OpenShift ships with four default catalog sources: redhat-operators, certified-operators, community-operators, redhat-marketplace
The default cluster network is 10.128.0.0/14 with a /23 host prefix, providing 510 pod IPs per node.
OpenShift ships with default ClusterRoles: admin, edit, view, cluster-admin, and self-provisioner.
Default imagePullPolicy: :latest tag → Always; any other tag → IfNotPresent.
The default maximum number of pods per node in OpenShift is 250.
The two default Machine Config Pools are master and worker; custom MCPs for control plane are not supported.
When a node becomes unreachable, pods are scheduled for eviction after 5 minutes by default (tolerationSeconds=300 added automatically).
Default control plane replicas are 3 (or 1 for single-node OpenShift); default compute replicas are 3 with a minimum of 2.
Enabling defaultRoute on the Image Registry Operator creates an external route with re-encrypt TLS termination.
The default service network is 172.30.0.0/16.
The annotation to mark a StorageClass as default is storageclass.kubernetes.io/is-default-class: "true".
ClusterOperator condition Degraded does not cause workload failure as long as Available is True.
Image stream tags can be deleted with either oc delete istag/<name>:<tag> or oc tag -d <name>:<tag>.
The annotation machine.openshift.io/delete-machine=true marks a specific machine for priority deletion, overriding the MachineSet deletion policy.
Deleting an OAuthAccessToken (oc delete oauthaccesstoken <name>) effectively revokes a user's session.
To fully delete an Operator: delete the Subscription first, then delete the CSV; may also need to clean up CRDs and operand resources
When deleting a user, associated Identity objects may also need to be deleted to fully clean up authentication state.
Deleting an ImageStreamTag resource removes both the spec and status entries for that tag.
In CAP theorem terms, Deployment favors availability (controller manager with leader election); DeploymentConfig favors consistency (deployer pod won't be replaced if node goes down).
Deployment objects use ReplicaSets as building blocks; DeploymentConfig objects use ReplicationControllers.
DeploymentConfig is an OpenShift-specific workload resource deprecated in favor of Kubernetes Deployments starting in OCP 4.14.
DeploymentConfig is deprecated as of OpenShift Container Platform 4.14; Deployment objects should be used for new installations.
DeploymentConfig (apps.openshift.io/v1) is deprecated in favor of Kubernetes Deployments (apps/v1).
DeploymentConfig (apps.openshift.io/v1) is OpenShift-specific and legacy; Deployment (apps/v1) is the standard Kubernetes resource.
DeploymentConfigs and BuildConfigs have image change trigger fields built into their API spec, unlike standard Kubernetes resources which require annotations.
DeploymentConfig is an OpenShift-specific resource distinct from Kubernetes Deployment.
OpenShift DeploymentConfig (now deprecated) used ReplicationControllers internally, while Deployments use ReplicaSets.
DeploymentConfig creates ReplicationControllers for each deployment, whereas Deployment uses ReplicaSets.
DeploymentRequest excludeTriggers field provides fine-grained control over which triggers fire during instantiation, overriding the triggers that latest would otherwise process
You cannot force a deployment on a paused DeploymentConfig — DeploymentRequest returns an Invalid error
DeploymentRequest (apps.openshift.io/v1) is OpenShift-specific, not part of upstream Kubernetes; it triggers deployments via the instantiate subresource of DeploymentConfig
DeploymentRequest required fields are name, latest, and force; the endpoint is POST /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/instantiate
The descheduler only evicts pods; it does not schedule replacement pods — the scheduler handles rescheduling.
The descheduler cannot evict pods in openshift-* or kube-system namespaces, nor static pods, mirror pods, stand-alone pods, or DaemonSet pods.
Red Hat OpenShift Dev Spaces is Red Hat's productized, supported distribution of Eclipse Che, providing browser-based containerized development environments on OpenShift.
OpenShift Dev Spaces has its own version numbering (3.x) independent of OpenShift Container Platform versions.
Dev Spaces workspace configurations use the devfile specification.
Developer Preview is unsupported and opt-in (may render cluster unsupportable, can be removed at any time); Technology Preview is partially supported but not production-ready.
Disabling all default catalog sources: oc patch operatorhub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Disaster recovery is the deepest point of topology divergence in the otherwise unified platform model: standalone clusters use etcd snapshot/restore, hosted control planes require separate encryption key backup and etcdutl (not etcdctl), and SNO accepts downtime — contradicting the platform's goal of operational uniformity across topologies
Disaster recovery and normal operations share the same immutability enforcement: etcd backup/restore operates under version governance (no rollback, forward-only) while node configuration flows exclusively through the MCO pipeline — both prohibit direct manipulation, making the immutable delivery model the universal access pattern.
Disaster recovery procedures diverge across topologies: standalone clusters use etcd snapshot/restore via oc debug+chroot under version governance, while hosted control planes require separately-saved encryption keys and use etcdutl (not etcdctl) with --skip-hash-check — but both share the same irreversibility constraint that backup is last-resort, not rollback.
Disaster recovery is constrained by the same version governance that controls normal operations: etcd backup/restore is last-resort only (not rollback), rollback is unsupported, and version coupling (OCP→CNV→HCP ordering) means a restore to a prior state may create version mismatches that cannot be corrected — making prevention through proper update governance critical.
Disconnected (air-gapped) OpenShift clusters require a specialized content delivery pipeline: oc-mirror generates IDMS manifests for image mirroring, the installer must be extracted from mirrored content, FBC catalogs replace registry-dependent SQLite catalogs, and MCO applies registry configuration to nodes — creating an end-to-end offline supply chain from operator catalogs through node configuration.
Both initial installation and day-2 operations (updates, operator installation) require mirrored content in disconnected environments
In disconnected environments, ImageContentSourcePolicy (ICSP) or ImageDigestMirrorSet (IDMS) redirect image pulls to a mirror registry
oc-mirror or oc adm catalog mirror are used to populate a local registry with required images for disconnected installations
In disconnected installations, the Cluster Samples Operator defaults to Removed status; it must be set to Managed to install image streams.
Disk encryption with TPM in OCP uses PCR 1 (UEFI state) and PCR 7 (secure boot state) to bind encryption keys; this is a Technology Preview feature.
OpenShift distributed tracing is backed by Red Hat OpenShift distributed tracing platform (based on Jaeger/Tempo) and the OpenTelemetry Collector
Distributed tracing in OpenShift is a configurable platform feature that is not enabled by default — it requires operator installation and configuration
Distributed tracing provides three key capabilities: store, analyze, and visualize transaction data across microservices
The DNS config fields baseDomain, publicZone, and privateZone are immutable after initial creation.
DNS TLS CA bundle ConfigMaps must be in openshift-config namespace with key ca-bundle.crt (PEM encoded).
Default DNS cache TTLs are positive = 900 seconds (15 minutes) and negative = 30 seconds.
Default DNS cache TTLs are positiveTTL=900s and negativeTTL=30s when fields are omitted.
The cluster domain (e.g., cluster.local) cannot be specified as a zone in .spec.servers.
The cluster DNS IP is the 10th address in the service CIDR range (e.g., 172.30.0.10 for 172.30.0.0/16).
cluster.local cannot be used as a forwarding zone in spec.servers.zones.
The DNS config object uses API group config.openshift.io/v1, distinct from the DNS operator object under operator.openshift.io.
Removing the default node-role.kubernetes.io/master toleration from DNS pods risks cluster DNS outage if all worker nodes go down.
DNS forward policy defaults differ: Random for .spec.servers entries, Sequential for .spec.upstreamResolvers.
DNS forward policy defaults differ: Random for spec.servers, Sequential for spec.upstreamResolvers.
Maximum of 15 upstreams per forwardPlugin in DNS forwarding configuration.
If publicZone is nil on the DNS config, no public DNS records are created (relevant for private/disconnected clusters).
The node-resolver DaemonSet adds an entry for image-registry.openshift-image-registry.svc to /etc/hosts on every node so the container runtime can resolve the image registry.
The DNS Operator deploys CoreDNS as a DaemonSet on all nodes with default domain cluster.local.
The DNS Operator deploys CoreDNS as a DaemonSet (not a Deployment) in the openshift-dns namespace.
The DNS Operator (operator.openshift.io/v1) manages CoreDNS as the cluster-wide name resolution service in OpenShift.
The DNS Operator runs in the openshift-dns-operator namespace; CoreDNS pods run in openshift-dns.
DNS-over-TLS uses port 853 by default (per RFC 7858) and requires the serverName field to be set.
The DNS config spec.platform currently only supports AWS as a named platform type, with privateZoneIAMRole for cross-account DNS management.
OpenShift DNS follows a deterministic architecture: CoreDNS runs as a DaemonSet (not Deployment) managed by the DNS Operator, the cluster DNS IP is algorithmically derived as the 10th address in the service CIDR, cluster.local is reserved and cannot be used as a forwarding zone, and the full cluster DNS name follows <metadata.name>.<baseDomain> — making DNS both predictable and constrained.
Setting DNS Operator managementState to Unmanaged blocks cluster upgrades.
DNSRecord default TTL is 30 seconds when recordTTL is set to zero; on AWS, TTL is ignored for Alias targets but applies to CNAME targets.
The DNSRecord resource (ingress.operator.openshift.io/v1) is an internal operator resource not intended for cluster admin manipulation.
The DNSRecord resource is namespaced, not cluster-scoped.
The dnsManagementPolicy field on DNSRecord controls whether the ingress operator manages DNS records; valid values are Managed (default) and Unmanaged.
NetworkAttachmentDefinition CRs managed by the Cluster Network Operator must not be manually edited
Administrators should not directly modify the ClusterVersion object — use oc CLI or web console instead.
Docker as a container runtime is deprecated in Kubernetes 1.20, but Docker-built images still work with all container runtimes including CRI-O.
Docker strategy builds require elevated privileges and may be restricted in multi-tenant clusters.
In Image objects, dockerImageManifests[] and dockerImageLayers[] are mutually exclusive — manifest lists vs single images
1Gi hugepages require kernel arguments: default_hugepagesz=1GB, hugepagesz=1G, hugepages=16
For DPDK workloads, Intel NICs use deviceType: vfio-pci (vendor 8086) while Mellanox NICs use deviceType: netdevice with isRdma: true (vendor 15b3)
DPDK/RDMA pods require three security capabilities: IPCLOCK, SYSRESOURCE, and NET_RAW
DPDK applications require hugepages (2Mi or 1Gi, mounted as emptyDir with medium HugePages) and exclusive CPUs via kubelet's static CPU Manager policy (set equal requests and limits for Guaranteed QoS)
oc adm drain requires --ignore-daemonsets=true when DaemonSet-managed pods exist on the node.
In dual-stack configurations, IPv4 and IPv6 addresses must be listed in the same order across all network parameters (clusterNetwork, serviceNetwork, machineNetwork).
OpenShift supports dual-stack IPv4+IPv6 addressing but with constraints: OVN-Kubernetes allows only a single service network block, UDN has specific MTU minimums per IP family, and OpenShift Virtualization cannot run on single-stack IPv6.
Dual-stack networking requires both IP families (IPv4 and IPv6) to use the same network interface for the default gateway.
Users can disable console plugins via the disable-plugins query parameter in the browser URL
Dynamic plugins are enabled/disabled by cluster admins via Administration → Cluster Settings → Configuration → Console (operator.openshift.io)
Dynamic plugins are deployed via Helm using helm upgrade -i <name> charts/openshift-console-plugin -n <namespace> --create-namespace --set plugin.image=<image>
Dynamic plugin i18n namespace must be prefixed with plugin__ and match the ConsolePlugin resource name
Custom dynamic plugin code is not supported by Red Hat — only cooperative community support is available
Dynamic plugins require PatternFly 4.x for OCP ≤4.14 and PatternFly 5.x for OCP ≥4.15
The proxy authorization field in a ConsolePlugin CR accepts values UserToken (forwards user's OCP token) or None
Service proxy endpoint for dynamic plugins follows the pattern /api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>
Dynamically provisioned volumes always use the Delete reclaim policy.
Dynamic provisioning requires a StorageClass — it creates PVs on-demand, eliminating the need for admin pre-provisioning.
Dynamically provisioned persistent volumes always use the Delete reclaim policy.
The eBPF agent operates at OSI layers 3-4 and cannot capture traffic on layer-2-only bridge interfaces like br-int or br-ex
The eBPF Manager Operator uses the alpha channel from the community-operators catalog source.
The eBPF Manager Operator is installed in the bpfman namespace with privileged pod security enforcement.
The eBPF Manager Operator is a Technology Preview feature — not supported for production use.
Applications access eBPF maps via CSI volume mounts, so application pods do not need privileged access.
eBPF programs managed by the eBPF Manager Operator are packaged as OCI container images.
Edge compute pool nodes (Local Zones / Wavelength Zones) have a NoSchedule taint by default; workloads require explicit tolerations.
Edge computing is a first-class deployment model in OpenShift Container Platform with dedicated documentation, tooling, and specialized topologies.
Edge computing in OpenShift targets far-edge use cases (e.g., cell towers, retail locations, industrial sites), not near-edge or regional data centers.
Edge fleet deployments combine ZTP provisioning with disconnected content delivery: ZTP/GitOps provisions clusters at scale while oc-mirror/IDMS/FBC pipelines deliver images and operators without direct registry access, creating a fully autonomous edge lifecycle from provisioning through software delivery.
Edge cluster lifecycle follows a managed pipeline: ZTP with GitOps provisions fleets at scale, TALM orchestrates updates with canary-first failure-gating, SNO provides the minimal topology, and vDU workloads require specific BIOS-level firmware constraints — creating an end-to-end edge operations model.
Edge routes provide TLS termination at the router level (HAProxy Ingress Controller). Created with oc create route edge <name> --service=<service>.
Default EBS volume type for AWS Local Zone and Wavelength Zone compute pools is gp2, unlike non-edge compute pools.
EgressFirewall default behavior is allow — without an EgressFirewall or when no rule matches, all egress traffic is permitted
EgressFirewall dnsName wildcards match only one label level — *.example.com matches sub1.example.com but not sub2.sub1.example.com
EgressFirewall is namespace-scoped (not cluster-scoped) and uses the k8s.ovn.org/v1 API group (OVN-Kubernetes specific)
EgressFirewall rules are evaluated in order (first match wins) with three mutually exclusive destination selectors: cidrSelector, dnsName, or nodeSelector
EgressFirewall supports three protocols for port filtering: tcp, udp, and sctp
The EgressFirewall CR uses the API group k8s.ovn.org/v1 in OVN-Kubernetes.
A broken EgressFirewall configuration causes all external traffic to be dropped.
Only cluster administrators can create, edit, or delete EgressFirewall resources.
EgressFirewall default behavior is allow when no rule matches or no EgressFirewall exists; rules are evaluated in order (first match wins)
A deny-all rule (0.0.0.0/0) in EgressFirewall blocks API server access; API server IPs must be explicitly allowed.
DNS-based EgressFirewall rules poll for IP changes based on TTL with a default interval of 30 minutes.
EgressFirewall rules can filter outbound traffic by DNS name, IP address, or CIDR range.
EgressFirewall rules are evaluated in order; the first matching rule wins and subsequent rules are ignored for that connection.
Pods with host networking enabled are not affected by EgressFirewall rules.
Maximum of 8,000 rules per EgressFirewall object.
Only one EgressFirewall custom resource is allowed per namespace when using OVN-Kubernetes.
Only one EgressFirewall CR is allowed per project, and it must be named default.
EgressFirewall requires the OVN-Kubernetes network plugin (API group k8s.ovn.org/v1).
Traffic going through OpenShift Routes bypasses EgressFirewall rules; users with Route CR permissions can bypass restrictions.
EgressIP uses API group k8s.ovn.org/v1 and is specific to the OVN-Kubernetes network plugin
EgressIP is a cluster-scoped resource (not namespaced)
EgressIP supports dual-stack with both IPv4 and IPv6 addresses in the same resource
EgressIP (k8s.ovn.org/v1) provides a fixed source IP for egress traffic from matching pods
When EgressIP podSelector is omitted, the egress IP applies to all pods in matched namespaces
EgressIP requires both spec.egressIPs (list of IPs) and spec.namespaceSelector in the spec; podSelector is optional
When both namespaceSelector and podSelector are set on an EgressIP, they are intersected — pods must match both
EgressIP .status.items[] is read-only and shows the node-to-IP mapping for assigned egress IPs
EgressQoS assigns DSCP (Differentiated Services Code Point) values to egress traffic from pods for QoS differentiation
In each EgressQoS rule, dscp is the only required field; dstCIDR and podSelector are optional
EgressQoS is a namespace-scoped resource in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes
When dstCIDR is omitted from an EgressQoS rule, the DSCP marking applies to all egress traffic regardless of destination
EgressQoS traffic is checked against rules in order; matching traffic gets the DSCP value from the first matching rule
EgressRouter uses API group network.operator.openshift.io/v1 and is managed by the Cluster Network Operator
Creating an EgressRouter CR automatically creates three resources with the same name: a Service, a Pod, and a NetworkAttachmentDefinition (NAD)
EgressRouter macvlan default mode is Bridge; the master interface is optional if inferable from the IP
If EgressRouter has redirect rules but no fallbackIP, connections on undefined ports are rejected
EgressRouter only supports mode Redirect (DNAT-based) and only supports macvlan as the network interface type
EgressRouter redirect rules support TCP, UDP, and SCTP protocols; targetPort defaults to port if omitted
When EgressService sourceIPBy=LoadBalancerIP, traffic is pinned to a single node shown in .status.host; when sourceIPBy=Network, status host is "ALL"
EgressService (k8s.ovn.org/v1) makes egress source IP equal to the LoadBalancer Service's ingress IP
EgressService network field enables routing egress through an alternate network/VRF rather than the default routing table
EgressService nodeSelector field only applies when sourceIPBy=LoadBalancerIP
EgressService is a namespaced CRD in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes
EgressService sourceIPBy has two modes: LoadBalancerIP (uses LB ingress IP as source) and Network (uses node interface IP)
EmptyDir volume usage counts toward the pod's overall ephemeral storage consumption and limits.
The default external route for the registry is enabled with oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'.
OpenShift enforces encryption at multiple layers: four TLS security profile types (Old/Intermediate/Modern/Custom) govern API and route encryption, IPsec uses AES-GCM-16-256 in Transport mode for pod-to-pod encryption on OVN-Kubernetes, and SAN fields are mandatory in HTTPS certificates since OCP 4.10 — creating defense-in-depth from certificate validation through transport encryption.
End users access images via ImageStreamTags or ImageStreamImages, not the Image resource directly.
End users should access images through ImageStreamTag or ImageStreamImage resources, not directly through Image resources (which are for cluster admins and integrations)
End users create projects via the ProjectRequest resource (oc new-project), not by directly creating Project objects
Endpoints objects are automatically created with the same name as the Service when the Service has a selector
The expanded endpoint set within a subset is the Cartesian product of Addresses × Ports
Endpoints are namespaced core v1 objects at API path /api/v1/
Endpoint addresses cannot use loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast (224.0.0.0/24) IP ranges
Manual Endpoints (Service with no selector) allow routing to external IPs or other namespaces
Addresses in notReadyAddresses have failed health checks or are still starting and are excluded from load balancing
EndpointPort protocol defaults to TCP; valid values are TCP, UDP, and SCTP
EndpointSlice addressType field is immutable after creation and supports three values: IPv4, IPv6, FQDN
EndpointSlice belongs to API group discovery.k8s.io/v1, not the v1 core API group
The default port protocol for EndpointSlice ports is TCP; supported protocols are TCP, UDP, and SCTP
Each EndpointSlice can hold a maximum of 1000 endpoints and 100 ports
A nil ready condition on an EndpointSlice endpoint should be interpreted as ready by consumers
EndpointSlice endpoints track three conditions: ready (prepared to receive traffic), serving (like ready but remains true during termination), and terminating (endpoint is shutting down)
Ephemeral containers are added to running pods via the ephemeralcontainers subresource for debugging — they cannot be specified at pod creation
Ephemeral containers are added to running pods via the ephemeralcontainers subresource, not by updating the pod spec directly.
Ephemeral storage is a best-effort resource — pods cannot detect available local storage or request guaranteed local storage.
Pod-level ephemeral storage limit equals the sum of all container limits in the pod; pod-level request equals the sum of all container requests.
The ephemeral storage root partition default path is /var/lib/kubelet/ and /var/log/; it holds emptyDir volumes, container logs, image layers, and writable layers.
Ephemeral storage unit suffixes are case-sensitive: M = megabytes, Mi = mebibytes, m = millibytes (0.001 bytes).
The /etc/passwd file must not exist in the container image because CRI-O injects random UIDs into it at runtime
The PVC for automated etcd backups must be in the openshift-etcd namespace.
Automated etcd backup retention types are RetentionNumber (default: 15 backups) or RetentionSize.
etcd must be backed up before shutting down a cluster.
etcd backup must be taken from only one control plane host, not from each control plane host.
etcd backup/restore is a last-resort disaster recovery mechanism, not a rollback mechanism — rolling back to a previous OCP version is not supported.
etcd backup and restore is the primary mechanism for cluster-level disaster recovery in OpenShift.
etcd backup produces two files: snapshot<datetimestamp>.db (the etcd snapshot) and statickuberesources_<datetimestamp>.tar.gz (static pod resources and encryption keys if enabled).
To run the etcd backup, you must first oc debug --as-root node/<node> then chroot /host before executing the backup script.
The etcd backup script is located at /usr/local/bin/cluster-backup.sh and is maintained by the etcd Cluster Operator.
etcd backup is separate from OADP and uses its own backup/restore mechanism; etcd backup is the fundamental cluster-level backup in OpenShift.
The Etcd operator controlPlaneHardwareSpeed field with value Slower tunes etcd for environments with higher network latency between control plane nodes.
Etcd operator default revision limits (both failedRevisionLimit and succeededRevisionLimit) are 5 when set to 0 or unset; -1 means unlimited.
etcd backup/restore is a last-resort disaster recovery mechanism (not rollback) that requires privileged access via oc debug + chroot, and must not be confused with routine operations — direct etcd access outside documented procedures is unsupported.
etcd encryption covers Secrets, ConfigMaps, Routes, OAuth access tokens, and OAuth authorize tokens; only values are encrypted, not keys (resource types, namespaces, object names remain unencrypted).
etcd encryption only encrypts values, not keys — resource types, namespaces, and object names remain unencrypted.
etcd encryption keys are rotated automatically on a weekly basis for both AES-GCM and AES-CBC encryption types.
OpenShift does not encrypt etcd data by default; encryption must be explicitly enabled via the APIServer custom resource.
etcd encryption supports three types: aesgcm (AES-GCM), aescbc (AES-CBC), and identity (no encryption/default); configured via spec.encryption.type on the APIServer resource.
etcd encryption completion must be verified on three separate API servers: openshiftapiserver, kubeapiserver, and authentication.operator.openshift.io.
The Nova ephemeral disk for etcd requires a minimum of 10 GB per control plane node.
Nova ephemeral storage for etcd must use a local storage backend, not rbd.
The ephemeral disk for etcd is formatted as XFS with label local-etcd and mounted with defaults,prjquota options.
The forceRedeploymentReason field on the Etcd CR is the mechanism to force redeployment of a previously failed static pod revision using a unique string.
Moving etcd from Cinder-backed root volume to Nova ephemeral local disk is a day-2 operation on RHOSP to resolve latency-sensitive etcd performance issues.
The MachineConfig 98-var-lib-etcd creates four systemd units: var-lib-etcd.mount, create-local-etcd.service, migrate-to-local-etcd.service, and relabel-var-lib-etcd.service.
The 98-var-lib-etcd MachineConfig must never be removed while ephemeral disks are in use — doing so breaks etcd and causes system instability.
Do not take an etcd backup before the first certificate rotation (24 hours after install) because the backup will contain expired certificates.
etcd is the primary datastore for OpenShift cluster state.
etcd requires a quorum (majority) of members to function; a 3-node control plane tolerates 1 etcd member failure, a 5-node control plane tolerates 2 failures.
The etcd Operator uses a preDrain lifecycle hook (named EtcdQuorumOperator, owner clusteroperator/etcd) to protect quorum during control plane machine replacement by waiting for a replacement node to join and sync.
etcd is the primary data store for Kubernetes and requires fast, low-latency I/O due to high-frequency small writes.
Restoring from an etcd backup requires a backup from the same z-stream release (e.g., 4.17.5 backup for a 4.17.5 cluster).
To roll back the etcd local disk migration, modify the ControlPlaneMachineSet to use a flavor without ephemeral disks, and only remove the MachineConfig after the CPMS update completes.
Etcd runs as static pods on control plane nodes, managed by the etcd operator with a revision-based deployment model tracked per node.
etcd runs exclusively on control plane (master) nodes as static pods managed by the cluster etcd operator.
etcd is the sole persistent key-value store for all Kubernetes and OpenShift cluster objects and configuration.
etcd stores cluster state data; kube-scheduler allocates pods to nodes; kube-controller-manager governs cluster state.
Extended Update Support (EUS) was extended to IBM Power and IBM Z platforms starting with OCP 4.14.
Events use API group events.k8s.io/v1 (distinct from the older v1 core Events).
eventTime (MicroTime) is the only required field on an Event (besides standard metadata).
Events are namespaced resources but can be listed cluster-wide via /api/v1/events or oc get events -A.
Event objects require metadata and involvedObject fields; involvedObject uses an ObjectReference structure.
The Event type field has two standard values: Normal and Warning.
Event type values are Normal and Warning; new types may be added in the future.
Kubernetes Events (v1) have limited retention time and are automatically garbage-collected; they should not be relied upon as a reliable audit log.
Events have limited retention and are best-effort supplemental data; they should not be relied upon for persistent state or decision-making.
Events are namespaced resources.
Both Eviction and PodDisruptionBudget belong to the policy/v1 API group (stable/GA).
The Eviction resource uses API group policy/v1 (stable), replacing the deprecated policy/v1beta1.
The fieldValidation parameter defaults to Warn in Kubernetes v1.23+ (relevant for OCP 4.x which is based on K8s 1.24+).
Eviction is a subresource of Pod, created by POSTing to /api/v1/namespaces/{namespace}/pods/{pod-name}/eviction, not a standalone top-level resource.
Eviction respects PodDisruptionBudgets (PDBs); direct pod deletion does not.
Eviction is a subresource of Pod accessed via POST /api/v1/namespaces/{namespace}/pods/{name}/eviction, not a top-level resource.
The annotation machine.openshift.io/exclude-node-draining on a machine skips the node drain step during deletion.
If Ignition certificates expire, recovery requires manually approving pending node-bootstrapper CSRs to restore kubelet certificates
Expired silences in Alertmanager cannot be deleted manually and are garbage collected after 120 hours.
Multiple OpenShift subsystems follow a common pattern where capability beyond the default platform requires explicit, multi-component enablement: service mesh needs multiple operators (mesh + Kiali + tracing) with multi-tenant SMCP, while observability requires separate admin action for user workload monitoring and distributed tracing — neither is automatic despite being platform-integrated.
All six Extension API types belong to one of three API groups: apiregistration.k8s.io/v1, apiextensions.k8s.io/v1, or admissionregistration.k8s.io/v1.
AWS credentials for the External DNS Operator come from the aws-creds secret in the kube-system namespace.
AWS GovCloud with STS-enabled clusters is not supported by the External DNS Operator.
The External DNS Operator subscription uses channel stable-v1 from the redhat-operators catalog source.
External DNS domain name length limits due to TXT registry prefix: CNAME max 44 chars, A record max 48 chars.
The External DNS Operator is installed into the external-dns-operator namespace.
The External DNS Operator supports x86_64 architecture only.
The External DNS Operator supports two source types: Service and OpenShiftRoute.
externalIP.autoAssignCIDRs is primarily useful for bare-metal clusters
externalIP.policy.rejectedCIDRs takes precedence over allowedCIDRs; if externalIP is nil, ExternalIP cannot be set on Services
In disconnected installs, the installer must be extracted from mirrored content using oc adm release extract --command=openshift-install to ensure version correctness.
The factory-precaching-cli tool (in quay.io/openshift-kni/telco-ran-tools:latest) is Technology Preview — not supported under production SLAs.
Bundle images and metadata in FBC are immutable; broken bundles require releasing a new bundle with an upgrade edge rather than in-place fixes
File-based catalogs (FBC) in JSON/YAML are the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.
File-based catalogs (FBC) became the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.
The olm.deprecations schema defines deprecation info for packages, bundles, and channels, surfacing PackageDeprecated, ChannelDeprecated, and BundleDeprecated status conditions
File-based catalogs (FBC) use plain-text JSON or YAML declarative configuration, replacing the older SQLite database format
File-based catalogs replaced SQLite as the default since OCP 4.11, with opm validate for integrity checking and skipRange for update graph pruning — representing the modern catalog management model.
Each FBC package requires exactly one olm.package blob, at least one olm.channel, and one or more olm.bundle blobs
Using skipRange in FBC channel entries prunes skipped versions from the update graph, making them uninstallable; combine skipRange with replaces to preserve incremental upgrade paths
File-based catalogs require three schema types per package: olm.package (exactly one), olm.channel (at least one), and olm.bundle (one or more).
File-based catalogs use three schemas: olm.package (exactly one per package), olm.channel (at least one per package), and olm.bundle (one or more per package).
Setting featureSet to CustomNoUpgrade on the FeatureGate resource is unsupported, irreversible, and blocks cluster upgrades.
The default featureSet on the FeatureGate resource is empty (no value), which applies the standard feature set.
Operators must read .status.featureGates (not .spec) to determine which features are active for their managed version.
Events can be filtered by involved object using field selectors: oc get events --field-selector involvedObject.name=<pod-name>.
The fieldValidation query parameter default changed from Ignore to Warn in Kubernetes v1.23.
Kubernetes fieldValidation parameter default changed from Ignore (pre-v1.23) to Warn (v1.23+); Strict rejects unknown or duplicate fields
The fieldValidation parameter default changed at Kubernetes v1.23: prior to v1.23 it defaults to Ignore, v1.23+ defaults to Warn.
The fieldValidation parameter default changed at Kubernetes v1.23: before v1.23 it was Ignore, from v1.23+ it is Warn.
The fieldValidation default changed from Ignore (pre-v1.23) to Warn (v1.23+) for Kubernetes API requests.
The fieldValidation parameter default changed at Kubernetes v1.23 from Ignore to Warn
The fieldValidation query parameter defaults to Ignore before Kubernetes v1.23 and Warn in v1.23+; Strict rejects requests with unknown or duplicate fields.
The fieldValidation parameter defaults to Ignore (silently drop unknown fields) before Kubernetes v1.23, and Warn (warn on unknown/duplicate fields) from v1.23 onward; Strict rejects requests with unknown or duplicate fields.
The fieldValidation=Strict query parameter on OpenShift/Kubernetes API requests rejects requests containing unknown or duplicate fields; default changed to Warn in v1.23+.
Setting fieldValidation=Strict on API requests rejects requests with unknown or duplicate fields; default since v1.23 is Warn
The fieldValidation query parameter default changed at Kubernetes v1.23 from Ignore to Warn.
The fieldValidation parameter defaults to Ignore prior to Kubernetes v1.23 and Warn in v1.23+.
The fieldValidation query parameter defaults to Warn in Kubernetes v1.23+, replacing the previous Ignore default; Strict rejects requests with unknown or duplicate fields.
Kubernetes API fieldValidation query parameter supports three modes: Ignore (pre-v1.23 default), Warn (v1.23+ default), and Strict (rejects unknown/duplicate fields).
File-based catalogs (FBC) using JSON/YAML format replace the deprecated SQLite catalog format; built with opm render, opm validate, and opm init
File-system-based volume expansion (EBS, GCE, Cinder) requires a pod restart to complete the filesystem resize on the node.
The FileSystemResizePending condition on a PVC indicates the backend volume resize is complete but the filesystem has not yet been resized; it clears once a pod mounts the volume.
The File Integrity Operator ships a default PrometheusRule alert NodeHasIntegrityFailure that fires a warning after 1 second of integrity failure on a node.
The File Integrity Operator config.maxBackups defaults to 5, controlling how many AIDE database and log backups are kept on each node after re-initialization.
The File Integrity Operator installs into the openshift-file-integrity namespace and requires the pod-security.kubernetes.io/enforce: privileged label in OCP 4.17+.
The File Integrity Operator is not supported on Hosted Control Planes (HCP) clusters.
The annotation file-integrity.openshift.io/re-init-on-failed= on a FileIntegrity CR reinitializes the AIDE database baseline on only failed nodes.
The File Integrity Operator uses AIDE (Advanced Intrusion Detection Environment) deployed as a DaemonSet running privileged containers on each matching node.
FIPS compliance in OpenShift is a cross-cutting constraint spanning three dimensions: install-time (must install from a FIPS-enabled RHEL machine), runtime (CRI-O propagates FIPS awareness to containers, SSH keys restricted to RSA/ECDSA), and architecture (validated only on x86_64, ppc64le, s390x — not ARM)
Enabling FIPS mode for OpenShift installation requires running the installer from a RHEL machine already in FIPS mode.
FIPS mode for OCP installation requires the installer to run from a FIPS-enabled RHEL machine.
FIPS 140-2/140-3 validation applies to x86_64, ppc64le, and s390x architectures, and must be installed from a FIPS-enabled RHEL machine.
FirmwareSchema (metal3.io/v1alpha1) defines the schema for bare-metal firmware settings, including attribute types (Enumeration, Integer, String), allowable values, range bounds, and read-only flags.
The only required field in FirmwareSchema .spec is schema, which maps firmware setting names to their schema definitions.
FlexVolume plugins are not supported on control plane nodes.
Default eBPF sampling rate is 50 (1-in-50 flows captured); value of 0 or 1 captures all flows
FlowCollector supports two deployment models: Service (direct, default) and Kafka (high-throughput/low-latency)
eBPF is the only supported agent type for flow collection in the Network Observability Operator (spec.agent.type: EBPF)
FlowCollector exporters support Kafka, IPFIX, and OpenTelemetry simultaneously for enriched flow data export
Kafka TLS certificates must be available in both netobserv (processor) and netobserv-privileged (eBPF agents) namespaces
The FlowCollector custom resource must be named cluster and only one instance is allowed per cluster
The FlowCollector custom resource is always named cluster and lives in the netobserv namespace
FlowCollector quick filter negation uses ! appended to the key name (e.g., src_namespace!)
The FlowCollector custom resource is a singleton that must be named cluster
Running Network Observability without Loki saves 20–65% memory and 10–30% CPU by relying on Prometheus only
FlowDirection field values: 0=Ingress, 1=Egress, 2=Inner (same source and destination node)
The FlowMetric custom resource uses API group flows.netobserv.io/v1alpha1
When FlowMetric valueField is left empty, the metric counts flows rather than summing a specific field value
FlowMetric resources must be created in the namespace defined in FlowCollector spec.namespace (default: netobserv)
FlowMetric-generated metrics are automatically prefixed with netobserv_ in Prometheus
FlowMetric labels should prefer SrcK8SOwnerName/DstK8SOwnerName over SrcK8SName/DstK8SName to reduce Prometheus cardinality
FlowMetric supports three metric types: Counter (rates), Histogram (sampled values like latencies), and Gauge (point-in-time values)
FlowSchema belongs to API group flowcontrol.apiserver.k8s.io/v1 and is a cluster-scoped resource.
FlowSchema distinguisher method type is either ByUser or ByNamespace, determining how flows within the schema are separated.
FlowSchema matchingPrecedence defaults to 1000 with valid range [1, 10000]; lower numeric value means higher logical priority (matched first).
FlowSchema and PriorityLevelConfiguration work together as the API Priority and Fairness (APF) system, which replaced max-in-flight request handling for the API server.
priorityLevelConfiguration is the only required field in FlowSchema .spec, referencing the PriorityLevelConfiguration that controls queuing and concurrency limits for matched requests.
A FlowSchema rule matches a request only if both a subject matches (User, Group, or ServiceAccount) and a resource or non-resource rule matches.
The forceRedeploymentReason field requires a unique string each time to trigger a new static pod rollout
OCP provides forward compatibility only — applications built for 4.14 are not guaranteed to work on 4.13.
When fsGroup is specified in a pod's securityContext, Kubernetes changes ownership of volume files to the specified GID and sets the setgid bit on directories.
GCE Persistent Disk supports a maximum of 128 PDs per node (127 usable, 1 reserved for root).
GCE Persistent Disk provisioner types are pd-standard (default) and pd-ssd.
GCP KMS key location in ClusterCSIDriver defaults to "global" if not set.
Setting the generation field to 0 on an image stream tag resets it to the latest stream generation, triggering a fresh re-import
Users creating pods with generic ephemeral volumes can indirectly create PVCs even without explicit PVC create permissions — cluster admins should use admission webhooks to restrict this.
Generic ephemeral volumes do not support offline snapshotting and resizing; Azure Disk CSI has no resize support and Cinder CSI has no snapshot support for ephemeral volumes.
The pod is the owner of auto-created ephemeral volume PVCs; Kubernetes garbage collector handles cleanup when the pod is deleted.
Generic ephemeral volume PVCs are named <pod-name>-<volume-name>; naming collisions in the same namespace can prevent pods from starting.
Generic ephemeral volumes are defined under volumes[].ephemeral.volumeClaimTemplate in the pod spec and follow the pod lifecycle (created/deleted with the pod).
WaitForFirstConsumer volume binding mode is recommended for generic ephemeral volumes so the scheduler can pick an appropriate node.
The command to retrieve the cluster infrastructure ID is oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster.
The Argo CD Agent architecture enables agent-based GitOps communication between a control plane and remote workload clusters for multi-cluster synchronization.
ApplicationSets can be managed in non-control-plane namespaces in OpenShift GitOps.
Argo Rollouts provides progressive delivery (canary, blue-green deployments) integrated into the OpenShift GitOps workflow.
Red Hat OpenShift GitOps is built on Argo CD and installed as an Operator via OLM.
The GitOps CLI tool for OpenShift is the argocd binary, not a separate Red Hat-specific binary.
In GitOps workflows, Git repositories serve as the single source of truth for declarative infrastructure and application configuration, and an agent reconciles the live cluster to match.
OpenShift GitOps (Argo CD) handles continuous deployment (CD), while OpenShift Pipelines (Tekton) handles continuous integration (CI).
OpenShift GitOps control plane workloads can run on infrastructure nodes, avoiding worker entitlement consumption.
OpenShift GitOps is installed via OperatorHub as an Operator managed by OLM.
OpenShift GitOps supports multicluster declarative continuous deployment across OpenShift and Kubernetes clusters, managing both infrastructure and application configuration.
OpenShift GitOps supports multicluster OpenShift and Kubernetes infrastructure management.
OpenShift GitOps is an Operator that must be installed separately — it is not a built-in platform component.
OpenShift GitOps is an Operator built on Argo CD that provides declarative GitOps workflows for Kubernetes-based infrastructure and applications.
OpenShift GitOps releases on a different cadence from OpenShift Container Platform itself.
Argo CD applications can be created via the Argo CD dashboard, the oc CLI, or the argocd GitOps CLI.
GitOps ZTP is the Red Hat-recommended approach for provisioning and managing edge clusters at scale in OpenShift.
GitOps ZTP can be updated independently from the hub cluster, RHACM, and managed OpenShift clusters.
The end-to-end image supply chain (build→ImageStream→registry for apps, FBC→OLM→CSV for operators) operates entirely within OpenShift's governance model: identity management controls who can push/pull/prune images, RBAC governs ImageStream access via get-layers permissions, and namespace-scoped quotas constrain resource consumption — making image delivery a governed pipeline, not an open one.
OpenShift governance operates across three reinforcing layers: identity management (OAuth → User → Identity chain), resource access control (dual auth systems + quota enforcement), and namespace provisioning (self-service with admin disable controls and custom templates), ensuring no resource is accessible without passing through all three gates.
Both application images and operator packages flow through governed supply chains (build→ImageStream→registry and FBC→OLM→CSV respectively) that terminate in an immutable node platform managed by singleton operators — no software executes without passing through a managed pipeline.
GPU support in OpenShift requires installing a GPU Operator; it is not built into the platform by default.
GPU Operators are installed via the Operator Lifecycle Manager (OLM).
GPU workloads use extended resource requests (e.g., nvidia.com/gpu) for pod scheduling to GPU-equipped nodes.
GPU support in OpenShift is delivered through Operators (e.g., NVIDIA GPU Operator), not manual driver installation.
During a graceful cluster restart, control plane nodes must come up first, then worker nodes.
The Group resource (user.openshift.io/v1) is a cluster-scoped OpenShift-specific resource; its only required field is users (string array of usernames).
Groups are the recommended way to manage access at scale rather than binding roles to individual users.
Hardware accelerators documentation in OpenShift is specifically scoped to AI/ML use cases via Red Hat OpenShift AI.
OpenShift enables specialized hardware (GPUs, FPGAs, NICs) through Node Feature Discovery (NFD), the Kernel Module Management (KMM) Operator, and driver containers rather than manual kernel-level configuration.
Hardware networks (e.g., SR-IOV) are configured as additional secondary networks via Multus CNI using NetworkAttachmentDefinition resources, not as replacements for the primary cluster network.
Hardware networks (SR-IOV) are configured as additional (secondary) pod networks via Multus NetworkAttachmentDefinitions, not as the primary cluster network.
HardwareData is a custom resource under the metal3.io/v1alpha1 API group
HardwareData is created automatically as a result of bare-metal host inspection (introspection), not manually by users in typical workflows
In dual-stack environments, NIC entries in HardwareData produce separate entries per IP address (one per IP family)
HardwareData is a namespaced resource, not cluster-scoped
HardwareData measures RAM in mebibytes (MiB), CPU clock speed in megahertz (MHz), and NIC speed in gigabits per second (Gbps)
HardwareData storage type field values are HDD, SSD, and NVME; the rotational boolean is deprecated in favor of type
Adding any identity provider to a hosted cluster's OAuth configuration removes the default kubeadmin user provider.
HCP uses HostedCluster and NodePool API resources from the hypershift.openshift.io API group (not openshift-install).
Hosted clusters are automatically imported into the local multicluster engine Operator when the hosted control plane becomes available — this is the default behavior.
AWS hosted cluster destruction requires five parameters: --name, --infra-id, --role-arn, --sts-creds, --base-domain
On AWS, taking an etcd snapshot requires API downtime — kube-apiserver, openshift-apiserver, and openshift-oauth-apiserver must be scaled to 0 replicas first
On AWS and OpenShift Virtualization, the managed cluster resource must be deleted (oc delete managedcluster) before destroying the hosted cluster
Bare metal hosted clusters created without --render/--render-sensitive flags require manual backend resource cleanup during destruction
The Cloud Credential Operator (CCO) for hosted clusters on AWS supports manual mode only — this is the default and only supported mode.
Operators declare support for CCO/STS in hosted control planes with the CSV annotation features.operators.openshift.io/token-auth-aws: "true".
Hosted cluster names must be unique cluster-wide; the name clusters is reserved and cannot be used
ClusterVersion resource changes are ignored in hosted clusters — updates are driven through HostedCluster and NodePool .spec.release.image.
The hosted control plane namespace follows the pattern ${HOSTEDCLUSTERNAMESPACE}-${CLUSTER_NAME} (e.g., clusters-my-cluster)
In hosted control planes, control plane and node pool updates are independent — unlike standalone OCP where they are coupled.
In hosted control planes, the control plane runs on the management cluster (managed by Control Plane Operator) and the data plane runs on the hosted cluster workers (managed by HostedClusterConfig Operator)
Hosted control planes run control plane components (etcd, API server, controller manager, VPN) as pods on a management cluster, not on dedicated machines.
Updating a hosted control plane requires two steps: (1) annotate HostedCluster with hypershift.openshift.io/force-upgrade-to, (2) patch spec.release.image.
The hcp create cluster command supports three platforms: aws, agent, and kubevirt.
Custom API server certificates for hosted control planes are configured at spec.configuration.apiServer.servingCerts.namedCertificates in the HostedCluster resource.
When kubeAPIServerDNSName is set on a HostedCluster, the HyperShift Operator generates a custom kubeconfig secret named <cluster_name>-custom-admin-kubeconfig.
Hosted control planes decouple the control plane from the data plane — the hosting cluster runs control plane pods while worker nodes run separately.
Hosted control planes decouple the control plane from the data plane — the control plane runs on the management cluster while worker nodes run separately.
HCP default CIDR ranges: 100.65.0.0/16 (OVN-Kubernetes internal), 10.132.0.0/14 (pod/cluster network), 172.31.0.0/16 (service network).
The default metrics set for hosted control planes is Telemetry (the smallest set).
The default namespace for hosted clusters is clusters.
The default TuneD profile in HCP is openshift-node when no custom profiles are defined
The hcp destroy cluster subcommand varies by platform: aws, kubevirt, or agent
Hosted control planes use distinct machine management patterns: NodePool replaces MachineSet/MHC, autoRepair replaces MachineHealthCheck, and upgrade strategies (Replace vs In-place) are NodePool-level settings.
Disabling auto-import of hosted clusters uses autoImportDisabled: "true" in the hypershift-addon-deploy-config AddonDeploymentConfig in the multicluster-engine namespace.
In disconnected environments, RHCOS images must be manually mirrored because oc-mirror does not automatically mirror them; an ImageDigestMirrorSet is used to configure the mirror.
Hosted control planes and standalone clusters use fundamentally different machine management: standalone uses MachineSet/MHC with BMC-based bare metal provisioning, while HCP replaces these with NodePool/autoRepair and runs control planes as pods — two incompatible operational models under the same platform.
Dual-stack networking for hosted control planes in disconnected environments is Technology Preview only — not supported for production
Hosted control planes (HCP) is enabled by default in the multicluster engine Operator.
The secret encryption key (spec.secretEncryption.aescbc) must be saved separately from the etcd snapshot for disaster recovery to a new cluster
In HCP, etcd encryption is configured via the SecretEncryption field on the HostedCluster resource (supporting AES-CBC or KMS for AWS), unlike standalone OCP which uses the APIServer resource.
In hosted control planes, etcd runs as a 3-member StatefulSet with individual PVCs (data-etcd-0, data-etcd-1, data-etcd-2), not as static pods on control plane nodes
Each hosted cluster's etcd runs as a pod on the management cluster rather than on dedicated control plane nodes.
In hosted control planes, etcd uses Persistent Volume Claims for storage (not local node storage) and is managed by the Control Plane Operator.
etcdutl snapshot restore (not etcdctl) is used for restoring etcd snapshots in HCP, with --skip-hash-check
Feature gates on hosted clusters are configured at spec.configuration.featureGate.featureSet in the HostedCluster CR on the management cluster
Feature gates for hosted clusters are set by editing the HostedCluster CR on the management cluster, not by editing resources on the hosted cluster directly
After etcd restore, a manual rollout is triggered using the hypershift.openshift.io/restart-date annotation on the HostedCluster resource
A highly available hosted control plane consists of 78 pods requiring approximately 5.5 vCPUs, 19 GiB memory, and three 8 GiB PVs for etcd.
The HostedCluster CR uses the API group hypershift.openshift.io/v1beta1
htpasswd and request-header are the only identity providers that do not require NodePool replicas configured in advance (other providers need worker nodes for DNS resolution).
The HyperShift Operator is included in the multicluster engine (MCE) for Kubernetes Operator; MCE is installed with RHACM or standalone from OperatorHub.
The --cluster-grace-period flag is used with hcp destroy cluster agent on IBM Power to specify destruction timeout
On IBM Z, scaling NodePool to 0 auto-detaches compute nodes only with KVM; z/VM and LPAR require manual compute node deletion
Applying ICSP/IDMS triggers a MachineConfig change that restarts kubelet (not the entire node) on each node
IDMS/ICSP applies to the management cluster; ImageContentSource in the hosted cluster spec is translated to IDMS on the hosted cluster
MachineConfig objects in HCP use Ignition version 3.2.0
Hosted control planes integrate with Red Hat Advanced Cluster Management (ACM) / Multicluster Engine (MCE) for lifecycle management.
The annotation import.open-cluster-management.io/klusterlet-deploy-mode: Hosted is required when manually importing a hosted cluster.
KlusterletAddonConfig is only needed when RHACM is installed, not for MCE-only deployments.
In HCP, API server-to-node communication uses Konnectivity (not direct communication), since control plane and workers are in different VPCs.
The kubeVirtContainer: true flag in ImageSetConfiguration mirrors the RHCOS boot container disk image and is available only in oc-mirror v2
Default ingress DNS for KubeVirt hosted clusters follows the pattern *.apps.<hostedclustername>.apps.<mgmtclusterdomain>
Default hosted cluster ingress for KubeVirt only supports HTTPS on port 443; plain HTTP on port 80 is rejected
A KubeVirt hosted cluster typically takes 10–15 minutes to fully provision
KubeVirt-based hosted control planes require the management cluster to run on bare metal
Machine configuration objects (MachineConfig, KubeletConfig, Tuned) must be embedded inside a ConfigMap in the management cluster's clusters namespace to be applied in HCP
Hosted control planes are powered by the HyperShift operator and managed via the hcp CLI and CRDs (HostedCluster, NodePool).
A hosted control planes management cluster requires at least 3 worker nodes; single-node OpenShift is not supported as a management cluster.
A management cluster on OCP 4.17 can deploy hosted clusters at versions 4.17, 4.16, 4.15, and 4.14 (current version plus two previous minor versions, totaling n-3).
Maximum supported latency between a management cluster and hosted clusters is 200 ms.
Default maxPods of 250 allows ~3 hosted control planes per node; increasing to 500 via KubeletConfig allows more density.
Upgrading MCE minor version updates the HyperShift Operator; upgrading MCE patch/z-stream does not update HyperShift.
The multicluster engine Operator manages hosted clusters from n+1 to n-2 OCP versions where n is the current minor version.
The metrics set is configured via the METRICS_SET environment variable on the HyperShift Operator deployment in the hypershift namespace.
In HCP, management cluster control plane failure alone does not impact running workloads — only combined control plane and worker node failure makes the API unavailable (data plane stays available)
Mixed infrastructure hosted control planes (e.g., management on AWS, workers on-premise) require the PublicAndPrivate publishing strategy.
HCP monitoring dashboard ConfigMaps are created in openshift-config-managed namespace with naming pattern cp-<namespace>-<name>, and deleting a hosted cluster automatically deletes its dashboard.
Monitoring dashboards are enabled via the hypershift-operator-install-flags ConfigMap in the local-cluster namespace with --monitoring-dashboards flag.
The must-gather image for hosted control planes is registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version>, not the standard OCP must-gather image.
The Machine Config Operator does not exist in hosted control planes; machine configuration is applied via ConfigMap referenced in NodePool's spec.config.
In hosted control planes, MachineConfigPool does not exist; NodePool is used instead for managing node configuration
In HCP, node labels do not persist during upgrades unless spec.management.upgradeType is set to InPlace on the NodePool
NodeHealthCheck remediation must be manually paused (via pauseRequests field) before updating hosted clusters because it cannot detect CVO status in hosted control planes.
Machine health checks in HCP use .spec.management.autoRepair on NodePool (not MachineHealthCheck resource).
Autoscaling in HCP is configured via spec.autoScaling on NodePool (not ClusterAutoscaler/MachineAutoscaler).
NodePool replaces MachineSets, MachineAutoscaler, MachineHealthCheck, and MachineConfigPool concepts from standalone OCP.
NodePool spec.config references ConfigMaps containing MachineConfig/KubeletConfig; spec.tuningConfig references ConfigMaps containing Tuned objects — these are separate fields
Node pool upgrade types are Replace (re-provisions nodes, suited for cloud) and In-place (updates OS on existing instances, suited for bare metal); the type is immutable after node pool creation.
Node pool version must not surpass the hosted control plane version per Kubernetes version skew policy.
OAuth for hosted clusters is configured in spec.configuration.oauth of the HostedCluster CR, not in a separate OAuth CR.
When OLM catalogs use management (default) placement mode, ICSP overrides are not automatically applied to the OLM catalog image stream — requires manual annotation
Before performing etcd backup/restore operations on a hosted cluster, reconciliation must be paused with spec.pausedUntil: "true" and resumed afterward with "null"
Registry CA certificates for disconnected HCP must be configured in two places: the management cluster (image.config.openshift.io additionalTrustedCA) and the hosted cluster workers (spec.additionalTrustBundle referencing a user-ca-bundle ConfigMap)
Updates to hosted clusters imported into a remote RHACM hub must be done on the local MCE where the cluster is hosted, not through the remote hub.
HCP supports both replace and in-place upgrade types for node pools; standalone OCP supports only in-place.
Hosted control planes require a fundamentally different operational playbook from standalone clusters: machine management uses NodePool instead of MachineSet/MHC, ClusterVersion is ignored in favor of HostedCluster CR for updates, the web console cannot show control plane status or manage machines, and etcd restore uses a restart-date annotation — making standalone operational procedures largely inapplicable.
Hosted control planes require multicluster engine for Kubernetes Operator; RHACM is optional and not required.
To restart all hosted control plane components, annotate the HostedCluster resource with hypershift.openshift.io/restart-date; the value is treated as a string, not a timestamp.
Custom API server certificate SANs must not conflict with the internal API endpoint (api-int), except on AWS with Private or PublicAndPrivate publishing strategies.
The service publishing strategy for hosted control planes is immutable after cluster creation.
HCP uses a single Control Plane Operator that replaces the many individual operators used in standalone OCP control planes.
HCP resource utilization can be overridden via a ConfigMap named hcp-sizing-baseline in the local-cluster namespace.
The web identity token path for STS in hosted control planes is /var/run/secrets/openshift/serviceaccount/token.
Hosted control planes support bare metal (Agent provider), OpenShift Virtualization, AWS, IBM Z, and IBM Power as platforms.
The supported-versions ConfigMap is created by the HyperShift Operator in the hypershift namespace with label hypershift.openshift.io/supported-versions: "true".
Enabling TechPreviewNoUpgrade feature set on a hosted cluster is irreversible and prevents minor version updates
Hosted control planes support three metrics sets: Telemetry (default, smallest), SRE (alerting/troubleshooting), and All (every metric standalone OCP produces).
Custom TLS certificate secrets for hosted cluster API servers are created on the management cluster, not within the hosted cluster itself.
The Node Tuning Operator appends a hash of the node pool name and namespace to Tuned CR names to avoid collisions across node pools
HCP update order is strict: (1) management cluster OCP, (2) multicluster engine Operator, (3) hosted cluster and node pools.
The web console for hosted clusters cannot show control plane status, manage machines, or perform cluster updates.
Wildcard DNS routes (WildcardsAllowed on the IngressController) must be enabled on the infrastructure cluster for default Ingress behavior on OpenShift Virtualization hosted clusters.
Worker nodes in NotReady state during hosted cluster creation is normal while the networking stack rolls out, but should not persist beyond approximately 15 minutes.
OpenShift provides two parallel application packaging mechanisms: Helm charts (cluster-scoped and project-scoped repositories, chart/release/revision lifecycle) and Templates (cluster-wide availability via the openshift namespace, labels applied to all generated objects) — both enabling repeatable application instantiation with different scope models.
In Helm, a chart is a packaging format, a release is a running instance of a chart, and a revision is an incremental snapshot created on install, upgrade, or rollback.
Chart.yaml apiVersion must be v2 for Helm 3 charts.
Red Hat provides a default Helm chart repository at https://charts.openshift.io/.
Namespace-scoped Helm chart repos (ProjectHelmChartRepository) require appropriate RBAC permissions but not cluster-admin.
CA certificates for private Helm chart repos are stored as ConfigMaps in the openshift-config namespace with key ca-bundle.crt.
Removing all Helm chart repositories (cluster and namespace level) hides the Helm option from the Developer Console UI.
OpenShift has two CRD kinds for Helm chart repos: HelmChartRepository (cluster-scoped) and ProjectHelmChartRepository (namespace-scoped), both using API group helm.openshift.io/v1beta1.
HelmChartRepository CA ConfigMaps and TLS Secrets must reside in the openshift-config namespace, with keys ca-bundle.crt, tls.crt, and tls.key.
HelmChartRepository is a cluster-scoped resource under API group helm.openshift.io/v1beta1 (Compatibility Level 2).
Setting spec.disabled: true on a HelmChartRepository disables the repository without removing it.
The HighNodeUtilization scheduler profile may place all replicas of a ReplicaSet on the same node
Projects default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label 0 or 1 bypass admission plugins including pod security admission, SCCs, cluster resource quotas, and image reference resolution.
Hive provisions self-managed OCP clusters to the hub; the klusterlet agent registers managed clusters to the hub.
The host-device CNI plugin requires specifying a device by exactly one of: device, hwaddr, kernelpath, or pciBusID.
Hosted control planes in OpenShift are based on the HyperShift upstream project and enable hyperscale cluster operations with centralized control planes.
Hosted control planes (HCP) run control plane components (API server, etcd, controllers) as pods on a management cluster, eliminating the need for dedicated VMs/machines per control plane.
HostFirmwareSettings belongs to API group metal3.io/v1alpha1 and is a namespaced resource
HostFirmwareSettings .status.conditions tracks schema validation of spec settings against a referenced FirmwareSchema resource, not host health
.spec.settings is the only required field in the HostFirmwareSettings spec
HostFirmwareSettings uses a spec/status pattern: .spec.settings holds desired BIOS/firmware name/value pairs, .status.settings reflects actual firmware state
When using hostNetwork: true, dnsPolicy must be set to ClusterFirstWithHostNet to retain cluster DNS resolution.
A hostPrefix of 23 in clusterNetwork CIDR provides 510 pod IPs per node (2^(32-23) - 2).
The HorizontalPodAutoscaler uses the autoscaling/v2 API group, which supports multiple metrics and custom metrics (v1 only supports CPU)
The averageUtilization target type is only valid for Resource metric source type (percentage of pod's resource request)
When no metrics are specified in an HPA, it defaults to 80% average CPU utilization
HPA supports five metric source types: Resource, ContainerResource (requires HPAContainerMetrics feature gate), Pods, Object, and External
HorizontalPodAutoscaler (HPA) is a namespaced resource that targets a scalable workload such as a Deployment or ReplicaSet.
When multiple metrics are defined in an HPA, the maximum calculated replica count across all metrics is used
HPA behavior policy periodSeconds maximum is 1800 seconds (30 min); selectPolicy defaults to Max
HPA calculates desired replicas as: desiredReplicas = currentReplicas × (currentMetricValue / targetMetricValue)
HPA spec requires scaleTargetRef and maxReplicas; minReplicas defaults to 1
HorizontalPodAutoscaler (HPA) requires a metrics source (Metrics Server or Prometheus adapter) to function.
HPA minReplicas: 0 requires both the HPAScaleToZero feature gate and at least one Object or External metric configured
HPA scale-down stabilization window defaults to 300 seconds (5 min); scale-up defaults to 0 seconds; maximum is 3600 seconds (1 hour)
HorizontalPodAutoscaler uses the autoscaling/v2 API in OCP 4.17, which supports custom and external metrics (not just CPU)
HostPath Provisioner (HPP) does not support block storage; LSO and LVM Storage do.
HTPasswd identity provider data is stored in a Secret with key htpasswd (not in a ConfigMap)
ConfigMap changes are not automatically synced to existing policies — requires either deleting the policy or using the policy.open-cluster-management.io/trigger-update annotation.
ConfigMaps referenced by hub templates must be in the same namespace as the generated policy.
The fromConfigMap function is the primary hub template function for pulling values from ConfigMaps, with syntax fromConfigMap "<namespace>" "<configmap-name>" "<key>".
RHACM hub cluster templates use {{hub ... hub}} delimiters (not standard Go {{ }}).
The toLiteral pipe is required in hub templates when a ConfigMap value is a JSON array/object that should be interpreted as YAML structure rather than a string.
Hardware networks are consumed as additional/secondary network interfaces on pods via Multus CNI, alongside the primary OVN-Kubernetes cluster network
Hardware offloading requires eSwitchMode: "switchdev" in the SriovNetworkNodePolicy with deviceType: netdevice (vfio-pci is not supported)
Hardware offloading is not compatible with DPDK applications
Hardware offloading in OpenShift requires bare metal nodes with SmartNICs and is not available on VMs
Hardware offloading requires the OVN-Kubernetes network plugin with gatewayConfig.routingViaHost set to false
The SR-IOV Operator must be set to configurationMode: "systemd" in the SriovOperatorConfig CR (named default) for hardware offloading
Hardware offloading supports only two communication types: pod-to-pod and pod-to-ClusterIP-service (backed by regular pods)
Enabling hardware offloading on a node without configuring pods to use it results in decreased throughput
The clusterNetwork and serviceNetwork settings from the seed cluster are baked into the seed image and cannot be changed after seed image creation.
Dual-stack networking is not supported for image-based installation (IBI) in OCP 4.17.
The Lifecycle Agent is installed in the openshift-lifecycle-agent namespace.
The IBI seed image is an OCI container image (not a disk image), generated from a seed cluster using the Lifecycle Agent.
Seed and target clusters for IBI must match on CPU topology (architecture, core count, tuned performance config), IP version, disconnected registry (yes/no), FIPS config, and proxy (enabled/disabled).
The shared container partition MachineConfig for IBI must be applied at installation time of the seed cluster.
Image-based installation (IBI) separates installation (preinstalling at central site) from deployment (reconfiguring at remote site) as two distinct phases.
The shared /var/lib/containers partition on the seed cluster requires a minimum of 500 GB and must be a dedicated partition shared between ostree stateroots.
IBM Cloud Bare Metal (Classic) is a supported installation platform for OpenShift Container Platform.
IBM Cloud Bare Metal (Classic) is distinct from IBM Cloud VPC, IBM Power, and IBM Z/LinuxONE as separate installation targets.
IBM Cloud has distinct installation paths: Bare Metal (Classic), VPC, and IBM Power Virtual Server, each with separate documentation.
IBM Cloud (VPC) is a supported installation target for OpenShift Container Platform 4.17.
IBM Power uses the ppc64le architecture and heterogeneous clusters are not supported — all machine pools must use the same architecture.
IBM Power has exactly two installation methods: standard (internet-connected) and restricted/disconnected network (using an internal mirror of release content).
IBM Power installations typically require user-provisioned infrastructure (UPI) rather than installer-provisioned infrastructure (IPI).
IBM Power supports only user-provisioned infrastructure (UPI) installations — IPI is not available.
IBM PowerVC (Power Virtualization Center) is built on OpenStack and provides virtualization management for IBM Power Systems.
IBM Z deployments can run on z/VM, LPAR (Logical Partitions), or KVM on IBM Z.
OpenShift Virtualization is unsupported on IBM Z and IBM Power platforms.
IBM Z installations use platform-specific disk provisioning via DASD or FCP/SCSI.
IBM Z installations use User-Provisioned Infrastructure (UPI) only — IPI is not available for the IBM Z platform.
IBM Cloud requires credentialsMode: Manual for the Cloud Credential Operator (CCO) — it is the only supported credentials mode because IBM Cloud does not support storing administrator-level credential secrets in kube-system.
After openshift-install destroy cluster on IBM Cloud, CCO credentials must be separately deleted using ccoctl ibmcloud delete-service-id as a manual step.
IBM Cloud supports five IPI installation variants: customized cluster, network customizations, existing VPC, private cluster on existing VPC, and restricted network (air-gapped).
The environment variable ICAPIKEY must be set (by exact name) before running openshift-install destroy cluster on IBM Cloud — the installer uses it to remove service IDs.
IBM Cloud supports only installer-provisioned infrastructure (IPI) for OpenShift installation — user-provisioned infrastructure (UPI) is not supported.
Only IPv4 addresses are supported for networking on IBM Cloud OpenShift installations.
PVCs created after cluster deployment are not automatically removed during openshift-install destroy cluster on IBM Cloud.
On cluster uninstall, installer-created resource groups are deleted while user-provided resource groups are preserved (only installer-provisioned resources within them are removed).
Only subnet names (not IDs) are supported for computeSubnets and controlPlaneSubnets in IBM Cloud install-config.yaml.
The metadata.json file in the installation directory is required for cluster deletion via openshift-install destroy cluster.
ICSP uses API group operator.openshift.io/v1alpha1 — it is an alpha-level API with no compatibility guarantees (Compatibility Level 4).
ImageContentSourcePolicy (ICSP) is a cluster-scoped resource with no namespace, applying globally across the cluster.
ICSP is deprecated starting in OCP 4.13 in favor of ImageDigestMirrorSet (IDMS), which provides the same digest-based mirroring with a stable API.
ImageContentSourcePolicy (ICSP) is deprecated and replaced by ImageDigestMirrorSet (IDMS) and ImageTagMirrorSet (ITMS) starting in OpenShift 4.13+
ImageContentSourcePolicy (ICSP) mirrors only apply to images pulled by digest — images referenced by tag are always pulled from the original source repository.
ICSP is essential for disconnected/air-gapped environments where images must be pulled from a local mirror rather than internet-facing registries.
When multiple ICSP objects define mirrors for the same source, mirror lists are merged preserving relative order where possible.
Applying or modifying an ICSP triggers the Machine Config Operator to update container runtime mirror configuration (/etc/containers/registries.conf) on nodes, causing rolling node reboots.
The Identity resource belongs to the user.openshift.io/v1 API group, not core Kubernetes.
The complete software delivery pipeline (build→image→operator→console) is identity-governed end-to-end: the OAuth→Identity→Authorization chain controls who can build images, deploy operators, and access console plugins, while dual RBAC+SCC enforces what those actors can do at each pipeline stage.
OpenShift identity and authorization governance controls both operator lifecycle and workload deployment: the complete OAuth→User→Identity→Authorization chain gates OLM operator installation (ClusterRole/ServiceAccount for InstallPlans) and workload pod admission (SCC evaluation), making identity the root of all platform access regardless of OLM generation.
An Identity resource requires both providerName and providerUserName fields, which together uniquely identify an authentication record.
OpenShift identity management forms a complete chain from authentication through session management to authorization: OAuth providers create User/Identity objects that map to sessions (OAuthAccessToken lifecycle with active revocation), which are then evaluated against dual authorization systems (OpenShift auth + K8s RBAC) — revoking a session invalidates all authorization decisions for that identity.
OpenShift provides end-to-end identity governance: the OAuth identity chain (provider → User → Identity → UserIdentityMapping) feeds into dual authorization systems (OpenShift auth + K8s RBAC with SCCs), creating a unified access control pipeline from authentication through authorization.
The user field on an Identity object is an ObjectReference that requires both Name and UID to be set.
ImageDigestMirrorSet (IDMS) applies only to images referenced by digest (@sha256:...); ImageTagMirrorSet (ITMS) is the companion resource for tag-based pulls
IDMS and ITMS support mirrorSourcePolicy: NeverContactSource to block fallback to the original source registry, critical for fully disconnected environments
When multiple IDMS objects match an image pull spec, the most specific namespace match applies (e.g., quay.io/libpod/busybox wins over quay.io/libpod)
Ignition config files contain certificates that expire after 24 hours; best practice is to use them within 12 hours of generation.
Ignition certificates expire after 24 hours and auto-renew; Ignition configs should be used within 12 hours of generation
Ignition configuration files expire after 24 hours — installation must begin within that window.
Ignition runs only on first boot from initramfs; it is declarative and machines cannot be partially configured. Subsequent OS changes go through the Machine Config Operator.
Ignition supports RAID but does not support LVM for disk configuration.
The additionalTrustedCA field on the Image config references a ConfigMap in the openshift-config namespace for custom CA bundles trusted during image operations.
In the Image config resource, registrySources.allowedRegistries and registrySources.blockedRegistries are mutually exclusive — only one may be set.
The allowedRegistriesForImport field does not restrict admin users who can directly create Images or ImageStreamMappings.
Image APIs (Image, ImageStream, ImageStreamTag, ImageStreamImage, ImageStreamImport, ImageTag) are OpenShift-specific extensions that do not exist in vanilla Kubernetes.
Image APIs (Image, ImageStream, ImageStreamTag, etc.) are OpenShift-specific extensions to the Kubernetes API, not available in vanilla Kubernetes
The cluster-wide image registry configuration CR is image.config.openshift.io/cluster (kind Image, name must be "cluster")
The containerRuntimeSearchRegistries field in the Image config works only with CRI-O, not with builds or imagestream imports.
ImageContentSourcePolicy is Compatibility level 4 (v1alpha1) with no compatibility guarantees, unlike most operator APIs which are level 1
The first entry in externalRegistryHostnames populates publicDockerImageRepository in ImageStreams.
OpenShift image governance spans the complete lifecycle: images flow through build systems and supply chains (S2I/Shipwright → ImageStream → registry for apps; FBC → OLM for operators) and are then subject to lifecycle controls (managed annotation for pruning eligibility, registry operator for automated cleanup) — the same governance model that controls creation also controls deletion.
The correct base RHCOS image for image layering is obtained with oc adm release info --image-for rhel-coreos.
All RHCOS image layering Containerfiles must end with ostree container commit after installing packages.
Image layering is the supported method for adding custom content to RHCOS node OS images without building entirely custom images
Realtime kernel or extensions RPMs must NOT be installed as custom layered content — they conflict with MCO-managed RPMs and cause a degraded state.
Custom layered image deployment on a node is verified with rpm-ostree status (via oc debug node).
OpenShift image lifecycle management spans creation to deletion: images require the openshift.io/image.managed annotation for pruning eligibility, the ImagePruner (managed by the Image Registry Operator) runs as a CronJob, and pruning requires a registry restart to clear the blob metadata cache — creating a multi-step lifecycle with manual intervention points.
An Image with dockerImageManifests populated represents a manifest list (multi-arch); dockerImageLayers should not be set in this case.
Image metadata is stored as standard API resources (images and image streams), not in the registry storage; actual image data goes to configurable storage.
Image mirroring follows a pipeline: oc-mirror generates IDMS manifests, MCO applies them as registries.conf on nodes, with ICSP deprecated in favor of IDMS since OCP 4.13.
Maximum image name length in OpenShift is 63 characters.
Image objects in OpenShift are immutable and content-addressed (named by a hash of their contents)
The Cluster Image Registry Operator auto-detects storage based on cloud provider; creates an incomplete resource if storage info is missing.
The image-registry cluster operator manages the lifecycle of OpenShift's built-in internal container image registry.
The image registry Config resource (imageregistry.operator.openshift.io/v1) is a cluster-scoped singleton named cluster.
Setting defaultRoute: true on the image registry Config creates an externally accessible route using the default hostname.
Setting disableRedirect: true on the image registry Config forces all image data to flow through the registry instead of redirecting clients to the storage backend.
The image registry emptyDir storage backend is not production-grade — data is lost when the pod restarts.
The internal image registry can be exposed externally via defaultRoute (with re-encrypt TLS), requires specific storage backend configuration, and credentials are stored in a named secret — forming a complete deployment model for registry accessibility.
The image registry operator uses configs.imageregistry.operator.openshift.io (not operator.openshift.io)
The image registry PVC claim field cannot be changed once set — the PVC must be deleted and recreated.
The replicas field is the only required field in the image registry Config .spec.
The image registry supports seven storage backends: S3, Azure Blob, GCS, OpenStack Swift, PVC, IBM COS, and emptyDir.
Image objects are cluster-scoped resources (not namespaced).
The Image resource (image.openshift.io/v1) is immutable and content-addressable — image names are derived from a hash of their contents, so any change produces a new Image object.
Image signatures can enforce cluster-wide image policy restricting which images are allowed to run.
Image Streams and Triggers enable automated rollouts when upstream images change, tying into CI/CD workflows.
OpenShift provides two parallel but converging image supply chains: application images flow through build systems → ImageStreams → registry, while operator images flow through FBC catalogs → OLM lifecycle → deployment — both ultimately delivering container images through managed, auditable pipelines.
Image tags are mutable human-readable labels pointing to immutable SHA digests; multiple tags can point to the same digest.
Kubernetes-native resources (Deployments, StatefulSets, DaemonSets, CronJobs, Jobs, ReplicationControllers, Pods) use the image.openshift.io/triggers annotation to trigger on image stream tag changes.
The fieldPath in an image trigger annotation must precisely match a container by name or index and cannot use wildcards.
The from.kind in an image trigger annotation must be ImageStreamTag — no other kinds are supported.
Setting paused: true in an image trigger annotation disables the trigger without removing the annotation.
ImageContentPolicy is a cluster-scoped (not namespaced) resource in the config.openshift.io/v1 API group
ImageContentPolicy mirrors only work for digest-based image pulls by default; allowMirrorByTags: true must be set to enable tag-based mirroring
When multiple ImageContentPolicy objects define mirrors for the same source, mirror lists are merged (not rejected); conflicting orderings result in unspecified behavior, not errors
Vulnerability scan results are exposed as ImageManifestVuln CRs (CRD: imagemanifestvulns.secscan.quay.redhat.com); CLI shorthand is oc get vuln --all-namespaces.
The ImagePruner resource uses API group imageregistry.operator.openshift.io/v1.
The ImagePruner default minimum image age before pruning eligibility is 60 minutes (keepYoungerThanDuration).
The ImagePruner default schedule is 0 0 * * * (daily at midnight).
The ImagePruner preserves a default of 3 tag revisions per image stream tag.
The ImagePruner keepYoungerThan field (nanoseconds) is deprecated in favor of keepYoungerThanDuration (duration string); if both are set, the duration field wins.
The ImagePruner resource is managed by the Image Registry Operator, which translates its spec into a Kubernetes CronJob — it is not created manually as a CronJob.
Setting suspend: true on the ImagePruner stops pruning without removing the configuration.
ImageSignature resources support only POST (create) and DELETE operations — no PATCH or PUT — making signatures immutable once created.
ImageSignature required fields are type and content; issuedTo also requires publicKeyID (at least 64 lowest bits of the public key fingerprint).
The API group for image streams is image.openshift.io/v1.
ImageStream and BuildConfig are OpenShift-native concepts with no direct Kubernetes equivalents.
ImageStream access follows a controlled model: images are immutable and content-addressed, end users access them via ImageStreamTag/ImageStreamImage (not Image directly), pulling requires explicit get-layers permission, and ImageStreamMapping is restricted to privileged integrators.
The spec.dockerImageRepository field on ImageStream is deprecated since v3.7; replaced by per-tag spec.tags[].from.
Image stream imports do not use the mirror/search mechanism — samplesRegistry must be explicitly set to the mirror hostname.
Setting spec.lookupPolicy.local: true on an ImageStream causes short image references in the namespace to be automatically resolved to the image stream's image ID without contacting a remote registry.
Setting spec.lookupPolicy.local: true on an image stream enables all resources in the same project to resolve image stream references without additional configuration.
Image stream metadata is stored in etcd.
Pulling from the integrated registry requires get imagestreams/layers permission.
referencePolicy.type: Local points the pull-spec to the integrated registry (enabling credential isolation and local layer mirroring); Source (default) uses the original upstream location.
The annotation alpha.image.policy.openshift.io/resolve-names: '*' on a pod template enables image stream resolution for that specific resource.
Image stream references must use single-segment names (<name>:<tag>, not full registry paths) and the image stream must be in the same project as the referencing resource.
Setting importPolicy.scheduled: true on an ImageStream tag enables periodic re-import to track upstream changes.
The first entry in status.tags[].items is the currently active image for that tag.
ImageStreamTag references an image by tag name while ImageStreamImage references a specific image by digest within an ImageStream.
ImageStreamImage name format is <STREAM>@<DIGEST> (e.g., mystream@sha256:abc123...), using a content-addressable digest reference rather than a tag.
ImageStreamImage is a read-only resource — only GET is supported, no create/update/delete.
ImageStreamImport only allows kind: DockerImage as the from source for importing images.
On ImageStreamImport, spec.import: true triggers actual import; false is a metadata preview/dry-run only.
The imageMissing boolean in ImageStreamLayers indicates an Image object was deleted by an admin but is still referenced by the ImageStream
ImageStreamLayers layers are ordered from base layer to top layer, and all referenced layers are guaranteed to exist in the blobs map
In ImageStreamLayers, multi-architecture images use the manifests field (list of digests) instead of layers/config
ImageStreamLayers is a read-only API subresource of ImageStream (only GET is supported), accessed via /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/layers
ImageStreamMapping only supports the create operation — no get, list, update, or delete
Creating an ImageStreamMapping grants view access to the image for anyone who can view the image stream
ImageStreamMapping is used by privileged integrators (not end users) to associate a container image with an image stream tag
ImageStreams provide an abstraction over container image repositories, enabling tag-based references, indirection over registry locations, and automatic updates.
ImageStreams enable automatic rollouts when upstream images change — DeploymentConfigs can trigger on ImageStream tag changes.
Image streams do not contain actual image data — they are an abstraction layer that presents a virtual view of related images via references and pointers.
ImageStreams are an OpenShift-specific abstraction (not a Kubernetes-native concept) that provides a virtual view of related images, enabling tagging, rollback, and trigger-based updates.
Deleting an ImageStreamTag clears both the status and spec fields of the associated image stream tag
Creating an ImageTag only succeeds if no spec tag already exists and the spec field is set
ImageTag (image.openshift.io/v1) is the newer replacement for ImageStreamTag, providing spec + status + image in a single object
An ImageTag's spec.from can reference ImageStreamTag (same stream only), ImageStreamImage, or DockerImage
OpenShift enforces immutability at two distinct levels: individual resource fields (Route host, IngressController domain, IngressClass controller, CSIDriver attachRequired) are locked after creation, while platform-wide decisions (FIPS, CPU partitioning, network plugin) are locked at install time — creating a layered immutability model where some things can never change and others freeze on first write.
OpenShift node management combines immutability with singleton operator governance: RHCOS nodes accept changes only through the MCO delivery pipeline (render → cordon → drain → apply → reboot), and multiple operator CRs enforce singleton naming conventions — creating a system where node state is both immutable and centrally controlled through well-known named resources.
Setting importPolicy.scheduled: true on an image stream tag enables periodic re-checking and re-import of external tags
Infrastructure nodes are identified by the label node-role.kubernetes.io/infra: "".
The recommended taint for infrastructure nodes is node-role.kubernetes.io/infra:NoSchedule to prevent user workloads from scheduling.
Infra nodes labeled with the infra role running only infra workloads do not count toward subscription charges, but must also use taints to prevent user workload scheduling.
Moving workloads (router, registry, monitoring, logging) to infra nodes requires configuring each operator's nodeSelector and tolerations individually; creating the infra node alone is not sufficient.
The cloud config ConfigMap referenced by Infrastructure lives in openshift-config; the stitched/generated version is kube-cloud-config in openshift-config-managed with key cloud.conf
Dual-stack clusters have two entries in apiServerInternalIPs and ingressIPs (one IPv4, one IPv6)
The Infrastructure Operator manages Assisted Service deployment for on-premise bare metal and vSphere OCP installations, including single-node OpenShift, and supports GitOps Zero Touch Provisioning (ZTP).
Infrastructure.spec.platformSpec.type determines whether infrastructure automation (load balancers, dynamic volumes, machine lifecycle) is enabled; setting None disables all automation
Allowed platformSpec.type values include: AWS, Azure, BareMetal, GCP, Libvirt, OpenStack, VSphere, oVirt, KubeVirt, EquinixMetal, PowerVS, AlibabaCloud, Nutanix, None
The Infrastructure resource (config.openshift.io/v1) is a cluster singleton always named cluster that defines platform provider type, cloud config, API server IPs, ingress IPs, and failure domains
Kubernetes Ingress belongs to API group networking.k8s.io/v1 (not the deprecated extensions/v1beta1)
spec.appsDomain on the Ingress config is an optional alternative domain for route host generation that can be modified post-install
The service referenced by an Ingress backend must be in the same namespace as the Ingress object
Cloud platforms (AWS, Azure, GCP) default to LoadBalancerService with External scope for endpoint publishing.
The Ingress resource (config.openshift.io/v1) is a cluster-wide singleton with canonical name cluster
The default number of replicas per Ingress Controller is 2.
The default TLS security profile for Ingress Controllers is Intermediate (TLS 1.2 minimum).
The default Ingress Controller is named default and lives in the openshift-ingress-operator namespace.
status.defaultPlacement on the Ingress config controls whether ingress router pods run on control-plane or worker nodes (default: Workers)
The domain field on an IngressController cannot be updated after creation and must be unique across all Ingress Controllers.
spec.domain on the Ingress config sets the default domain for route host generation and cannot be changed after installation
The HTTP header forwarding policy defaults to Append.
HAProxy default thread count is 4 (max 64) and default max connections is 50000.
HSTS policies in spec.requiredHSTSPolicies are enforced via the haproxy.router.openshift.io/hsts_header annotation with first matching policy winning
The headerBufferBytes must be at least 16384 if HTTP/2 is enabled (default 32768).
When multiple Ingress paths match a request, the longest matching path takes priority
The IngressNodeFirewallConfig CR must be named ingressnodefirewallconfig and created in the openshift-ingress-node-firewall namespace.
The Ingress Node Firewall Operator uses eBPF programs with XDP preferred for packet processing; NICs without native XDP drivers run at lower performance.
oc adm must-gather -- gatheringressnode_firewall collects firewall-specific diagnostics including eBPF bpftool outputs.
The Ingress Node Firewall Operator runs in the openshift-ingress-node-firewall namespace.
Ingress Node Firewall rules use an order field (1–100 per source CIDR); lower order number means higher priority (executes first).
For Single-Node OpenShift clusters, the openshift-ingress-node-firewall namespace requires the annotation workload.openshift.io/allowed=management.
The Ingress Node Firewall Operator supports only stateless firewall rules (no connection tracking).
The Ingress Node Firewall verification webhook prevents invalid configs and blocks rules that would break critical cluster services such as the API server.
The Ingress Operator always converts TLS 1.0 to TLS 1.1 for Old or Custom security profiles.
The Ingress Operator deploys and manages HAProxy-based Ingress Controllers to route external traffic into the cluster.
The Ingress Operator runs in the openshift-ingress-operator namespace; the router runs in the openshift-ingress namespace.
Ingress pathType is required on every path entry with three possible values: Exact, Prefix, and ImplementationSpecific
Ingress Prefix path matching is element-wise by / — /foo/bar matches /foo/bar/baz but does NOT match /foo/barbaz
The routeAdmission.namespaceOwnership policy defaults to Strict (no cross-namespace hostname sharing).
Ingress Controller sharding is implemented via namespaceSelector and routeSelector on the IngressController CR.
TLS on Kubernetes Ingress only supports port 443
The IngressController wildcardPolicy defaults to WildcardsDisallowed.
Ingress wildcard hosts (*.foo.com) match exactly one DNS label — * alone is not a valid host
IngressClass is a cluster-scoped resource (not namespaced) in API group networking.k8s.io/v1
IngressClass spec.controller field is immutable — cannot be changed after creation
The annotation ingressclass.kubernetes.io/is-default-class: "true" marks an IngressClass as the default; new Ingress resources without an explicit class get assigned to it
IngressController is the resource that controls HAProxy router deployments; updating it can cause traffic disruption
Custom error pages for IngressController require a ConfigMap in openshift-config namespace; only 503 and 404 error pages are customizable.
The default IngressController TLS security profile is Intermediate (TLS 1.2–1.3); profiles may change on OCP upgrade causing rolling router updates.
Default IngressController endpoint publishing strategy is platform-dependent: LoadBalancerService (External) for AWS/Azure/GCP/IBMCloud/AlibabaCloud; HostNetwork for Libvirt and unknown platforms.
IngressController clientTLS (mTLS) works only with edge-terminated and reencrypt routes, not passthrough TLS or cleartext HTTP.
IngressController default replicas: 1 for SingleReplica topology, 2 for HighlyAvailable topology.
IngressControllers can be sharded using namespaceSelector and/or routeSelector to control which routes they serve.
IngressController endpointPublishingStrategy and domain fields cannot be updated after creation.
Wildcard DNS management by the Ingress Operator is only supported on AWS, Azure, and GCP.
Init containers run before application containers and are used for setup tasks not present in the application image.
Init containers run sequentially and each must complete successfully before the next starts; all must complete before app containers start.
Init containers run sequentially, must all succeed, and cannot have probes or lifecycle hooks.
Insights Advisor is available at console.redhat.com/openshift/insights/advisor/ and displays identified issues with remediation steps
The Insights Operator is installed and enabled by default on OpenShift Container Platform clusters.
The Insights Operator uploads its archive to OpenShift Cluster Manager every 2 hours
The Insights Operator reports configuration and component failure status to Red Hat every 2 hours.
The InsightsOperator API group is operator.openshift.io/v1 — not config.openshift.io.
InsightsOperator config override precedence order: hardcoded defaults → observedConfig → unsupportedConfigOverrides.
An empty InsightsOperator gatherStatus or insightsReport means no data gathering has occurred — relevant for disconnected cluster scenarios.
InsightsOperator health check totalRisk ranges from 1–4; higher values indicate more critical issues.
InsightsOperator managementState controls the operator lifecycle with values: Managed, Unmanaged, Removed.
All install-config.yaml parameters (networking, platform, etc.) are immutable after OpenShift cluster installation.
The install-config.yaml parameters cannot be changed after cluster installation.
The install-config.yaml file is consumed/pruned by the installer during the transformation pipeline (install-config.yaml → Kubernetes manifests → Ignition configs) and must be backed up before installation
To install a specific Operator version, set startingCSV in the Subscription and use installPlanApproval: Manual.
OpenShift has multiple cluster-defining decisions that are permanently locked at install time and cannot be changed post-install: FIPS mode, CPU partitioning (workload partitioning), and the network plugin — creating a class of irreversible architectural choices that must be planned before cluster creation.
InstallPlan spec.approval must be either "Automatic" or "Manual" — this is a required field.
The InstallPlan approval strategy determines whether Operator upgrades are applied automatically or require admin approval.
InstallPlans must be approved (manually or automatically) before an Operator installs or upgrades
The InstallPlan attenuatedServiceAccountRef field enables scoped/least-privilege operator installation using a specific service account.
InstallPlan is a namespaced resource, not cluster-scoped.
The three required spec fields for an InstallPlan are approval, approved, and clusterServiceVersionNames.
The OpenShift integrated image registry runs in the openshift-image-registry namespace.
The integrated registry sends notifications to the cluster when new images are pushed, which can trigger builds and deployments automatically.
The OpenShift internal registry is configurable and can be enabled, disabled, or pointed at different storage backends (e.g., PVCs, S3 object storage).
The internal registry service endpoint is image-registry.openshift-image-registry.svc:5000.
OVN-Kubernetes gatewayConfig.ipForwarding defaults to Restricted (only Kubernetes traffic); Global forwards all traffic on OVN-managed interfaces
The IPAddress resource belongs to the ipam.cluster.x-k8s.io/v1beta1 API group and is part of the Cluster API IPAM subsystem, not core Kubernetes networking.
The IPAddress resource is namespace-scoped (not cluster-scoped).
The IPAddress spec has four required fields: address, claimRef, poolRef, and prefix; gateway is optional.
IPAddressClaim follows a claim-based allocation model: a claim referencing a pool is created, the IPAM controller allocates an address by creating an IPAddress object, and status.addressRef is populated with a reference to it.
IPAddressClaim status conditions have three required fields: lastTransitionTime, status, and type; the severity field is only set when Status=False.
IPAddressClaim is the request object and IPAddress is the fulfilled allocation object, following a claim/binding pattern similar to PVC/PV.
The IPAddressClaim spec has only one required field: poolRef, which itself requires kind and name.
With IPI (Installer-Provisioned Infrastructure) the installer manages cloud resources directly, while with UPI (User-Provisioned Infrastructure) the user provisions all infrastructure manually.
IPI installations on cloud providers get full MachineSet/MachineAPI support; UPI and bare-metal may have limited automation.
IPI — the installer manages infrastructure (networking, LBs, DNS, storage, machines); UPI — the user provisions and manages all infrastructure
IPPool spec requires both range (CIDR notation) and allocations fields; each allocation requires id and podref (with ifname optional)
IPPool belongs to API group whereabouts.cni.cncf.io/v1alpha1 and is a namespaced custom resource for managing IP address pools used by the Whereabouts CNI plugin
CNO generates a self-signed X.509 CA valid for 10 years; node certificates are valid for 5 years and auto-rotated after 4.5 years.
IPsec uses AES-GCM-16-256 encryption cipher (ICV=16 bytes, key length=256 bits).
IPsec encryption is disabled by default in OpenShift Container Platform and must be explicitly enabled via the networks.operator.openshift.io CR.
External IPsec requires NMState Operator, Butane tool, and routingViaHost=true in ovnKubernetesConfig.gatewayConfig.
Cluster MTU must be reduced by 46 bytes when IPsec is enabled to accommodate ESP header overhead.
IPsec is not supported on hosted control planes.
IPsec is not supported on RHEL compute nodes due to libreswan incompatibility.
IPsec uses Transport mode (not Tunnel mode) for pod-to-pod encryption on the OVN-Kubernetes cluster network.
IPsec requires UDP 500 (IKE), UDP 4500 (NAT-T), and ESP protocol to be allowed through firewalls.
Same-node pod traffic is never encrypted by IPsec.
IPsec has three modes: Disabled (default), Full (pod-to-pod + external), and External (external traffic only).
IPsec can be verified by running ovn-nbctl --no-leader-only get nb_global . ipsec inside an ovnkube-node pod, which returns true if enabled.
ipvlan shares the parent MAC address across pods; macvlan gives each pod a unique MAC address.
Image stream tags are formatted as <imagestream-name>:<tag> (colon-separated); image stream images are formatted as <imagestream-name>@<image-id> (at-sign separated).
Image stream tags maintain a history stack — new images are placed at the top, enabling rollback to previous image versions.
Tag-based mirroring via ImageTagMirrorSet carries the risk of pulling different images from different mirrors for the same tag; digest-based mirroring via IDMS avoids this
The Jenkins base agent image includes headless Java, Jenkins JNLP client, git, tar, zip, nss, and the oc CLI tool.
The default Java version in the Jenkins agent image is java-11, configurable via the USEJAVAVERSION environment variable.
Jenkins agent pods are deleted by default after build completion; pod retention options are never(), onFailure(), always(), and default().
Jenkins agent images are available from registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8.
Jenkins can be deployed on OpenShift via Samples Operator templates or a certified Helm chart.
Jenkins is on a deprecation path in OCP; OpenShift Pipelines (Tekton) is the strategic replacement for CI/CD.
Jenkins is deprecated in OpenShift Container Platform in favor of OpenShift Pipelines (Tekton).
Jenkins has its own dedicated documentation section in OpenShift Container Platform, available across versions 3.0 through 4.21.
Jenkins and Agent Base images moved from OCP install payload to ocp-tools-4 repository at registry.redhat.io starting in OCP 4.11.
Three image stream tags control Jenkins upgrade behavior: ocp-upgrade-redeploy (default, auto-redeploys on OCP upgrade), user-maintained-upgrade-redeploy (manual), and scheduled-upgrade-redeploy (periodic check).
JAVAMAXHEAP_PARAM takes precedence over dynamic heap calculation when set on Jenkins agent containers.
The Jenkins JNLP agent JVM uses 50% of container memory for heap by default (CONTAINERHEAPPERCENT=0.5); additional JVMs default to 25%.
Maven and NodeJS agent images were deprecated in OCP 4.10 and removed from the payload in 4.11; the recommended replacement is the sidecar pattern with the Jenkins Kubernetes Plugin.
Running Jenkins outside of OpenShift is not supported by Red Hat.
Jenkins in OpenShift integrates with the OpenShift OAuth server for authentication.
Starting with OCP 4.12, the bundled oc CLI in Jenkins images may not match the cluster version; pipelines needing a specific version must declare it in the pipeline DSL.
The jenkinsPipelineStrategy build strategy is deprecated; OpenShift Pipelines (Tekton) is the replacement
Jenkins pipelines were the original JenkinsPipeline build strategy in OCP before Tekton/Pipelines became the recommended approach.
Jenkins images are updated quarterly aligned with upstream Jenkins LTS; only the latest LTS version is supported by Red Hat.
The Job .spec.backoffLimit defaults to 6 retries before marking the Job as failed.
Job backoffLimit defaults to 6 retries with exponential backoff (10s, 20s, 40s…) capped at 6 minutes.
Jobs belong to the batch/v1 API group and are namespaced resources.
Job .spec.completionMode has two values: NonIndexed (default) and Indexed.
Pod failure policy actions are FailJob, FailIndex, Ignore, and Count; rules are evaluated in order with first match winning.
Job restartPolicy: Never creates new pods on failure (job controller retries), while restartPolicy: OnFailure restarts in-place on the same node (kubelet retries).
Pod restartPolicy in a Job template must be Never or OnFailure (not Always)
Job Pod restartPolicy must be Never or OnFailure; Always is not allowed.
Suspending a Job resets its startTime and activeDeadlineSeconds timer.
Setting ttlSecondsAfterFinished: 0 on a Job deletes it immediately after completion.
CSR Approved and Denied conditions are mutually exclusive and cannot be removed once added.
CertificateSigningRequest (CSR) objects are cluster-scoped (not namespaced) in the certificates.k8s.io/v1 API.
The minimum expirationSeconds for a CertificateSigningRequest is 600 seconds (10 minutes).
Of the three well-known Kubernetes CSR signers, only kubernetes.io/kube-apiserver-client-kubelet can be auto-approved by the csrapproving controller.
Kubernetes has three well-known CSR signers: kubernetes.io/kube-apiserver-client, kubernetes.io/kube-apiserver-client-kubelet, and kubernetes.io/kubelet-serving.
The K8S_FlowLayer field categorizes network traffic as either app or infra
In a partially disrupted Kubernetes zone (>55% nodes unhealthy), eviction rate is reduced from 0.1 to 0.01 nodes/sec; requires >3 zones and ≥50 nodes.
Kubernetes-native autoscaling in OpenShift spans two complementary dimensions: KEDA provides horizontal scaling based on external triggers (Cron, Kafka, Prometheus, CPU/Memory) via ScaledObject/ScaledJob, while VPA adjusts vertical resource requests/limits — covering both scale-out and scale-up patterns.
Key KEDA custom resources are: ScaledObject, ScaledJob, KedaController, and TriggerAuthentication
In KEDA CPU/Memory triggers, the type field is removed and replaced by metricType
Custom Metrics Autoscaler supported trigger types include: Cron, Kafka, Prometheus, Kubernetes workload, CPU, and Memory
The KedaController CR is automatically created during Custom Metrics Autoscaler Operator installation (since version 2.17.2)
The Kepler CRD is deprecated and replaced by the PowerMonitor CRD (starting with power monitoring 0.5).
Default Kepler metric levels are node, pod, and vm (not container or process).
Kepler default sample rate is 5 seconds and default staleness is 500 milliseconds.
PowerMonitor default security mode is rbac with TLS encryption, not none.
Kepler runs as a DaemonSet (one pod per node), as evidenced by DaemonSet-like scheduling status fields (desiredNumberScheduled, currentNumberScheduled, numberReady, etc.).
Kepler runs as a DaemonSet and is scheduled only on Linux nodes by default (kubernetes.io/os: linux).
Kernel bonding is the default bonding type when no OVS bonds are configured in OpenShift.
Kernel bonding only supports failovermac=0 (none); values 1 (active) and 2 (follow) are not supported by Red Hat.
On high-CPU nodes, container kernel memory overhead follows the formula: $(nproc) × 1/2 MiB due to per-cgroup kmem_cache.
Key escrow is not supported by OpenShift Container Platform; only TPM and NBDE are supported encryption methods.
The kn CLI interacts with OpenShift Serverless components (Knative Serving and Eventing).
The kn CLI manages both Knative Serving (services, revisions, traffic-splitting) and Knative Eventing (sources, triggers) components.
The kn CLI has a flexible plugin architecture modeled after kubectl's plugin system.
The Knative CLI (kn) is a separate CLI from oc, covering Functions, Serving, and Eventing operations.
Knative Eventing handles event-driven architectures via event sources, brokers, triggers, and channels.
Knative Eventing provides event-driven architecture capabilities (event sources, brokers, triggers) in OpenShift Serverless.
Knative Serving handles request-driven compute — deploying and auto-scaling serverless containers, including scale-to-zero.
Krew works with oc even without the CLI Manager Operator installed.
The KubeStorageVersionMigrator operator manages a component that re-writes stored resources in etcd to their current storage version after API schema changes during upgrades
Kubernetes "kube-like" version sorting order: GA > beta > alpha, then by major/minor version number (e.g., v10 > v2 > v1 > v11beta2 > v3beta1 > v12alpha1).
The kubeadmin password is located at <install_directory>/auth/kubeadmin-password.
The KubeAPIServer custom resource uses the API group operator.openshift.io/v1, not config.openshift.io
The KubeAPIServer operator resource name is always cluster (singleton pattern for OpenShift operators)
There are 8 standard kubelet containernetwork* metrics: 4 receive and 4 transmit (bytes, errors, packets, packets_dropped).
The default kubelet log verbosity level in OpenShift is 2 (KUBELETLOGLEVEL=2).
Kubelet evicts pods when individual container ephemeral storage usage exceeds its limit or total pod usage exceeds the sum of all container limits.
Kubelet log levels 0–4 are debug-level; levels 5–8 are trace-level.
One-time kubelet log level changes are written to /etc/systemd/system/kubelet.service.d/30-logging.conf and require systemctl daemon-reload && systemctl restart kubelet.
The kubelet only manages containers created by Kubernetes, not other containers on the node.
Persistent kubelet log level changes require a MachineConfig object with the machineconfiguration.openshift.io/role label targeting the correct pool (master/worker).
The kubelet runs on each node, reads container manifests, and ensures defined containers are running. kube-proxy also runs on every node and maintains network traffic between resources.
The kubelet must not be newer than kube-apiserver; it can be up to 1 minor version older on odd OCP releases or up to 2 minor versions older on even OCP releases.
KubeletConfig and ContainerRuntimeConfig are higher-level abstractions that generate MachineConfig objects under the hood via the Machine Config Operator.
KubeletConfig CRs are the supported way to modify kubelet parameters in OCP; direct kubelet config editing is not supported.
KubeletConfig is the dedicated CR for managing Kubelet parameters (e.g., pod limits, eviction thresholds), separate from MachineConfig.
KubeletConfig CR is used for managing Kubelet configuration on nodes; ContainerRuntimeConfig CR is used for CRI-O settings
A nil machineConfigPoolSelector in KubeletConfig selects no pools — it must be explicitly set for the config to take effect.
Invalid kubelet configuration values in KubeletConfig are not validated by the OpenShift API — they are passed through to the kubelet and can make nodes unusable.
KubeletConfig tlsSecurityProfile defaults to the cluster-wide setting from apiservers.config.openshift.io/cluster when unset.
KubeletConfig only supports Old and Intermediate TLS profiles; Modern is not supported and maximum minTLSVersion is VersionTLS12.
A new latestAvailableRevision value on OpenShiftAPIServer triggers pod redeployments (used as suffix for revisioned secrets like encryption-config)
The load balancer for OCP must proxy ports 6443 (Kubernetes API), 22623 (Machine Config Server), 80, and 443.
LDAP group sync (oc adm groups sync) automatically creates and maintains Group objects from external directory services.
LDAP with insecure: false and ldap:// URL upgrades to TLS via StartTLS; ldaps:// always uses TLS regardless of insecure setting
The Lease resource belongs to the coordination.k8s.io/v1 API group, not core/v1.
Leases are namespaced resources.
The leaseTransitions field on a Lease tracks the number of times the lease has changed holders.
Leases are used for leader election among controller replicas and for node heartbeats (kubelets maintain Lease objects in the kube-node-lease namespace).
OpenShift lifecycle management must navigate a fundamental tension: install-time and update-time constraints create irreversible platform boundaries, while the node fleet is inherently heterogeneous (RHCOS immutable nodes vs. Windows nodes with different runtimes and networking) — meaning lifecycle operations must account for divergent upgrade paths and capability profiles within a single cluster.
Deployment lifecycle hook failure policies are: Abort (fail deployment), Retry (retry until success), and Ignore (ignore failure and continue).
OpenShift Lightspeed is an AI-powered assistant delivered as a separate operator (version 1.0) with its own versioning independent of OCP.
OpenShift Lightspeed is a generative AI-powered virtual assistant accessed through a natural-language interface in the OpenShift web console.
OpenShift Lightspeed is available as of OpenShift Container Platform 4.17.
OpenShift Lightspeed is a generative AI-powered virtual assistant that provides a natural-language interface within the OpenShift web console.
OpenShift Lightspeed releases on a separate cadence from OpenShift Container Platform and has its own independent documentation set and versioning (e.g., Lightspeed 1.0 does not correspond to OCP 4.17).
OpenShift Lightspeed requires explicit verification of version compatibility with the underlying OpenShift Container Platform before installation.
OpenShift Lightspeed is accessed through the OpenShift web console, not the oc CLI.
LimitRange sets default, minimum, and maximum resource constraints per pod or container within a namespace, complementing ResourceQuota's aggregate limits.
LimitRange sets default resource values and min/max constraints on individual pods and containers within a namespace.
LimitRange sets default resource requests/limits per container in a project. ResourceQuota sets project-wide totals. They serve different purposes.
Pull secrets are linked to service accounts with oc secrets link <sa> <secret> --for=pull.
oc get packagemanifests -n openshift-marketplace lists all available Operators from OperatorHub catalogs.
oc api-resources -o name | grep config.openshift.io lists all cluster configuration resources
The command to list machines is oc get machine -n openshift-machine-api.
oc api-resources --api-group=oauth.openshift.io lists all OAuth API resources in OpenShift.
All Kubernetes/OpenShift List API responses share four fields: apiVersion, kind, items (required), and metadata (ListMeta).
Command to discover available Operators: oc get packagemanifests -n openshift-marketplace
Authorization resources prefixed with "Local" (e.g., LocalSubjectAccessReview, LocalResourceAccessReview) are namespace-scoped; non-local variants operate cluster-wide.
All three local storage solutions (HPP, LSO, LVM Storage) only support ReadWriteOnce (RWO) access mode — none support RWX.
Device paths in local storage configurations should use /dev/disk/by-id/ for stable identification.
Supported filesystems for LSO and LVM Storage are ext4 and xfs.
The Local Volume Operator is installed in the openshift-local-storage namespace.
Local volumes in OpenShift do NOT support dynamic provisioning.
The localhost-recovery.kubeconfig file on a control plane node can be used when admin.kubeconfig is unavailable.
OVN-K localnet topology requires bridge mappings configured via NodeNetworkConfigurationPolicy (NNCP) from the NMState Operator, where the localnet name in the NNCP must match the name field in the NAD.
LocalResourceAccessReview (authorization.openshift.io/v1) answers "who can do X?" — it returns which users and groups are authorized to perform a specified action within a particular namespace.
LocalResourceAccessReview is namespace-scoped; the namespace is part of the URL path (POST /apis/authorization.openshift.io/v1/namespaces/{namespace}/localresourceaccessreviews).
LocalResourceAccessReview asks "who can do X?" while LocalSubjectAccessReview asks "can user Y do X?"
When LocalSubjectAccessReview returns allowed=false and denied=false, the authorizer has no opinion — this is distinct from an explicit denial.
LocalSubjectAccessReview uses the upstream Kubernetes API group authorization.k8s.io/v1, not the OpenShift-specific authorization.openshift.io/v1.
LocalSubjectAccessReview spec must set exactly one of resourceAttributes (for resource requests) or nonResourceAttributes (for non-resource URL requests).
The upgrade from OpenShift Logging 5.x to 6.x is a documented manual migration procedure, not an in-place automatic upgrade.
OpenShift Logging 5.8 reached End of Life on November 3, 2025 and is replaced by Logging 6.0.
OpenShift Logging 6.x installation requires three operators: Loki Operator, Red Hat OpenShift Logging Operator, and Cluster Observability Operator (COO).
OpenShift Logging 6.x uses Loki (via LokiStack) as the default log store, replacing Elasticsearch from 5.x.
OpenShift logging follows a three-tier evolutionary architecture: three log categories (infrastructure/application/audit) flow through Vector (replacing Fluentd) into Loki (replacing Elasticsearch in 6.x), with the 5.x→6.x transition requiring manual migration — not automatic upgrade.
The OpenShift Logging collector (Vector) can be configured as an HTTP server to receive logs as a webhook input.
Elasticsearch, Fluentd, and Kibana are deprecated in OpenShift Logging 5.8 and removed in Logging 6.0; Vector (collector) + LokiStack (storage) is the preferred stack.
OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.
LogFileMetricExporter is no longer deployed by default with the collector in Logging 5.8; it must be manually created as a CR to generate log metrics.
In Logging 5.8, multiple isolated RBAC-protected ClusterLogForwarder CRs can be deployed in any namespace, not just openshift-logging.
OpenShift Logging is not installed by default — it requires installing the Red Hat OpenShift Logging operator (and typically a log store operator like Loki).
The OpenShift Logging Operator is not installed by default and must be installed separately.
Red Hat OpenShift Logging is a separate product with its own release cycle, not bundled directly under OCP.
OpenShift Logging is a separate installable component with its own release cycle, independent from core OpenShift Container Platform.
The stable subscription channel provides updates only for the most recent logging release; use stable-x.y (e.g., stable-5.7) to pin to a specific logging version.
OpenShift has three categories of logs: infrastructure logs, application logs, and audit logs.
Uninstalling OpenShift Logging requires removing the operators and the UIPlugin resource.
Default Loki perStreamRateLimit is 3 MB/sec and perStreamRateLimitBurst is 15; HTTP 429 errors are fixed by increasing these in the LokiStack CR
Loki "empty ring" error after reinstall is fixed by removing old PVCs and reinstalling LokiStack
Red Hat Loki Operator sets max message size to 100 MiB; spec.loki.batchSize must not exceed 98 MiB
The Loki tenant for Network Observability uses X-Scope-OrgID: network
LokiStack supports a 1x.extra-small deployment size for up to 100GB/day log ingestion.
LokiStack is the recommended log storage backend, replacing the deprecated Elasticsearch/Kibana stack.
LokiStack and log forwarding resources can be scheduled to specific nodes using node selectors and tolerations.
When lookupPolicy.local=true on an ImageStreamTag, docker short image references are resolved to image IDs from the image stream without contacting external registries; scoped to the current namespace only
The Local Storage Operator (LSO) installs into the openshift-local-storage namespace.
LSO uses the LocalVolume CR (apiVersion local.storage.openshift.io/v1) and only supports static provisioning — not dynamic.
LVM Storage is the only local storage solution in OpenShift that supports dynamic provisioning, PVC expansion, volume snapshots, and volume clones.
LVM Storage uses the TopoLVM CSI driver for dynamic provisioning and topology awareness.
Machine APIs are the declarative interface for managing compute node lifecycle (creation, scaling, deletion) in OpenShift.
The Machine, MachineSet, and MachineHealthCheck resources use API group machine.openshift.io/v1beta1
The Machine API handles all node host provisioning after cluster installation (not during installation).
Key Machine API objects are: Machine, MachineSet, MachineHealthCheck, MachineAutoscaler, and ClusterAutoscaler
Machine API objects reside in the openshift-machine-api namespace.
The Machine API Operator provisions exactly five resources: MachineSet, Machine, ClusterAutoscaler, MachineAutoscaler, and MachineHealthCheck.
Machine API operations require cluster-admin privileges.
The Machine API is only operational on installer-provisioned infrastructure (IPI); UPI installations do not have compute machine sets by default.
The Machine API scaling hierarchy is: ClusterAutoscaler → MachineAutoscaler → MachineSet → Machine → Node.
Machine management uses two API groups: machineconfiguration.openshift.io/v1 for node/OS-level configuration and machine.openshift.io (v1/v1beta1) for machine lifecycle.
Machine objects use API version machine.openshift.io/v1beta1, kind Machine.
The Cluster Machine Approver auto-approves CSRs for new worker nodes; the bootstrap node approves control plane CSRs.
MachineAutoscaler resources must be created in the openshift-machine-api namespace.
Machine configs are applied in lexicographic order (00* through 99*); last file wins for conflicts.
The annotation machine.openshift.io/delete-machine="true" marks a machine for preferential deletion when scaling down a MachineSet.
Machine deletion order is: preDrain hooks → drain node → preTerminate hooks → remove cloud instance → delete Node object.
Machine errorMessage/errorReason fields are set only for terminal (non-transient) problems requiring manual intervention
The Failed machine phase indicates an unrecoverable problem such as the cloud provider deleting the instance.
Machine lifecycle hooks have two types: preDrain (blocks drain and termination) and preTerminate (blocks termination, runs after drain completes)
Machine, MachineSet, and MachineHealthCheck are machine.openshift.io/v1beta1 (Compatibility Level 2), while ControlPlaneMachineSet is machine.openshift.io/v1 (Compatibility Level 1).
Machine management capabilities differ by installation type — IPI installations typically offer more automation than UPI
Not all machine management tasks are available in all installation types; some features require IPI (Installer-Provisioned Infrastructure).
Each Machine object has a 1:1 relationship with a Kubernetes Node, linked via status.nodeRef and providerID
Machine lifecycle phases are: Failed, Provisioning, Provisioned, Running, Deleting
Machines in OpenShift have five lifecycle phases: Provisioning, Provisioned, Running, Deleting, and Failed.
Machine phases progress through: Provisioning → Provisioned → Running → Deleting.
The providerID field on a Machine must match the Node's provider ID and is used by the cluster autoscaler to detect unregistered machines
A machine's status.nodeRef is populated only when it reaches the Running phase, after Ignition completes and the cluster machine approver approves the kubelet CSR.
The annotation machine.openshift.io/exclude-node-draining on a Machine skips node draining during deletion.
Taints on Machine/MachineSet spec are additively reconciled to the Node — the controller re-applies them if manually removed but does not remove other taints
MachineAutoscaler API group is autoscaling.openshift.io/v1beta1 — an OpenShift-specific CR, not upstream Kubernetes
MachineAutoscaler is namespaced, typically deployed in openshift-machine-api
MachineAutoscaler is a namespaced resource tied to specific MachineSets, defining min/max replicas for those MachineSets.
MachineAutoscaler scales MachineSets to add or remove worker nodes and references a specific MachineSet.
MachineAutoscaler spec has three required fields: minReplicas, maxReplicas, and scaleTargetRef
MachineAutoscaler requires the ClusterAutoscaler to be enabled in order to take effect
MachineAutoscaler scaleTargetRef requires kind and name but not namespace — the target must be in the same namespace
MachineAutoscaler uses autoscaling.openshift.io/v1beta1 (not yet GA), while ClusterAutoscaler is at v1
Best practice is to put MachineConfig CRs in SiteConfig extraManifests so they are applied at install time rather than post-install.
MachineConfig objects use Ignition spec version 3.2.0 for defining systemd unit drop-ins.
MachineConfig targets OS-level settings including systemd units, files on disk, and kernel arguments on RHCOS nodes.
Three distinct CR types control node configuration: MachineConfig (OS-level), KubeletConfig (kubelet), ContainerRuntimeConfig (CRI-O)
MachineConfig, KubeletConfig, and ContainerRuntimeConfig are the three primary custom resources for node-level configuration in OpenShift.
Changes applied via MachineConfig trigger node reboots, rolled out by the MCO through MachineConfigPools
Changes applied via MachineConfig typically trigger a rolling node reboot across the affected MachineConfigPool.
MachineConfigPool groups nodes that share the same machine configuration (e.g., worker, master pools)
MachineConfigPools group nodes that share the same machine configuration, using role labels like worker or master.
MachineConfigPool groups nodes that share the same MachineConfig and controls configuration rollout (e.g., master and worker pools).
MachineHealthCheck detects unhealthy machines, deletes them, and provisions replacements on supported platforms.
A separate MachineOSConfig CR is needed for each machine config pool when using on-cluster image layering.
Machine and MachineSet resources managed by the Machine API live in the openshift-machine-api namespace.
Machine, MachineSet, and MachineHealthCheck are namespaced resources typically in the openshift-machine-api namespace
The full API resource name for machine sets is machinesets.machine.openshift.io (not just machinesets).
MachineSet CR changes only affect newly created machines; existing machines are not updated when the MachineSet is modified.
MachineSet defaults: replicas is 1, deletePolicy is Random; valid delete policies are Random, Newest, Oldest
MachineSet deletion policy defaults to Random; other options are Newest and Oldest.
MachineSet has a dedicated /scale sub-resource for scaling operations
All MachineSet and Machine resources live in the openshift-machine-api namespace.
To propagate MachineSet changes: annotate old machines with machine.openshift.io/delete-machine="true", scale up to 2× replicas, wait for new machines to reach Running, then scale back down.
Each MachineSet is scoped to a single availability zone; the installer distributes MachineSets across zones automatically.
MachineSet selector must match the machine template's labels — a mismatch will cause issues
Setting managementState to Unmanaged on an operator.openshift.io/v1 resource stops the operator from reconciling changes
The managementState field on OpenShift operator resources controls operator behavior with values: Managed (active), Unmanaged (hands-off), Removed
The managementState field on operator.openshift.io/v1 resources controls whether the operator actively manages its component, with values: Managed, Unmanaged, Removed
Installing an Operator with Manual approval in a namespace causes all Operators in that namespace to use Manual approval and update together; use separate namespaces for independent updates.
Setting manual approval strategy applies to all Operators in the same namespace, not just the one being configured.
Token-based auth clusters (AWS STS, Azure Workload ID, GCP Workload Identity) require Manual approval strategy for operator Subscriptions
The label selector for control plane nodes is node-role.kubernetes.io/master; for workers it is node-role.kubernetes.io/worker.
The maximum number of EBS volumes per node is 39, with in-tree and CSI volumes counted separately.
The maxUnavailable default is 1 for all machine config pools; Red Hat recommends never setting it to 3 for the control plane pool.
Four critical MCD metrics that can block updates and upgrades: mcddrainerr, mcdpivoterr, mcdkubeletstate, and mcdrebooterr.
The MCD kubelet health failure threshold is 2 — exceeding it signals a problem via the mcdkubeletstate metric.
MCD metrics have been available since OpenShift Container Platform 4.3.
MCD logs are in namespace openshift-machine-config-operator, container machine-config-daemon.
The Machine Config Daemon (MCD) runs as a DaemonSet with one instance per node in the cluster.
The Machine Config Daemon has exactly three states: Done, Working, and Degraded.
The multicluster-operators-subscription image uses RHEL 9 base starting with MCE 2.10 (RHACM 2.10+); earlier versions use RHEL 8.
The only valid apiGroup for managedBootImages machineManagers is machine.openshift.io and the only valid resource is machinesets
failedRevisionLimit and succeededRevisionLimit default to 5 when set to 0 or unset; -1 means unlimited
Valid node disruption action types are Reboot, Drain, Reload, Restart, DaemonReload, and None — Reboot and None cannot be combined with other actions
nodeDisruptionPolicy supports a maximum of 50 file entries, 50 unit entries, and 10 actions per entry
managedBootImages must be explicitly configured in MachineConfiguration; when omitted, boot images are not updated during cluster upgrades
The Machine Config Operator (MCO) is the controller responsible for reconciling MachineConfig, KubeletConfig, and ContainerRuntimeConfig resources and applying changes to nodes.
The Machine Config Operator (MCO) manages and applies OS-level configurations and updates between the kernel and kubelet layers
The nodeDisruptionPolicy in MachineConfiguration only affects day-2 MachineConfig changes, not cluster upgrades
The MCO updates nodes alphabetically by zone (oldest first within a zone), cordons per maxUnavailable, then reboots.
The Machine Config Operator (MCO) reconciles MachineConfig objects and applies them to nodes
The MCO does not restart nodes for registry configuration changes — it restarts CRI-O only (cordon, restart CRI-O, uncordon)
MCO rollout process for config changes: render new MC → cordon → drain → write config → apply image → reboot.
MachineConfigPool uses API group machineconfiguration.openshift.io/v1 and is cluster-scoped (no namespace)
Default MachineConfigPools are master and worker; custom pools can be created for specialized node roles
In MCP, a node is degraded when configuration application fails; unavailable when updating or NodeReady is false
MachineConfigPool maxUnavailable defaults to 1 and cannot be set to 0; use paused: true to stop updates instead
Setting paused: true on a MachineConfigPool stops both generating new desiredMachineConfig and updating machines
MachineConfigPool updates respect Pod Disruption Budgets even when maxUnavailable is greater than 1
The Metadata APIs category in OpenShift 4.17 includes: APIRequestCount, Binding, ComponentStatus, ConfigMap, ControllerRevision, Event, Lease, and Namespace.
Metal3RemediationTemplate belongs to API group infrastructure.cluster.x-k8s.io/v1beta1 (Cluster API infrastructure provider), not metal3.io
Metal3RemediationTemplate remediation strategy is configured via spec.template.spec.strategy with fields: type (string), retryLimit (integer), and timeout (string for time between retries)
MachineHealthCheck references a Metal3RemediationTemplate to define what remediation action to take when a bare-metal machine is unhealthy
Bare metal clusters use MetalLB for load balancing with two complementary modes: Layer 2 (gratuitous ARP failover within ~10s) and BGP (constrained to single ASN/router-ID), providing external service access without cloud provider load balancers.
In OpenShift MetalLB, all BGP peers must share a single ASN (spec.myASN) and a single router ID — this differs from community MetalLB.
MetalLB external traffic policy local preserves client IP but risks uneven distribution; cluster (default) obscures client IP but distributes evenly.
MetalLB and IP failover are incompatible; IP failover must be removed before installing MetalLB.
MetalLB Layer 2 failover uses gratuitous ARP with typical failover within 10 seconds.
In MetalLB Layer 2 mode, all traffic for a service flows through a single node, making it a failover mechanism rather than a true load balancer.
Only one MetalLB CR instance is supported per cluster; deleting it removes MetalLB from the cluster.
The MetalLB Operator provides load balancing specifically for bare metal clusters, not cloud deployments
MetalLB uses six custom resources: MetalLB, IPAddressPool, L2Advertisement, BGPAdvertisement, BGPPeer, BFDProfile.
MetalLB operates in two modes: Layer 2 (using ARP/NDP, single-node traffic) and BGP (router distributes traffic across nodes).
The Metrics API group is metrics.k8s.io/v1beta1 and provides NodeMetrics and PodMetrics resources that back oc top commands and HPA decisions.
Both NodeMetrics and PodMetrics report memory usage as the memory working set, not RSS or total allocated.
The Metrics Server must be running in the cluster for oc top node and oc top pods to work; it is deployed by default in OpenShift.
NodeMetrics and PodMetrics use timestamp and window fields to define the collection interval: metrics were collected during [Timestamp - Window, Timestamp].
For control plane MachineHealthChecks, maxUnhealthy should be set to 1 to prevent action when multiple control plane nodes appear unhealthy.
A MachineHealthCheck with an empty selector matches all machines
A machine with Failed phase is remediated immediately by MachineHealthCheck without waiting for timeout.
MachineHealthCheck maxUnhealthy defaults to 100% if not set, meaning remediation always proceeds.
MachineHealthCheck maxUnhealthy is a circuit breaker — remediation stops if more than this many machines are unhealthy; setting it to 0 or 0% blocks all remediation
Setting MachineHealthCheck nodeStartupTimeout to "0" disables startup health checks (machines without nodes won't be remediated)
MachineHealthCheck remediates only one node at a time (drains and deletes) to limit disruption.
MachineHealthCheck resources must be paused before cluster updates using annotation cluster.x-k8s.io/paused="" in the openshift-machine-api namespace, and resumed after
Percentage-based maxUnhealthy values in MachineHealthCheck are rounded down.
MachineHealthCheck remediationTemplate is optional; without it, default remediation (delete and recreate machine) is used
MachineHealthCheck unhealthy conditions are OR'd — any single condition match triggers unhealthy status
Multi-Instance GPU (MIG) requires NVIDIA Ampere architecture or newer (A100, A30) and supports up to 7 independent GPU instances per physical GPU.
The minimum CPU allocation per pod is 10 mCPU (10 millicores), even if less is requested.
The minReadySeconds field controls when a pod counts as "available" (ready for at least that many seconds) versus merely "ready".
Mirror configuration from IDMS/ITMS/ImageContentPolicy is applied to nodes by the Machine Config Operator via /etc/containers/registries.conf, which may trigger node reboots
Mirror registries defined in registries.conf are automatically added to the unauthenticated ignore list — no need to list them under spec.unauthenticatedRegistries in AgentServiceConfig.
The ConfigMap for mirror registry configuration must be in namespace multicluster-engine with label app: assisted-service.
Mirror registries must support Docker v2-2 manifest format.
When cluster nodes have different MTU values, the cluster network MTU must be set to the lowest node MTU minus the overlay overhead.
Cluster Monitoring configuration is edited via the cluster-monitoring-config ConfigMap in the openshift-monitoring namespace.
The monitoring-to-alerting pipeline is fully layered: metrics collection feeds recording and alerting rules (evaluated at 30s default intervals), AlertRelabelConfigs filter before reaching Alertmanager, inhibit rules suppress duplicates via source/target matching, and silences require persistent storage — creating a complete observe→evaluate→route→notify chain.
Access to monitoring APIs is governed by cluster roles including cluster-monitoring-view, monitoring-edit, and monitoring-rules-edit.
Platform monitoring is automatic but both user workload monitoring and distributed tracing require explicit administrator action to enable, creating a two-tier observability model.
OpenShift monitoring uses a layered architecture where AlertingRules generate PrometheusRules, AlertRelabelConfigs filter before Alertmanager, and inhibit rules suppress cascading alerts — forming a three-stage alert pipeline.
OpenShift monitoring CRDs span two API groups: monitoring.coreos.com (upstream prometheus-operator) and monitoring.openshift.io (OpenShift-specific wrappers).
MTC uses MigCluster, MigStorage, MigPlan, and MigMigration custom resources for managing migrations
The Migration Toolkit for Containers (MTC) is the supported tool for migrating stateful application workloads between OCP 4 clusters
MTC is an Operator installed from OperatorHub — it is not a built-in platform feature
MTC supports two PV migration strategies: move (direct transfer) and copy (snapshot or filesystem copy)
MTC leverages Velero (via OADP — OpenShift API for Data Protection) under the hood for backup/restore operations
MTU migration on OpenShift requires at least two rolling reboots and is disruptive; rollback is not possible during migration.
MTU migration requires at least two rolling reboots of all cluster nodes; MCO reboots one node per pool at a time by default.
MTU migration is a 3-phase process: (1) patch CNO with migration spec on Network.operator.openshift.io, (2) update hardware MTU on nodes, (3) finalize by setting spec.migration to null and updating ovnKubernetesConfig.mtu.
You cannot roll back MTU during an active migration; rollback is only possible after the migration completes.
Migration Toolkit for Virtualization (MTV) is the official supported tool for migrating VMs at scale to OpenShift Virtualization from other platforms.
Multi-attach storage errors are resolved by either using RWX (ReadWriteMany) volumes or recovering/deleting the failed node for RWO (ReadWriteOnce) volumes.
OpenShift networking uses a layered CNI architecture: OVN-Kubernetes as default primary CNI, Multus as meta-plugin for additional interfaces, connecting to SR-IOV, bridge, and macvlan secondaries.
OpenShift autoscaling operates at three distinct levels: infrastructure scaling (ClusterAutoscaler + MachineAutoscaler add/remove nodes), pod horizontal scaling (HPA for built-in metrics, KEDA for external triggers like Kafka/Cron), and pod vertical scaling (VPA adjusts requests/limits) — each level operates independently but infrastructure scaling is gated on having at least one MachineAutoscaler deployed.
The multicluster engine for Kubernetes Operator is included with OCP subscription but delivered separately from the core payload and must be explicitly installed.
Multicluster engine is enabled by default when Red Hat Advanced Cluster Management (RHACM) is installed.
Multicluster engine provides full lifecycle management for OCP clusters but only partial lifecycle management for non-OCP Kubernetes distributions.
MultiNetworkPolicy uses the API group k8s.cni.cncf.io/v1beta1, distinct from the native NetworkPolicy API group networking.k8s.io/v1
MultiNetworkPolicy applies network policy rules to secondary networks (additional interfaces attached via Multus CNI), not the primary pod network
MultiNetworkPolicy selectors depend on subnets config: with subnets defined, podSelector/namespaceSelector/ipBlock are available; without subnets, only ipBlock is allowed.
MultiNetworkPolicy spec is structurally identical to Kubernetes NetworkPolicy — same fields for podSelector, ingress, egress, and policyTypes
Only one StorageClass should be default at any time; multiple defaults trigger a MultipleDefaultStorageClasses alert, and the most recently created default is used.
Multiple Identity objects can map to a single User object, enabling authentication from multiple identity providers.
Multus automatically names attached secondary interfaces as net1, net2, net3, etc., unless overridden with the @name suffix in the pod annotation.
Multus CNI is the meta-plugin that enables attaching multiple network interfaces to pods in OpenShift
Audit logs are not collected by default with oc adm must-gather; they require explicit -- /usr/bin/gatherauditlogs
oc adm must-gather creates a temporary pod on a random control plane node to collect debugging data
To collect default data AND feature-specific data together, add --image-stream=openshift/must-gather alongside --image
oc adm must-gather default timeout is 10 minutes
The oc adm must-gather command is used to collect diagnostic data for submitting support cases to Red Hat.
In disconnected environments, import the must-gather image first with oc import-image is/must-gather -n openshift
oc adm inspect is the fallback when oc adm must-gather cannot schedule its pod
Multiple --image flags can be combined in a single oc adm must-gather command to collect data for multiple features
Network logs require -- gathernetworklogs; by default only OVN nbdb/sbdb databases are collected
oc adm must-gather is the primary recommended tool for collecting cluster diagnostic data when opening a support case with Red Hat.
oc adm must-gather requires the cluster-admin role
oc adm must-gather default --volume-percentage is 30%
MutatingWebhookConfiguration belongs to API group admissionregistration.k8s.io/v1
MutatingWebhookConfiguration webhooks can accept, reject, or modify incoming objects, unlike ValidatingWebhookConfiguration which can only accept or reject
Mutating admission plugins run before validating admission plugins in the admission chain.
NetworkAttachmentDefinition uses API group k8s.cni.cncf.io/v1 and is a namespace-scoped resource defined by the Network Plumbing Working Group
NetworkAttachmentDefinition spec.config field is a JSON string (not a nested object) containing the full CNI plugin configuration
NetworkAttachmentDefinition (NAD) is the CRD used to define and configure secondary network attachments for pods
NetworkAttachmentDefinition (NAD) network names must be unique across the entire cluster; multiple NADs with different configs referencing the same network name is unsupported.
NAD network names are not namespaced — a network named identically in different namespace NADs enables cross-namespace pod communication on the same secondary network.
Namespace is a core v1 API resource in Kubernetes/OpenShift, served at /api/v1/ (not under any API group)
The /api/v1/namespaces/{name}/finalize PUT endpoint is used to clear finalizers and resolve a namespace stuck in Terminating state
Namespace finalizers are the mechanism that prevents premature deletion; a namespace stuck in Terminating typically has uncleared finalizers
Namespaces have exactly two phases: Active and Terminating
The dedicated /api/v1/watch/namespaces endpoints are deprecated; use the watch query parameter on list operations instead
Namespaces scope deployments, services, and pods, but do NOT apply to cluster-wide resources such as storage classes, nodes, and persistent volumes.
NBDE (Network-Bound Disk Encryption) ties LUKS encryption keys to network presence using Tang servers and Clevis clients, enabling automatic decryption without manual password entry.
NBDE must be enabled at OpenShift installation time, but disk encryption policy can be changed post-installation.
A node configured with NBDE that cannot reach its Tang servers at boot will retry indefinitely and cannot boot.
NBDE is the only supported OpenShift encryption method that protects against entire-server theft and never transmits keys over the network; TPM alone does not protect against entire-server theft.
Network Observability CLI default max capture time is 5 minutes for flows/packets and 1 hour for metrics; recommended max is 8-10 minutes
Network Observability CLI feature options (--enablepktdrop, --enablertt, --enabledns) work with flows and metrics commands but NOT with packets
Network Observability CLI default maximum capture size is 50MB
Network Observability CLI flow output is JSON + SQLite DB (./output/flow/), packet output is PCAP (./output/pcap/), and metrics output is a Prometheus dashboard via service monitor
The Network Observability CLI (oc netobserv) is installed separately from the Network Observability Operator — they are independent components
Console plugin registration requires both spec.consolePlugin.register: true in the FlowCollector and netobserv-plugin listed in console.operator.openshift.io
FlowCollector logTypes values for conversation tracking: Flows, All (highest storage), Conversations, EndedConversations (lowest storage)
Network Observability default-enabled metrics are namespaceflowstotal, nodeingressbytestotal, and workloadingressbytestotal
Network flow data can be exported to Kafka, stored in Loki, and used for Prometheus metrics via FlowMetrics API
eBPF flow filter actions: Accept (cache in eBPF table) and Reject (drop, don't cache); unmatched flows are cached by default
Network Observability Loki stream selector labels are: DstK8SNamespace, DstK8SOwnerName, DstK8SType, DstK8SZone, FlowDirection, K8SClusterName, K8SFlowLayer, SrcK8SNamespace, SrcK8SOwnerName, SrcK8SType, SrcK8SZone, _RecordType
Loki is the recommended storage backend for Network Observability flow logs
Network Observability metrics are configured via spec.processor.metrics.includeList in the FlowCollector custom resource
All Network Observability Operator metrics are prefixed with netobserv_ in Prometheus
The must-gather image for Network Observability is quay.io/netobserv/must-gather
Network Observability is a cluster-level capability, not namespace-scoped observation only
Network Observability Operator memory limits are configured via the Subscription object's spec.config.resources, not the FlowCollector
The Network Observability Operator is an optional, installable component — not enabled by default in OpenShift
Network Observability packet drops are classified as host drops (prefixed SKBDROP) and OVS drops (prefixed OVSDROP)
PacketDrop metrics require privileged mode enabled in spec.agent.ebpf.features of the FlowCollector CR
Network Observability RTT values are provided in nanoseconds; use divider: "1000000000" to convert to seconds for Prometheus
Network Observability RTT uses TCP smoothed RTT (sRTT) from the fentry/tcprcvestablished eBPF hookpoint
Network Observability provides three console views: Overview, Traffic Flows, and Topology — accessed under Observe → Network Traffic
Network Observability Topology view default layout is Cola; other options are ColaNoForce, Concentric, Dagre, Force, Grid
The Network Observability Operator uses eBPF technology for efficient flow collection at the kernel level
Multiple NetworkPolicy objects are additive — traffic allowed by any matching policy is permitted (union logic).
Network policy audit logs are stored at /var/log/ovn/acl-audit-log.log inside OVN-Kubernetes node pods.
OVN-Kubernetes network policy audit logging is enabled via the k8s.ovn.org/acl-logging annotation on the namespace, with deny/allow severity keys.
NetworkPolicy cannot block traffic from localhost or from the pod's resident node.
All pods in a project are accessible from all other pods and network endpoints until a NetworkPolicy is applied.
Default network policies for new projects are injected by modifying the project request template in the openshift-config namespace.
A NetworkPolicy with podSelector: {} and empty ingress: [] creates a deny-all-ingress policy; ingress: [{}] (empty rule) means allow-all-ingress.
Combined namespaceSelector + podSelector in a single from entry uses AND logic; separate from entries use OR logic.
To allow traffic from the OpenShift Ingress Controller, match on namespace label policy-group.network.openshift.io/ingress: "".
Multitenant isolation requires three policies per namespace: deny-by-default, allow-same-namespace, and allow-from-ingress.
NetworkPolicy only affects TCP, UDP, ICMP, and SCTP protocols — other protocols are unaffected.
A pod not selected by any NetworkPolicy remains fully accessible — it is not denied by default.
OpenShift networking combines a multi-CNI plugin architecture (OVN-Kubernetes + Multus for secondary interfaces) with dual-stack IPv4/IPv6 support, but dual-stack imposes additional constraints on service network blocks, MTU, and virtualization workloads.
The Network resource (config.openshift.io/v1) is a cluster-scoped singleton with canonical name cluster
The CNO connectivity check controller runs TCP connection health checks every minute in parallel, storing results in PodNetworkConnectivityCheck objects.
Network diagnostics are configured on the Network CR named cluster (API: config.openshift.io/v1) under spec.networkDiagnostics with modes All (default), Disabled, or empty string (= All).
Network connectivity check log reason values are: TCPConnect, TCPConnectError, DNSResolve, DNSError.
All network connectivity diagnostic resources live in the openshift-network-diagnostics namespace.
Node labels must be applied before updating the network diagnostics configuration — labels applied after are ignored.
The network diagnostics source pod is a Deployment (single replica) and target pods are a DaemonSet (runs on every node).
Network flow export (NetFlow, SFlow, IPFIX) is only supported on OVN-Kubernetes
The Network Metrics Daemon is a daemonset that collects and publishes network-related metrics including podnetworkname_info to supplement kubelet's built-in container network metrics.
The networkname label in podnetworknameinfo uses the format <namespace>/<NetworkAttachmentDefinition name>, derived from the Multus k8s.v1.cni.cncf.io/network-status annotation.
The Network Observability Operator is optional and provides an additional Netobserv dashboard when installed.
The network plugin (OVN-Kubernetes or OpenShift SDN) is selected at cluster install time.
When multiple NetworkPolicies select the same pod, the union of all their rules applies (policies are additive, not overriding).
Kubernetes NetworkPolicies operate at L3/L4 (IP address and port level) and do not support L7 filtering (e.g., HTTP path or header matching).
When any NetworkPolicy selects a pod, all traffic not explicitly allowed by a policy is denied; pods with no selecting policy allow all traffic.
Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy
NetworkPolicy rules use podSelector, namespaceSelector, and ipBlock to select traffic sources and destinations.
Consumers should read status (not spec) on the Network config to see the currently deployed network configuration
The Network operator resource (operator.openshift.io/v1) is always named "cluster" — exactly one per cluster
OpenShift network security is primarily implemented through two distinct mechanisms: network policies (pod/namespace-level ingress/egress) and egress firewalls (cluster-to-external traffic).
The only currently supported networkType value is OVNKubernetes
OpenShift networking and network observability form an integrated stack: the layered CNI architecture (OVN-Kubernetes + Multus) with dual-stack addressing provides the data plane, while the observability pipeline (eBPF→FlowCollector→Loki) provides flow-level visibility — both following the platform's explicit multi-component enablement pattern.
In both NetworkPolicy and MultiNetworkPolicy, an empty ingress array means deny all inbound traffic; an empty egress array means deny all outbound traffic
NetworkPolicy endPort field creates inclusive port ranges but cannot be used with named ports
In NetworkPolicy peers, ipBlock cannot be combined with podSelector or namespaceSelector in the same peer entry
Traffic from a pod's local node is always allowed for ingress, regardless of NetworkPolicy rules
When no NetworkPolicy selects a pod, all traffic is allowed by default (default allow); once any policy selects a pod, only explicitly allowed traffic is permitted
The only required field in a NetworkPolicy or MultiNetworkPolicy spec is podSelector; an empty podSelector {} matches all pods in the namespace
In NetworkPolicy and MultiNetworkPolicy, the protocol field defaults to TCP when not specified
Multiple NetworkPolicies selecting the same pod have their rules combined additively (union); you cannot use NetworkPolicy to deny traffic that another policy allows
Never scale a compute machine set to 0 without first relocating router pods, as they are needed for cluster access including the web console.
Worker machine sets should never be scaled to 0 without first relocating router pods, which run on workers by default and are required for web console access.
Node Feature Discovery (NFD) detects hardware features on nodes and labels them for scheduling purposes.
The Node Feature Discovery (NFD) Operator must be installed before the GPU Operator; NFD detects GPU hardware so the GPU Operator can manage it.
Node Feature Discovery (NFD) is typically required alongside GPU operators to detect hardware capabilities on nodes.
NFS supports all access modes (RWO, ROX, RWX). AWS EBS and Azure Disk only support RWO/RWOP.
If all NMState enactments fail, the problem is likely in the policy; if only some fail, the problem is likely node-specific.
NMState automatically rolls back failed network configurations — triggered by: failed apply, lost default gateway connectivity, or lost API server connectivity.
The NMState Operator cannot update the primary NIC or br-ex bridge on most on-premise networks.
NMState bonding configuration is base64-encoded and delivered via MachineConfig to the path /etc/nmstate/openshift/cluster.yml on nodes.
Kubernetes NMState provides declarative management of node network configuration (interfaces, bridges, bonds, VLANs, routes) via Kubernetes custom resources.
In disconnected environments, NMState health checks probe root-servers.net; the DNS server must have an NS entry for this zone or health checks will fail.
The NMState CR instance is a cluster-wide singleton and must be named nmstate.
The Kubernetes NMState Operator installs into the openshift-nmstate namespace.
The jsonpath filter '{.status.conditions[?(@.type=="Failing")].message}' extracts the error message from an NMState enactment resource.
Uninstalling the NMState Operator via OLM does not automatically delete CRDs, CRs, or API Services — manual cleanup is required.
The NMState Operator must be installed separately from OperatorHub; it is not enabled by default in OpenShift.
The Kubernetes NMState Operator must be installed before NMState features can be used.
NMState resource shortnames: nncp (NodeNetworkConfigurationPolicy), nnce (NodeNetworkConfigurationEnactment), nns (NodeNetworkState).
NMState is supported on bare-metal, IBM Power, IBM Z/LinuxONE, VMware vSphere, and RHOSP, with limited Azure support (DNS only).
Kubernetes NMState uses three core CRDs: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).
Kubernetes NMState uses three key custom resources: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).
NMState troubleshooting flow: oc get nncp (policy status) → oc get nnce (per-node status) → inspect failing enactment with jsonpath → oc get nns (actual node state) → oc edit nncp (fix policy).
NodeNetworkConfigurationEnactment (NNCE) tracks per-node status of policy application (success/failure), named as <node-name>.<policy-name>.
NodeNetworkConfigurationPolicy (NNCP) is the resource administrators create to declare and apply desired network state across matching nodes.
NodeNetworkState (NNS) is read-only and automatically created per node — it reports current network configuration.
All etcd operations must go through the API server or documented backup/restore procedures — direct etcd access is not supported.
Container processes in OpenShift must not listen on privileged ports (below 1024) because they run as non-root
Node affinity requiredDuringSchedulingIgnoredDuringExecution terms are ORed; within each term, match expressions are ANDed
Node affinity nodeSelectorTerms are ORed; matchExpressions within a single term are ANDed.
Node .status.allocatable defaults to .status.capacity; the difference represents resources reserved for system daemons.
The Node resource uses the core v1 API group (/api/v1/nodes) and is a cluster-scoped (not namespaced) Kubernetes resource.
A node can only belong to one MCP; custom pools take priority over the worker pool based on node labels.
spec.cgroupMode on the Node config controls whether nodes use cgroups v1 or v2; changing requires node reboots
Node condition .status field accepts three values: True, False, or Unknown.
Node configuration follows an immutable delivery pipeline: RHCOS nodes accept changes only via Operators and rpm-ostree atomic images, while image mirroring configuration flows through oc-mirror → IDMS manifests → MCO → registries.conf on nodes — both channels enforce the immutable infrastructure contract.
The Node resource (config.openshift.io/v1) is a cluster-scoped singleton with canonical name cluster, distinct from core Kubernetes Node objects
oc adm cordon sets unschedulable: true on a node, which only prevents new pod scheduling and does not evict existing pods.
The OpenShift node fleet is fundamentally heterogeneous: RHCOS nodes follow an immutable rpm-ostree model with operator-mediated changes, while Windows nodes use an entirely different container runtime (not CRI-O) and require OVN-Kubernetes hybrid networking — operational procedures, troubleshooting, and capacity planning must account for this runtime divergence.
Nodes send heartbeats every 10 seconds to the kube controller manager (node-status-update-frequency: 10s).
Correct node maintenance order: cordon first, then drain, perform maintenance, then uncordon.
The Node Metrics Dashboard is accessed from the Administrator perspective under Observe → Dashboards → Node cluster filter.
The Node Metrics Dashboard critical threshold for individual Kubelet and CRI-O reserved CPU and memory utilization is 50%.
No data appearing in the Node Metrics Dashboard Critical category means no anomalies were detected, not a dashboard malfunction.
The Node Metrics Dashboard critical threshold for overall system reserved CPU and memory utilization is 80%.
The default node-monitor-grace-period is 40 seconds; after this period without a heartbeat, node status becomes Unknown.
The node-monitor-grace-period is 40 seconds and cannot be modified; after this period without heartbeat the node is marked Unhealthy.
The Node .status.phase field is deprecated and never populated; .status.conditions should be used instead.
A node's podCIDRs field can contain at most 1 IPv4 and 1 IPv6 value for dual-stack support, and podCIDRs[0] must match podCIDR.
System reserved resources are calculated as total capacity minus allocatable (kubenodestatuscapacity - kubenodestatusallocatable).
Valid node selector operators are In, NotIn, Exists, DoesNotExist, Gt, and Lt.
Node selector operators are: In, NotIn, Exists, DoesNotExist, Gt, Lt
The status.nodeStatuses[] field on static pod operators tracks per-node deployment state including currentRevision, targetRevision, lastFailedRevision, and lastFallbackCount
Node taints support three effects: NoSchedule (hard block, existing pods stay), PreferNoSchedule (soft, scheduler tries to avoid), and NoExecute (evicts non-tolerating pods).
The Node Tuning Operator uses TuneD daemons for kernel tuning, running one per node across all nodes.
NodeMetrics is a read-only API resource (GET only; no create/update/delete) at endpoints /apis/metrics.k8s.io/v1beta1/nodes and /apis/metrics.k8s.io/v1beta1/nodes/{name}.
Setting nodeName on a Pod bypasses the scheduler entirely, directly assigning the Pod to the named node.
NodeNetworkState (NNS) resources are read-only and report current node network state.
Nodes are cordoned during graceful shutdown and must be uncordoned during restart to become schedulable.
Non-graceful node shutdown can be caused by hardware/system failures, missing Inhibitor Locks triggers, or misconfigured shutdownGracePeriod/shutdownGracePeriodCriticalPods settings.
Nutanix AHV is the hypervisor layer used for OCP installations on Nutanix; Prism Element manages individual clusters.
In OCP 4.17, the boot type for Nutanix VMs must be set to Legacy (options are Legacy, SecureBoot, UEFI).
The Cloud Credential Operator (CCO) must be set to manual mode for Nutanix installations — this is not optional.
The ccoctl binary for CCO manual mode is Linux-only and must be run in a Linux environment.
Nutanix provides CSI-based persistent storage integration (Nutanix Volumes/Files) out of the box for OpenShift.
The default (and only listed) network type for Nutanix OCP installations is OVNKubernetes.
Default compute replicas for Nutanix OCP installations is 3; control plane replicas must be 3 (or 1 for SNO).
The annotation machine.openshift.io/delete-machine="true" marks machines for deletion during scale-down on Nutanix (and other platforms).
On Nutanix, Disk.SCSI.0 and CDRom.IDE.0 device indices are reserved; custom data disks using those adapter types must start at deviceIndex 1.
Nutanix OCP installations require DNS records for api.<cluster>.<domain> and *.apps.<cluster>.<domain>, resolvable both externally and from within the cluster.
Machines across Nutanix Prism Element failure domains must reside on the same Ethernet network with subnets sharing the same CIDR containing cluster VIPs.
Three failure domains are recommended for high availability on Nutanix OpenShift clusters.
Nutanix failure domains enable high availability by distributing VMs across different Prism Element clusters and subnets.
Nutanix provides integrated OCP infrastructure: AHV hypervisor with Prism management, CSI-based persistent storage, GPU passthrough on compute nodes, and reserved disk indices for system use.
GPU passthrough is supported on Nutanix compute machines, identified by Name or DeviceID.
The Infrastructure CR (infrastructures.config.openshift.io) must be configured with failure domains before updating control plane or compute machine sets to reference them.
Parameters in install-config.yaml (including networking) cannot be changed after OCP installation on Nutanix.
OCP on Nutanix uses installer-provisioned infrastructure (IPI) as the primary installation method.
Nutanix is a supported IPI platform for OpenShift Container Platform, introduced in OCP 4.11.
Nutanix minimum versions for OCP 4.17: AOS 6.5.2.7+ and Prism Central pc.2022.6+.
Only one subnet per failure domain per OpenShift cluster is supported on Nutanix.
Only IPv4 addresses are supported for Nutanix network configuration in OCP 4.17.
Nutanix Prism Central is used as the management plane for OCP cluster provisioning on Nutanix.
Nutanix platform configuration requires apiVIPs and ingressVIPs as mandatory parameters in install-config.yaml.
OCP on Nutanix runs on the AHV hypervisor and integrates with Prism Central (not Prism Element directly) for IPI installations.
All Nutanix Prism Element instances used as failure domains must be managed by a single Prism Central instance; multi-Prism-Central is unsupported.
Nutanix infrastructure configuration requires prismCentral and prismElements; currently only one Prism Element per cluster is supported
A standard Nutanix OCP installation creates 3 control plane + 3 compute + 1 temporary bootstrap = 7 VMs during install (6 after bootstrap teardown), requiring minimum 800 GB storage.
Nutanix is a supported installation platform for OpenShift Container Platform.
Nutanix is a supported installation platform for OpenShift Container Platform 4.17, running on Nutanix AHV (Acropolis Hypervisor).
Nutanix supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods for OCP.
UPI clusters on Nutanix may leave behind resources requiring manual cleanup after openshift-install destroy cluster.
Nutanix installations use Prism Central (not Prism Element) as the API endpoint for the OpenShift installer integration.
The NVIDIA GPU Operator is supported only by NVIDIA, not by Red Hat.
OADP 1.1.x is required for CSI backup on OCP 4.11+ because OADP 1.0.x uses snapshot.storage.k8s.io/v1beta1 which is absent on 4.11+.
OADP 1.4 supports OCP 4.14–4.17; OADP 1.3 supports OCP 4.12–4.15.
OADP (OpenShift API for Data Protection) is the supported method for application-level backup and restore and is built on Velero.
In OADP 1.4, the CSI plugin is built into Velero and no longer requires a separate init container.
OADP Data Mover uses Kopia under the hood to move CSI snapshots to remote object storage.
OADP provides five core APIs: Backup, Restore, Schedule, BackupStorageLocation, and VolumeSnapshotLocation.
Full cluster backup and restore is not supported by OADP — only workload namespaces and cluster-scoped resources.
OADP installs in the openshift-adp namespace by default.
OADP (OpenShift API for Data Protection) is the supported backup and restore solution for OpenShift Container Platform.
OADP (OpenShift API for Data Protection) is the Red Hat-supported solution for application backup and restore, built on Velero.
OADP (OpenShift API for Data Protection) is not a disaster recovery solution for etcd or OpenShift Operators — it only protects customer workloads, cluster-scoped resources, and persistent volumes.
OADP requires the cluster-admin role and object storage (S3-compatible, AWS, Azure, GCP, ODF, IBM Cloud).
OADP upgrades must be sequential — never skip minor versions (e.g., 1.1→1.2→1.3→1.4).
OAuth API objects in OpenShift live in the oauth.openshift.io API group and are OpenShift-specific extensions (not part of upstream Kubernetes).
OAuth API resources in OpenShift belong to the oauth.openshift.io/v1 API group.
OAuth API objects (OAuthClient, OAuthAuthorizeToken, OAuthAccessToken, UserOAuthAccessToken, OAuthClientAuthorization) are OpenShift-specific resources, not part of standard Kubernetes.
On OAuthAuthorizeToken, both userName and userUID must match for the token to be valid (dual verification).
OAuthAuthorizeToken supports PKCE (RFC 7636) via codeChallenge and codeChallengeMethod fields.
All five OAuth API resources have Compatibility Level 1: stable within a major release for at least 12 months or 3 minor releases.
The OAuth resource configuration (oauth.config.openshift.io) is only honored when the Authentication resource has type: IntegratedOAuth.
The OAuth resource (config.openshift.io/v1) is a cluster-scoped singleton named cluster that configures the integrated OAuth server
Deleting an OAuthAccessToken object effectively revokes that user's session/token.
The expiresIn field on OAuth tokens is measured in seconds from CreationTimestamp, defining absolute maximum token lifetime.
The five OAuth API resources are: OAuthAccessToken, OAuthAuthorizeToken, OAuthClient, OAuthClientAuthorization, and UserOAuthAccessToken.
The inactivityTimeoutSeconds field on OAuthAccessToken is automatically incremented on token use, implementing sliding session expiry rather than fixed expiry.
The mappingMethod for OAuth identity providers defaults to "claim"
External OAuth metadata is stored in a ConfigMap in the openshift-config namespace; integrated OAuth metadata is in openshift-config-managed.
If a referenced secret/configmap for an OAuth identity provider is missing, the provider is silently not honored (no error)
OAuth config is only honored when the Authentication config has type set to IntegratedOAuth
OAuth API resources (OAuthAccessToken, OAuthAuthorizeToken, etc.) are cluster-scoped resources (no namespace in the API path).
All secrets and configmaps referenced by OAuth identity providers must reside in the openshift-config namespace
The OpenShift OAuth server is exposed via a route named oauth-openshift in the openshift-authentication namespace.
OpenShift OAuth session management operates through five API resources, where deleting an OAuthAccessToken actively revokes a user session — providing both programmatic and administrative session control.
Supported OAuth identity provider types: HTPasswd, LDAP, BasicAuth, RequestHeader, Keystone, GitHub, GitLab, Google, OpenID Connect
OAuthAccessToken inactivityTimeoutSeconds auto-increments when the token is used, resetting the idle timeout.
OAuth access token resource names use the format sha256~<base64url-hash>, derived by SHA-256 hashing the raw token and encoding with URL-safe unpadded base64 (RFC 4648).
The dedicated /watch/ endpoints for OAuth resources are deprecated; the ?watch=true query parameter on list operations should be used instead.
OAuthClient additionalSecrets field enables secret rotation without downtime by supporting multiple valid secrets simultaneously.
OAuthClient is a cluster-scoped resource (no namespace) in the oauth.openshift.io/v1 API group.
OAuthClient grantMethod field accepts auto (auto-approve for trusted clients) or prompt (requires user approval for third-party clients).
Changing accessTokenInactivityTimeoutSeconds on an OAuthClient does NOT retroactively affect existing tokens — only newly issued tokens.
OAuthClient respondWithChallenges: true returns WWW-Authenticate challenges instead of redirects, useful for CLI and non-browser clients.
OAuthClient scope restrictions use an allowlist model: any matching restriction allows the scope; if no restriction matches, the scope is denied.
OAuthClient accessTokenInactivityTimeoutSeconds minimum non-zero value is 300 (5 minutes); setting to 0 disables inactivity timeout entirely.
OAuthClientAuthorization is a cluster-scoped resource in the oauth.openshift.io/v1 API group.
Deleting an OAuthClientAuthorization effectively revokes the user's authorization for that OAuth client.
Both userName AND userUID must match for an OAuthClientAuthorization to be valid — knowing just the username is insufficient.
OpenShift observability is a specific instance of the platform-wide multi-component enablement pattern: like service mesh, it requires explicit opt-in beyond the default platform layer (user workload monitoring, distributed tracing), layered component composition (AlertingRules → PrometheusRules → Alertmanager), and multi-operator coordination.
Red Hat OpenShift Observability covers four signal types: metrics, logs, traces, and events.
Observability in OpenShift is provided as an integrated platform capability and is a top-level architectural concern, not a bolt-on or sub-component of another subsystem.
OpenShift observability operates through a layered enablement model: the monitoring stack itself is architecturally layered (AlertingRules → PrometheusRules → AlertRelabelConfig → Alertmanager), but only platform monitoring is automatic — user workload monitoring and distributed tracing require explicit admin action.
OpenShift Observability encompasses monitoring (Prometheus/Thanos), logging (OpenShift Logging subsystem), distributed tracing (Jaeger/Tempo), and network observability (flow-based analysis).
The observedConfig field on OpenShift operator resources is stored in .spec (not .status) because it serves as input to the operator's reconciliation loop
oc adm cordon marks a node unschedulable; oc adm uncordon re-enables scheduling; oc adm drain evicts pods and marks the node unschedulable.
Node maintenance uses oc adm cordon (mark unschedulable), oc adm drain (evacuate pods), and oc adm uncordon (mark schedulable again).
oc adm drain uses the Eviction API internally to safely remove pods from a node.
The oc adm groups command family is the primary CLI for group management (e.g., oc adm groups new, oc adm groups add-users, oc adm groups sync).
Groups are managed via oc adm groups new, oc adm groups add-users, and oc adm groups remove-users commands.
oc adm groups new, oc adm groups add-users, and oc adm groups remove-users are the standard commands for managing group membership
oc adm must-gather is the command to collect cluster data for Red Hat support cases.
The command oc adm node-logs --role <role> -u kubelet gathers kubelet logs by node role without requiring SSH access.
oc adm node-logs --role=master -u kubelet is the preferred way to get node logs over SSH when the API is accessible.
The command oc adm policy add-scc-to-user <scc> <user> grants an SCC to a user.
oc adm policy add-role-to-user and oc adm policy add-cluster-role-to-user are the primary commands for managing role assignments in OpenShift.
The CLI command oc adm policy who-can <verb> <resource> -n <namespace> uses the LocalResourceAccessReview/ResourceAccessReview API under the hood.
The -z flag in oc adm policy add-role-to-user specifies a service account (not a user). Example: oc adm policy add-role-to-user view -z default grants view to the default service account.
oc adm release mirror mirrors OCP release images to a local registry; its imageContentSources output must be added to install-config.yaml.
oc adm top nodes/pods requires both the metrics stack installed and cluster-reader permission.
oc adm upgrade --include-not-recommended shows conditional updates with known risks that are not normally displayed.
oc adm upgrade is the primary CLI command for viewing and applying cluster updates; --to-latest=true applies the latest, --to=<version> targets a specific version
oc adm upgrade status is a Technology Preview command requiring OCENABLECMDUPGRADESTATUS=true environment variable; works on clusters 4.12+
oc api-resources lists all available API resources including extensions; oc explain <resource> inspects API object schemas from the CLI.
Config API resources can be listed with oc api-resources --api-group=config.openshift.io
Available API resources on an OpenShift cluster can be discovered using oc api-resources and explored with oc explain <resource>
The oc api-resources command lists all available API objects in the cluster, including their short names, API groups, and whether they are namespaced.
The command oc api-resources lists all available API resources on an OpenShift cluster, including extension APIs.
oc auth can-i <verb> <resource> is the CLI equivalent of creating SubjectAccessReview/SelfSubjectAccessReview resources for checking permissions.
The oc auth can-i --as=<user> command is the CLI equivalent of creating a SubjectAccessReview
The oc CLI is the primary general-purpose OpenShift CLI tool, used by both administrators and developers.
The oc CLI is compatible with kubectl but provides additional OpenShift-specific features.
oc create token <service-account-name> creates a TokenRequest for a service account (bound token with audience/expiry).
oc debug node/<node> followed by chroot /host is the standard method to access a node's filesystem for troubleshooting.
oc describe clusterversion provides detailed update history and available updates for the cluster.
oc explain <resource>.config.openshift.io shows the schema/documentation for a cluster config resource
oc explain <resource> retrieves documentation directly from the cluster's API schema, useful for exploring resource fields.
The oc explain <resource> command inspects API object schemas directly from the cluster, with oc explain <resource>.spec drilling into spec fields.
The oc explain command can be used to inspect Operator API object schemas directly from the cluster.
The oc explain <resource> command displays API field documentation for a resource directly from the CLI.
The oc CLI extends kubectl with OpenShift-specific commands such as oc new-project, oc new-app, and others.
oc get clusterversion provides a quick summary of cluster version, availability, progressing status, and uptime.
The Homebrew formula for oc is openshift-cli (installed via brew install openshift-cli).
The oc idle <service> command scales all scalable resources associated with a service to zero replicas to conserve resources.
The oc idle command is limited to a single project — it cannot idle resources across multiple projects in one invocation.
The oc import-image command is the CLI interface to the ImageStreamImport API; use --confirm to actually import, --all to import an entire repository.
When oc runs inside a pod without a namespace specified, it defaults to the pod's namespace.
The oc login flow creates OAuthAccessToken objects behind the scenes.
The oc login --web flag runs a localhost HTTP server (not HTTPS) for the callback — a security concern on shared workstations.
The oc-mirror plugin generates IDMS manifests when mirroring content to a local registry
The oc CLI must match the cluster version — earlier versions of oc cannot complete all commands for the target OCP release.
oc new-app automatically creates ImageStream, Deployment, and Service (plus BuildConfig for S2I builds), but does NOT create Routes — routes must be created separately with oc create route edge.
oc new-app --template=<name> can instantiate applications from templates
The oc new-app <builder-image>~<git-repo-url> tilde syntax creates an S2I BuildConfig automatically.
oc new-project both creates a new project and switches the current context to that project.
oc new-project uses the ProjectRequest API, not direct Project creation.
The command oc patch pv <name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' changes the reclaim policy on an existing PV.
oc process renders a template into a resource list; oc new-app --template= can process and create resources in one step
The oc CLI respects HTTPPROXY, HTTPSPROXY, and NO_PROXY environment variables; authentication headers are only sent over HTTPS.
RPM installation of the oc CLI (yum install openshift-clients) is not supported on RHEL 9 — binary download must be used instead.
oc set image-lookup <imagestream> enables image lookup on an image stream; oc set image-lookup deploy/<name> enables it on a specific resource; --enabled=false disables it.
Health probes are set with oc set probe deployment/<name> --liveness|--readiness --get-url=http://:port/path --initial-delay-seconds=N.
The command oc set triggers deploy/<name> --from-image=<stream>:<tag> -c <container> configures image stream change triggers on a Deployment by setting the image.openshift.io/triggers annotation.
The default volume type when using oc set volume --add is emptyDir.
The --overwrite flag is required when updating an existing volume with oc set volume.
The oc start-build --from-dir command uploads local content as binary input to a build.
The default oc tag behavior creates permanent tags (pinned to image ID); use --alias=true to create tracking tags.
The oc binary version must match the cluster version; earlier versions cannot complete all commands.
OpenShift on OCI is installed using the Agent-based Installer, which provides Assisted Installation capabilities for both connected and disconnected environments.
The command ./openshift-install agent create image --log-level debug generates the agent ISO image for OCI installations.
Supported cluster topologies on OCI are: single-node, HA (3 control plane + 2 compute minimum), and compact 3-node (3 control plane only).
Disconnected OCI installations require bootArtifactsBaseURL in agent-config.yaml and a separately hosted rootfs image.
OCI installations require three DNS A records: api.<cluster>.<domain> and api-int.<cluster>.<domain> pointing to apiVIP, and *.apps.<cluster>.<domain> pointing to ingressVIP.
OVNKubernetes is the default network type used for OCI installations of OpenShift.
OCI is configured as platform.external with platformName: oci and cloudControllerManager: External in install-config.yaml — it is not a native integrated platform.
The rendezvousIP in agent-config.yaml must be an IPv4 address from the VCN CIDR that matches at least one booted instance's IP.
OCI installations support 64-bit x86 (amd64) and 64-bit ARM (arm64) architectures.
Oracle Cloud Infrastructure (OCI) is a supported installation target for OpenShift Container Platform starting from version 4.17.
Custom images on OCI must be configured to boot in UEFI mode for OpenShift installation.
OpenShift Cluster Manager is the control plane for ROSA (AWS), ARO (Azure), OSD (GCP/AWS) managed clusters, and also supports registered self-managed OCP clusters.
OpenShift Cluster Manager (OCM) is a Red Hat-hosted SaaS console at console.redhat.com for centralized management of OpenShift clusters, distinct from per-cluster web consoles.
OCM supports three cluster types: OpenShift Container Platform (self-managed), Red Hat OpenShift Service on AWS (ROSA), and OpenShift Dedicated.
OCM cluster update strategy can be set to automatic (scheduled day/time) or manual.
OpenShift Cluster Manager (OCM) is accessible at console.redhat.com/openshift and requires a Red Hat account belonging to an OpenShift organization.
The OpenShift version jump from 3.x to 4.x reflects a major architectural shift to an operator-driven, immutable infrastructure model using RHEL CoreOS and the Cluster Version Operator.
Starting with OCP 4.10, HTTPS certificates must contain Subject Alternative Name (SAN) fields; certificates with only CommonName are rejected.
OpenShift 4.17 favors Vector (collector) + LokiStack (store) over the legacy Fluentd + Elasticsearch logging stack.
OCP 4.17 follows OCP 4.16 in the continuous 4.x minor-version release cadence.
OpenShift Container Platform 4.17 has 16 optional cluster capabilities: baremetal, Build, CloudControllerManager, CloudCredential, ImageRegistry, Storage, Console, CSISnapshot, DeploymentConfig, Ingress, Insights, MachineAPI, marketplace, NodeTuning, openshift-samples, and OperatorLifecycleManager.
OpenShift Container Platform 4.17 supports optional cluster capabilities that can be selectively enabled or disabled.
OpenShift Container Platform 4.17 is built on Kubernetes 1.30 with CRI-O as the container runtime.
OpenShift Container Platform 4.21 has a dedicated documentation section for AI workloads, signaling first-class platform support for AI training.
OCP 4.21 is the current documented release of OpenShift Container Platform
OpenShift Container Platform 4.21 is the latest version in the 4.x release line as of the current documentation.
OpenShift Container Platform 4.x is built on Kubernetes for deploying and managing containerized applications at scale.
OpenShift adds additional default ClusterRoles beyond Kubernetes defaults, including admin, edit, view, cluster-admin, and self-provisioner.
OpenShift adds enterprise features that Kubernetes lacks at the platform level: authentication, networking, security, monitoring, and log management.
When updating across y-streams that remove Kubernetes APIs, OpenShift requires an admin acknowledgment (AdminAckRequired gate) via patching the admin-acks ConfigMap in openshift-config namespace.
Cluster admins can prevent authenticated user groups from self-provisioning new projects in OpenShift.
Admission plugins (pod security admission, SCCs, cluster resource quotas, image reference resolution) do not work in highly privileged projects.
The Agent-based Installer is available starting from OCP 4.12.
The Agent-based Installer generates a bootable ISO containing the cluster configuration, eliminating the need for a separate bootstrap machine.
The Agent-based Installer is the recommended method for disconnected/air-gapped on-premise OpenShift installations.
OpenShift AI workload support focuses on large-scale AI training workloads running reliably across multiple nodes (distributed training).
Each AlertingRule generates a corresponding PrometheusRule in the openshift-monitoring namespace.
The AlertingRule resource only permits alerting rules; recording rules are explicitly prohibited.
Cluster admins must use the AlertingRule resource (monitoring.openshift.io/v1) to create custom alerts on the platform monitoring stack — not PrometheusRule directly.
AlertmanagerConfig uses API version monitoring.coreos.com/v1beta1 (beta, not yet stable v1).
AlertmanagerConfig is namespace-scoped — it only applies to alerts whose namespace label matches the namespace where the resource is created, enforced by the operator.
The route defined in AlertmanagerConfig is added as a first-level route in the generated Alertmanager configuration.
Secrets referenced by AlertmanagerConfig must be in the same namespace as the AlertmanagerConfig object.
AlertRelabelConfig supports actions: Replace (default), Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep.
AlertRelabelConfig relabeling is applied after alerting rules fire but before alerts reach Alertmanager.
AlertRelabelConfig is an OpenShift-specific CRD (monitoring.openshift.io/v1), not an upstream Prometheus/Kubernetes resource.
AlertRelabelConfig spec.configs array is evaluated sequentially — order matters.
OpenShift Container Platform is API-driven — all cluster operations can be performed via the REST API, and every oc command corresponds to an underlying API call.
OpenShift-specific API resources live in their own API groups, e.g. apps.openshift.io/v1 and route.openshift.io/v1.
The API load balancer requires TCP 6443 (Kubernetes API) and TCP 22623 (Machine Config Server, bootstrap only); the Ingress load balancer requires TCP 443 (HTTPS) and TCP 80 (HTTP)
The APIServer custom resource is named cluster and is edited with oc edit APIServer cluster.
The APIServer CR propagates TLS settings to: Kubernetes API server, controller manager, scheduler, OpenShift API server, OAuth API server, OAuth server, etcd, MCO, and Machine Config Server.
OpenShift runs containers with arbitrarily assigned UIDs; writable directories must be owned by root group (GID 0) with group-writable permissions (chgrp -R 0 /dir && chmod -R g=u /dir)
The Authentication operator resource is at API group operator.openshift.io/v1, distinct from the cluster-level auth config at config.openshift.io/v1.
The Authentication operator manages the OAuth API server and authentication-related components in OpenShift.
The OpenShift Authorization API is a key API group that governs RBAC and access control, using common shared object structures across API groups.
OpenShift Authorization API objects include Role, ClusterRole, RoleBinding, ClusterRoleBinding, SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview, and SelfSubjectRulesReview.
All OpenShift authorization API resources (authorization.openshift.io) are Compatibility level 1 — stable within a major release for at least 12 months or 3 minor releases.
Automatic image pruning is managed by the imagepruners.imageregistry.operator.openshift.io/cluster CR, running as a CronJob with default schedule 0 0 * * * (daily at midnight).
OCP distinguishes between automatic (Machine API-driven) and manual machine management approaches
OpenShift autoscaling operates at two levels: pod-level (HPA/VPA) and cluster/node-level (ClusterAutoscaler + MachineAutoscaler).
OpenShift Container Platform supports AWS as a first-class installation target with dedicated documentation.
On AWS IPI installations, OpenShift cluster nodes are placed on private subnets without public IP addresses; a bastion host on a public subnet is needed for SSH access
Azure Resource Manager (ARM) templates are the mechanism provided for UPI installations on Azure.
Default compute (worker) configuration on Azure is 3 replicas with premium_LRS disk type and 128 GB OS disk.
Microsoft Azure Government (MAG) regions are explicitly supported for OpenShift installations handling US government workloads.
Azure regions need at least 3 Availability Zones for proper HA distribution of the control plane.
IPI (installer-provisioned infrastructure) is the default installation method for Azure; UPI requires the administrator to manage infrastructure manually.
Only IPv4 is supported for OpenShift installations on Azure.
When using an existing Azure resource group (platform.azure.resourceGroupName), the group must be empty and used exclusively for the cluster.
OpenShift Container Platform supports Azure Stack Hub (on-premises Azure) as a separate installation platform from public Azure.
Microsoft Azure is a supported installation target for OpenShift Container Platform, with both IPI and UPI installation methods available
Each Azure UPI cluster requires 1 VNet with 2 subnets, 2 network security groups (controlplane on port 6443, node on ports 80/443), 3 load balancers, and 3 public IP addresses.
Default Azure UPI cluster requires 44 vCPUs total: 3 control plane nodes at StandardD8sv3 (8 vCPUs each), 3 workers at StandardD4sv3 (4 vCPUs each), and 1 bootstrap at StandardD8sv3 (8 vCPUs). Default Azure limit is only 20 per region.
OpenShift cluster backup strategy centers on etcd snapshots for preserving cluster state.
OpenShift Container Platform supports bare metal (direct physical server) installation as a first-class target.
The OCP bootstrap process uses a temporary bootstrap machine to create the control plane, which then creates compute nodes; the bootstrap machine is destroyed after initialization
OpenShift's built-in build system supports Source-to-Image (S2I), Docker, and Custom build strategies.
Builds and BuildConfigs are OpenShift-native resources not present in upstream Kubernetes.
OpenShift Container Platform is built on Kubernetes and its API is 100% Kubernetes-compatible — applications run identically on both with no changes required.
OpenShift includes a built-in OAuth server, which is a key differentiator from vanilla Kubernetes.
Canary rollout updates use custom MachineConfigPools with a pause/unpause workflow to update worker nodes in stages
Once a cluster capability is enabled in OpenShift Container Platform, it cannot be disabled — enabling is a one-way operation.
The baremetal capability depends on MachineAPI; it cannot be enabled without MachineAPI also being enabled.
The marketplace capability depends on OperatorLifecycleManager; it cannot be enabled without OLM also being enabled.
The Cloud Credential Operator supports Mint, Passthrough, Manual, or empty string credential modes (not all modes supported on all providers).
When short-term credentials (Azure AD Workload Identity) are used, ccoctl azure delete must be run after standard uninstall to clean up OIDC resources not removed by the installer.
OpenShift Container Platform provides multiple CI/CD solutions: OpenShift Pipelines (Tekton), OpenShift GitOps (Argo CD), Builds/BuildConfigs, and Jenkins (legacy).
OpenShift cluster FQDN follows the format <metadata.name>.<baseDomain>.
Cluster monitoring is enabled by default in OpenShift, while user workload monitoring must be explicitly enabled.
The Cluster Monitoring Operator (CMO) deploys and manages the monitoring stack, which includes Prometheus, Alertmanager, Thanos Querier, and Telemeter Client.
The Cluster Observability Operator (COO) is a separate operator from the default built-in cluster monitoring stack (Prometheus, Alertmanager, Grafana) and is used to deploy and configure observability components.
ClusterResourceQuota does not guarantee even distribution across projects — one project could consume the entire cluster quota budget.
ClusterResourceQuota can select projects by annotation (openshift.io/requester) or by label, but cannot use both simultaneously.
OpenShift cluster updates can be performed via the web console, CLI, or OpenShift Update Service (for disconnected environments).
OCP cluster updates are non-disruptive — the cluster remains online during the update process (in-place, zero-downtime upgrade model)
Cluster-wide proxy settings in OpenShift affect how all cluster components reach external resources
The Cluster Network Operator (CNO) is responsible for deploying and managing the CNI plugin selected at install time.
OpenShift Compatibility level 1 means the API is stable within a major release for a minimum of 12 months or 3 minor releases, whichever is longer
Config API objects in OpenShift are cluster-scoped resources that define platform-wide behavior (networking, authentication, scheduling, etc.)
The resource to edit for console branding (logo, product name) is consoles.operator.openshift.io cluster.
Both the OpenShift web console and the oc CLI are clients of the API; the API is the authoritative interface.
The web console is configured by editing the cluster-scoped resource with oc edit console.config.openshift.io cluster.
Console customization CRDs include: ConsoleLink, ConsoleNotification, ConsoleExternalLogLink, ConsoleCLIDownload, ConsoleYAMLSample, and ConsoleQuickStart.
Setting spec.authentication.logoutRedirect on console.config.openshift.io controls the post-logout URL and enables single logout (SLO) through the identity provider.
ConsoleLink CRD location valid values are: HelpMenu, UserMenu, ApplicationMenu, NamespaceDashboard.
ConsoleNotification CRD location valid values are: BannerTop, BannerBottom, BannerTopBottom.
CRI-O is the container engine in OpenShift Container Platform (not Docker); it runs as a systemd service on each node.
OCP uses CRI-O as the container runtime, not Docker
Control plane and bootstrap machines require minimum 4 vCPU, 16 GB RAM, 100 GB storage, 300 IOPS; compute machines require minimum 2 vCPU, 8 GB RAM, 100 GB storage, 300 IOPS
Control plane nodes must run RHCOS; compute nodes can run RHCOS or RHEL 8.6+
The OpenShift control plane does not support TLS 1.3 or the Modern TLS security profile.
Control Plane Only updates (formerly "EUS-to-EUS") in OpenShift are only viable between even-numbered minor versions (e.g., 4.14 → 4.16).
The control plane machine pool name must be "master" and the compute pool name must be "worker" in install-config.yaml.
All control plane nodes must run RHCOS; compute nodes can optionally run RHEL but only with UPI installations
The default cloudTokenPath for CredentialsRequest is /var/run/secrets/openshift/serviceaccount/token.
CredentialsRequest (cloudcredential.openshift.io/v1) is a namespaced resource managed by the Cloud Credential Operator.
Every CredentialsRequest must specify spec.secretRef to define where generated cloud credentials will be stored as a Secret.
CRI-O is the container runtime that ensures containers are aware they run on a FIPS-enabled host.
OpenShift uses CRI-O as the container runtime on RHCOS nodes and containerd on Windows nodes (via WMCO).
OpenShift Container Platform documentation covers version 4.21, with versions ranging from 3.0 through 4.21.
Custom console routes are configured via ingress.config.openshift.io cluster using spec.componentRoutes, not via the console operator (deprecated method).
Custom login error templates only work with redirect-based identity providers (request header, OIDC), not direct auth providers (LDAP, htpasswd).
Custom console logos are stored in a ConfigMap in the openshift-config namespace, with max-height 60px and max size 1 MB.
The Custom Metrics Autoscaler Operator in OCP is based on KEDA.
Custom project templates must be created in the openshift-config namespace and referenced via project.config.openshift.io/cluster.
The Cluster Version Operator (CVO) checks the OpenShift Update Service (OSUS) for valid updates and uses release images to perform upgrades
CVO spec.overrides with unmanaged: true blocks cluster upgrades and renders the cluster unsupported
Day 2 operations in OpenShift correspond to postinstallation configuration
Postinstallation configuration in OpenShift is referred to as "Day 2 operations," distinct from Day 0 (planning) and Day 1 (installation) activities.
Key Day 2 postinstallation tasks include configuring identity providers (OAuth), persistent storage, networking policies, node scaling, monitoring, logging, image registry storage, and cluster-wide proxy/certificate settings.
The default baselineCapabilitySet value is vCurrent, which enables all optional capabilities including any new ones added in future releases.
Default OpenShift cluster network CIDR is 10.128.0.0/14 with /23 host prefix, providing 510 pod IPs per node.
Key default cluster roles in OpenShift are: cluster-admin, admin, edit, view, and self-provisioner.
OpenShift 4.x default CNI plugin shifted from OpenShift SDN to OVN-Kubernetes in later 4.x releases.
Default compute (worker) replicas in OpenShift is 3; control plane replicas must be 3 (or 1 for single-node OpenShift).
The default host prefix is /23, giving 510 usable pod IPs per node
The default Ingress Controller in OpenShift Container Platform uses HAProxy.
The default Machine CIDR in OpenShift is 10.0.0.0/16 and cannot be changed after cluster installation
Default OCP network CIDRs: cluster network 10.128.0.0/14 with /23 host prefix (510 pod IPs per node), service network 172.30.0.0/16, machine network 10.0.0.0/16.
OVNKubernetes is the default (and only listed) CNI network plugin for OpenShift 4.17, supporting Linux and hybrid Linux/Windows nodes.
The default Pod CIDR (clusterNetwork CIDR) in OpenShift is 10.128.0.0/14 and can be expanded post-installation
Default compute node replicas: 3 (minimum 2); control plane replicas: 3 (or 1 for single-node OpenShift).
The default container runtime in OCP 4.17 is runC; crun is the alternative (C-based, by Red Hat).
The default Service CIDR in OpenShift is 172.30.0.0/16
Default OpenShift service network CIDR is 172.30.0.0/16.
Deleting an application in OpenShift's Developer perspective Topology view removes the application and all associated components.
Deleting an application in the OpenShift web console requires typing the application name to confirm deletion.
Deleting an ImageStreamTag removes both the spec and status entries for that tag.
Deployment and DeploymentConfig are the two object types for deploying applications in OpenShift.
The primary command for removing an IPI cluster from AWS is openshift-install destroy cluster --dir <installation_directory> --log-level info
The openshift-install destroy cluster command requires the original installation directory containing metadata.json — without it, the cluster cannot be programmatically removed.
The openshift-install destroy cluster command requires the metadata.json file in the installation directory to identify and delete cluster resources
To disable the web console, set spec.managementState: Removed on consoles.operator.openshift.io cluster.
To disable self-provisioning: remove subjects from the self-provisioners binding AND set annotation rbac.authorization.kubernetes.io/autoupdate: "false" to prevent automatic reset.
Disabling the NodeTuning capability can limit cluster scalability beyond 900 nodes or 900 routes.
Disconnected/restricted network OpenShift installations require mirroring installation images.
Distributed tracing in OpenShift Container Platform is used to store, analyze, and visualize microservices transactions in distributed systems.
OpenShift distributed tracing uses the Tempo architecture as the backend for storing and visualizing requests across microservices.
The cluster's full DNS name follows the pattern <metadata.name>.<baseDomain>.
The DNS Operator deploys and manages CoreDNS for pod name resolution in OpenShift (not kube-dns).
DNS-based service discovery is preferred over environment variables because environment variables break when services are recreated with new IPs; backend services must exist before frontend pods if using env-var discovery.
For dual-stack networking, IPv4 and IPv6 must use the same NIC for the default gateway and addresses must be listed in consistent order across all config parameters.
Capabilities can be enabled post-install using oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["<capability>"]}}}'.
etcd requires 10 ms p99 fsync duration; faster storage is strongly recommended for control plane nodes
OCP supports etcd encryption for data at rest and network encryption via IPsec or WireGuard with OVN-Kubernetes.
etcd is broken out as its own configuration topic in OpenShift, reflecting its criticality to cluster state (backup, restore, encryption)
Extended Update Support (EUS) is available on all even-numbered minor OpenShift releases (e.g., 4.14, 4.16).
New EUS/stable channel update paths are not available until 45-90 days after initial GA of an OpenShift minor release; use fast channel for early testing.
Every pod in OpenShift receives a unique IP address from the cluster network CIDR with no NAT between pods
Extended resources (e.g., GPUs) only support the requests. prefix in quotas — overcommitment is not allowed.
OpenShift extends the Kubernetes API with custom resource definitions (CRDs) for platform-specific functionality.
OpenShift Container Platform extends the upstream Kubernetes API with additional resource types including Routes, BuildConfigs, DeploymentConfigs, and ImageStreams.
OpenShift-specific APIs (e.g., Route, BuildConfig, DeploymentConfig, ClusterVersion, MachineSet) are implemented as Custom Resource Definitions (CRDs) on top of Kubernetes.
Azure File storage is incompatible with OpenShift FIPS mode.
In FIPS mode, etcd data-at-rest encryption uses the AES CBC algorithm and is applied after cluster installation.
FIPS mode and Azure File storage are incompatible — Azure File storage cannot be used when FIPS is enabled.
FIPS mode is enabled by setting fips: true in install-config.yaml.
The FIPS-capable OpenShift installer binary is named openshift-install-fips, distinct from the standard openshift-install.
FIPS mode must be enabled at install time from a FIPS-configured RHEL host and cannot be enabled post-install; supported on x86_64, ppc64le, and s390x only.
FIPS mode in OpenShift is an installation-time option (cannot be enabled post-install).
FIPS mode must be enabled at OpenShift cluster install time — it cannot be enabled after deployment.
OpenShift Container Platform FIPS support is available on x86_64, ppc64le, and s390x architectures only — aarch64 is NOT supported for FIPS.
FIPS mode requires running the OpenShift installer from a FIPS-enabled RHEL machine.
The FIPS-capable OpenShift installer must be run from a RHEL 9 machine that is already running in FIPS mode.
For FIPS mode, SSH keys must use RSA or ECDSA algorithms — ed25519 is not supported.
When FIPS mode is enabled, SSH keys must use RSA or ECDSA (ed25519 is not allowed)
FIPS mode in OpenShift is supported only on x86_64, ppc64le, and s390x architectures (not aarch64).
Firmware updates are NOT part of the OpenShift Container Platform update process — they are the customer's responsibility.
OCP provides five primary CLI tools: oc (OpenShift CLI), kn (Knative CLI), tkn (Pipelines CLI), opm (Operator catalog CLI), and Operator SDK (operator-sdk).
OpenShift Container Platform supports four types of hardware accelerators: GPUs, NPUs (Neural Processing Units), ASICs (Application-Specific Integrated Circuits), and DPUs (Data Processing Units).
OpenShift Container Platform provides four CI/CD solutions: OpenShift Builds, OpenShift Pipelines, OpenShift GitOps, and Jenkins.
OpenShift Container Platform 4.17 provides four installation methods: Assisted Installer, Agent-based Installer, installer-provisioned infrastructure (IPI), and user-provisioned infrastructure (UPI)
OpenShift Container Platform supports installation on Google Cloud Platform (GCP) as a first-class cloud provider.
OpenShift GitOps is based on Argo CD and provides declarative CD for managing cluster and application state via Git.
Groups in OpenShift are cluster-scoped and can be referenced in both ClusterRoleBindings and namespace-scoped RoleBindings.
Highly privileged projects are: default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label set to 0 or 1.
Pods requiring access to the host network (e.g., cloud metadata at 169.254.169.254) must set spec.hostNetwork: true in their pod spec.
Hosted control planes use different default CIDRs than standard clusters: pod 10.132.0.0/14, service 172.31.0.0/16
Hosted control planes (HCP) can be deployed on OpenShift Virtualization, AWS, bare metal, IBM Z, and IBM Power, including in disconnected environments.
Hosted control planes (HyperShift) is a supported cluster management model where control planes run as pods on a management cluster
OpenShift supports these identity providers: HTPasswd, LDAP, GitHub, GitLab, Google, OpenID Connect, Keystone, Basic Authentication, and Request Header.
All OpenShift Image APIs are in the image.openshift.io/v1 API group.
The --namespace flag on oc adm prune images only removes image streams, not images, because images are cluster-scoped resources.
Image pruning requires the system:image-pruner cluster role or cluster-admin privileges.
After manual image pruning, the registry must be redeployed to clear the blob metadata cache: oc rollout restart deployment/image-registry -n openshift-image-registry.
The OpenShift image registry cannot be used as a mirror target because it does not support pushing without a tag.
ImageStreamImage resources are accessed using the name format <STREAM>@<DIGEST>.
ImageStreamImport allows users to find, preview metadata, and import images from external registries before actually tagging them in an ImageStream.
ImageStreamMapping is for privileged integrators only; creating a mapping exposes the image to anyone who can view the stream.
OpenShift Container Platform includes a built-in private container registry installed with the cluster.
The Ingress capability must always be enabled — OpenShift cluster installation fails without it.
The Ingress Controller runs as a scalable pod inside the cluster, not as a separate infrastructure component.
OpenShift uses HAProxy as the underlying technology for Ingress Controllers.
The Ingress Controller converts TLS 1.0 to TLS 1.1 when using Old or Custom TLS profiles.
The Ingress Controller's TLS profile defaults to the API server's TLS profile setting if not explicitly configured.
Ingress dashboard metrics can be filtered by Top 10 Per Route, Top 10 Per Namespace, and Top 10 Per Shard.
The Ingress Controller is managed in the openshift-ingress-operator namespace.
Kubernetes Ingress resources are automatically translated into Route objects by OpenShift.
Alertmanager inhibit rules use sourceMatch and targetMatch with an equal labels list — when source alerts fire, target alerts with the same equal label values are suppressed.
OCP installation configuration is declarative, defined in install-config.yaml before the installer runs.
The install-config.yaml parameters are immutable after OpenShift cluster installation — networking, capabilities, FIPS, and workload partitioning cannot be changed post-install.
OpenShift Container Platform installation documentation is organized per-platform, with each supported platform (AWS, Azure, GCP, bare metal, vSphere, etc.) having its own dedicated installation path.
OpenShift supports installation into existing VPC (AWS, GCP) or existing VNet (Azure).
OpenShift Container Platform offers two primary installation approaches: Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI).
Some OCP install-time configuration choices are immutable or hard to change after installation, distinct from day-2 configuration that can be modified on a running cluster.
OCP installation proceeds through 12 stages: Ignition creation → bootstrap boot → control plane fetch → etcd cluster formation → temporary control plane → production control plane handoff → bootstrap shutdown → worker setup → Operator installation → day-2 configuration.
OCP has a dedicated validation and troubleshooting workflow as a post-installation phase in the cluster lifecycle
OpenShift Container Platform ships with an integrated container image registry managed by the Image Registry Operator.
Pulling from the integrated container registry requires get imagestreams/layers permission on the image stream.
OpenShift runs an internal OAuth server for authentication; identity providers are configured on this OAuth server.
OpenShift IP failover provides high availability for external-facing IP addresses using VRRP (Virtual Router Redundancy Protocol)
Installer-provisioned infrastructure (IPI) is the default installation method for OpenShift; UPI requires manual creation of infrastructure resources.
Jenkins is the legacy CI/CD option in OpenShift, being de-emphasized in favor of Tekton-based Pipelines.
Jenkins on OpenShift is a legacy approach; the platform has shifted toward Pipelines (Tekton) and GitOps (Argo CD).
Key cluster-level API resources in OpenShift include: ClusterVersion, Infrastructure, OAuth, DNS, Network, Ingress, Proxy, Scheduler, FeatureGate, Image, Build, and Project.
After installation, OpenShift uses a temporary kubeadmin admin account; a real identity provider must be configured for production and kubeadmin should then be removed.
Changing kubelet TLS settings via KubeletConfig triggers node reboots, applied by the Machine Config Operator.
Kubelet TLS settings can be verified by checking /etc/kubernetes/kubelet.conf on the node.
Kuryr network plugin was deprecated as of OCP 4.14 and removed in OCP 4.16.
The OpenShift latest tracking tag does not automatically update to the newest version — it must be manually updated, unlike Docker's latest behavior.
Groups can be synced from external LDAP directories using oc adm groups sync.
The link-local CIDR 169.254.0.0/16 is not reachable from the pod network; pods must use hostNetwork to access it.
Deploying and managing the OpenShift logging stack is a cluster administrator responsibility.
OpenShift Logging is a distinct subsystem from OpenShift monitoring (Prometheus/Alertmanager) — they serve different observability purposes.
OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.
OpenShift Logging is not installed by default — it requires installing the Cluster Logging Operator (and typically a log store operator like Loki Operator).
Logging 6 documentation is maintained as a separate documentation set at docs.redhat.com/en/documentation/redhatopenshift_logging/, not in the main OCP docs.
OpenShift Logging releases on a separate cadence from OpenShift Container Platform itself and is versioned independently.
OpenShift Logging collects three distinct log types: node system audit logs, application container logs, and infrastructure logs.
Custom login page templates (login, provider selection, error) are stored in Secrets in the openshift-config namespace, not ConfigMaps.
LokiStack-based customized alerts and recorded metrics require Logging version 5.7 or later.
Machine sets are used to manage both compute and control plane machines in OpenShift.
The MachineAPI capability can only be disabled when using user-provisioned infrastructure (UPI).
An image must have the openshift.io/image.managed annotation to be eligible for pruning by the image pruner.
Setting an operator's managementState to Unmanaged stops the operator from reconciling its managed component.
The managementState field on OpenShift operator resources accepts three values: Managed (default, operator reconciles), Unmanaged (running but not reconciled), and Removed (disabled entirely). This pattern is common across many OpenShift operators.
The Machine Config Operator (MCO) maxUnavailable defaults to 1 during cluster updates, controlling how many nodes are cordoned simultaneously
Worker nodes should be divided into MachineConfigPool groups of approximately 8-10 nodes for staged rolling updates in telco CNF environments.
MachineConfigPool pausing (spec.paused: true/false) is the mechanism to control when worker nodes reboot during OpenShift updates.
The metadata.name field in install-config.yaml must be 14 characters or fewer, using only lowercase letters, hyphens, and periods.
The MetalLB Operator provides external IP addresses for LoadBalancer-type services on bare metal clusters.
OpenShift supports minimum node topologies: SNO (1 node), TNO (2 nodes), and standard HA (3 control plane + workers).
OpenShift monitoring API objects include AlertingRule, AlertRelabelConfig, PrometheusRule, ServiceMonitor, and PodMonitor custom resources.
OpenShift Container Platform exposes dedicated Monitoring API objects as Custom Resource Definitions, separate from core Kubernetes APIs and operator APIs.
OpenShift Container Platform has dedicated monitoring API objects (PrometheusRule, ServiceMonitor, PodMonitor, AlertmanagerConfig, etc.) beyond what upstream Kubernetes provides
Monitoring configuration is done via ConfigMap objects in the openshift-monitoring and openshift-user-workload-monitoring namespaces.
Monitoring is the only observability component deployed by default in every OpenShift Container Platform installation; all other observability components must be installed separately.
The OpenShift monitoring stack is based on the Prometheus ecosystem (Prometheus, Alertmanager, Thanos).
The OpenShift Container Platform monitoring stack is built-in and ships pre-configured — it is not an optional add-on.
The OpenShift monitoring stack is based on Prometheus (metrics collection), Alertmanager (alert routing), and Thanos Querier (federated querying).
The OpenShift monitoring stack is pre-configured and deployed by default on OpenShift clusters — no installation required.
OpenShift Container Platform ships with a preconfigured, preinstalled, and self-updating monitoring stack for core platform components
The OCP monitoring stack is self-updating as part of the platform — no manual operator installation is needed for platform monitoring
Migration Toolkit for Containers (MTC) is the tool for migrating workloads between clusters or from v3 to v4
The Multus CNI meta-plugin enables attaching multiple network interfaces to pods in OpenShift.
Multus CNI enables multiple network interfaces on pods, connecting to SR-IOV, Macvlan, and other additional network types
OpenShift maps Kubernetes Namespaces to Projects — the terms are related but Project adds additional features
Network APIs are managed by the Cluster Network Operator and the Ingress Operator.
The Network Observability Operator is a separate installation — it is not enabled by default.
The Network Observability Operator stores flow logs in a Loki instance for querying, with optional Kafka as an intermediate message broker.
The Network Observability Operator uses eBPF agents on nodes to capture network flow data.
Network policies in OpenShift are namespace-scoped and use label selectors to define allowed traffic
OpenShift networking dashboards are accessed via Observe → Dashboards in the web console.
OpenShift manages networking components through Operators (e.g., Cluster Network Operator, DNS Operator, Ingress Operator) rather than static configuration.
OpenShift Container Platform networking is managed through multiple specialized Operators (Ingress, DNS, CNO, MetalLB, SR-IOV, PTP, NMState), not a single monolithic component.
The Cluster Network Operator (CNO) is installed by default in OpenShift and manages the pod network (SDN/OVN-Kubernetes)
The DNS Operator is installed by default in OpenShift and runs CoreDNS pods for cluster DNS resolution
The Ingress Operator is installed by default in OpenShift and manages HAProxy-based IngressControllers for route/ingress traffic
OpenShift organizes its APIs into distinct categories, with Node APIs being a specific category governing how nodes are defined, configured, and managed.
OpenShift Container Platform nodes run Red Hat Enterprise Linux CoreOS (RHCOS).
OpenShift Container Platform nodes run as RHCOS (Red Hat Enterprise Linux CoreOS) or RHEL.
The OAuth API server uses revision-based deployments tracked by latestAvailableRevision; new revisions trigger pod redeployments.
All observability components except Monitoring follow separate release cycles from core OpenShift Container Platform releases.
The OCP observability stack includes Monitoring, Logging, Network Observability, Distributed Tracing, OpenTelemetry, Power Monitoring, and Cluster Observability Operator
OpenShift has its own CLI (oc) that is distinct from but compatible with kubectl.
The oc explain <resource> command is used to inspect API object schemas at runtime, and oc api-resources lists available API resources.
oc expose svc/<service-name> is the quickest way to create a non-TLS route from an existing service.
Odd-numbered OpenShift Container Platform releases (e.g., 4.17) receive 18-month support; even-numbered releases are Extended Update Support (EUS).
OLM v1 (Operator Lifecycle Manager) is the current extension mechanism in OCP 4.21
Two on-premise installation methods exist: Assisted Installer and Agent-based Installer
OpenShift Container Platform references the Open Service Broker API as a mechanism for provisioning and managing service instances.
Operator logLevel valid values are Normal (default), Debug, Trace, and TraceAll.
Operators are the primary extension mechanism for OCP; most additional components (networking, security, observability, CI/CD, etc.) are delivered as Operators.
MetalLB, External DNS, and Ingress Node Firewall operators are optional and installed via OperatorHub
OVN-Kubernetes is the default/primary network plugin for OpenShift Container Platform
The two default web console perspective IDs are admin and dev, with visibility states Enabled, Disabled, or AccessReview.
OpenShift Pipelines is based on Tekton, a cloud-native Kubernetes-native CI/CD pipeline framework.
Red Hat OpenShift Pipelines is a cloud-native CI/CD solution based on Kubernetes resources (Tekton).
Both OpenShift Pipelines and OpenShift GitOps are installed as Operators from OperatorHub.
PodDisruptionBudget and Eviction are Policy API objects in OpenShift, controlling voluntary pod disruptions and eviction requests respectively.
PodTemplate is a core Kubernetes v1 resource, not an OpenShift-specific extension — unlike Template, TemplateInstance, and BrokerTemplateInstance which are template.openshift.io/v1
OpenShift Container Platform organizes its APIs into distinct groups, with Policy APIs being one such group covering access control, authorization, and policy enforcement.
Port 6443 is the Kubernetes API server port (load balanced to control plane); port 22623 is the Machine Config Server port (internal load balancer to control plane).
The Power Monitoring Operator tracks power consumption metrics (CPU, DRAM) at the container level and reports per namespace.
Power Monitoring in OpenShift tracks CPU and DRAM power consumption at container-level granularity and must be explicitly configured (not enabled by default).
Power Monitoring in OpenShift is typically powered by Kepler (Kubernetes-based Efficient Power Level Exporter), which exports power metrics as Prometheus metrics scraped by the in-cluster monitoring stack.
Power Monitoring in OpenShift is a Technology Preview feature.
Red Hat OpenShift Container Platform is the core self-managed product and the primary target of the EX280/DO280 certification track.
The API group for OpenShift project resources is project.openshift.io/v1.
Project deletion transitions through states: Active → Terminating → removed; no new content can be added during Terminating.
OpenShift Projects extend Kubernetes namespaces with additional metadata including display name, description, and requesting user annotations.
A project (or access to one with appropriate roles) is required before creating an application in OpenShift.
Projects can be self-provisioned by users (controlled by the self-provisioners cluster role binding), managed via oc new-project, oc project, and oc projects commands, and customized via ProjectRequestTemplate.
OpenShift Projects wrap Kubernetes namespaces with additional metadata and policy, serving as the primary multi-tenancy boundary; the Project API is an OpenShift-specific extension, not a vanilla Kubernetes API.
OpenShift projects are OpenShift's abstraction over Kubernetes namespaces, serving as the organizational boundary for applications.
The default Prometheus evaluation interval is 30 seconds unless overridden per rule group.
OpenShift Container Platform provides multiple CI/CD solutions, not a single integrated pipeline.
Provisioning APIs in OpenShift underpin the Bare Metal IPI workflow, managing BareMetalHost and Provisioning custom resources, and integrate with Metal³ and Ironic for bare-metal host discovery and provisioning.
Provisioning APIs handle lower-level infrastructure provisioning while Machine APIs manage the OpenShift-level machine lifecycle; these are separate API groups in OpenShift.
All oc adm prune commands default to dry-run mode; the --confirm flag is required to actually delete objects.
Default pruning retention values: --keep-complete=5, --keep-failed=1, --keep-younger-than=60m, --keep-tag-revisions=3.
The --prune-over-size-limit flag cannot be combined with --keep-tag-revisions or --keep-younger-than; they are mutually exclusive strategies.
Setting publish: Internal in install-config.yaml creates a private cluster inaccessible from the internet.
As of OCP 4.7.4, changes to the global pull secret no longer trigger node drains or reboots
The accessReviewResources field on ConsoleQuickStart controls which users can see a quick start based on RBAC permissions.
Quick starts are defined by the ConsoleQuickStart custom resource in API group console.openshift.io/v1.
The nextQuickStart field references other quick starts by their CR metadata name, not their displayName.
The BestEffort quota scope can only restrict the pods count (not CPU or memory).
In ResourceQuota, cpu and requests.cpu are interchangeable; same for memory/requests.memory and ephemeral-storage/requests.ephemeral-storage.
When a quota specifies requests.cpu or limits.memory, every incoming container must explicitly declare those values or creation is rejected.
Object count quotas use the count/<resource>.<group> syntax (e.g., count/deployments.apps).
Setting a storage class quota value to "0" prevents any use of that storage class in the project.
The four types of subjects in OpenShift RBAC are: Users, Groups, Service Accounts, and system identities.
RBAC in OpenShift operates at two levels: cluster roles (cluster-wide) and local/project roles (namespace-scoped).
The user who creates a project is automatically assigned the admin role for that project (via the default project template).
Required DNS records for OCP: api.<cluster>.<domain> (public+private), api-int.<cluster>.<domain> (private only), *.apps.<cluster>.<domain> (public+private), plus etcd A records and etcd-server-ssl.tcp SRV records
Projects starting with openshift- or kube- cannot be created with oc new-project; they require oc adm new-project.
Restricted/disconnected network clusters require a locally installed OpenShift Update Service (OSUS) instance and mirrored images
Restricted network (disconnected) installations require a mirror registry containing OCP images; the cluster shows "Unable to retrieve available updates" and Developer Catalog is unavailable by default.
SSH access to RHCOS nodes uses the core user; the SSH key is injected via Ignition config
Red Hat Developer Hub (RHDH) is based on the Janus IDP platform (upstream Backstage) and provides a centralized software catalog.
RHEL worker nodes require the OpenShift API to be updated before the kubelet during cluster upgrades
DNS records must be manually cleaned up after running the RHOSP UPI teardown playbooks.
For UPI on RHOSP, you must manually create Nova servers, Neutron ports, and security groups.
RHOSP UPI teardown playbook order: down-bootstrap, down-control-plane, down-compute-nodes, down-load-balancers, down-network, down-security-groups (dependent resources removed before infrastructure).
UPI cluster removal on RHOSP uses Ansible playbooks prefixed with "down-", not the openshift-install binary (which is used for IPI).
Rolling back an OCP cluster to a previous version is not supported — only forward updates are allowed.
The Route API object is an OpenShift-specific resource, not a core Kubernetes resource.
Load balancing strategy can be configured per-route with options: roundrobin, leastconn, source.
OpenShift Routes support three TLS termination types: edge, passthrough, and re-encrypt.
Routes are an OpenShift-specific resource for exposing services externally; Ingress is the upstream Kubernetes equivalent — OCP supports both
OpenShift Routes support TLS re-encryption, TLS passthrough, and blue-green traffic splitting — features not available in standard Kubernetes Ingress resources.
OpenShift automatically runs fsck on volumes before mounting them.
OpenShift Container Platform runs on Red Hat Enterprise Linux CoreOS (RHCOS) and uses kdump for kernel crash analysis.
Scalability and Performance is a top-level documentation section in OpenShift Container Platform covering both cluster scaling (changing capacity) and performance tuning (optimizing existing resources).
Security Context Constraints (SCCs) are an authorization mechanism for pod-level security that is related to but distinct from RBAC.
SecurityContextConstraints (SCCs) are unique to OpenShift and not present in vanilla Kubernetes, available via the security.openshift.io API group.
Supported secondary network types in OpenShift include SR-IOV, Macvlan, Bridge, and IPVLAN.
Secondary network configurations are defined using NetworkAttachmentDefinition (NAD) custom resources.
FIPS compliance mode in OpenShift Container Platform must be enabled at install time and cannot be enabled post-install.
OpenShift security documentation spans three domains: container security, certificate configuration, and encryption.
The self-provisioner cluster role is bound to system:authenticated:oauth by default via the self-provisioners cluster role binding.
RHACM, ACS, ODF, and Red Hat Quay require separate subscriptions regardless of whether you have OKE or OCP.
OpenShift Serverless is built on Knative and provides Kubernetes-native building blocks for serverless, event-driven applications on OpenShift.
When the OpenShift Serverless Operator is installed, the default resource type for new applications changes to Serverless Deployment
OpenShift Serverless is an optional component, not enabled by default, installed via the OpenShift Serverless Operator.
OpenShift Service Mesh is built on Istio and deployed via the OpenShift Service Mesh Operator along with dependent operators like Kiali and Jaeger/Tempo.
OpenShift Service Mesh has two active major versions (2.x and 3.x); 3.x was in tech preview as of OCP 4.17.
Service Mesh is categorized under Integration in OpenShift documentation, not under Networking
OpenShift Observability encompasses seven tools: Monitoring, Network Observability, Logging, OpenTelemetry, Distributed Tracing, Insights, and Power Monitoring.
OpenShift Observability has six core components: Monitoring, Logging, Distributed Tracing, Red Hat build of OpenTelemetry, Network Observability, and Power Monitoring.
Single Node OpenShift (SNO) and Two Node OpenShift are supported deployment topologies
OpenShift provides multiple specialized CLI tools beyond oc: kn (Serverless), tkn (Pipelines), helm (charts), oc-mirror (disconnected image mirroring), odo (developer), argocd (GitOps).
Direct SSH access to OpenShift nodes should only be used for disaster recovery; when the Kubernetes API is responsive, use privileged pods instead
OpenShift uses persistent volumes (PVs), persistent volume claims (PVCs), and StorageClasses as its core storage model with support for dynamic provisioning.
OpenShift 4.x uses the Container Storage Interface (CSI) as its standard plugin architecture for storage backends.
Three specific hardware accelerators are supported by OCP: NVIDIA GPU, AMD Instinct GPU, and Intel Gaudi.
OpenShift Container Platform supports multiple CPU architectures: x86_64 (amd64), ppc64le (IBM Power), and s390x (IBM Z).
The primary supported cloud/infrastructure installation targets for OCP include AWS, Azure, Azure Stack Hub, GCP, bare metal, and vSphere.
OCP 4.17 supports installation on AWS, Azure, Azure Stack Hub, GCP, IBM Cloud, IBM Z/LinuxONE, IBM Power, Alibaba Cloud, Nutanix, OpenStack, OCI, VMware vSphere, bare metal (UPI and IPI), and single node.
OpenShift Container Platform supports IPv4, IPv6, and dual-stack (IPv4 + IPv6) addressing
OpenShift Container Platform supports installation on IBM Cloud Bare Metal (Classic) infrastructure as of OCP 4.21.
OpenShift Container Platform supports installation on IBM Power systems using the ppc64le architecture.
IBM Power Virtual Server (cloud-based IaaS for Power architecture) is a supported installation platform for OCP 4.21, distinct from IBM Power bare metal.
OpenShift Container Platform supports installation on IBM PowerVC as a distinct platform option from other IBM Power deployment methods.
OpenShift Container Platform supports installation on IBM Z and IBM LinuxONE using the s390x architecture.
OCP 4.17 supports heterogeneous multi-architecture clusters that can include Power nodes alongside other architectures.
OpenShift Container Platform supports PTP (Precision Time Protocol) hardware for time synchronization in latency-sensitive workloads.
OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as an advanced networking feature beyond TCP/UDP.
OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as a transport-layer protocol, relevant for telecom workloads.
The Telemeter Client sends a subset of platform Prometheus data to Red Hat for Remote Health Monitoring.
Hardcoded namespace values in Template objects are removed during instantiation; only ${PARAMETER_REFERENCE} namespace values are preserved
To process/instantiate a template via the API, POST to the processedtemplates endpoint (/apis/template.openshift.io/v1/namespaces/{namespace}/processedtemplates)
The only required field in an OpenShift Template is objects — the array of resources to include
The only supported generator type for Template parameters is "expression", which produces random strings from regex-like patterns (e.g., [a-zA-Z0-9]{8})
A Template parameter's value field takes precedence over the generate/from generator — if value is set, the generator is ignored
Template parameters are referenced using ${PARAMETER_NAME} syntax (not {{}} or other formats)
oc process is the CLI command to process a template into a list of resources
A Template is the definition with parameters; a TemplateInstance is the record of an instantiation of that template
Templates can be stored in a project namespace or in the openshift namespace for cluster-wide availability
Templates are an OpenShift-specific resource type (API group template.openshift.io/v1), not available in vanilla Kubernetes
OCP provides three networking dashboard categories: Networking/Linux Subsystem Stats (utilisation, saturation, errors), Networking/Infrastructure (OVN-Kubernetes metrics), and Networking/Ingress (Ingress Operator metrics).
The three pillars of observability in OpenShift are monitoring (metrics via Prometheus/Alertmanager), logging (Loki/Vector), and distributed tracing.
OCP supports three distinct Oracle installation targets: Oracle Cloud Infrastructure (OCI), Oracle Distributed Cloud, and Oracle Edge Cloud.
The default TLS security profile for all OpenShift components (Ingress Controller, control plane, kubelet) is Intermediate, with minimum TLS 1.2.
OpenShift supports four TLS security profile types: Old, Intermediate, Modern, and Custom, based on Mozilla recommended configurations.
TLS version values in OpenShift use the format VersionTLS11, VersionTLS12, VersionTLS13.
The Topology view is in the Developer perspective (not Administrator) and is the primary UI for managing application lifecycle.
Jaeger has been deprecated in favor of Tempo as the tracing backend in recent OpenShift Container Platform versions.
Distributed tracing components in OpenShift are installed and managed via OLM Operators (OpenTelemetry Operator and Tempo Operator).
OpenShift distributed tracing has two main components: Red Hat build of OpenTelemetry (collecting/forwarding trace data) and Red Hat distributed tracing platform Tempo (storing/querying traces).
OpenShift has two parallel authorization API groups: authorization.openshift.io/v1 (6 resources) and authorization.k8s.io/v1 (4 resources).
OCP has two build systems: the traditional BuildConfig-based system (available since OpenShift 3.x) and the newer Shipwright-based Builds system.
OpenShift has two coexisting build systems: Shipwright (newer, extensible) and BuildConfig (legacy)
There are two Console resources: one under config.openshift.io (edited via oc edit for console config) and one under operator.openshift.io (used for operator management and quick start configuration).
Two Node OpenShift (TNO) is a supported cluster topology starting in OCP 4.21, distinct from SNO (1 node) and standard HA clusters (3+ control plane nodes).
The unsupportedConfigOverrides field on operator resources is unsupported by Red Hat and blocks cluster upgrades; it must be removed before upgrading.
OpenShift update channel stability progression is: candidate → fast → stable → eus.
OCP cluster updates are non-disruptive — the cluster remains online during the update process (except single-node OpenShift which requires downtime)
Rolling back a failed OCP cluster update is not supported — contact Red Hat support instead
The terms "updating" and "upgrading" are used interchangeably in OCP documentation
OCP cluster updates are designed to be performed without taking the cluster offline (in-place, zero-downtime model).
In UPI installations, kubelet serving certificate CSRs must be manually approved because the machine-approver cannot validate them automatically
UPI installation requires a minimum of 1 temporary bootstrap machine, 3 control plane machines, and 2 compute (worker) machines
UPI clusters may leave orphaned Azure resources that require manual cleanup since the installer didn't create all of them.
OpenShift extends Kubernetes with its own User and Group custom resource types that are not native to upstream Kubernetes.
User workload monitoring must be explicitly enabled; it is not active by default even though cluster monitoring is.
User objects in OpenShift are cluster-scoped resources (not namespaced).
The v4.11 baselineCapabilitySet includes only: baremetal, MachineAPI, marketplace, and openshift-samples.
OCP release versioning format: in 4.13.2, 4 = major, 13 = minor, 2 = z-stream.
OpenShift Container Platform versioning follows a major.minor scheme (e.g., 4.17).
Cluster capabilities can be viewed with oc get clusterversion version -o jsonpath='{.spec.capabilities}' (desired) and oc get clusterversion version -o jsonpath='{.status.capabilities}' (actual).
OpenShift Virtualization 4.17 requires OCP 4.17 — version alignment is mandatory.
On AWS, EBS gp3 storage does not support live migration or cloning; EFS does not support cloning or snapshots.
In OpenShift Virtualization, bandwidthPerMigration: 0 means unlimited bandwidth (this is the default).
Boot source images are stored in the openshift-virtualization-os-images namespace.
OpenShift Virtualization cannot run on single-stack IPv6 clusters.
CDI requires scratch space (a temporary PVC equal to the destination DataVolume size) during import and upload operations.
The cluster checkup framework for OpenShift Virtualization is Technology Preview in OCP 4.17 and includes three types: latency, DPDK, and storage checkups.
Cluster checkup results are stored in the same ConfigMap used for input (status fields are appended).
Three cloning strategies for VM disks: snapshot (default when snapshots available), csi-clone (must be explicitly configured), and copy (host-assisted, least efficient).
All OpenShift Virtualization components run in the openshift-cnv namespace.
A dedicated Multus network for live migration traffic is highly recommended to avoid saturating tenant workload networks.
Default file system overhead for VM PVCs is 5.5% of PVC space.
The default minCPU model for CPU feature labeling in OpenShift Virtualization is Penryn.
The default parallel migration limit in OpenShift Virtualization is 5 cluster-wide and 2 outbound per node.
Traffic on the default pod network is interrupted during live migration of VMs.
The annotation storageclass.kubevirt.io/is-default-virt-class: "true" marks a storage class as the virtualization default; if both OCP and virtualization default storage classes exist, the virtualization class takes precedence for VM disks.
The DPDK checkup verifies that VMs can run Data Plane Development Kit workloads with zero packet loss, and requires SR-IOV networking.
The enableCommonBootImageImport feature gate in HyperConverged CR controls automatic updates for Red Hat boot sources; custom boot sources are not affected by this gate.
The default VM eviction strategy is LiveMigrate for multi-node clusters and None for single-node OpenShift (SNO).
For failed/offline nodes, oc adm drain --force=true is required; hardware should be powered down before proceeding to avoid data corruption on shared storage.
Hot-plug memory and CPU from the web console are GA in OpenShift Virtualization 4.17.
HostPathProvisioner (HPP) pods must run on the same nodes as OpenShift Virtualization components — this is a hard requirement.
After installing the OpenShift Virtualization operator, a HyperConverged custom resource must be created to deploy the virtualization platform.
The HyperConverged CR has separate spec.infra.nodePlacement and spec.workloads.nodePlacement sections for placing infrastructure vs workload components.
To initiate live migration via CLI, create a VirtualMachineInstanceMigration object; to cancel, delete it with oc delete vmim. Alternatively, use virtctl migrate and virtctl migrate-cancel.
OpenShift Virtualization is an integrated feature of OpenShift Container Platform that allows running and managing virtual machines alongside containers, not a separate product.
IPAM is not supported in Network Attachment Definitions (NADs) for virtual machines.
KubeMacPool allocates unique MAC addresses from a shared pool for VMs; addresses persist across reboots.
The latency checkup requires a bridge interface on cluster nodes, at least two worker nodes, and a configured NetworkAttachmentDefinition.
Default live migration settings: completionTimeoutPerGiB=800, parallelMigrationsPerCluster=5, parallelOutboundMigrationsPerNode=2, progressTimeout=150.
The live migration network NAD must be created in the openshift-cnv namespace.
Live migration uses pre-copy mode by default (iteratively copies memory pages while VM runs); post-copy mode is opt-in via allowPostCopy: true and not recommended for critical data or unstable networks.
Live migration requires ReadWriteMany (RWX) shared storage as a hard requirement.
OVN-Kubernetes localnet requires OVS bridge configuration via NNCP before creating the NAD; layer2 topology does not require NNCP.
OVN-Kubernetes localnet supports network policies but not trunk access; Linux bridge supports trunk access but not network policies.
Masquerade mode is the required binding mode for connecting VMs to the default pod network; it uses NAT via a Linux bridge.
SR-IOV with Mellanox NICs causes node reboots when VFs are increased; Intel NICs reboot only if intel_iommu=on and iommu=pt kernel params are missing.
Live migration cluster-wide settings are configured in the HyperConverged CR under spec.liveMigrationConfig in the openshift-cnv namespace.
MigrationPolicy objects allow per-group migration configurations using label selectors on VMs and/or namespaces; when multiple policies match, the one with the most matching labels wins, with ties broken alphabetically by label key.
Live migration traffic in OpenShift Virtualization is encrypted with TLS by default.
Multus is a meta CNI plugin that enables pods and VMs to connect to multiple network interfaces using other CNI plugins.
OpenShift Virtualization must be installed into the openshift-cnv namespace; installing to any other namespace causes failure.
The Node Maintenance Operator (NMO) is a standalone Operator deployed from OperatorHub — it is no longer shipped with OpenShift Virtualization.
OpenShift Virtualization cannot run on single-stack IPv6 clusters.
Custom VM metrics in OpenShift Virtualization are exposed via node-exporter running as a DaemonSet inside the VM, not on the host.
Non-migratable VMs with LiveMigrate eviction strategy will block node drains and cluster upgrades; use LiveMigrateIfPossible or None instead.
ODF best practice for OpenShift Virtualization: use ocs-storagecluster-ceph-rbd storage class with VolumeMode: Block for best performance.
OpenShift Data Foundation deployments require a dedicated storage class for Windows VM disks.
The OpenShift Virtualization operator is called kubevirt-hyperconverged and is installed via OLM from the redhat-operators catalog source.
OVN-Kubernetes is the supported (required) network provider for OpenShift Virtualization.
OVN-Kubernetes localnet is the recommended method to expose VMs to the underlying physical network (preferred over Linux bridge).
Ports 49152 and 49153 are reserved by the libvirt platform and incoming traffic to these ports is dropped.
Post-copy live migration is GA in OpenShift Virtualization 4.17.
VM run strategies are: Always (same as running:true), RerunOnFailure, Manual, and Halted (same as running:false).
spec.runStrategy and spec.running are mutually exclusive in a VirtualMachine spec — using both is invalid.
VMs with RWO storage or passthrough devices (GPUs) cannot live migrate; they require evictionStrategy: None.
ReadWriteMany (RWX) access mode and Block volume mode are the recommended best practice for VM disks in OpenShift Virtualization.
VMs require RWX (ReadWriteMany) PVCs to be live migrated during node maintenance.
Single-node OpenShift (SNO) does not support live migration, HA, pod disruption budgets, or eviction strategies for OpenShift Virtualization.
SR-IOV setup order for VMs: SriovNetworkNodePolicy → SriovNetwork → VM config.
The storage checkup service account requires a cluster-reader ClusterRoleBinding (cluster-scoped, not namespace-scoped).
One StorageProfile is automatically created per StorageClass; if CDI does not recognize the provisioner, manual configuration is required (empty status section indicates this).
The OpenShift Virtualization operator subscription channel must be set to stable.
The Subscription object for OpenShift Virtualization node placement supports only nodeSelector and tolerations — it does not support affinity.
OpenShift Virtualization supported platforms include on-prem bare metal and AWS bare metal (c5n.metal); IBM Cloud Bare Metal is Tech Preview only; other cloud bare metal is not supported.
Connecting VMs directly to the underlay network is not supported on ROSA (Red Hat OpenShift Service on AWS).
The virt-default storage class (annotated storageclass.kubevirt.io/is-default-virt-class: "true") takes precedence over the cluster default storage class for virtualization workloads.
VM name must not exceed 47 characters or live migration will fail.
VMs must use DHCP to acquire IPv4 addresses when using masquerade mode on the default pod network.
vTPM data is ephemeral in OpenShift Virtualization — lost on migration or restart (affects BitLocker).
Memory overcommit in OpenShift Virtualization uses wasp-agent which assigns swap to worker nodes.
The watchdog device type for OpenShift Virtualization VMs is i6300esb with supported actions: poweroff, reset, or shutdown; requires the watchdog package installed and enabled inside the VM.
OpenShift Virtualization worker nodes must run RHCOS; RHEL worker nodes are not supported.
Virtual Routing and Forwarding (VRF) is supported in OpenShift for network segmentation, allowing multiple independent routing tables on the same node.
OpenShift Container Platform provides both a web console and CLI (oc) as first-class interfaces for cluster interaction
The OpenShift web console is a built-in, customizable web-based UI component of OpenShift Container Platform (not a separate install).
Optional web console capabilities (Pipelines, Serverless, Web Terminal) are installed as Operators through OperatorHub.
Web console user preferences are accessed from the masthead (top navigation bar) under the user profile
The OpenShift web console has two perspectives: Administrator and Developer; the default can be set in user preferences
OpenShift web console user preferences are automatically saved — no explicit save action is needed
The Web Terminal Operator provides a browser-based terminal with common CLI tools for interacting with the cluster from the web console.
When troubleshooting worker nodes, minimum wait times are 60 minutes for bare metal and 40 minutes for other platforms
Workload partitioning (cpuPartitioningMode: AllNodes) can only be enabled at install time and cannot be disabled after installation.
OpenShift workload APIs extend upstream Kubernetes with additional objects like DeploymentConfig and Build
OCP 3 to 4 is a migration, not an in-place upgrade — the architectures are fundamentally different
OpenShift Container Platform 4.x is fundamentally built on Operators — cluster Operators manage core platform components.
In OpenShift Container Platform 4.x, core platform components are managed as Operators.
OCP 4.x has two primary installation approaches: Installer-Provisioned Infrastructure (IPI, automated/opinionated) and User-Provisioned Infrastructure (UPI, manual/flexible).
OCP 4.x uses a fundamentally different architecture than 3.x, based on operators and immutable infrastructure.
OCP 4 uses RHCOS (Red Hat Enterprise Linux CoreOS) for control plane nodes, replacing the traditional RHEL-based masters in OCP 3
OCP 4.x uses the openshift-install binary for installation, replacing the Ansible playbook approach used in OCP 3.x.
The default EBS storage type for OpenShift Container Platform 4.10+ is gp3, provisioned via the AWS EBS CSI driver.
OpenShift Container Platform 4.17 supports CSI specification v1.6.0.
In OCP 4.17, the restricted-v2 SCC is applied to all newly created pods by default, which enforces the runtime/default seccomp profile.
In OCP 4.17, InfraEnv kernel arguments support only the append operation (no replace or delete).
OpenShift SDN is no longer supported in OCP 4.17; clusters must migrate to OVN-Kubernetes before upgrading to 4.17.
ARM64 OpenShift Virtualization supports Linux guests only with no live migration and no hotplug.
AWS bare metal OpenShift Virtualization does not support SR-IOV or bridge CNI; OVN-Kubernetes secondary overlay networks must be used instead.
NetworkAttachmentDefinition spec.config.type must be changed from cnv-bridge to bridge before upgrading from OCP 4.12 or live migration will fail.
A dedicated Multus network for live migration is highly recommended to avoid network saturation.
The default maximum number of parallel live migrations per cluster is 5 in OpenShift Virtualization.
The annotation storageclass.kubevirt.io/is-default-virt-class: "true" designates the default virtualization storage class; it takes precedence over the OCP default storage class.
Google Cloud support for OpenShift Virtualization is Technology Preview only (as of 4.21).
VMs with GPU passthrough cannot be live migrated and must set evictionStrategy: None.
Hot plugging volumes on running VMs requires enabling the HotplugVolumes feature gate on the HyperConverged CR in the openshift-cnv namespace.
The HyperConverged CR is the single entrypoint for configuring OpenShift Virtualization and creates CRs for all sub-operators.
IBM Z OpenShift Virtualization uses default CPU model gen15b and does not support memory hotplug, SR-IOV, PCI passthrough, vTPM, UEFI, Windows VMs, HugePages, or FIPS mode.
OpenShift Virtualization infrastructure nodes require 4 additional CPU cores total; each worker node needs 2 additional cores for virtualization management.
OpenShift Virtualization is an integrated feature of OpenShift Container Platform (not a separate product), enabling VMs to run alongside containers on the same platform.
Layer2 topology User-Defined Networks (UDNs) preserve VM IP addresses during live migration without NAT.
virt-launcher pods run libvirt in session mode as non-root (unprivileged), adhering to the restricted Kubernetes pod security standards profile.
Default live migration limits: 2 outbound migrations per node, 5 concurrent migrations per cluster.
OVN-Kubernetes localnet topology supports network policies and layer 2 access on primary NICs; Linux bridge supports trunk access but does not support network policies.
Masquerade is the default binding mode for connecting VMs to the pod network in OpenShift Virtualization; it uses NAT via a Linux bridge to hide VM traffic behind the pod IP.
Memory dump PVC must use FileSystem volume mode and be sized as (VMMemorySize + 100Mi) × FileSystemOverhead.
VM memory overhead ≈ (0.002 × requested memory) + 218 MiB + (8 MiB × vCPUs) + (16 MiB × graphics devices), plus additional overhead for SR-IOV/GPU (1 GiB each), SEV (256 MiB), and TPM (53 MiB).
Migration Toolkit for Virtualization (MTV) is a separate product from OpenShift Virtualization, requiring separate installation, and supports migration from VMware vSphere, RHOSP, RHV, OVA files, and other OCP clusters.
Multus is a meta CNI plugin that enables pods and VMs to attach to multiple network interfaces via other CNI plugins using NetworkAttachmentDefinition CRDs.
Node labels (feature.node.kubevirt.io) are not automatically removed when uninstalling OpenShift Virtualization and must be cleaned up manually.
OADP 1.3.x+ is required for OpenShift Virtualization 4.14+; OADP supports only CSI backups and CSI backups with DataMover (not file system backup or volume snapshot backup/restore).
Online VM snapshots have a default 5-minute failure deadline, configurable via FailureDeadline in the snapshot spec.
OpenShift Virtualization 4.21 requires OSSM 3.0.4 / Istio 1.24.4 for service mesh compatibility; OSSM 3.1.1 / Istio ≥1.25 are incompatible.
Ports 49152 and 49153 are reserved by the libvirt platform in OpenShift Virtualization; incoming traffic to these ports is dropped.
Public clouds (AWS, Azure, GCP, OCI) cannot connect VMs directly to the underlay; layer2 topology UDNs must be used instead.
The QEMU guest agent is required for application-consistent (quiesced) online snapshots; without it, only best-effort snapshots are taken.
VMs with ReadWriteOnce (RWO) storage cannot live migrate and must set evictionStrategy: None.
The recommended storage configuration for OpenShift Virtualization VMs is ReadWriteMany (RWX) access mode with Block volume mode.
ReadWriteMany (RWX) access mode with Block volume mode is the recommended storage configuration for OpenShift Virtualization.
RWX access mode is required for live migration of VMs; VMs with RWO access mode cannot be live migrated.
Service account tokens become invalid after VM migration because they are bound to the original pod; user accounts should be used instead.
Single-stack IPv6 support in OpenShift Virtualization is Technology Preview only, limited to OVN-Kubernetes localnet and Linux bridge CNI.
The Snapshot feature gate must be enabled in the kubevirt CR under spec.developerConfiguration.featureGates for VM snapshots to work.
VM snapshot management uses three CRDs: VirtualMachineSnapshot (create request), VirtualMachineSnapshotContent (provisioned resource, 1:1 with snapshot), and VirtualMachineRestore (restore request), all in API group snapshot.kubevirt.io/v1beta1.
Single-node OpenShift (SNO) does not support high availability, pod disruption, live migration, or eviction strategies for VMs.
Single-node OpenShift (SNO) does not support live migration, high availability, pod disruption budgets, or eviction strategies for OpenShift Virtualization.
SR-IOV in OpenShift Virtualization requires bare metal or RHOSP — it is not available on public clouds.
OpenShift Virtualization installation requires approximately 10 GiB storage overhead per node.
OpenShift Virtualization is SVVP-certified for Windows Server workloads on RHCOS workers with Intel/AMD CPUs only.
OpenShift Virtualization tested maximums: 216 vCPUs per VM, 6 TB RAM per VM, 500 hosts per cluster, 10,000 defined VMs per cluster.
TLS certificate rotation cadence: KubeVirt rotates daily, CDI every 15 days, MAC pool yearly — all automatic with no disruption.
Namespaces using a primary User-Defined Network must have the label k8s.ovn.org/primary-user-defined-network.
Legacy virtctl ssh syntax (type/name.namespace) is removed; must use explicit vmi/<name> or vm/<name> format.
VM disk storage class migration is now native to OpenShift Virtualization (no longer requires Migration Toolkit for Containers) and supports cross-namespace bulk migration.
Live migration fails if the VM name exceeds 47 characters in OpenShift Virtualization.
VMs connect to the pod network by default; secondary networks (Linux bridge, OVN-Kubernetes, SR-IOV) require explicit configuration.
VMs with vTPM devices cannot be cloned or created from snapshots.
Windows VMs on OpenShift Data Foundation require a dedicated storage class, with Ceph RBD preferred over CephFS.
Windows VMs require manual MTU configuration with netsh because the Windows DHCP client does not read MTU options.
OpenShift Virtualization worker nodes must run Red Hat Enterprise Linux CoreOS (RHCOS); RHEL worker nodes are not supported.
Oracle Database Appliance (ODA) is a distinct installation target from Oracle Cloud Infrastructure (OCI) in OpenShift documentation.
ODF 4.20 supports Metropolitan DR, Regional DR, and stretch cluster disaster recovery configurations, all GA.
ODF supports internal mode (storage runs on OCP nodes) and external mode (connects to external Red Hat Ceph Storage or IBM FlashSystem).
Multiple ODF storage clusters can coexist — an external cluster can be deployed alongside an existing internal cluster.
The Multicloud Object Gateway (NooBaa) is the ODF component that enables hybrid and multicloud object storage resource management.
Red Hat OpenShift Data Foundation (ODF) provides block, file, and object storage as a software-defined storage solution for OpenShift.
OpenShift Data Foundation (ODF) provides agnostic persistent storage supporting file, block, and object storage for OCP.
The odo CLI tool is no longer covered in official OpenShift documentation; it falls under Cooperative Community Support, not standard Red Hat product support.
OKE includes cluster monitoring (Prometheus) but excludes User Workload Monitoring.
OKE excludes developer console, S2I/builder automation, OpenShift Pipelines, odo CLI, and Dev Spaces.
OKE excludes Service Mesh (Istio/Kiali), Serverless (Knative/Kourier), Distributed Tracing, and Platform Logging.
OpenShift Kubernetes Engine (OKE) includes OpenShift Virtualization.
OKE includes log forwarding but excludes Platform Logging (Elasticsearch/Fluentd/Kibana stack).
OpenShift Container Engine was renamed to OpenShift Kubernetes Engine in April 2020.
OpenShift Kubernetes Engine (OKE) and OpenShift Container Platform (OCP) are the same binary download — the difference is subscription entitlement only.
A Cluster Service Version (CSV) contains both user-facing metadata (logo, description, version) and technical specification (RBAC rules, managed/dependent CRs) required by OLM to run an Operator.
Default CatalogSources (redhat-operators, certified-operators, community-operators) live in the openshift-marketplace namespace
OLM resolves Operator dependencies by finding Operators in a catalog that satisfy required CRD APIs, not through direct package or bundle references.
Operator Lifecycle Manager (OLM) is deployed by default in OpenShift Container Platform.
OLM (Operator Lifecycle Manager) is deployed by default in OpenShift Container Platform 4.17 and manages Operator installation, upgrades, and RBAC.
The olm.deprecations schema in file-based catalogs allows deprecating entire packages, channels, or specific bundles with custom messages.
OLM operator installation follows a deterministic chain: CatalogSource → Subscription → InstallPlan → CSV → Operator Deployment, where Subscriptions track channels and InstallPlans require explicit approval fields.
OLM (Operator Lifecycle Manager) has been included with OpenShift Container Platform since the initial OCP 4.0 release.
Index images (containing Operator bundle database snapshots with CSVs, CRDs, all versions) are managed with the opm CLI tool.
OLM operator installation lifecycle chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion.
An install plan is a calculated list of resources to be created for automatic CSV installation or upgrade.
An Operator group configures all Operators in a namespace to watch for custom resources in a list of namespaces or cluster-wide.
The original Operator Lifecycle Manager (OLM) has been included in OpenShift Container Platform since the 4.0 initial release.
OLM operator installation lifecycle follows: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion → OperatorGroup.
A Subscription keeps CSVs up to date by tracking a channel in a package.
OLM supports disconnected/restricted network environments for Operator installation and management.
OLM is in active generational transition: v1 (CatalogSource→Subscription→InstallPlan→CSV chain) is production GA with FBC catalogs, while v1 extension (ClusterExtension replacing Subscription+OperatorGroup) is emerging — operators must navigate both the established lifecycle chain and its incoming replacement.
The OLM v1 API was renamed from Operator to ClusterExtension in OCP 4.16.
OLM v1 cannot authenticate to private registries including Red Hat-provided catalogs (known issue OCPBUGS-36364)
The OLM v1 catalog server runs in the openshift-catalogd namespace.
The ClusterExtension custom resource uses apiVersion olm.operatorframework.io/v1alpha1.
ClusterExtension objects in OLM v1 are cluster-scoped, unlike original OLM where Operators could be namespace- or cluster-scoped.
Extensions supported by OLM v1 must use registry+v1 bundle format, support AllNamespaces install mode, must not use webhooks, and must not declare dependencies via olm.gvk.required, olm.package.required, or olm.constraint.
In OLM v1 terminology, "extensions" is the broader category that generalizes beyond just Operators; Operators are one type of extension.
OLM v1 uses HTTPS encryption for catalogd server responses.
OLM v1 does not have built-in permissions to install extensions; a ServiceAccount with explicit RBAC (ServiceAccount + ClusterRole + ClusterRoleBinding) must be created before installation.
OLM v1 removes the etcd value size limit constraint on bundle size that existed in original OLM.
OCP 4.21 uses OLM v1 (Operator Lifecycle Manager v1) for extension management, replacing the classic OLM (v0) with new APIs and workflows.
OLM v1 documentation is referred to as "Extensions" in the reorganized documentation starting in OCP 4.17.
In OLM v1, each Kubernetes object can only be owned by one ClusterExtension at a time; CRD-providing bundles can only be installed once per cluster
OLM v1 (Operator Lifecycle Manager v1) is Technology Preview in OpenShift 4.17 — not GA.
OLM v1 is a Technology Preview feature in OpenShift Container Platform 4.17, not supported under production SLAs
OLM v1 is composed of two main components: Operator Controller (installs/manages Operators) and Catalogd (unpacks file-based catalog content from container images)
OLM v1 has two core components: Operator Controller (provides the ClusterExtension API) and catalogd (provides the Catalog API and unpacks catalog content).
Setting upgradeConstraintPolicy: SelfCertified in a ClusterExtension CR bypasses upgrade path constraints in OLM v1.
OLMConfig is a cluster-scoped singleton resource in operators.coreos.com/v1 that configures OLM behavior globally.
OLMConfig spec.features.disableCopiedCSVs disables the Copied CSV feature for cluster-scoped operators (OperatorGroup targeting all namespaces); re-enabling causes OLM to recreate them.
OLMConfig spec.features.packageServerSyncInterval controls packageserver CatalogSource polling frequency and only accepts h, m, s duration units.
On-cluster layering Containerfiles use FROM configs AS final as the base stage; out-of-cluster Containerfiles use the full RHCOS image reference.
For on-cluster image layering builds, the push secret and pull secret must be different secrets.
On-cluster RHCOS image layering is Technology Preview and requires the TechPreviewNoUpgrade feature gate to be enabled.
Only one OperatorGroup is allowed per namespace — this is a hard constraint enforced by OLM.
Only one primary network can be created per pod; multiple secondary networks are allowed.
Only the OVN-Kubernetes network plugin supports changing the MTU value on an existing OpenShift cluster.
Only OVN-Kubernetes supports changing the cluster network MTU post-installation; OpenShift SDN does not.
OOM kill tracking in the Node Metrics Dashboard uses the CRI-O specific counter containerruntimecriocontainersoomcounttotal.
The opc binary included in the tkn package is a Technology Preview feature and not supported for production use.
The Open Service Broker API is the mechanism for provisioning and binding to external managed services (databases, message queues, etc.) within OCP.
OpenShift AI Cloud Service installs on OpenShift Dedicated or ROSA — not on self-managed OCP.
OpenShift AI Feature Store is a Technology Preview feature, not GA.
OpenShift AI uses S3-compatible object stores as the primary data storage integration pattern.
Red Hat OpenShift AI combined with OpenShift Container Platform forms the enterprise AI application platform.
OpenShift AI defines three distinct user roles: OpenShift cluster administrators, OpenShift AI administrators, and OpenShift AI users (ML Ops Engineers / Data Scientists).
OpenShift organizes its API reference documentation by functional category, with Metadata being one of the primary categories
Red Hat OpenShift API Management is a managed service add-on built on 3scale API Management, running on managed OpenShift offerings (ROSA/OSD).
OpenShift API Management is a managed service, not a self-installed operator — distinct from self-managed 3scale.
OpenShift organizes its APIs into categories including Workloads, Networking, Storage, Security, Config, Metadata, and Operator APIs
The OpenShift API Server handles OpenShift-specific APIs (Routes, DeploymentConfigs, Builds) and is separate from the Kubernetes API Server which handles core Kubernetes resources
OpenShift has a built-in OAuth server managed by the Authentication operator; this is a key differentiator from vanilla Kubernetes.
OpenShift cloud services (managed) editions include ROSA (Red Hat OpenShift Service on AWS) and ARO (Microsoft Azure Red Hat OpenShift).
The openshift-controller-manager is separate from kube-controller-manager and handles OpenShift-specific controllers for builds, deployments, images, and service accounts
OpenShift has dual authorization systems: its own authorization API group alongside the Kubernetes RBAC API, with OpenShift-specific resources (SCC, ClusterRoles like self-provisioner) layered on top.
OpenShift extends the Kubernetes API with platform-specific Extension API resources such as Route, BuildConfig, DeploymentConfig, ImageStream, Project, ClusterVersion, and MachineSet
OpenShift extends the Kubernetes API with its own extension API objects including Route, DeploymentConfig, BuildConfig, ImageStream, Project, and SecurityContextConstraints.
OpenShift GitOps is Red Hat's supported distribution of Argo CD.
OpenShift GitOps is an Operator that uses Argo CD as its declarative GitOps engine, enabling GitOps workflows across multicluster OpenShift and Kubernetes infrastructure.
OpenShift GitOps is an Operator (installed via OLM/OperatorHub) that wraps Argo CD as its declarative GitOps engine for continuous deployment.
OpenShift has its own Authorization API (com.github.openshift.api.authorization.v1) with Role, ClusterRole, RoleBinding, and ClusterRoleBinding alongside the Kubernetes RBAC equivalents (io.k8s.api.rbac.v1).
OpenShift has its own authorization API group (authorization.openshift.io) in addition to Kubernetes-native RBAC (rbac.authorization.k8s.io)
OpenShift identity management operates as a chain: OAuth config (singleton, requires IntegratedOAuth) → identity providers → User objects (user.openshift.io) → UserIdentityMapping → Identity, with session revocation via OAuthClientAuthorization deletion.
In OpenShift, the ingress controller typically translates Kubernetes Ingress objects into Route objects
The openshift-install destroy cluster command requires the original installation directory containing metadata.json and the same installer version used to create the cluster.
OpenShift supports changing MTU (Maximum Transmission Unit) settings post-installation.
OpenShift Pipelines is a Kubernetes-native CI/CD framework based on Tekton where each pipeline step runs in its own container.
OpenShift Pipelines is typically installed via the OpenShift Pipelines Operator from OperatorHub.
OpenShift Pipelines defines pipelines as Kubernetes custom resources (CRDs), not as external server configurations, making them portable across Kubernetes clusters.
OpenShift Pipelines releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.
OpenShift Pipelines is serverless in nature — pipeline runs are ephemeral and do not require a persistent CI server.
OpenShift Pipelines is serverless and distributed with no central controller dependency, unlike Jenkins which requires a central controller node.
OpenShift Pipelines (Tekton) is the strategic replacement for Jenkins as the CI/CD engine in OpenShift Container Platform.
OpenShift Pipelines (Tekton-based) is the strategic CI/CD solution replacing Jenkins in OpenShift Container Platform.
OpenShift Pipelines uses Kubernetes custom resources (Tasks, Pipelines, PipelineRuns, Triggers) as its primitives.
In OpenShift, Projects wrap Namespaces with additional annotations and RBAC; every Project creates a corresponding Namespace
OpenShift provides PTP (Precision Time Protocol) hardware support for high-accuracy time synchronization use cases.
OpenShift SDN is deprecated; migration to OVN-Kubernetes is expected.
OpenShift self-managed editions include OpenShift Container Platform (OCP) and OpenShift Platform Plus, which bundles OCP with ACS, ACM, and Quay.
OpenShift Serverless is the Red Hat-supported distribution of Knative on OpenShift Container Platform.
build.openshift.io/v1 and apps.openshift.io/v1 are OpenShift-specific API groups; apps/v1 and batch/v1 are standard Kubernetes.
OpenShift supports SCTP (Stream Control Transmission Protocol) as a transport protocol beyond TCP/UDP, relevant for telecom workloads.
OpenShift uses Metal3 (Metal³) and Ironic for bare-metal provisioning; the provisioning service (Ironic) is deployed automatically during bare-metal IPI installations
OpenShift Virtualization Engine is a separate, standalone edition of Red Hat OpenShift purpose-built for virtualization workloads — distinct from the OpenShift Virtualization operator/feature within full OCP.
OpenShift Virtualization has defined supported maximum numbers of VMs per node, documented as part of tuning and scaling guidance.
OpenShift Virtualization version numbers align with OpenShift Container Platform version numbers (e.g., OCP 4.21 = OpenShift Virtualization 4.21).
OpenShift Virtualization is a feature within OpenShift Container Platform that enables creating, deploying, and managing virtual machines alongside containers.
Red Hat OpenStack Platform (RHOSP) is a supported installation platform for OpenShift Container Platform.
OCP supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods on OpenStack.
Red Hat build of OpenTelemetry is a separate Operator from the cluster monitoring stack and the distributed tracing platform Operator, installed via OperatorHub.
Red Hat build of OpenTelemetry collects three signal types: traces, metrics, and logs.
OpenTelemetry is the vendor-neutral, open standard for telemetry collection in OpenShift, not tied to a specific observability backend.
Each OpenShift Operator API is backed by a CustomResourceDefinition (CRD).
OpenShift distinguishes Operator APIs from Config APIs, Machine APIs, and core Kubernetes APIs in its documentation taxonomy.
OpenShift Operator APIs are implemented as CustomResourceDefinitions (CRDs) registered in the cluster, distinct from core Kubernetes APIs.
Each Operator bundle must contain exactly one Cluster Service Version (CSV) and belong to at least one channel.
Operator delivery follows an end-to-end pipeline: FBC catalogs (replacing SQLite) feed into the OLM lifecycle chain (CatalogSource → Subscription → InstallPlan → CSV → Deployment), creating a fully declarative operator supply chain.
Most operator.openshift.io/v1 configuration resources are singleton objects named "cluster"
Operators follow a complete delivery pipeline from catalog to UI: FBC catalogs feed through OLM lifecycle (CatalogSource → Subscription → InstallPlan → CSV → Deployment), and then extend the web console via HTTPS-backed ConsolePlugins registered through OLM, making OLM the single delivery mechanism for both backend and frontend operator components.
OLM supports three Operator dependency types: olm.package (version-based), olm.gvk (API group/version/kind), and olm.constraint (generic constraints).
The entire OpenShift platform operates through an operator-driven model: operators are delivered via the FBC→OLM→Console pipeline and then manage immutable nodes through singleton CRs, creating a closed loop where the delivery mechanism and the management mechanism are both operator-mediated.
The Operator Framework consists of four components: Operator SDK, Operator Lifecycle Manager (OLM), Operator Registry, and OperatorHub.
The Operator install chain is: OperatorHub → PackageManifest → Subscription → InstallPlan → CSV.
The operator-driven immutable platform model must operate within hard lifecycle boundaries: operators deliver and manage everything, but install-time irreversible decisions and version-coupling constraints define the envelope within which operators can act — creating a tension between operator-mediated flexibility and platform-level rigidity.
Operator lifecycle classifications (Platform Aligned, Platform Agnostic, Rolling Stream) were introduced in OCP 4.14.
OpenShift operator resources have two separate log level controls: logLevel for the operand and operatorLogLevel for the operator itself
Valid log levels across OpenShift operators are: Normal, Debug, Trace, and TraceAll (default is Normal).
OpenShift operator CRs accept log level values Normal, Debug, Trace, and TraceAll for both logLevel (operand) and operatorLogLevel (operator).
logLevel controls logging for the operand while operatorLogLevel controls logging for the operator process itself
The managementState field on OpenShift operators supports three values: Managed (actively reconciles), Unmanaged (stops reconciling), and Removed (deletes managed resources).
The Operator Manager default behavior watches only the namespace where the Operator runs; set Namespace: "" to watch all namespaces.
The Operator maturity model defines five phases: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot.
The observedConfig field lives in .spec (not .status) because it serves as input to the operator's reconciliation logic.
The operator-driven immutable platform model is not unique to OCP — RHOSO replicates the same pattern (master operator orchestrating sub-operators, CRD-based configuration, running on OCP as substrate), demonstrating that the operator model is a reusable platform architecture, not an OCP-specific design.
OperatorPKI CA cert validity is 10 years (rotated after 9 years); target cert validity is 6 months (rotated after 3 months)
Base images for Ansible-based and Helm-based Operator projects are not deprecated and remain supported for bug fixes and CVEs, even though the Operator SDK CLI itself is deprecated.
The Red Hat-supported Operator SDK CLI is deprecated in OpenShift Container Platform 4.17 and planned for removal in a future release.
The Red Hat-supported Operator SDK CLI is deprecated as of OpenShift Container Platform 4.17 and planned for removal in a future release.
Kubebuilder is embedded into the Operator SDK as the scaffolding solution for Go-based Operators; existing Kubebuilder projects work as-is.
The operator-sdk init command uses the Go plugin by default.
Running make bundle automates executing operator-sdk generate kustomize manifests followed by operator-sdk generate bundle.
The Operator SDK is the official tool for building custom Operators in OpenShift.
The Operator SDK is a component of the Operator Framework, used to build, test, and deploy Operators.
The --repo flag is required when creating an Operator SDK project outside $GOPATH/src/.
The --security-context-config restricted flag for operator-sdk run bundle is not compatible with the default namespace.
The default scorecard configuration path is bundle/tests/scorecard/config.yaml.
The Operator SDK supports building Operators based on Go, Ansible, Helm, or Java.
The Operator SDK supports four project types: Go, Ansible, Helm, and Java.
Operator SDK supports three Operator types: Helm (lower maturity), Ansible, and Go (enables highest maturity level).
OpenShift Container Platform 4.17 supports Operator SDK v1.36.1.
OpenShift Container Platform 4.17 ships Operator SDK v1.36.1.
An OperatorCondition with Upgradeable=False blocks OLM from upgrading that Operator
The OperatorGroup resource uses API group operators.coreos.com/v1
OperatorGroup Default upgrade strategy blocks operator upgrades when a prior install/upgrade has failed (CSVs can only move to Replacing from Succeeded)
OperatorGroup TechPreviewUnsafeFailForward upgrade strategy allows CSVs to move to Replacing from Succeeded or Failed, and triggers new InstallPlan generation on catalog updates
OperatorGroups control which namespaces an Operator can watch, with options: AllNamespaces, OwnNamespace, or a specific set of namespaces.
Only one OperatorGroup should exist per namespace; multiple OperatorGroups cause conflicts
OperatorGroup serviceAccountName specifies the service account used to deploy operators within the group, enabling least-privilege configurations
In an OperatorGroup, targetNamespaces takes precedence over selector; if both are set, the selector is ignored
OperatorGroup is the unit of multitenancy for OLM-managed operators, constraining which namespaces an operator can watch and manage
OperatorHub API objects (CatalogSource, Subscription, InstallPlan, CSV, OperatorGroup, OperatorCondition) are CRDs under the operators.coreos.com API group, managed by OLM.
OperatorHub API resources are in the operators.coreos.com API group, discoverable via oc api-resources | grep operators.coreos.com.
OperatorHub is available in every OpenShift Container Platform 4.x cluster.
OperatorHub config controls default catalog sources only; custom CatalogSource resources are managed separately and are not affected
The default CatalogSources in the openshift-marketplace namespace are: redhat-operators, certified-operators, community-operators, and redhat-marketplace.
OperatorHub is deployed by default in OpenShift Container Platform 4.17 for Operator discovery via the web console.
Setting disableAllDefaultSources: true on OperatorHub is a required step for disconnected/air-gapped installations
The Operator installation pipeline follows the chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion (CSV).
The OperatorHub resource (config.openshift.io/v1) is a cluster-scoped singleton named cluster that controls default hub catalog sources
When disableAllDefaultSources is true, individual spec.sources[] entries can selectively re-enable specific default catalog sources
OperatorPKI is a custom resource in the network.operator.openshift.io/v1 API group, managed exclusively by the Cluster Network Operator (CNO) for internal PKI needs
OperatorPKI CA certificate validity is 10 years, rotated after 9 years
The CNO creates three resources per OperatorPKI named <name>: Secret <name>-ca, ConfigMap <name>-ca, and Secret <name>-cert
The only required spec field for OperatorPKI is spec.targetCert.commonName
OperatorPKI target certificates have both ClientAuth and ServerAuth extended key usages enabled
OperatorPKI target certificate validity is 6 months, rotated after 3 months
Operators and cluster updates are constrained by the same security hierarchy: install-time locks (FIPS, CPU partitioning) permanently bound both the operator runtime environment and the update path, runtime TLS/IPsec enforcement governs both operator and update traffic, and API governance controls both operator CRD stability and update version ordering
Kubernetes Operators use the control loop pattern: they continuously compare desired state vs. actual state and act to reconcile differences. They manage applications using custom resources.
Operators automate both Day 1 operations (installation and configuration) and Day 2 operations (autoscaling, backups, ongoing maintenance).
In OLM v1, Operators are framed as a subset of the broader category "extensions", and OLM v1 introduces different CRDs replacing classic OLM concepts like Subscriptions and CSVs.
Operators documentation addresses three distinct roles: cluster administrators (install/manage), developers (consume), and Operator authors (build with Operator SDK).
The opm CLI is used to create and maintain Operator catalogs, distinct from the Operator SDK which builds/tests/deploys Operators.
File-based catalog (FBC) is the default Operator catalog format since OpenShift Container Platform 4.11, replacing the deprecated SQLite-based format.
The opm index add --mode flag supports graph update modes: replaces (default), semver, and semver-skippatch.
The opm index subcommands (add, prune, prune-stranded, rm) work only with SQLite-based catalogs and do not work with file-based catalogs.
The opm migrate command converts a SQLite-based catalog index to file-based catalog format.
The opm CLI is not forward compatible — the version used to generate catalog content must be less than or equal to the version used to serve it.
opm render <image-reference> converts an existing catalog image into file-based catalog format
The opm serve command serves declarative configs via gRPC on default port 50051.
The opm serve command loads configuration at startup only; runtime changes to the declarative config are not reflected.
opm validate <catalog-directory> checks catalog validity including duplicate detection and schema violations
The opm validate <catalog-dir> command validates a file-based Operator catalog.
Optional cluster capabilities that can be disabled at install time include: Baremetal, CSI Snapshot Controller, Cluster Samples, Cluster Storage, Console, and Insights.
Oracle Database Appliance (ODA) is a supported installation platform for OCP as of version 4.21.
Oracle Distributed Cloud Infrastructure refers to Oracle's cloud services deployed outside of Oracle's public cloud regions (e.g., at customer data centers or edge locations).
Oracle Distributed Cloud Infrastructure (DCI) is a supported installation target for OCP, distinct from standard Oracle Cloud Infrastructure (OCI).
Oracle Edge Cloud is a supported installation platform for OCP 4.21, distinct from Oracle Cloud Infrastructure (OCI).
OpenShift Dedicated supports Tekton Pipelines, Shipwright builds, BuildConfig (legacy), GitOps (Argo CD), and Jenkins for CI/CD.
OpenShift Dedicated clusters are provisioned and configured through OpenShift Cluster Manager (OCM), not directly via openshift-install.
OpenShift Dedicated (OSD) runs on AWS and Google Cloud only — no Azure or on-prem support.
OpenShift Dedicated has a shared responsibility model — Red Hat manages the control plane and infrastructure; customers manage workloads.
OpenShift Dedicated uses OVN-Kubernetes as its network plugin (not OpenShift SDN).
Applying the out-of-service taint evicts all pods from the node (not just those using volumes) and must be removed after the node restarts.
The out-of-service taint for non-graceful node shutdown is node.kubernetes.io/out-of-service=nodeshutdown:NoExecute.
The out-of-service taint must be manually applied by a cluster-admin; it is not automatic, and must only be applied after confirming the node is fully shut down.
Applying the out-of-service taint to a node that is still running risks filesystem corruption.
Red Hat Ansible Automation Platform manages the full VM lifecycle on OpenShift Virtualization Engine: provisioning, patching, configuration enforcement, and migration.
OpenShift Virtualization Engine is installed via the Assisted Installer for OpenShift Container Platform.
OpenShift Virtualization Engine supports migration from VMware vSphere and Red Hat Virtualization (RHV) via the Migration Toolkit for Virtualization.
Red Hat Advanced Cluster Management (RHACM) provides single-console multi-cluster management with built-in security policies and compliance for OpenShift Virtualization Engine clusters.
All OVN databases (nbdb, sbdb) and northd run on each node (not centralized), processing mostly local information.
OVN-Kubernetes dual-stack limitation: both IPv4 and IPv6 must use the same default gateway interface; violation causes CrashLoopBackOff in ovnkube-node pods.
OVN-Kubernetes uses Geneve encapsulation (not VXLAN) with default port 6081 and default MTU 1400
v4InternalSubnet (100.64.0.0/16), v6InternalSubnet (fd98::/48), and internalTransitSwitchSubnet cannot be changed after installation
Setting ipv6.disable=1 in kernel arguments causes CrashLoopBackOff in ovnkube-node pods and blocks cluster upgrades.
OVN-Kubernetes secondary networks require CNI type ovn-k8s-cni-overlay with cniVersion: 0.3.1.
OVN-Kubernetes supports three secondary network topologies: layer2 (cluster-wide logical switch, L2 only), localnet (connects workloads to physical network via OVS bridge), and layer3 (routed).
OVN-Kubernetes is built on Open Virtual Network (OVN), which itself builds on Open vSwitch (OVS).
OVN-Kubernetes is the default Container Network Interface (CNI) for OpenShift Container Platform clusters.
OVN-Kubernetes is the default CNI network plugin in OpenShift Container Platform (replacing OpenShift SDN as default from OCP 4.12+)
OVN-Kubernetes is the default network plugin and supports both IPv4 and IPv6.
OVN-Kubernetes is the default network plugin in OpenShift Container Platform 4.17
OVN-Kubernetes is the default SDN in OpenShift Container Platform; network issues should be checked in the openshift-ovn-kubernetes namespace.
OVN-Kubernetes natively enforces Kubernetes NetworkPolicy and OpenShift-specific network policy objects.
OVN-Kubernetes uses six reserved internal subnets (join, masquerade, transit for IPv4 and IPv6) that must never overlap with any other CIDR in the cluster
The default OVN-Kubernetes V4JoinSubnet is 100.64.0.0/16 and V6JoinSubnet is fd98::/64
OVN-Kubernetes default network multicast is suitable only for low-bandwidth use cases (coordination, service discovery); SR-IOV is required for high-bandwidth multicast.
OVN-Kubernetes resources run in the openshift-ovn-kubernetes namespace.
OVN-Kubernetes network plugin has a 100-byte overhead, so cluster network MTU should be set to hardware MTU minus 100.
OVN-Kubernetes overlay overhead is exactly 100 bytes; cluster network MTU = hardware MTU - 100.
OVN-Kubernetes plugin owns most egress CRDs: EgressFirewall, EgressIP, EgressQoS, EgressService, and AdminPolicyBasedExternalRoute (all k8s.ovn.org/v1)
OVN-Kubernetes is the primary network plugin in OpenShift 4.x (replacing OpenShift SDN in newer versions).
OVN-Kubernetes supports only a single IP address block for the service network.
OVN-Kubernetes supports IPsec for encrypting cluster network traffic.
OVN-Kubernetes uses the Geneve protocol (not VXLAN) to create the overlay network between nodes.
internalMasqueradeSubnet (default 169.254.169.0/29 for IPv4, fd69::/125 for IPv6) can be changed after installation and must accommodate at least 6 IPs
OVN-Kubernetes session affinity stickiness timeout is calculated from the last packet received, not the first — continuous traffic keeps the session alive indefinitely.
ovnkube-control-plane runs as a Deployment with 2 replicas on separate control plane nodes, using leader election.
ovnkube-node pods run as a DaemonSet (one per node) with 8 containers: ovn-controller, ovn-acl-logging, kube-rbac-proxy-node, kube-rbac-proxy-ovn-metrics, northd, nbdb, sbdb, ovnkube-controller.
OVNKubernetes is the default network plugin (CNI) for OpenShift Container Platform, supporting Linux and hybrid Linux/Windows networks.
OVNKubernetes is the default and only supported networkType in OpenShift 4.17; it supports only a single service network CIDR.
OVS bonding supports two modes: active-backup and balance-slb.
In OVN-Kubernetes networking, br-ex receives VM traffic, patch ports connect it to br-phy, and br-phy controls the SLB bond to physical NICs.
PackageManifest uses API group packages.operators.coreos.com/v1
The PackageManifest defaultChannel field determines what channel gets installed when no channel is specified in a Subscription
PackageManifest deprecation can occur at three levels: entire package, individual channel, or individual entry (CSV) within a channel
The entries[] array in a PackageManifest channel lists all CSVs with their upgrade edges, enabling OLM to compute valid upgrade paths
PackageManifest is a read-only resource with no POST/PUT/DELETE endpoints; it is generated from CatalogSource content
oc get packagemanifests -n openshift-marketplace lists available Operators from OperatorHub catalogs.
PodDisruptionBudget (PDB) is a policy/v1 API resource, not in the apps or core API groups.
Setting maxUnavailable: 0 or minAvailable: 100% on a PDB blocks all voluntary evictions.
Default maxUnavailable for machine config pools is 1; it should not be changed to 3 for the control plane.
minAvailable and maxUnavailable in a PDB spec are mutually exclusive — specifying both is invalid.
PDB spec uses either minAvailable or maxUnavailable (not both) to define disruption tolerance.
PodDisruptionBudget misconfiguration can prevent nodes from draining during cluster updates.
PodDisruptionBudgets are namespaced resources.
A null PDB selector matches no pods; an empty selector {} matches all pods in the namespace.
PodDisruptionBudgets only protect against voluntary disruptions (drains, evictions), not involuntary ones (node crashes, OOM kills).
The unhealthyPodEvictionPolicy field in PDB defaults to IfHealthyBudget behavior, meaning unhealthy running pods can only be evicted if currentHealthy >= desiredHealthy.
PDB minAvailable and maxUnavailable fields accept either an integer or a percentage string (IntOrString type).
PDBs only affect voluntary disruptions (evictions); they do not protect against involuntary disruptions like node crashes or OOM kills.
PodDisruptionBudgets are only honored on voluntary evictions, not involuntary disruptions like node failures.
After a graceful restart, pending CSRs may need to be manually approved with oc adm certificate approve for nodes to reach Ready state.
Setting PerformanceProfile defaultHugepagesSize to 1G removes all 2M hugepage folders from the node, making 2M hugepage configuration impossible.
PerformanceProfile uses API group performance.openshift.io/v2 (v2, not v1).
PerformanceProfile balanceIsolated defaults to true; setting to false disables load balancing on isolated CPUs for most predictable latency.
PerformanceProfile controller auto-creates a RuntimeClass (name in .status.runtimeClass) and a Tuned CR (referenced in .status.tuned).
PerformanceProfile workloadHints highPowerConsumption and perPodPowerManagement cannot be enabled together (mutually exclusive).
When userLevelNetworking is enabled in a PerformanceProfile, network device queue count is set equal to the reserved CPU count.
PerformanceProfile NUMA topologyPolicy defaults to best-effort when TopologyManager is enabled.
PerformanceProfile requires spec.cpu (with both isolated and reserved) and spec.nodeSelector.
Real-time kernel packages are not installed on OpenShift nodes unless realTimeKernel.enabled: true is explicitly set in the PerformanceProfile.
The perspective switcher (to toggle between Administrator and Developer views) is available only to cluster-admin users
PGT bindingRules labels must match labels in the SiteConfig CR — a mismatch means policies won't apply to the managed cluster.
PolicyGenTemplate (PGT) is deprecated in OCP 4.17 in favor of RHACM PolicyGenerator CRs.
The Namespace CR must NOT be in the same file as the PolicyGenTemplate CR.
Generated ZTP policy names follow the pattern <PGT-metadata.name>-<policyName> (e.g., group-du-sno-config-policy).
OpenShift Pipelines is Tekton-based; OpenShift GitOps is Argo CD-based.
OpenShift Pipelines orchestrates multi-step CI/CD workflows, while OpenShift Builds focuses on container image creation — they are related but distinct.
OpenShift unifies software delivery and platform governance across all topology variants: the same operator-driven pipeline (FBC→OLM→Console) and identity-to-node governance stack operate whether the cluster is standard HA, hosted control plane, or edge/SNO — with topology-specific operational divergences layered on top.
OpenShift governance is a unified stack spanning four layers: identity management (OAuth→User→Identity chain), resource access control (dual RBAC + SCC), namespace/project self-provisioning, and node-level immutable configuration — all enforced through singleton operator CRs.
OpenShift platform lifecycle is constrained at both boundaries: install-time decisions (FIPS, CPU partitioning, network plugin) are permanently irreversible, while post-install changes are gated by strict version coupling and update ordering (OCP before CNV, management before hosted) — the platform cannot be freely reconfigured at either end.
OpenShift lifecycle management operates under version governance at both ends: progressive updates (canary rollouts, EUS-to-EUS skips) and disaster recovery (etcd backup/restore) are both constrained by the same version coupling rules — recovery cannot escape the boundaries that updates must respect.
OpenShift operates through a single operator-driven immutable platform model that recognizes two sanctioned divergence paths — hosted control planes (control/data plane split) and edge/SNO (reduced capability profile) — each requiring distinct operational playbooks while sharing the same underlying operator and update governance.
Clusters with infrastructure platform type none cannot use the Machine API, and this cannot be changed post-install.
OpenShift Platform Plus is a product SKU that bundles OpenShift Container Platform with Advanced Cluster Management (ACM), Advanced Cluster Security (ACS), and Quay.
Clusters with infrastructure platform type none cannot use the Machine API, and this is immutable post-install.
The preferred (non-deprecated) pod binding endpoint is POST /api/v1/namespaces/{namespace}/pods/{name}/binding.
Once a pod is bound to a node, it will never be rebound to another node.
The default DNS policy for pods is ClusterFirst; to use DNS with hostNetwork: true, you must explicitly set ClusterFirstWithHostNet
The default Pod dnsPolicy is ClusterFirst.
The default pod interface is always eth0; secondary network interfaces are named net1, net2, etc.
The default Pod restartPolicy is Always.
The default terminationGracePeriodSeconds for a Pod is 30 seconds.
The default terminationGracePeriodSeconds for pods is 30 seconds
The podnetworkname_info metric always has a fixed value of 0 and exists solely as a label carrier for PromQL joins with container network metrics.
To enrich containernetwork* metrics with network names, use + on(namespace,pod,interface) groupleft(networkname) ( podnetworkname_info ).
The only required field in PodSpec is containers (at least one container must be specified).
Default pod restart policy is Always; exponential back-off delay (10s, 20s, 40s) caps at 5 minutes.
Pod scheduling to nodes is controlled via node selectors, node affinity, and taints/tolerations.
Pods are attached to secondary networks using the annotation k8s.v1.cni.cncf.io/networks.
The serviceAccount field in PodSpec is deprecated — serviceAccountName should be used instead
The Pod is the smallest logical unit in Kubernetes, containing one or more containers running on a worker node.
Static IP assignment for pods on secondary networks is only available on layer2/localnet topologies and only when subnets is NOT defined in the NAD.
Container names in PodMetrics map directly to pod.spec.containers[].name; all container metrics within a pod are collected within the same time window.
PodMetrics API endpoints: /apis/metrics.k8s.io/v1beta1/pods (all namespaces), /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods (namespace-scoped), /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} (specific pod). All GET-only.
PodMonitor is a CRD from the monitoring.coreos.com/v1 API group
PodMonitor endpoint authentication options (authorization, basicAuth, oauth2) are mutually exclusive
PodMonitor's bearerTokenSecret is deprecated; the replacement is the authorization field
PodMonitor default scrape path is /metrics and default scheme is http
PodMonitor's filterRunning is enabled by default, dropping non-Running pods from target discovery
The only required field in PodMonitor .spec is selector, a label selector for pod discovery
In PodMonitor, relabelings apply to target metadata labels before scrape; metricRelabelings apply to scraped samples before ingestion
PodMonitor targets pods directly without requiring a Service, unlike ServiceMonitor which targets Services
PodNetworkConnectivityCheck belongs to API group controlplane.operator.openshift.io/v1alpha1 and has Compatibility Level 4 (no stability guarantees)
PodNetworkConnectivityCheck is an internal control plane API for cluster health monitoring, not intended for end-user application use
PodNetworkConnectivityCheck status tracks successes[], failures[] (individual log entries), and outages[] (time periods with start/end timestamps and boundary logs)
PodNetworkConnectivityCheck targetEndpoint uses host:port format; using an IP bypasses DNS resolution, using a DNS name causes failure if DNS resolution fails
PodNetworkConnectivityCheck tlsClientCert must reference a kubernetes.io/tls type secret in the same namespace as the resource
Pods (not containers) are the basic unit of deployment, scaling, and management in Kubernetes/OpenShift.
Pods are immutable while running (changes require recreation) and expendable (do not maintain state when recreated).
Pods reference NetworkAttachmentDefinitions via the annotation k8s.v1.cni.cncf.io/networks
OpenShift has three PodSecurityPolicy review APIs: PodSecurityPolicyReview (which SAs can create a pod), PodSecurityPolicySelfSubjectReview (can the current user create it), and PodSecurityPolicySubjectReview (can a specific user/SA create it)
In PodSecurityPolicySubjectReview, the status.allowedBy field references the SCC that permits the pod; when nil, the request was denied
PodSecurityPolicySubjectReview belongs to the security.openshift.io/v1 API group and is OpenShift-specific, not available in vanilla Kubernetes
PodSecurityPolicySubjectReview is a namespace-scoped resource accessed via POST /apis/security.openshift.io/v1/namespaces/{namespace}/podsecuritypolicysubjectreviews
In PodSecurityPolicySubjectReview, if user is specified without groups, the user is tested as if belonging to no groups; if both are empty, only the serviceAccountName from the template is evaluated
The containers field is the only required field in a PodSpec — at least one container must be specified
All PolicyGenerator CRs must be in a namespace prefixed with ztp.
PolicyGenTemplate CRs are deprecated in favor of RHACM PolicyGenerator CRs for generating Day 2 configuration policies.
In a PolicyRule, an empty apiGroups field means both Kubernetes and OpenShift API groups are assumed.
In PolicyRules, nonResourceURLs supports * wildcards but only as the final path segment.
Power consumption metrics are categorized as total, active, and idle CPU power.
The PowerMonitor custom resource instance must be named exactly power-monitor; all other instance names are ignored by the operator.
Power Monitoring in OCP tracks power consumption at the container level, not just node or pod level
Developers with view permissions on the openshift-power-monitoring namespace can access power monitoring dashboards but can only see the Overview dashboard, not the Namespace (Pods) dashboard.
Power monitoring installation requires two steps: install the Power monitoring Operator, then deploy the PowerMonitor custom resource.
Kepler is deployed in the openshift-power-monitoring namespace.
The Power Monitoring Operator installation makes power monitoring available across all namespaces.
Power Monitoring is an optional capability installed and managed via the Power Monitoring Operator
Power monitoring dashboards require three prerequisites: Power Monitoring Operator installed, Kepler deployed, and user-defined project monitoring enabled.
Installing, configuring, and uninstalling power monitoring requires the cluster-admin role.
Power monitoring for OpenShift is Technical Preview and not supported for production use.
Power monitoring in OpenShift Container Platform is a Technology Preview feature, not supported under production SLAs and not recommended for production use.
Power monitoring using Kepler is a Technology Preview feature in OCP 4.17, not supported under production SLAs.
Power monitoring tracks power consumption of two specific hardware components: CPU and DRAM, at container granularity.
Power monitoring provides two dashboards: "Power Monitor / Overview" (cluster/node level) and "Power Monitor / Namespace (Pods)" (namespace/pod level, showing top 10 power-consuming namespaces).
Power monitoring uninstall must follow a specific order: delete Kepler instance first, then delete PowerMonitor CR, then uninstall the Power Monitoring Operator.
Power monitoring for OpenShift is built on Kepler (Kubernetes-based Efficient Power Level Exporter) for collecting power consumption metrics.
Power Monitoring is powered by Kepler (Kubernetes Efficient Power Level Exporter) as its upstream project
The PowerMonitor CR uses apiVersion kepler.system.sustainable.computing.io/v1alpha1.
The PowerMonitor custom resource instance must be named power-monitor; all other names are rejected by the operator webhook.
The disk must be wiped before partitioning with wipefs -a; the factory-precaching-cli tool fails on non-empty disks.
The --du-profile flag adds Day-2 Operator images for telco 5G RAN distributed unit workloads to the pre-cache.
The factory-precaching-cli default parallel download workers is 80% of available CPUs, configurable via --parallel / -p.
The pre-cache data partition must be at the end of the disk and labelled data so that coreos-installer preserves it; formatted as XFS with GPT partition table.
The PreprovisioningImage custom resource belongs to API group metal3.io/v1alpha1 and is a namespaced resource.
PreprovisioningImage supports two image formats: iso and initrd; kernel-related fields (kernelUrl, extraKernelParams) only apply to initrd format.
PreprovisioningImage injects network data via a Kubernetes Secret referenced by name in the spec field networkDataName.
To preserve historical images from pruning, maintain a tag in the ImageStream spec pointing to the image by digest.
PriorityClass (scheduling.k8s.io/v1) maps a priority class name to an integer value; higher values mean higher priority for both scheduling order and preemption behavior.
Setting preemptionPolicy: Never on a PriorityClass creates high-priority pods that queue instead of evicting lower-priority pods.
PriorityLevelConfiguration default queuing parameters are 64 queues, hand size 8, and queue length limit 50; setting NominalConcurrencyShares to 0 creates a "jail" that holds requests indefinitely.
PriorityLevelConfiguration (flowcontrol.apiserver.k8s.io/v1) has exactly two types: Exempt (requests bypass all limits) and Limited (requests subject to concurrency limits); default NominalConcurrencyShares for Limited is 30.
Default/privileged projects (default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label 0 or 1) do not support image stream reference resolution.
Default/privileged projects (default, kube-public, kube-system, openshift, openshift-infra, openshift-node) should not run workloads — pod security admission and image reference resolution do not work in these projects.
The Probe CRD belongs to the monitoring.coreos.com/v1 API group
The Probe CRD's default prober path is /probe, default scheme is http, default auth type is Bearer
Probe default values: initialDelaySeconds=0, periodSeconds=10, timeoutSeconds=1, successThreshold=1, failureThreshold=3.
The successThreshold parameter must be 1 for liveness probes.
Probe OAuth2 configuration requires three fields: clientId, clientSecret, and tokenUrl
The Probe CRD's prober.url field is mandatory — targets cannot be probed without it
Startup probe maximum startup time is calculated as failureThreshold × periodSeconds.
When both staticConfig and ingress targets are defined on a Probe, staticConfig takes precedence
Health check probes support three test mechanisms: HTTP GET (200–399 = success), container command/exec (exit 0 = success), and TCP socket (connection established = success).
OpenShift/Kubernetes supports three health check probe types: readiness (removes pod from endpoints on failure), liveness (kills/restarts container on failure), and startup (gates other probes until success).
Probe supports two target types: staticConfig (explicit host list) and ingress (auto-discovery from Ingress objects via label selectors)
OpenShift progressive update strategies (canary MCPs, EUS-to-EUS skips) must navigate the heterogeneous node fleet: RHCOS nodes accept updates via rpm-ostree atomic images while Windows nodes diverge entirely, and install-time locks (FIPS, network plugin) create irreversible boundaries that updates cannot cross.
OpenShift update strategies (canary rollouts via custom MCPs and EUS-to-EUS skips for even minor versions) operate strictly within the platform's lifecycle boundaries — install-time decisions constrain what can be updated, and version coupling determines the order and scope of what canary pools can validate.
Project administrators cannot alter their own project quotas — only cluster administrators can modify quotas
The Project and ProjectRequest resources belong to the project.openshift.io/v1 API group, not core Kubernetes
The config.openshift.io/v1 Project resource is a cluster-wide singleton with the canonical name cluster.
config.openshift.io/v1 Project is the cluster config singleton; project.openshift.io/v1 Project represents individual project resources — they are distinct API groups.
Listing or watching projects returns only projects where the user has the reader role
Every OpenShift Project maps 1:1 to a Kubernetes Namespace, but not every Namespace is necessarily a Project
The spec.projectRequestMessage field on the Project config controls the message shown to users who cannot create projects via the projectrequest endpoint.
The default project request template can be customized to inject default network policies, resource quotas, and limit ranges into every new project.
The custom project request template referenced by the Project config must reside in the openshift-config namespace.
Project self-provisioning is governed by a three-part mechanism: admins can disable it (two-step process: remove subjects + set annotation), a custom request template controls project defaults, and a configurable message informs denied users — enabling fine-grained organizational control over namespace creation.
A Project's status phase is either Active (available for use) or Terminating (undergoing graceful termination)
Projects have three roles: admin (set membership), edit (create/manage resources), view (read-only, no container access)
The dedicated watch endpoints for Projects (/watch/projects) are deprecated — use the watch query parameter on list operations instead
Project (project.openshift.io/v1) wraps Namespace (v1) with additional policy in OpenShift.
An OpenShift Project is an alternative representation of a Kubernetes Namespace; Projects are editable by end users while Namespaces are not
The CA bundle ConfigMap for ProjectHelmChartRepository uses the key ca-bundle.crt; if empty, default system roots are used.
ProjectHelmChartRepository (helm.openshift.io/v1beta1) is namespace-scoped, while HelmChartRepository is cluster-scoped.
Secrets and ConfigMaps referenced by a ProjectHelmChartRepository for auth, TLS, and CA must be in the same namespace as the resource.
ProjectRequest has displayName and description fields that are OpenShift-specific metadata not present on Kubernetes Namespaces
OpenShift Projects extend Kubernetes namespaces with additional features including user self-provisioning, policies, constraints, and service accounts.
Projects are the fundamental organizational unit (namespace/tenancy boundary) for applications in OpenShift.
PrometheusRule belongs to API group monitoring.coreos.com/v1 and is namespace-scoped
The expr field (PromQL expression) is required on every PrometheusRule rule
User-defined project alerting rules use kind PrometheusRule with apiVersion monitoring.coreos.com/v1, created in the user's project namespace.
In PrometheusRule, for controls how long a condition must be true before an alert fires; keepfiringfor controls how long an alert continues firing after the condition clears
The name field is required on every PrometheusRule rule group
PrometheusRule's limit field on rule groups requires Prometheus >= 2.31
A PrometheusRule rule must set exactly one of record or alert, never both
PrometheusRule (monitoring.coreos.com/v1) supports both recording and alerting rules, unlike the OpenShift-specific AlertingRule which only supports alerting rules.
Provisioning APIs (metal3.io group) are specific to bare-metal deployments and do not apply to cloud-based (AWS, Azure, GCP) or virtualized installations
Provisioning APIs (BareMetalHost, Provisioning, HardwareData, PreprovisioningImage, HostFirmwareSettings, FirmwareSchema) belong to the metal3.io API group.
The Provisioning CR is consumed by the cluster-baremetal-operator to manage metal3 container lifecycle.
The Provisioning custom resource (metal3.io/v1alpha1) is a singleton — only one exists per cluster, named cluster, created automatically by the OpenShift installer.
The default provisioning DHCP range is .10 to .100 of the provisioningNetworkCIDR.
The provisioningDHCPExternal field is deprecated in favor of the provisioningNetwork field on the Provisioning CR.
The provisioningDHCPRange field is the only field on the Provisioning CR that can be changed after installation.
The provisioningIP must be within the provisioning subnet (provisioningNetworkCIDR) but outside the DHCP range.
IPv6 provisioning networks in Managed mode cannot exceed a /64 prefix length.
The Provisioning CR supports three provisioningNetwork modes: Managed (full IPI management), Unmanaged (user manages DHCP), and Disabled (no provisioning network, requires virtual media or assisted installation).
The OpenShift bare metal provisioning subsystem uses Ironic under the covers for BMC communication via IPMI, Redfish, and iDRAC protocols.
The Provisioning CR field watchAllNamespaces defaults to false, meaning bare metal hosts are only provisioned in the openshift-machine-api namespace by default.
Empty values for httpProxy, httpsProxy, or noProxy in the Proxy resource mean no corresponding environment variable is set on pods.
The proxy validator merges the custom CA bundle with system defaults and writes the result to trusted-ca-bundle ConfigMap in the openshift-config-managed namespace.
The Proxy resource's readinessEndpoints field is used to verify proxy connectivity before applying the configuration.
The Proxy resource's trustedCA field references a ConfigMap in the openshift-config namespace with key ca-bundle.crt.
When the registry Operator is Managed, the pruner uses --prune-registry=true (prunes blobs); when Removed, the pruner uses --prune-registry=false (only prunes etcd metadata).
PTP clock health requires master_offset between -100 and +100 ns, gmPresent must be true, and portState should be SLAVE.
PTP fast event notifications use a pub-sub REST API delivered via cloud-event-proxy sidecar over HTTP.
GNSS timing for PTP is supported only with Intel E810 Westport Channel NICs.
The linuxptp package provides ts2phc (grandmaster), ptp4l (boundary/ordinary clocks), phc2sys (system clock to PHC sync), and pmc daemons.
The PTP Operator works only on bare-metal infrastructure in OpenShift.
The PTP Operator is installed in the openshift-ptp namespace with label openshift.io/cluster-monitoring: "true".
NTP/chronyd must be disabled via MachineConfig CR before enabling PTP on OpenShift nodes.
PTP (Precision Time Protocol) provides sub-microsecond clock accuracy using hardware support, more accurate than NTP.
PTP defines three clock types: Grandmaster (syncs to GNSS, authoritative source), Boundary (multi-port relay between upstream/downstream), and Ordinary (single-port, source or destination).
publish: Internal is not supported on non-cloud platforms.
Setting publish: Internal in install-config.yaml creates a private cluster inaccessible from the internet.
Pull secret types: kubernetes.io/dockerconfigjson for Docker (~/.docker/config.json) and kubernetes.io/podmanconfigjson for Podman (~/.config/containers/auth.json).
OpenShift supports four PV access modes: RWO (ReadWriteOnce), ROX (ReadOnlyMany), RWX (ReadWriteMany), and RWOP (ReadWriteOncePod).
Once a PV is bound to a PVC, it cannot bind to another PVC — the PV is effectively scoped to the binding project's namespace.
PersistentVolumes (PVs) are cluster-scoped resources; PersistentVolumeClaims (PVCs) are namespace/project-scoped resources.
Recovery from failed PV expansion requires: set PV reclaim policy to Retain, delete the PVC, remove claimRef from PV spec, re-create PVC with valid size, restore original reclaim policy.
PV lifecycle phases are: Available → Bound → Released → Failed.
A PV bound to a PVC cannot be bound to additional PVCs — the binding is one-to-one.
PV reclaim policies are Retain, Recycle, and Delete — determining what happens to a PV after release.
The four PV access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP).
PVC binding matches on access modes and size only, selecting the smallest sufficient PV.
OCP binds PVCs to the smallest PV that matches all criteria to minimize storage waste.
PVCs cannot be shrunk — only expanded. A smaller value in .spec.resources.requests.storage is rejected.
dataSourceRef is more flexible than dataSource on PVCs — it supports any non-core object, cross-namespace references (alpha), and preserves disallowed values as errors instead of silently dropping them.
The default volumeMode for a PersistentVolumeClaim is Filesystem when not specified.
PersistentVolumeClaims (PVCs) are namespaced resources; PersistentVolumes (PVs) are cluster-scoped resources.
A PVC has three phases: Pending (not yet bound), Bound (bound to a PV), and Lost (underlying PV no longer exists).
The Red Hat Quay Container Security Operator is deprecated and will be replaced by Red Hat Advanced Cluster Security (ACS) for Kubernetes.
Resource quotas create a strict contract: when quotas specify CPU/memory, every container must declare those values, and extended resources like GPUs cannot be overcommitted — enforcing explicit resource accounting.
The quota.openshift.io/v1 API group contains OpenShift-specific quota resources (ClusterResourceQuota, AppliedClusterResourceQuota); LimitRange and ResourceQuota are core v1, PriorityClass is scheduling.k8s.io/v1, and flow control uses flowcontrol.apiserver.k8s.io/v1.
RangeAllocation (security.openshift.io/v1) is a cluster-scoped resource with Compatibility Level 4 (no stability guarantees)
RangeAllocation's range field uses the format "start-end/blockSize" (e.g., "1000000000-2000000000/10000") and both range and data fields are required
RangeAllocation tracks which UID ranges have been assigned to namespaces using a bitmap stored in the data field, supporting OpenShift's multi-tenant UID isolation model
RangeAllocation is a Security API object that tracks UID/GID range assignments for namespaces in OpenShift.
RBAC APIs live under rbac.authorization.k8s.io/v1 (Kubernetes) and authorization.openshift.io/v1 (OpenShift extensions).
RoleBindings and ClusterRoleBindings reference roles but do not contain them — they are separate API objects.
OpenShift uses both Kubernetes-native RBAC (rbac.authorization.k8s.io) and OpenShift-specific authorization APIs (authorization.openshift.io) for role-based access control.
In RBAC rules, "" (empty string) represents the core API group containing pods, services, configmaps, etc.
The four core RBAC API resources in OpenShift/Kubernetes are ClusterRole, ClusterRoleBinding, Role, and RoleBinding, all under the rbac.authorization.k8s.io/v1 API group.
The nonResourceURLs field in PolicyRules only works in ClusterRoles referenced by ClusterRoleBindings, not in namespace-scoped Roles.
RBAC roles are managed via oc adm policy add-cluster-role-to-user <role> <user> for cluster-wide and oc adm policy add-role-to-user <role> <user> -n <namespace> for namespace-scoped bindings.
In a PolicyRule, verbs is the only required field; valid verbs include get, list, create, update, delete, and * (all).
Role is namespace-scoped and only grants permissions within the namespace where it is created; ClusterRole is cluster-scoped.
A Role alone does nothing — it must be paired with a RoleBinding to grant permissions to subjects.
A RoleBinding can reference a ClusterRole, which grants the ClusterRole's permissions but scoped only to the RoleBinding's namespace.
The roleRef field on a RoleBinding is immutable after creation — the RoleBinding must be deleted and recreated to change the referenced role.
ServiceAccount subjects use "" (empty) apiGroup and require a namespace field; User and Group subjects use rbac.authorization.k8s.io apiGroup and must not specify a namespace.
The three valid subject kinds in RoleBindings/ClusterRoleBindings are User, Group, and ServiceAccount.
_RecordType values are: flowLog (regular), newConnection, heartbeat, endConnection (for conversation tracking)
The Recreate deployment strategy supports pre, mid, and post lifecycle hooks; the mid-hook runs between scale-down and scale-up. Rolling strategy only supports pre and post hooks.
The Recycle reclaim policy is deprecated in OpenShift Container Platform 4; dynamic provisioning is the recommended replacement.
Red Hat's AWS account ID for AMI ownership is 309956199498.
Red Hat's container registry is registry.redhat.io.
referencePolicy.type: Local provides two key benefits: namespace-scoped credential isolation (via pull secrets) and offline resilience through local layer mirroring in the integrated registry.
--reference-policy=local forces image pulls through the integrated registry, enabling pull-through from insecure registries without container runtime --insecure flags.
referencePolicy.type=Local on an ImageStreamTag points pulls to the integrated registry, enabling namespace-level credential management and layer mirroring so images remain available if the upstream registry goes down
Authentication to the exposed registry uses oc whoami -t to obtain an OAuth token, which is passed to podman login.
When using podman login to the internal registry, the token (oc whoami -t) carries all auth info; the username is largely irrelevant but must not contain colons.
On bare metal and vSphere installations, the registry managementState defaults to Removed and must be changed to Managed with storage configured manually.
In additional trusted CA ConfigMaps for external registries, the port delimiter is .. (double dot) not : — e.g., registry.example.com..5000.
Allowed registries are reflected in /etc/containers/policy.json; blocked registries in /etc/containers/registries.conf on cluster nodes
The Image Registry Operator custom resource is always named cluster — full path: configs.imageregistry.operator.openshift.io/cluster.
Registry storage credentials are stored in a secret named image-registry-private-configuration-user in the openshift-image-registry namespace.
Custom registry routes are configured in the operator CR's spec.routes array with fields name, hostname, and optionally secretName for custom TLS certificates.
Setting spec.defaultRoute: true on configs.imageregistry.operator.openshift.io/cluster creates a route named default-route in the openshift-image-registry namespace.
The registry's default route uses the Ingress Operator's certificate (not a registry-specific certificate); the default secret is router-certs-default in openshift-ingress namespace.
Setting disableRedirect: true on the registry CR forces traffic through the registry proxy instead of redirecting clients to object storage directly, increasing registry resource usage.
The emptyDir storage backend for the registry is acceptable only for non-production use; data does not persist across pod restarts.
Registry logs are viewed with oc logs deployments/image-registry -n openshift-image-registry.
The Image Registry Operator managementState has three values: Managed (actively manages), Unmanaged (ignores changes), and Removed (tears down registry and storage).
The integrated registry exposes Prometheus metrics at /extensions/v2/metrics.
The OpenShift image registry is not exposed outside the cluster by default; external access requires explicitly creating a route.
The Image Registry Operator manages the registry via the configs.imageregistry.operator.openshift.io CR; the cluster-scoped instance is named cluster.
Repository names pushed to the internal registry must use <project>/<name> format; deeper paths cause authentication errors.
PVCs for the registry must be in the openshift-image-registry namespace with annotation imageregistry.openshift.io: "true".
registry.redhat.io requires authentication; registry.access.redhat.com is the deprecated unauthenticated alternative.
The S3 storage backend default chunkSizeMiB is 10 MiB with a minimum of 5 MiB.
Registry storage is only auto-configured on installer-provisioned infrastructure (IPI) clusters on AWS, Azure, GCP, IBM, or RHOSP.
Custom storage credentials for the registry go in secret image-registry-private-configuration-user in namespace openshift-image-registry.
Registry storage credential secret keys by provider: AWS S3 uses REGISTRYSTORAGES3ACCESSKEY/REGISTRYSTORAGES3SECRETKEY, GCS uses REGISTRYSTORAGEGCSKEYFILE, Swift uses REGISTRYSTORAGESWIFTUSERNAME/REGISTRYSTORAGESWIFTPASSWORD, Azure uses REGISTRYSTORAGEAZUREACCOUNTKEY.
The registry-viewer role grants pull access and the registry-editor role grants push access to the integrated image registry.
Release channel graduation from fast to stable depends on connected cluster telemetry data about update success rates
OCP release artifacts are hosted in Quay as container images.
Remote health monitoring in OpenShift consists of two mechanisms: Telemetry (metrics/usage data) and the Insights Operator (configuration analysis and recommendations).
Neither Telemetry nor the Insights Operator collects identifying information such as usernames, passwords, or certificates
Remote health monitoring data is encrypted using TLS with mutual certificate authentication, both in transit and at rest
Remote worker nodes must use virtual media (not PXE) for IPI bare metal deployments, configured via virtualMediaViaExternalNetwork: true.
Removing the self-provisioner ClusterRoleBinding from system:authenticated:oauth prevents users from creating their own projects.
ReplicaSets belong to the apps/v1 API group (not v1 or extensions).
ReplicaSet .spec.replicas defaults to 1.
The .spec.selector is the only required field in a ReplicaSet spec; it must match the pod template's labels.
ReplicationController is a v1 core API resource that uses equality-based label selectors only, unlike ReplicaSet which supports set-based selectors.
In workload partitioning, reserved and isolated CPU sets must not overlap, and all non-isolated CPUs must be reserved.
Multiple OpenShift resources enforce field immutability after creation — Route host, IngressController domain, and IngressClass controller cannot be changed post-creation — establishing a pattern where identity-defining fields are write-once to prevent runtime conflicts and maintain stable addressing.
SubjectAccessReview resourceAttributes uses Kubernetes verbs (get, list, watch, create, update, delete, proxy); HTTP verbs are used only for nonResourceAttributes
ResourceAccessReview (authorization.openshift.io/v1) is cluster-scoped (no namespace in the URL path: POST /apis/authorization.openshift.io/v1/resourceaccessreviews), unlike its namespace-scoped counterpart LocalResourceAccessReview.
ResourceAccessReview (returns which users/groups can perform an action) is an OpenShift-only resource with no Kubernetes equivalent.
In LocalSubjectAccessReview, resourceAttributes.verb uses Kubernetes API verbs (get, list, watch, create, update, delete, proxy), while nonResourceAttributes.verb uses standard HTTP verbs.
ResourceQuota limits aggregate resource consumption per namespace in OpenShift/Kubernetes.
ResourceQuota can limit compute resources (CPU, memory), object counts (pods, services, configmaps), and storage requests; when a namespace would exceed its quota, new resource creation is blocked.
ResourceQuota is a namespace-scoped Kubernetes API object (core v1) that enforces aggregate resource consumption limits within a single namespace.
ResourceQuota scopes include BestEffort, NotBestEffort, Terminating (activeDeadlineSeconds >= 0), NotTerminating (activeDeadlineSeconds is nil), PriorityClass, and CrossNamespacePodAffinity; scope selectors use AND logic.
The restricted-v2 SCC is more restrictive than restricted — it does not allow privilegeEscalation. In upgraded clusters both exist; in new OCP 4.11+ installs only restricted-v2 is available by default.
Setting static pod operator revision limits to -1 enables unlimited revision retention
Administrators can launch Marketplace application instances by browsing CRDs in the Installed Operators list.
The Developer perspective in OCP does not include Operator installation or usage tracking — those are Administrator-only functions.
The Red Hat Marketplace Operator performs three functions: updates image registry secrets, manages the catalog, and reports application usage.
Lab-validated scale: 3,500 virtual SNO clusters managed from a single RHACM hub cluster (tested with 50ms RTT, 0.02% packet loss, 20 Mbps bandwidth).
The default SSH username for RHCOS (Red Hat Enterprise Linux CoreOS) nodes is core
The default user on RHCOS is core, with SSH key injected via Ignition.
RHCOS filesystem modifications are not preserved across minor releases unless made through a supported Operator (MCO, Node Tuning Operator).
RHCOS (Red Hat Enterprise Linux CoreOS) is the immutable container host OS used on all OCP cluster machines, including kubelet, CRI-O runtime, and SELinux enabled by default
RHCOS nodes follow an immutable infrastructure model: changes applied via Operators (not SSH), OS updates via rpm-ostree atomic images, and custom layering verified through rpm-ostree status.
RHCOS nodes are immutable — changes are applied via Operators, not SSH. SSH is a last resort when API/kubelet is down.
RHCOS is the only supported operating system for control plane nodes in OpenShift Container Platform 4.x; workers can optionally run RHEL.
QCOW2 images are not supported for ZTP; RHCOS images must match or be less than or equal to the OCP version being installed.
RHCOS uses rpm-ostree for atomic in-place OS updates, with OS updates delivered as bootable container images
SSH access to RHCOS nodes uses the core user: ssh core@<node>.
On RHCOS, /usr is read-only; /etc, /boot, and /var are writable but intended to be changed only by the MCO.
RHEL compute nodes are deprecated as of OpenShift Container Platform 4.16 and will be removed in a future release.
The trusted CA certificate path on RHEL is /etc/pki/ca-trust/source/anchors/, updated with sudo update-ca-trust enable.
Adding RHEL workers requires two rounds of CSR approval (client CSRs first, then server CSRs) within 1 hour before certificates rotate.
CSRs for new worker nodes must be approved within one hour before certificate rotation creates additional certificates.
Adding RHEL workers requires two rounds of CSR approval: first client CSRs (from node-bootstrapper), then server/serving CSRs (from system:node:*).
RHEL compute nodes require the fast-datapath-for-rhel-8-x86_64-rpms repo, but the playbook machine does not.
firewalld must be permanently disabled on RHEL worker nodes; re-enabling it breaks log access.
Four repos must be enabled for RHEL 8 workers on OCP 4.17: rhel-8-for-x8664-baseos-rpms, rhel-8-for-x8664-appstream-rpms, rhocp-4.17-for-rhel-8-x8664-rpms, fast-datapath-for-rhel-8-x8664-rpms.
RHEL worker nodes require manual OpenShift API update before the MCO can update the kubelet on those machines.
RHEL compute nodes require RHEL 8.8 or later; RHEL 7 is not supported and RHEL 7 nodes must be replaced, not upgraded.
RHEL 7 is not supported for OCP 4.17 worker nodes; minimum is RHEL 8.8.
Package-based RHEL compute worker support is deprecated and will be replaced by RHCOS image layering.
The Ansible scaleup playbook for adding RHEL workers is at /usr/share/ansible/openshift-ansible/playbooks/scaleup.yml.
Swap memory is disabled on all RHEL compute machines and cannot be re-enabled.
Control plane nodes must be RHCOS; only compute/worker nodes can be RHEL.
Package-based RHEL compute nodes are deprecated in favor of RHCOS image layering.
RHEL can only be used for compute (worker) nodes, never for control plane nodes; control plane must run RHCOS.
RHEL compute machines are supported only on x86_64 architecture in OpenShift Container Platform.
RHEL 7 workers cannot be updated in-place during cluster updates — they must be replaced with RHEL 8 or RHCOS workers
OpenShift AI distributed workloads support GPU-aware auto-scaling for distributing data processing and training jobs across GPUs.
OpenShift AI Feature Store defines, stores, and serves reusable ML features to models across both training and serving pipelines.
Guardrails is the OpenShift AI safety mechanism for filtering model input and output on deployed models.
OpenShift AI Self-Managed supports two installation modes: standard (connected) and disconnected (air-gapped) environment.
The LlamaStack operator in OpenShift AI enables OpenAI-compatible RAG APIs, integrating with vLLM and vector stores.
LM-Eval is the OpenShift AI evaluation framework, configured via LMEvalJob CRDs for benchmarking model performance.
The OpenShift AI Model Registry provides cross-project model sharing with RBAC group-based access control and version lifecycle management.
OpenShift AI model serving uses KServe with two deployment modes: RawDeployment and Knative.
There is no upgrade path from Red Hat OpenShift AI 2.x to 3.x; a fresh installation is required.
OpenShift AI pipelines are based on Kubeflow Pipelines (KFP) with S3-compatible artifact storage.
Red Hat OpenShift AI Self-Managed runs as an operator on OpenShift Container Platform.
OpenShift AI telemetry (usage data collection) can be enabled or disabled by administrators.
RHOSO default topology is "compact" where RHOSO and RHOCP control planes share the same physical nodes on a 3-node compact cluster.
RHOSO 18.0 deploys the OpenStack control plane as pods on a Red Hat OpenShift Container Platform cluster, while the data plane runs on external RHEL nodes.
The OpenStackControlPlane CRD uses apiVersion core.openstack.org/v1beta1.
RHOSO data plane RHEL nodes are configured via Ansible automation execution environments run by the OpenStack Operator.
RHOSO services disabled by default: ironic, horizon, designate, octavia, heat, and manila.
RHOSO 18.0 supports disconnected (air-gapped) deployment.
Red Hat OpenStack Services on OpenShift follows the same operator-driven platform pattern as OCP itself: a single master operator (openstack-operator) installed via OperatorHub manages all sub-operators, the control plane is defined by a CRD (OpenStackControlPlane at core.openstack.org/v1beta1), and the control plane runs as pods on RHOCP — making RHOSO a nested instance of the operator-driven immutable platform model.
Multiple RHOSO environments can coexist on a single RHOCP cluster.
NFS versions earlier than 4 are not supported across RHOSO services (Cinder, Nova, Glance).
RHOSO supports only x86_64 architecture for RHOCP master and worker nodes.
The openstack-operator is the single master operator installed via OperatorHub that installs and manages all individual RHOSO service operators.
RHOSO 18.0 requires RHOCP 4.18 as the hosting platform.
RHOSO 18.0 is the successor to director/TripleO-based RHOSP deployments; the adoption path is from RHOSP 17.1 or director Operator environments (migration, not in-place upgrade).
rocminfo is the diagnostic command for verifying AMD GPU detection in OpenShift (analogous to nvidia-smi for NVIDIA).
The OpenShift-native RBAC API objects (ClusterRole, ClusterRoleBinding, Role, RoleBinding, RoleBindingRestriction) belong to the authorization.openshift.io/v1 API group, distinct from the Kubernetes rbac.authorization.k8s.io/v1 API.
All five OpenShift authorization API objects (ClusterRole, ClusterRoleBinding, Role, RoleBinding, RoleBindingRestriction) are Compatibility Level 1 — stable within a major release for at least 12 months or 3 minor releases.
Role is namespace-scoped while ClusterRole is cluster-scoped; RoleBinding is namespace-scoped while ClusterRoleBinding is cluster-scoped.
A Role object requires the rules field, which is an array of PolicyRule objects; each PolicyRule requires verbs and resources fields.
A namespaced RoleBinding can reference a ClusterRole, granting its permissions only within the RoleBinding's namespace.
A RoleBinding referencing a ClusterRole grants those ClusterRole permissions only within the RoleBinding's namespace, not cluster-wide.
RoleBindings only have effect in the namespace where they exist, except in the master namespace which has power across all namespaces.
A RoleBinding references a Role via roleRef — it does not contain or embed the Role. Required fields are subjects and roleRef.
The userNames and groupNames fields on RoleBinding are legacy backward-compatibility fields; modern clients should use the subjects field exclusively.
RoleBindingRestriction is an OpenShift-specific resource (not in upstream Kubernetes) that controls which subjects (users, groups, service accounts) are allowed to have rolebindings in a given namespace.
RoleBindingRestriction uses permissive/OR matching: if any RoleBindingRestriction in a namespace matches a subject, rolebindings for that subject are allowed.
RoleBindingRestriction supports three restriction types: userrestriction, grouprestriction, and serviceaccountrestriction.
Rolling is the default deployment strategy for DeploymentConfig, providing zero-downtime deployments.
oc rollout undo dc/<name> reverts to the last successful revision and disables image change triggers; they must be re-enabled with oc set triggers dc/<name> --auto.
Rootless DPDK workloads (OCP 4.14+) require needVhostNet: true in SriovNetworkNodePolicy, TAP CNI plugin, SELinux boolean containerusedevices=on, and a performance profile runtime class
ROSA Classic has protected/managed resources that are managed exclusively by Red Hat SRE and cannot be modified by customers.
ROSA Classic uses AWS Secure Token Service (STS) for its deployment workflow with short-lived credentials.
ROSA is managed via two CLI tools (ROSA CLI and oc CLI) plus the OpenShift Cluster Manager (OCM) web UI.
The rosa create network command wraps AWS CloudFormation for VPC infrastructure provisioning and requires ROSA CLI v1.2.48+.
ROSA HCP defaults: Machine CIDR 10.0.0.0/16, Service CIDR 172.30.0.0/16, Pod CIDR 10.128.0.0/14, Host prefix /23.
ROSA HCP default compute configuration is 2x m5.xlarge instances (4 vCPU, 16 GiB RAM) with no autoscaling.
ROSA HCP default storage class is gp3-csi using the ebs.csi.aws.com provisioner with 300 GiB GP3 node volumes.
ROSA HCP (hosted control planes) runs the control plane in Red Hat's AWS account, not the customer's.
The ROSA logging subsystem is not installed by default — it must be added and can forward logs to external services.
ROSA uses OVN-Kubernetes as its network plugin (both HCP and classic architectures).
ROSA installation requires three CLI tools: aws CLI, rosa CLI, and oc (OpenShift client).
The IP address 172.20.0.1 is reserved for the internal Kubernetes API in ROSA and CIDRs must not conflict with it.
ROSA follows a shared responsibility model split between Red Hat, AWS, and the customer.
ROSA requires public subnets tagged with kubernetes.io/role/elb and private subnets tagged with kubernetes.io/role/internal-elb.
ROSA supports deployment into AWS GovCloud regions for government workloads.
ROSA has two deployment architectures: default (Hosted Control Planes/HCP) and classic, each with separate documentation sets.
Route is under route.openshift.io/v1 — OpenShift's native ingress mechanism, distinct from Kubernetes Ingress (networking.k8s.io/v1).
The Route resource uses API version route.openshift.io/v1 and is Compatibility Level 1 (stable within a major release for 12 months or 3 minor releases)
Route backend weights range 0–256 (default 100); weight 0 suppresses traffic; all-zero weights return 503
The destinationCACertificate field is used with reencrypt termination for validating the backend's certificate during health checks
Route HTTP header actions allow max 20 actions each for request and response headers; reserved headers (Strict-Transport-Security, Proxy, Cookie, Set-Cookie) cannot be modified
Route request header actions execute after IngressController actions; Route response header actions execute before IngressController actions
A Route's host field cannot be changed after creation; routers resolve host conflicts by preferring the oldest route
OpenShift Route host field is immutable after creation; oldest route wins on host conflicts
Route hostname pattern is <route-name>.<route-namespace>.<domain> based on the Ingress config spec.domain
HTTP/2 ALPN on OpenShift Routes requires a custom (non-wildcard) certificate — not supported with the default ingress certificate
Route insecureEdgeTerminationPolicy defaults to None; options are None, Allow, and Redirect
A Route supports maximum 4 backends total: 1 primary (spec.to) plus up to 3 alternate backends (spec.alternateBackends), all must be Services
Route is OpenShift-specific; Ingress is the Kubernetes-native equivalent.
Passthrough routes are incompatible with HTTP header actions
Route TLS termination types: edge (terminated at router, HTTP to backend), passthrough (no termination, direct to backend), reencrypt (terminated at router, re-encrypted to backend)
Setting routingViaHost to true causes pod egress to exit via ovn-k8s-mp0 into the host stack and disables hardware offload
rpm-ostree delivers transactional, atomic OS upgrades via container images with single-reboot rollback capability.
RukPak is Tech Preview (not GA) in OCP 4.17, representing the next-gen OLM packaging component using the BundleDeployment API.
Running workloads require two independently governed infrastructure stacks simultaneously: the networking/observability stack (OVN-Kubernetes + Multus + eBPF flow collection + dual-stack addressing) provides connectivity and visibility, while the resource governance stack (autoscaling + scheduling + quotas + storage placement) controls capacity and placement — both operating within the identity and quota governance model
RuntimeClass uses API group node.k8s.io/v1 and is a cluster-scoped resource.
RuntimeClass handler field is required, immutable once set, and must be a lowercase DNS label conforming to RFC 1123.
RuntimeClass resources are manually defined by users or cluster provisioners — they are not auto-discovered.
RuntimeClass scheduling.nodeSelector is merged with the pod's existing nodeSelector during admission; conflicts cause admission rejection.
RuntimeClass scheduling.tolerations are appended (not replaced) to the pod's tolerations during admission, excluding duplicates.
S2I build steps execute in order: FROM builder image → copy source code → run assemble script → set run script as default command → Buildah creates the container image.
Buildah is the tool that creates the final container image after S2I completes its build steps.
Source-to-Image (S2I) builds use the builder~git-url syntax (e.g., python~https://github.com/...) to trigger a source build that creates a BuildConfig, ImageStream, Deployment, and Service.
Custom S2I scripts are placed in the .s2i/bin/ directory of the application source (e.g., .s2i/bin/assemble, .s2i/bin/run).
Source-to-Image (S2I) runtime base images are accessible from the Developer perspective via +Add → Developer Catalog.
Source-to-Image (S2I) is the recommended default build strategy — it produces consistent images without requiring a Dockerfile.
The two required S2I scripts are assemble (build the app) and run (execute the app)
When wrapping the S2I run script, you must use exec to invoke the default run script to ensure proper signal handling; no commands can follow the exec call.
S2I script search order: (1) build config, (2) .s2i/bin in application source, (3) io.openshift.s2i.scripts-url label on builder image
The S2I scripts location is stored in the io.openshift.s2i.scripts-url label on the builder image (typically image:///usr/libexec/s2i).
automountServiceAccountToken: false on a ServiceAccount disables automatic token mounting, but pod-level settings override SA-level settings.
The annotation kubernetes.io/enforce-mountable-secrets must be set to "true" on a ServiceAccount to restrict which secrets a pod can mount via the SA's secrets list.
ServiceAccount imagePullSecrets are accessed by the kubelet (not the pod) for pulling container images and are not mountable into pods.
Service account issuer trust has a 24-hour default expiration for previously-used issuers in the KubeAPIServer resource
ServiceAccounts are namespace-scoped resources accessed via /api/v1/namespaces/{namespace}/serviceaccounts.
The recommended way to obtain ServiceAccount tokens for use outside pods is the TokenRequest API, not auto-generated SA token secrets.
To change the Cluster Samples Operator architecture, you must set state to Removed first, then change architecture and set back to Managed
The Cluster Samples Operator bootstraps as Removed when: registry unreachable after 3 minutes on fresh install, IPv6 network detected, or image controller config prevents image stream creation
The Cluster Samples Operator config resource is configs.samples.operator.openshift.io, kind Config, name cluster; edited via oc edit configs.samples.operator.openshift.io/cluster
The Cluster Samples Operator default management state is Managed and default registry is registry.redhat.io
The Samples Operator default registry for sample ImageStreams is registry.redhat.io.
The imagestreamtag-to-image config map in openshift-cluster-samples-operator namespace maps imagestream tags to image references for mirroring guidance
Failed image stream tag imports are retried every ~15 minutes; failing-import alerts start 2 hours after installation when state is Managed
The Samples Operator manages sample ImageStreams and Templates in the openshift namespace.
Setting the Samples Operator managementState: Removed causes it to delete all managed ImageStreams, Templates, and the registry secret.
Using skippedImagestreams/skippedTemplates in the Samples Operator prevents recreation but does not delete existing resources — admins must manually delete them.
The Samples Operator supports three architectures: x86_64, ppc64le, and s390x.
The Cluster Samples Operator has three management states: Managed (actively manages samples), Unmanaged (ignores updates), and Removed (deletes all managed content then behaves like Unmanaged)
OpenShift sandboxed containers use Kata Containers to run pods inside lightweight VMs, providing hardware-virtualization-based isolation stronger than namespace/cgroup isolation.
OpenShift sandboxed containers are deployed via the OpenShift sandboxed containers Operator, and the KataConfig CR triggers deployment of the Kata runtime on selected nodes.
Workloads opt into OpenShift sandboxed containers by setting runtimeClassName: kata in the pod spec.
OpenShift sandboxed containers use Kata Containers as the underlying runtime technology for workload isolation beyond standard container boundaries.
OpenShift sandboxed containers is versioned separately from core OCP (e.g., version 1.11).
OpenShift sandboxed containers and OpenShift Virtualization (KubeVirt) both use virtualization but serve different purposes — KubeVirt runs full VMs as workloads, while sandboxed containers run standard container images in lightweight VMs for isolation.
Empty string for namespace in SubjectAccessReview resourceAttributes means "all namespaces" for namespace-scoped resources
SubjectAccessReview spec must contain exactly one of resourceAttributes or nonResourceAttributes
The command to scale a MachineSet is oc scale --replicas=<n> machinesets.machine.openshift.io <name> -n openshift-machine-api.
The Scale subresource is part of autoscaling/v1 and is accessed via /{resource-name}/scale — not a top-level API object
Four resource types support the Scale subresource: Deployment, ReplicaSet, StatefulSet, and ReplicationController
allowPrivilegeEscalation in an SCC defaults to true if unset.
SecurityContextConstraints (SCC) is under the security.openshift.io/v1 API group — OpenShift-specific, not standard Kubernetes.
SecurityContextConstraints (SCCs) belong to the security.openshift.io API group.
SecurityContextConstraints use the API group security.openshift.io/v1; the old core Kubernetes API group exposure is deprecated.
SecurityContextConstraints (SCCs) are cluster-scoped resources, not namespaced.
SCCs are granted to users/service accounts via oc adm policy add-scc-to-user <scc-name> -z <service-account>.
SCC is migrating from the core API group to security.openshift.io; the core API group exposure is deprecated
SecurityContextConstraints (SCCs) are OpenShift-specific (not standard Kubernetes), have Compatibility Level 1 (stable 12+ months), and are the primary mechanism for controlling pod security privileges in OpenShift
SecurityContextConstraints (SCCs) are the primary OpenShift-specific security API object, controlling what a pod can and cannot do.
SCC priority field determines evaluation order: higher priority SCCs are tried first; ties are broken by most-restrictive-first, then by name.
SecurityContextConstraints (SCCs) are OpenShift-specific security controls with no direct Kubernetes equivalent; PodSecurityPolicies are deprecated.
Capabilities listed in requiredDropCapabilities are always dropped and cannot be re-added via allowedCapabilities.
SCCs have seven required boolean fields: allowHostDirVolumePlugin, allowHostIPC, allowHostNetwork, allowHostPID, allowHostPorts, allowPrivilegedContainer, readOnlyRootFilesystem.
SCC volumes field uses "*" to allow all volume types and ["none"] to allow none.
oc tag <source> <stream>:<tag> --scheduled=true enables periodic re-import of a tag from an external registry.
The Scheduler config API (config.openshift.io/v1) defines scheduling profiles and policies, while the KubeScheduler operator API (operator.openshift.io/v1) manages how the scheduler is deployed
The Scheduler resource's defaultNodeSelector creates an intersection with existing pod nodeSelectors (constrains further, does not replace).
The default OpenShift scheduler profile is LowNodeUtilization, which spreads pods evenly across nodes
The Scheduler resource's mastersSchedulable defaults to false — master/control plane nodes do not run workload pods by default.
The namespace-level openshift.io/node-selector annotation overrides the cluster-wide defaultNodeSelector from the Scheduler config.
The Scheduler resource's policy field (ConfigMap-based custom scheduler policy in openshift-config) is deprecated, replaced by scheduling profiles.
The kube-scheduler prefers maximumVolumeSize over capacity when filtering nodes for volume placement; if neither is set, the node is considered to have insufficient capacity.
The scheduler profile is configured on the Scheduler object named cluster (API config.openshift.io/v1) via spec.profile, requiring cluster-admin role
The Scheduler resource supports three profiles: LowNodeUtilization (default, spreads pods), HighNodeUtilization (packs pods onto fewer nodes), and NoScoring (skips scoring for faster scheduling).
The default scheduler operates in 3 steps: (1) filter nodes using predicates, (2) prioritize using scoring functions (0–10 scale multiplied by weight), (3) select highest-scoring node with random tiebreaker
OpenShift pod scheduling operates across multiple constraint dimensions simultaneously: node selectors with six operators (In/NotIn/Exists/DoesNotExist/Gt/Lt), affinity/anti-affinity rules, taint effects (NoSchedule/PreferNoSchedule/NoExecute), scheduling gates (creation-time only), topology manager NUMA policies, and default node selectors that intersect with pod-level selectors — creating a constraint-satisfaction problem, not a simple placement decision.
Pod schedulingGates can only be set at creation time and removed afterward; they cannot be added post-creation.
SCTP is enabled on OpenShift by loading the sctp kernel module via MachineConfig (clearing blacklist in /etc/modprobe.d/sctp-blacklist.conf and adding to /etc/modules-load.d/sctp-load.conf).
Seccomp profiles cannot be applied to privileged containers.
The pod annotation method for seccomp (seccomp.security.alpha.kubernetes.io/pod) is deprecated in OCP 4.17; the current method uses seccompProfile.type: Localhost with localhostProfile in the security context.
Custom seccomp profiles are stored as JSON files at /var/lib/kubelet/seccomp/ on each node and must be deployed to all worker nodes via MachineConfig.
Secondary networks can be defined using either a UserDefinedNetwork CR or a NetworkAttachmentDefinition CR.
Kubernetes Secret data values are base64-encoded (not encrypted at rest by default), and total bytes of all values in data must be less than MaxSecretSize (1 MB)
Keys in Secret data fields must consist of alphanumeric characters, -, _, or .
Setting immutable: true on a Secret prevents data modifications; only metadata can be changed afterward
The Secret stringData field is write-only: it accepts plain strings on creation/update that are merged into data as base64, but is never returned in API responses
A Secret with type: kubernetes.io/tls requires the keys tls.crt and tls.key
The ImageStream secrets endpoint is read-only (only GET is defined); secrets are managed through the core Secret API
SecretList is accessed as a sub-resource of ImageStream via GET /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/secrets
The items field is the only required field in the SecretList resource
Secrets are created with oc create secret generic <name> --from-literal=KEY=VALUE and attached to deployments with oc set env --from=secret/<name> deploy/<name>.
OpenShift enforces both software delivery governance (build→operator→console pipeline) and security enforcement (FIPS, TLS, SCCs, admission) as topology-invariant properties: whether the cluster is standalone HA, hosted control plane, or single-node edge, the same governance pipeline delivers software and the same security stack constrains it
OpenShift enforces a unified security and governance stack: install-time locks (FIPS, CPU partitioning) set the foundation, identity management (OAuth→User→Identity) controls who, dual authorization (RBAC+SCC) controls what, node immutability (MCO pipeline) ensures infrastructure integrity — all reinforced by API admission and runtime TLS/IPsec enforcement.
Security API compatibility levels: SCC is Level 1 (stable 12 months/4 minor releases), PodSecurityPolicy reviews are Level 2 (stable 9 months/3 minor releases), RangeAllocation is Level 4 (no guarantees)
Security enforcement shapes the entire progressive update path: install-time locks (FIPS, CPU partitioning) persist immutably through all updates, TLS profiles must be maintained during rolling upgrades across heterogeneous node fleets, and API stability tiers gate which deprecations can occur at each version boundary.
OpenShift security operates as a three-layer enforcement model: install-time constraints lock FIPS mode and CPU partitioning permanently, runtime TLS profiles and IPsec govern network encryption, and API-boundary controls (webhooks with mandatory TLS, admission with 13s timeout cap, tiered stability guarantees) prevent unauthorized or unstable mutations — creating defense-in-depth from cluster birth through ongoing operations.
Security enforcement is the invariant that holds across all topology variants: install-time locks (FIPS, CPU partitioning) apply regardless of whether control planes are standalone, hosted, or edge; TLS/IPsec spans all network topologies; and API governance prevents circumventing security via any operational model — divergent topologies cannot escape the unified security stack.
security.openshift.io/v1 is Tier 1 except RangeAllocation (Tier 4) and *Reviews (Tier 2).
Project self-provisioning can be enabled or disabled cluster-wide by modifying the self-provisioner ClusterRoleBinding
Cluster admins can restrict project self-provisioning by removing the self-provisioners cluster role binding.
SelfSubjectRulesReview status contains resourceRules (actions on API resources with K8s verbs) and nonResourceRules (actions on non-resource URL paths like /healthz with HTTP verbs).
SelfSubjectRulesReview results can be incomplete — the status.incomplete boolean and status.evaluationError string indicate this. However, authorization rules are additive: presence in the list confirms permission even if the list is incomplete.
SelfSubjectRulesReview should only be used for UI show/hide hints, NOT for driving external authorization decisions (confused deputy/cache concerns).
SelfSubjectRulesReview (authorization.k8s.io/v1) is intended for UI display purposes only (show/hide actions); external systems should use SubjectAccessReview or LocalSubjectAccessReview for authorization decisions.
OpenShift Serverless is based on the open source Knative project and is the Red Hat enterprise distribution of Knative.
OpenShift Serverless is installed and managed via the OpenShift Serverless Operator from OperatorHub.
OpenShift Serverless is installed via the Serverless Operator, which manages Knative Serving and Knative Eventing components.
OpenShift Serverless integrates with OpenShift Service Mesh.
OpenShift Serverless is Red Hat's distribution of Knative, providing Serving, Eventing, and Functions capabilities.
The kn CLI is the primary Knative command-line client for managing serverless resources on OpenShift.
OpenShift Serverless enables scale-to-zero behavior — pods are removed when there is no traffic and recreated on demand.
OpenShift Serverless releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.
OpenShift Serverless has two core components: Knative Serving (request-driven compute with scale-to-zero) and Knative Eventing (declarative event source and routing infrastructure).
Changing spec.serviceAccountIssuer on the Authentication resource does not immediately invalidate existing tokens — a 24-hour grace period allows internal components to transition.
Dual-stack Services use ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack) and ipFamilies (IPv4, IPv6); clusterIPs holds max two entries
externalTrafficPolicy: Local preserves client source IP but drops traffic on nodes with no local endpoints; default is Cluster
A headless Service is created by setting clusterIP: "None" — no virtual IP allocated, endpoints published directly; used for StatefulSet peer discovery
healthCheckNodePort only applies when type=LoadBalancer AND externalTrafficPolicy=Local; lets external LBs probe endpoint availability
loadBalancerIP is deprecated; implementation-specific annotations should be used instead
Red Hat OpenShift Service Mesh 3.x is now generally available and is based on Istio Sail rather than Maistra (used by 2.x).
OpenShift Service Mesh 3.x is built on upstream Istio with the Sail Operator, replacing the older Maistra-based approach from 2.x.
Red Hat OpenShift Service Mesh 2.x is based on the open source Istio project, with additional components: Envoy Proxy (sidecar), Kiali (observability console), and Jaeger/Tempo (distributed tracing).
The Service Mesh control plane (SMCP) is typically installed in the istio-system namespace.
OpenShift Service Mesh 3.x (up to 3.2) is the current major version line, separate from the older 2.x line.
OpenShift Service Mesh provides four core capabilities: traffic management, service identity and security, policy enforcement, and telemetry.
OpenShift Service Mesh operates as a multi-operator, multi-tenant system: it requires installing multiple operators (Service Mesh, Kiali, tracing), defaults to multi-tenant isolation (unlike upstream Istio), uses Istio Sail (replacing Maistra in 3.x), and integrates with Serverless.
OpenShift Service Mesh is multi-tenant by default, unlike upstream Istio which uses a single-tenant cluster-wide model; scope is limited to namespaces listed in the ServiceMeshMemberRoll.
Service Mesh does not require application code changes — it works transparently via sidecar proxies that intercept traffic between services.
OpenShift Service Mesh provides traffic management, observability, and security (mTLS) between microservices.
Service Mesh requires multiple operators to be installed: the Red Hat OpenShift Service Mesh Operator, Kiali Operator, and a tracing operator (Jaeger or Tempo).
serviceNetwork currently supports only a single entry
serviceNodePortRange defaults to 30000-32767 and can be changed post-install (unlike most Network spec fields)
port is the only required field in a ServicePort definition; targetPort defaults to the port value if omitted
publishNotReadyAddresses: true treats all endpoints as ready; critical for StatefulSet peer discovery via SRV DNS records
Service sessionAffinity supports ClientIP or None (default); ClientIP sticky timeout defaults to 10800s (3 hours), max 86400s (1 day)
Service types form a hierarchy: ClusterIP (default) → NodePort (adds node port) → LoadBalancer (adds external LB); ExternalName is separate (CNAME only, no proxying)
The ServiceCA resource (operator.openshift.io/v1) configures the operator that manages the service serving certificate signer, responsible for automatic TLS cert generation for services
ServiceMonitor endpoint authentication options (authorization, basicAuth, oauth2) are mutually exclusive
In ServiceMonitor, honorLabels: true preserves the metric's own labels when they collide with target labels
ServiceMonitor's jobLabel field selects a label from the associated Service to use as the Prometheus job label; defaults to Service name if unset
The only required field under ServiceMonitor .spec is selector — a label selector for Endpoints discovery
In ServiceMonitor endpoints, port refers to the Service port name and targetPort refers to the Pod container port; port takes precedence when both are specified
ServiceMonitor's sampleLimit controls the per-scrape limit on accepted samples; exceeding it causes the scrape to fail
ServiceMonitor selects monitoring targets by matching services; PodMonitor selects monitoring targets by matching pods directly. Both are monitoring.coreos.com/v1.
The Shared Resource CSI Driver is deprecated in OCP; it migrated to Builds for Red Hat OpenShift 1.1.
The Shared Resources CSI Driver is a component that integrates with Builds for Red Hat OpenShift, enabling shared resources (secrets/ConfigMaps) to be mounted into build pods.
The openshift namespace contains cluster-level shared templates available to all projects
Shipwright can build container images from both source code and Dockerfiles.
Shipwright can build container images from source code (including local directories), and Dockerfiles.
Shipwright builds execute within the OpenShift cluster itself, not externally.
The Shipwright CLI is a separate tool from oc used for creating builds, viewing build run logs, and managing builds on the cluster.
Shipwright-based Builds is distinct from and replaces the legacy OpenShift Build system based on BuildConfig objects and oc start-build.
Builds (Shipwright) releases on a different cadence from OpenShift Container Platform itself and has its own separate documentation set at docs.redhat.com.
Shipwright is an extensible, Kubernetes-native build framework for building container images on OpenShift Container Platform clusters, based on the upstream Shipwright project (shipwright.io).
Shipwright builds run on-cluster within the OpenShift environment, not externally.
Shipwright-based Builds supports both Source-to-Image (S2I) and Buildah as build strategies.
Shipwright-based Builds supports three build strategy types: Source-to-Image (S2I), Buildah, and custom user-defined strategies.
Image signature condition types are exactly two: Complete and Failed, with status values of True, False, or Unknown.
Sigstore enables key-less container image signing using OIDC identity via the Fulcio certificate authority, eliminating traditional key management.
Rekor is the sigstore component that records signature metadata to an immutable, tamper-resistant transparency log.
Sigstore signatures are stored in the same container registry as the build images, requiring no separate signature server.
Non-admin users need both cluster-monitoring-view and monitoring-alertmanager-edit roles to manage silences; monitoring-rules-edit role is needed to create alerting rules in user projects.
Alertmanager silences are replicated across Alertmanager pods but require persistent storage to survive pod restarts.
Single-NIC nodes must use br-ex for localnet bridge mappings; multi-NIC nodes can use a dedicated bridge for traffic isolation.
Worker nodes with GPUs must have all GPUs of the same type — mixing GPU models on a single node is not supported by the NVIDIA Device Plugin.
Multiple OpenShift operators enforce a singleton naming convention where the CR must be named a specific value (typically cluster or default): OAuth, Console, FlowCollector, ClusterAutoscaler, Storage operator, and PowerMonitor each reject other names.
A ServiceMeshMember (SMM) resource allows project admins to add their namespace to a mesh without needing cluster-admin to edit the SMMR.
The ServiceMeshMemberRoll (SMMR) must be named default and must reside in the same namespace as the ServiceMeshControlPlane (SMCP).
The VolumeSnapshot/VolumeSnapshotContent/VolumeSnapshotClass pattern mirrors the PVC/PV/StorageClass pattern: VolumeSnapshot is the user request, VolumeSnapshotContent is the backing object, VolumeSnapshotClass defines provider parameters.
Required capabilities for SNO vDU with baselineCapabilitySet: None: NodeTuning (4.13+), OperatorLifecycleManager (4.15+), and Ingress (4.16+).
DNS must resolve api-int.<clustername>.<basedomain> for worker node addition to an SNO cluster.
SNO clusters require three DNS records: api.<cluster>.<domain>, api-int.<cluster>.<domain>, and *.apps.<cluster>.<domain>.
Adding worker nodes to a single-node OpenShift cluster requires no downtime and the original node retains its control plane role.
SNO cluster expansion by adding worker nodes is a Technology Preview feature in OCP 4.17 (not supported under production SLAs).
All ingress traffic routes to the single control-plane node by default in SNO, even after adding worker nodes.
SNO can be installed via the Assisted Installer, agent-based installer, or manual UPI.
Single-Node OpenShift (SNO) is a key topology for edge deployments, running both control plane and workloads on a single node.
Single-node OpenShift (SNO) clusters support a tested maximum of 2 worker nodes; exceeding this may cause performance degradation or cluster failure.
SNO does not provide high availability — etcd runs as a single instance.
Single-node OpenShift has a constrained operational profile: no live migration or HA for VMs, SR-IOV requires disabling drain, and worker node expansion requires OCP 4.11+.
Single Node OpenShift (SNO) runs both control plane and worker roles on a single node, combining etcd, API server, controllers, and workloads on one host.
For SNO with static IPs, the node-specific, API, and Ingress IPs should all be the same address.
Single Node OpenShift (SNO) is a supported production configuration, not limited to development or testing.
Single-node OpenShift (SNO) updates require downtime; no MHC pause is needed, node draining is skipped, and there is no automatic rollback on failure
CSR approval is mandatory to complete worker node installation on SNO clusters.
SNO worker node minimum requirements: 2 vCPU, 8 GB RAM, 100 GB storage.
Adding worker nodes to SNO requires OpenShift Container Platform 4.11 or later.
Adding worker nodes to SNO does NOT provide high availability and does NOT expand the control plane.
Workload partitioning policies must be deployed and remediated on the hub cluster before installing the worker node; doing it after requires manual drain and pod deletion.
spec.oauthMetadata takes precedence over status.integratedOAuthMetadata on the Authentication resource.
SR-IOV provides near-native I/O performance by bypassing the kernel networking stack, exposing virtual functions (VFs) directly to pods while the physical function (PF) remains on the host.
The SR-IOV network config daemon runs as a DaemonSet on worker nodes, discovering and initializing SR-IOV devices.
SR-IOV (Single Root I/O Virtualization) enables near-native network performance by allowing pods direct access to virtual functions (VFs) on physical NICs.
The SR-IOV Network resources injector adds the resource field to only the first container in a pod.
SR-IOV is a key technology for telco/NFV and low-latency use cases on OpenShift.
SR-IOV functionality in OpenShift is managed by the SR-IOV Network Operator, installed via OperatorHub/OLM.
Multi-network policies on SR-IOV networks are Technology Preview, supported for kernel NICs only, and not supported for DPDK applications.
NET_ADMIN capability is required in a pod only when the application needs to assign a multicast IP address to the SR-IOV interface.
The physical network infrastructure (not OpenShift) controls multicast routing and topology for SR-IOV interfaces.
SR-IOV multicast IPAM must include routes 224.0.0.0/5 and 232.0.0.0/5 to override the default network provider's static multicast routes.
Applying an SriovNetworkNodePolicy may drain and reboot nodes; sufficient available nodes must exist for evicted workloads
The SR-IOV Network Resources Injector and Operator Webhook both run as DaemonSets on control plane nodes.
The SR-IOV Operator performs node draining before every policy change by default; this must be disabled for single-node clusters.
The node label to mark SR-IOV-capable nodes is feature.node.kubernetes.io/network-sriov.capable="true".
SR-IOV network node policies use the node selector label feature.node.kubernetes.io/network-sriov.capable: "true" to target SR-IOV capable nodes.
The SriovOperatorConfig CR (named default) controls enablement of the SR-IOV webhook and resources injector, both enabled by default.
The SriovOperatorConfig CR must be named default in the openshift-sriov-network-operator namespace — no other name is valid.
The SR-IOV Network Operator automatically creates NetworkAttachmentDefinitions when SriovNetwork CRs are defined
All SR-IOV Network Operator resources live in the openshift-sriov-network-operator namespace
The SR-IOV Network Operator is required to manage SR-IOV resources in OpenShift, discovering SR-IOV-capable devices and configuring virtual functions.
SR-IOV (Single Root I/O Virtualization) is the primary hardware networking technology in OpenShift, allowing a single physical NIC to present multiple virtual functions to pods for near-native network performance
SR-IOV Operator installation requires bare-metal hardware with SR-IOV-capable NICs.
For single-node OpenShift, the SR-IOV Operator requires disableDrain: true and annotation workload.openshift.io/allowed=management on the namespace.
SR-IOV is supported only on bare metal and Red Hat OpenStack Platform (RHOSP) — not on cloud platforms like AWS/Azure/GCP.
SR-IOV has two driver modes: netdevice (exposes VF as kernel network device) and vfio-pci (exposes VF as character device).
Setting startingCSV in a Subscription to pin a specific Operator version requires installPlanApproval: Manual.
StatefulSet default pod management policy is OrderedReady — pods created sequentially (0, 1, 2…) and scaled down in reverse order.
StatefulSet default update strategy is RollingUpdate; the alternative OnDelete requires manual pod deletion to trigger updates.
Setting partition in a StatefulSet RollingUpdate only updates pods with ordinal >= partition value, enabling canary deployments.
StatefulSet pods are named <statefulsetname>-<podindex> (e.g., web-0, web-1, web-2).
StatefulSet PVC retention default is Retain — PVCs are NOT deleted when the StatefulSet is deleted or scaled down.
StatefulSet replicas defaults to 1 if unspecified.
A StatefulSet's serviceName field is required and must reference a pre-existing headless Service that provides network identity.
The only allowed restartPolicy in a StatefulSet pod template is Always.
StatefulSets are for applications needing stable identity/numbering and independent storage (e.g., databases, ZooKeeper).
Default revision limits (failedRevisionLimit and succeededRevisionLimit) for static pod operators are 5 when set to 0 or unset
Static pods are automatically restarted by the kubelet on node reboot but cannot use Secrets or ConfigMaps.
OCP storage APIs span multiple API groups: v1 (core — PV/PVC), storage.k8s.io (StorageClass, CSI objects), and snapshot.storage.k8s.io (VolumeSnapshot resources).
OpenShift storage follows a complete lifecycle model: CSI plugin architecture provides the backend, PVCs progress through three phases (Pending→Bound→Lost) with indefinite waiting semantics, StorageClass defaults to Delete reclaim policy, and ClusterCSIDriver enforces platform-specific limits (e.g., vSphere 3-snapshot cap) — creating a governed resource lifecycle from claim through cleanup.
Storage Object in Use Protection is enabled by default in OCP, preventing deletion of PVCs actively used by pods and PVs bound to PVCs.
The Storage operator CR (operator.openshift.io/v1) singleton instance must be named cluster
CSIDriver, StorageClass, VolumeAttachment, and VolumeSnapshotClass are non-namespaced (cluster-scoped) resources.
allowVolumeExpansion: true must be set on the StorageClass to permit PVC resizing.
The default reclaimPolicy for dynamically provisioned PersistentVolumes is Delete.
StorageClass objects are globally scoped (not namespaced) and must be created by cluster-admin or storage-admin users.
StorageClass mountOptions are not validated at creation time; invalid options only cause failures at mount time.
The provisioner field is the only required field on a StorageClass resource.
volumeBindingMode: WaitForFirstConsumer delays PVC binding and provisioning until a Pod referencing the PVC is scheduled, enabling topology-aware provisioning.
StorageState is in the migration.k8s.io/v1alpha1 API group (alpha-level API).
The currentStorageVersionHash in StorageState comes from the API server's discovery document, not from the StorageState spec.
StorageState and StorageVersionMigration are v1alpha1 APIs in the migration.k8s.io API group.
If "Unknown" is present in persistedStorageVersionHashes, it is not safe to upgrade or downgrade the API server.
StorageVersionMigration targets a resource using three fields: group, resource, and version.
The StorageVersionMigration .spec.resource field is immutable after creation.
Clusters using AWS STS, Microsoft Entra Workload ID, or GCP Workload Identity must use Manual approval strategy for Operator subscriptions.
SubjectAccessReview is cluster-scoped (not namespaced) — accessed via a single endpoint POST /apis/authorization.k8s.io/v1/subjectaccessreviews
Submariner provides layer 3 inter-cluster networking; Red Hat Service Interconnect provides layer 7 inter-cluster networking
The Subscription resource uses API group operators.coreos.com/v1alpha1
Subscription spec.config.env and spec.config.resources are immutable after creation
The Subscription config section supports: env, envFrom, volumes, volumeMounts, tolerations, resources, and nodeSelector.
Subscription spec.config supports nodeSelector, tolerations, and affinity to control operator pod placement (e.g., placing operators on infrastructure nodes)
Subscription installPlanApproval has exactly two valid values: Automatic and Manual
Subscription required spec fields are name, source, and sourceNamespace
A Subscription specifies the channel, source, and approval strategy (Automatic vs Manual) for Operator updates.
Subscription startingCSV optionally pins the initial ClusterServiceVersion; without it, the latest in the channel is installed
A Subscription triggers OLM to resolve and create an InstallPlan, which when approved installs the ClusterServiceVersion (CSV).
Support cases are filed through the Red Hat Customer Portal at access.redhat.com
Filing a Red Hat support case requires a Red Hat Standard or Premium subscription
system:authenticated and system:unauthenticated are virtual groups automatically assigned to users based on authentication status
The system-node-critical priority class has higher priority than system-cluster-critical.
Setting tag.reference=true on an ImageStreamTag or ImageTag spec means the tag will NOT be imported
TALM (Topology Aware Lifecycle Manager) applies ZTP policies in wave order using the ran.openshift.io/ztp-deploy-wave annotation and automatically creates a ClusterGroupUpgrade CR.
TALM's batchTimeoutAction defaults to continue (skip failing clusters); can be set to abort to stop all remediation.
In TALM, canary clusters are updated first (each in its own batch), and any failure in a canary cluster stops the entire update process.
The ClusterGroupUpgrade (CGU) CR (ran.openshift.io/v1alpha1) is TALM's primary resource, defining clusters, policies, concurrency, canaries, timeouts, and actions.
A completed TALM ClusterGroupUpgrade CR cannot be reused — a new CGU CR must be created for subsequent updates.
The TALM controller deployment is named cluster-group-upgrades-controller-manager in the openshift-operators namespace.
Policies used with TALM must have remediationAction: inform — TALM handles the enforce lifecycle itself.
TALM's pre-caching feature (preCaching: true) is designed for Single-Node OpenShift clusters with limited bandwidth; TALM checks disk space before caching images.
The Topology Aware Lifecycle Manager (TALM) requires Red Hat Advanced Cluster Management (RHACM) 2.9 or later.
To stop advertising old Tang keys while still allowing decryption, rename .jwk files with a dot prefix (e.g., .key.jwk).
Tang server keys are stored in /var/db/tang as .jwk files; new keys are generated by /usr/libexec/tangd-keygen /var/db/tang.
Tang rekeying order: generate new key → rekey all nodes → delete old key. Deleting the old key before all nodes are rekeyed will make those nodes unbootable.
Tang is a stateless server that requires no TLS, no authentication, and never stores or learns node encryption keys.
Jenkins-to-Tekton concept mapping: Jenkins Pipeline maps to Pipeline + PipelineRun, Jenkins Stage maps to Task, Jenkins Step maps to a step within a Task.
Every step in OpenShift Pipelines runs as a container in a pod.
Tekton Hub replaces Jenkins plugins as the extensibility mechanism, providing a catalog of reusable community tasks.
The runAfter field controls task execution order in a Tekton pipeline.
OpenShift Pipelines uses OpenShift's built-in RBAC for authorization instead of a plugin like Jenkins.
Tekton Workspaces serve triple duty: storage for inputs/outputs/artifacts, shared data among tasks, and mount points for secrets/configmaps.
Both Telemetry and the Insights Operator are installed and enabled by default on OpenShift clusters
Telemetry and the Insights Operator are enabled by default in connected OpenShift clusters.
The Telemeter Client sends Prometheus metrics to Red Hat every 4 minutes and 30 seconds
The Telemetry client gathers and uploads metrics to Red Hat every 4 minutes and 30 seconds.
Viewing telemetry data requires the cluster-admin or cluster-monitoring-view role
Telemetry collects metrics and usage data, while the Insights Operator gathers anonymized cluster configuration and provides actionable recommendations via Red Hat Insights analysis.
The Template API category covers three object types: Template (parameterized resource definition), TemplateInstance (record of processed template), and BrokerTemplateInstance (used by template service broker)
Image streams must have the builder tag in annotations to appear as builder images in the web console Developer Catalog.
Cluster-wide templates are stored in the openshift project and can be listed with oc get templates -n openshift.
Hardcoded namespace values in template objects are stripped during instantiation, but parameterized namespaces (containing ${PARAMETER_REFERENCE}) are preserved after substitution
Template-level labels are applied to all objects created from the template.
oc process --parameters -f <filename> lists the overridable parameters of a template.
If a value is specified on a template parameter, the generator is ignored
Template parameter substitution uses ${PARAMETER_NAME} syntax, and the only supported generator type is "expression"
Template parameters with generate: expression and from: (e.g., '[A-Z0-9]{8}') produce auto-generated values such as passwords.
oc process -f <file> | oc create -f - is the standard pattern for creating objects from a template file in OpenShift.
Quick start database templates use ephemeral storage by default — data is lost on pod restart.
A template parameter with required: true causes template processing to fail if no value is supplied and no default or generator exists.
The Template Service Broker is a deprecated component in newer OCP versions; BrokerTemplateInstance exists to support the Open Service Broker API integration.
TemplateInstance is a namespaced resource in the template.openshift.io/v1 API group that records the instantiation of a Template
TemplateInstance .spec.secret references a Secret containing template parameter values, keeping sensitive values out of the TemplateInstance spec
TemplateInstance status conditions have two types: Ready and InstantiateFailure
Templates are an OpenShift-native mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.
Templates are an OpenShift-specific API extension not present in upstream Kubernetes
Shared templates are placed in the openshift namespace to make them accessible from all namespaces.
Templates are an OpenShift-specific mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.
Templates are an OpenShift-specific concept not found in vanilla Kubernetes
Templates are an OpenShift-specific mechanism for deploying parameterized sets of resources, distinct from Helm charts.
Templates are increasingly supplemented by Helm charts and Operators as preferred deployment mechanisms in modern OpenShift versions
To delete a TempoStack instance via CLI: oc delete tempo <instance_name> -n <namespace> (uses tempo resource kind, not tempostack)
When removing the Distributed Tracing Platform (Tempo), TempoStack instances must be deleted before removing the Tempo Operator
Removing the Distributed Tracing Platform requires cluster-admin role, or dedicated-admin on Red Hat OpenShift Dedicated
ThanosRuler's alertmanagersConfig requires Thanos v0.10.0+; queryConfig requires v0.11.0+
ThanosRuler is a CRD in the monitoring.coreos.com/v1 API group, managed by the Prometheus Operator
ThanosRuler's default data retention is 24h
ThanosRuler deploys as a StatefulSet with two containers: thanos-ruler and config-reloader
ThanosRuler's prometheusRulesExcludedFromEnforce is deprecated in favor of excludedFromEnforcement
ThanosRuler always adds the thanosrulerreplica label and automatically drops it from alerts
If ThanosRuler's ruleNamespaceSelector is unspecified, only the ThanosRuler's own namespace is used for rule discovery
Third-party registries do not provide image push notifications to OpenShift; tags are fetched only at image stream creation time and must be manually refreshed with oc import-image.
OpenShift provides three autoscaling mechanisms: HPA (horizontal, CPU/memory-based), VPA (vertical, adjusts resource requests), and Custom Metrics Autoscaler (non-CPU/memory metrics).
OpenShift BuildConfig supports three build strategies: Dockerfile-based, Source-to-Image (S2I), and Custom builds.
Exactly three control plane nodes are required for production; bare metal clusters can scale up to five.
OpenShift has three image mirror resources: ImageContentPolicy (general), ImageDigestMirrorSet (digest-based), and ImageTagMirrorSet (tag-based).
OpenShift has three image reference types: ImageStreamTag (<stream>:<tag>), ImageStreamImage (<stream>@<sha256:digest>), and DockerImage (<registry>/<namespace>/<image>:<tag>).
Three distinct roles interact with Operators in OpenShift: cluster admin (install/manage), developer (consume), and Operator author (build).
Tier 1 APIs must round-trip between versions without information loss.
GPU time-slicing has no memory or fault isolation between workloads, unlike MIG which provides full isolation.
TCP Round Trip Time (TimeFlowRttNs) is the Smoothed RTT (SRTT) measured in nanoseconds
The tkn CLI interacts with OpenShift Pipelines (Tekton-based CI/CD).
The tkn CLI version for OpenShift Container Platform 4.17 is 1.18.0.
The --keep N flag on tkn pipelinerun delete and tkn taskrun delete preserves the N most recently executed runs when bulk deleting.
The tkn CLI archive includes three executables: tkn, tkn-pac, and opc.
The tkn pipelinerun delete --all command does not delete pipeline run resources that are in a running state (since Pipelines 1.6).
The tkn task start command requires specifying a ServiceAccount via the -s flag.
TokenReview is a POST-only API that validates a bearer token and returns user identity information without creating persistent resources
TokenReview responses may be cached by the webhook token authenticator, which affects token revocation behavior.
TokenReview results may be cached by the webhook token authenticator in kube-apiserver
TokenReview has two endpoints in OpenShift: /apis/authentication.k8s.io/v1/tokenreviews (Kubernetes-native) and /apis/oauth.openshift.io/v1/tokenreviews (OpenShift OAuth)
A user's UID uniquely identifies them across time — if a user is deleted and recreated with the same name, the UID will differ
Topology Manager has four policies: none, best-effort, restricted, single-numa-node; and two scopes: container (default) and pod.
Topology Manager single-numa-node is the strictest policy — it rejects pods that cannot fit on a single NUMA node.
Pod topologySpreadConstraints are ANDed together — all constraints must be satisfied
In the Developer perspective Topology view, a yellow border around a resource name indicates resource limits or quota messages; a yellow dot appears when zoomed out
Tracking tags (--alias=true) only work within a single image stream; cross-image-stream aliases produce an error.
Red Hat build of Trustee is the attestation component that validates TEE integrity before releasing secrets or keys to confidential containers.
The Tuned custom resource uses API version tuned.openshift.io/v1
The Tuned CR is a namespaced resource, typically in the openshift-cluster-node-tuning-operator namespace
Setting machineConfigLabels on a Tuned recommend entry triggers automatic MachineConfig creation for host-level changes like kernel boot parameters
The Cluster Node Tuning Operator manages Tuned CRs and deploys containerized TuneD daemons on each node
Tuned match rules at the same level are combined with logical OR; nested match rules within a match entry use logical AND
Tuned match rule type defaults to node when omitted; valid values are node and pod
The Node Tuning Operator creates and manages Profile resources by watching Tuned CRs and translating them into per-node Profile objects consumed by the TuneD daemon.
In Tuned recommend rules, priority 0 is the highest priority
Profile (tuned.openshift.io/v1) is a namespaced resource representing the per-node realization of a TuneD profile, distinct from the Tuned CR which is the cluster-level definition.
The .spec.config.tunedConfig.reapply_sysctl field on a Profile resource controls whether the TuneD daemon reapplies sysctl settings.
In Tuned CRs, data and name are required in .spec.profile[]; priority and profile are required in .spec.recommend[]; label is required in match rules (value is optional)
Two Event API versions exist in OpenShift/Kubernetes: v1 (core) and events.k8s.io/v1.
Two-node clusters are a distinct topology from both SNO and standard HA (3+2) clusters.
Two-node clusters are not supported for GPU workloads — must be 1 node (SNO) or 3+ nodes.
Red Hat Universal Base Images (UBI) are freely redistributable without a Red Hat subscription; available in standard, init, and minimal variants.
The ClusterUserDefinedNetwork CR and UserDefinedNetwork CR cannot be modified after creation
OVN-Kubernetes uses 100.64.0.0/16 as default join subnet; UDN joinSubnets must not use this range; default UDN joinSubnets are 100.65.0.0/16 (IPv4) and fd99::/64 (IPv6)
UDN default MTU is 1400; minimum IPv4 MTU is 576; minimum IPv6 MTU is 1280
Pod DNS lookups resolve to the pod's IP on the cluster default network, not the UDN
UDNs must not be created in openshift-* namespaces
Kubelet health checks use the default network, not the primary UDN interface — a pod may appear healthy but have broken UDN connectivity
UDN Layer 2 subnets are optional; Layer 3 subnets are mandatory
UDN Layer 2 topology creates a distributed virtual switch (single broadcast domain, supports VM live migration); Layer 3 creates unique L2 segments per node with routing between them and requires cidr and hostSubnet parameters
The label k8s.ovn.org/primary-user-defined-network must be applied to a namespace before creating a primary UDN
UserDefinedNetwork is preferred over NetworkAttachmentDefinition for network segmentation for security reasons
User-Defined Networks (UDNs) are only supported with OVN-Kubernetes and do not work with other CNI plugins.
User-Defined Networks (UDNs) are a Technology Preview feature in OCP 4.17, not supported for production under SLAs
PVCs remain unbound indefinitely if no matching PV exists — they do not fail, they wait.
OpenShift automatically formats unformatted volumes based on fsType, erasing any existing data.
Automatic unidling (restoring replicas on incoming traffic) is only supported by the default HAProxy router.
OpenShift enforces security as a continuous chain from install-time locks (FIPS, CPU partitioning) through runtime TLS/IPsec enforcement to API-level immutability and webhook admission control — no single layer can be bypassed without affecting the others.
Setting unsupportedConfigOverrides on OpenShift operator resources blocks cluster upgrades and is not supported by Red Hat; it must be removed before upgrading.
API fields prefixed with unsupported<FieldName> have zero compatibility guarantees across or within releases.
The unsupportedConfigOverrides field on operator.openshift.io/v1 resources is not supported by Red Hat and blocks cluster upgrades — it must be removed before upgrading
Update channel promotion order is: candidate → fast → stable, with eus promoted simultaneously with stable. fast and stable have identical support levels; the only difference is the time delay.
Production OCP clusters must use stable-*, eus-*, or fast-* update channels; candidate-* is not for production
Cluster update prerequisites include: etcd backup, CSI snapshots for PVs, OLM Operators updated to compatible versions, MCPs unpaused, Upgradeable=False conditions resolved, MHCs paused, and unsupportedConfigOverrides removed
OpenShift updates support two complementary risk-mitigation strategies: canary rollout updates use custom MachineConfigPools with pause/unpause workflows to stage worker node updates, while Control Plane Only updates between even-numbered minor versions allow decoupling control plane and worker updates — both enabling phased rollouts but at different scopes.
When a ClusterOperator's Upgradeable condition is False, the CVO prevents minor version updates unless forced; patch/z-stream updates are not blocked.
The upgradeable-to annotation must be set on the CloudCredential resource via oc annotate cloudcredential cluster cloudcredential.openshift.io/upgradeable-to=<version> to unblock minor version updates for manually maintained credential clusters.
User-Provisioned Infrastructure (UPI) requires manual provisioning of load balancer, DNS, and storage; default storage classes are NOT defined.
Wrapper scripts in container entrypoints should use exec to replace the script process with the application so signals (e.g., SIGINT) are delivered correctly to PID 1
The useMoreSecureServiceCA field on KubeControllerManager is a one-way toggle — once set to true, it cannot be reverted to false
OpenShift Users are a separate user.openshift.io/v1 API resource, distinct from Kubernetes ServiceAccounts
User and Identity resources are created automatically when a user first authenticates via a configured identity provider; administrators do not need to pre-create them.
Monitoring for user-defined projects is not enabled by default; a cluster administrator must explicitly enable it after installation
The user.openshift.io/v1 API group contains User, Identity, Group, and UserIdentityMapping resources.
The groups array field on the User object is deprecated; the recommended approach is to create separate Group objects that reference users.
Identity objects link external authentication identities to internal User objects; one user can have multiple identities from different providers
User workload monitoring must be explicitly enabled; core platform monitoring is always on by default.
The UserIdentityMapping resource is the binding that connects an Identity object to a User object, resolving which user account a login corresponds to after authentication.
There is no LIST endpoint for UserIdentityMapping resources, unlike most other API resources.
Usernames in OpenShift must be unique and are derived from the identity provider; if a collision occurs, a numeric suffix may be appended.
Users can delete their own access tokens via the UserOAuthAccessToken API to revoke them.
UserOAuthAccessToken is a virtual (non-persisted) resource that mirrors OAuthAccessTokens scoped to the token's owner, allowing users to view/manage their own tokens.
v1alpha1 APIs default to Tier 4 (no compatibility guarantee), except for monitoring.coreos.com and operators.coreos.com where all versions including alpha are Tier 1.
ValidatingAdmissionPolicy uses CEL (Common Expression Language) for in-process validation without requiring an external webhook service.
ValidatingWebhookConfiguration can only accept or reject requests — it cannot modify objects
ValidatingWebhookConfiguration sideEffects accepts values None, NoneOnDryRun, Some, or Unknown; dry-run requests are auto-rejected if sideEffects is Some or Unknown
Chronyd must be stopped and disabled on vDU cluster nodes; PTP provides time synchronization instead.
crun is enabled as the OCI container runtime for vDU clusters.
Default OperatorHub sources must be disabled (disableAllDefaultSources: true) on vDU clusters.
For vDU clusters, BIOS C-States must be limited to C0/C1 only, with C1E disabled, Processor C6 disabled, and CPU Power Policy set to Performance.
Firmware for vDU SNO must be set to UEFI boot mode, and SR-IOV and VT-d must be enabled in firmware for bare-metal environments.
module_blacklist=irdma is a required kernel argument for vDU clusters.
Required Operators for vDU workloads on SNO: Node Tuning Operator, PTP Operator, SR-IOV Network Operator, OpenShift Logging Operator, and Local Storage Operator.
Minimum hardware for vDU SNO: 4-8 vCPU, 32GB RAM, 120GB storage.
The stalld service must be enabled in the Tuned CR for real-time vDU workloads.
The Tuned CR include line must reference the associated PerformanceProfile name using the pattern openshift-node-performance-${PerformanceProfile.metadata.name}.
The OpenShift web console must be disabled (managementState: Removed) on vDU clusters to reduce resource usage.
Vector has replaced Fluentd as the default log collector in OpenShift.
OpenShift enforces strict version coupling and update ordering: CNV minor version must match OCP minor version, OCP must update before CNV, HCP follows a three-step update sequence (management OCP → MCE → hosted cluster), and rollback is never supported — creating a unidirectional, order-dependent upgrade graph.
VM disk image provisioning in OpenShift Virtualization follows a defined pipeline: CDI requires scratch space equal to the destination volume during import, three cloning strategies (snapshot/csi-clone/host-assisted) offer different performance profiles, and boot source images are managed through a feature gate that controls automatic updates — creating a multi-strategy provisioning model.
VM live migration requires both RWX storage (RWO blocks migration) and a dedicated Multus network, making it a feature that demands specific infrastructure provisioning.
VM live migration depends on the full platform networking and storage stack: Multus CNI (from the multi-CNI architecture) provides the dedicated migration network, while RWX-capable storage classes must be provisioned — making live migration a feature that only works when both the CNI layer and storage layer are correctly configured.
VM live migration requires both infrastructure prerequisites (RWX storage + dedicated Multus network) and multi-node topology — SNO explicitly lacks live migration/HA, making virtualization feature availability topology-dependent.
VM live migration is the most infrastructure-demanding feature in OpenShift: it requires the complete CNI+storage stack (Multus for dedicated network, RWX storage) AND a multi-node topology, making it a capability that emerges only when both infrastructure depth and cluster breadth are sufficient.
OpenShift Virtualization's most demanding feature (live migration) validates the full governed infrastructure stack: it requires CNI networking (multi-CNI architecture), storage lifecycle (RWX PVCs from the storage model), topology validation, and singleton operator configuration (HyperConverged CR) — all managed through the operator-driven immutable platform model.
OpenShift Virtualization is the most demanding consumer of the governed platform model: live migration requires the full CNI+storage infrastructure stack operating under operator-driven governance (singleton CRs, immutable nodes), and both application images and VM disk images flow through governed supply chains — making virtualization a comprehensive validation that all platform layers are functioning correctly.
The --persist flag on virtctl addvolume permanently mounts the disk; it applies only to VMs, not VMIs.
virtctl guestfs deploys a libguestfs container for VM disk manipulation; virt-sysprep seals a VM disk image as a template.
virtctl is installed separately from the OpenShift CLI — downloaded from the web console or via RPM (kubevirt-virtctl package on RHEL 8).
OCP supports VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass API objects for point-in-time storage copies.
VolumeAttachment objects are non-namespaced (cluster-scoped) resources in the storage.k8s.io/v1 API group.
Only the external-attacher should set status.attached and attachmentMetadata on VolumeAttachment — not users or other controllers.
VolumeAttachment spec requires three sub-fields: attacher (CSI driver name), source (volume reference), and nodeName.
VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent are all GA at snapshot.storage.k8s.io/v1.
VolumeSnapshotContent is in the snapshot.storage.k8s.io/v1 API group.
VolumeSnapshotContent requires bidirectional binding: VolumeSnapshotContent references VolumeSnapshot via volumeSnapshotRef, and VolumeSnapshot references VolumeSnapshotContent via spec.volumeSnapshotContentName.
VolumeSnapshotContent is cluster-scoped (no namespace), while VolumeSnapshot is namespaced.
VolumeSnapshotContent has two deletion policies: Retain (keep physical snapshot) and Delete (remove both object and physical snapshot).
When restoring a volume from a snapshot, the volume size must not be smaller than restoreSize from the VolumeSnapshotContent status.
The VolumeSnapshotContent source field is immutable after creation; it uses either volumeHandle (dynamic) or snapshotHandle (pre-existing), which are mutually exclusive.
VerticalPodAutoscaler (VPA) adjusts resource requests and limits on pods rather than scaling replica count.
The CNI VRF plugin allows overlapping IP addresses with the OpenShift cluster's main network CIDR.
VRF (Virtual Routing and Forwarding) operates at OSI Layer 3 only and does not affect Layer 2 protocols such as LLDP.
VRF functions correctly only when the resource is of type netdevice
The CNI VRF plugin must be the second plugin in a chained CNI configuration, after the base network plugin (e.g., macvlan)
Applications in OpenShift pods must use SOBINDTODEVICE (requires CAPNET_RAW) to bind to VRF interfaces; ip vrf exec is not supported in pods
The VRF plugin table parameter is optional; the CNI plugin auto-assigns a free routing table ID if omitted
The default vSphere snapshot limit per block volume in ClusterCSIDriver is 3; increasing above 3 impacts performance.
vSphere failure domains require vCenter tag categories named exactly openshift-region and openshift-zone for region/zone mapping
The vsphereStorageDriver field set to CSIWithMigrationDriver is irreversible and is the current default; the field itself is deprecated
VMware vSphere is a supported installation platform for OpenShift Container Platform.
OpenShift supports both installer-provisioned infrastructure (IPI) and user-provisioned infrastructure (UPI) installation methods on vSphere.
vSphere 7.0 supports max 4 vGPU per VM; vSphere 8.0 supports max 8 vGPU per VM and adds heterogeneous profile support.
volumeBindingMode: WaitForFirstConsumer delays PV binding until a pod using the PVC is scheduled, enabling topology-aware provisioning.
Watch-specific API endpoints (e.g., /watch/...) are deprecated — the watch query parameter on list operations should be used instead.
Dedicated watch endpoints (e.g., /watch/apiservices) are deprecated in favor of using the watch query parameter on list operations.
Watch endpoints (/watch/...) are deprecated; the watch parameter on list operations should be used instead
Dedicated /watch/ API endpoints are deprecated across Kubernetes APIs; the watch query parameter on list operations should be used instead.
The dedicated /watch/ endpoints for User and Identity resources are deprecated; the correct approach is to use the watch query parameter on list operations.
AWS Wavelength Zones require three IAM permissions: ec2:ModifyAvailabilityZoneGroup, ec2:CreateCarrierGateway, and ec2:DeleteCarrierGateway.
AWS Wavelength Zones require a carrier gateway for connectivity between the Wavelength Zone and the carrier network; Local Zones do not.
The OpenShift web console supports both an Administrator perspective and a Developer perspective
Cluster admins' DevWorkspace CRs are always created in the openshift-terminal project and cannot choose another
The DevWorkspace Operator is automatically installed as a dependency of the Web Terminal Operator and should not be installed separately
Web terminal requires NetworkPolicy allowing ingress from both openshift-console and openshift-operators namespaces when restrictive network policies exist, or the terminal fails with "context deadline exceeded"
The Web Terminal Operator is installed in the openshift-operators namespace with All namespaces scope
The embedded web terminal in the console requires the Web Terminal Operator and is available from OCP 4.7+
The Web Terminal includes pre-installed CLI tools: oc, kubectl, odo, kn, tkn, helm, subctl
Uninstalling the Web Terminal Operator does NOT automatically remove CRDs or managed resources — manual cleanup of DevWorkspace CRDs and webhooks is required
Removing the devworkspace-webhook-server deployment without removing the associated mutating/validating webhooks causes oc exec commands to fail cluster-wide
Webhook admission in OpenShift follows a constrained enforcement model: all webhook communication requires TLS, timeouts are hard-capped at 13 seconds (non-configurable), webhooks are never invoked on their own kind (preventing infinite loops), and each webhook must declare four required fields — creating a bounded, self-protecting admission pipeline.
The spec.webhookTokenAuthenticator field on the Authentication resource can only be set when spec.type is None.
Communication between the webhook admission plugin and the webhook server must use TLS.
The two webhook configuration resource kinds are MutatingWebhookConfiguration and ValidatingWebhookConfiguration in API group admissionregistration.k8s.io/v1beta1.
The failurePolicy for admission webhooks defaults to Fail, meaning an unreachable webhook rejects the request
Webhook failurePolicy can be set to Fail (deny on error) or Ignore (accept on error); Ignore unconditionally accepts requests when the webhook is unavailable.
Webhook matchConditions use CEL expressions to filter requests, with a maximum of 64 conditions per webhook
Webhook matchPolicy defaults to Equivalent, converting requests across API group versions to match rules
The maximum webhook admission plugin timeout is 13 seconds and cannot be changed.
Mutating and Validating webhook configurations are never called on admission requests for their own kind to prevent unrecoverable cluster states
Webhook reinvocationPolicy: IfNeeded re-calls the webhook if other admission plugins mutate the object afterward, and requires the webhook logic to be idempotent
Each admission webhook entry requires four fields: name, clientConfig, sideEffects, and admissionReviewVersions
The port field in a webhook clientConfig.service reference defaults to 443
Admission webhook timeoutSeconds defaults to 10 and must be between 1–30 seconds
The spec.webhookTokenAuthenticators (plural) field on the Authentication resource is deprecated and setting it has no effect.
The url field in webhook clientConfig must use HTTPS; in-cluster webhooks should use the service field instead
Webhooks within each admission phase (mutating or validating) are called in parallel, not sequentially; all must approve or the request is denied.
Whereabouts IPAM provides cluster-wide IP address management with overlap detection, unlike host-local which is node-scoped only.
The Whereabouts CNI plugin provides cluster-wide IPAM for secondary/additional pod networks, typically used with Multus CNI, preventing IP conflicts across nodes
OverlappingRangeIPReservation (whereabouts.cni.cncf.io/v1alpha1) tracks IP reservations across overlapping IP ranges used by multiple NetworkAttachmentDefinitions, with a required podref field
OVN-Kubernetes with hybrid networking is required for Windows container support in OpenShift
Windows container support in OpenShift is managed by the Windows Machine Config Operator (WMCO)
Windows nodes diverge from the standard OpenShift node model: they use Windows container runtime instead of CRI-O and require OVN-Kubernetes hybrid networking, making them a specialized compute tier.
Windows nodes use the Windows container runtime rather than CRI-O
Windows nodes in OpenShift function as worker nodes only — control plane nodes must be Linux
Worker Ignition configs reference the bootstrap/control plane via https://api.<cluster>:22623/config/worker.
workerLatencyProfile has three values: Default, MediumUpdateAverageReaction, and LowUpdateSlowReaction, progressively tolerating higher network latency between workers and control plane
Pending CSRs must be approved for worker nodes to join the cluster, using oc get csr followed by oc adm certificate approve <csr_name>.
Workload Availability for Red Hat OpenShift is a separate product from OCP with its own version numbers (e.g., 26.1), providing remediation, fencing, and maintenance capabilities.
The three pillars of Workload Availability are remediation (automated recovery), fencing (isolating failed nodes), and maintenance (controlled node drain/downtime).
Workload partitioning is enabled by setting cpuPartitioningMode: AllNodes in the SiteConfig CR.
Workload partitioning can only be enabled at install time — it cannot be enabled or disabled post-installation. CPU assignments can be changed later via PerformanceProfile CR.
Pod placement in OpenShift must satisfy two independent constraint systems simultaneously: the scheduling system (node selectors, taints, affinity rules, topology manager NUMA policies) determines WHERE a pod runs, while the storage lifecycle (CSI provisioning, PVC binding phases, access mode requirements) determines WHETHER the pod's data dependencies can be met at that location.
Run-to-completion workloads use Job/CronJob; long-running use Deployment/DeploymentConfig; every-node use DaemonSet; identity requirements use StatefulSet; lifecycle management uses Operators with OLM.
xPaaS middleware images are suffixed with -openshift (e.g., registry.redhat.io/jboss-eap-6/eap64-openshift).
Z-stream releases never break API or AOE compatibility except for critical security issues.
OpenShift creates a cluster CA at installation time as the root of trust for service certificates.
OVN-Kubernetes supports transparent pod-to-pod IPsec encryption and north-south egress IPsec encryption.
Zero trust capabilities (IPsec, mTLS via mesh, NetworkPolicy) can be added without changing application code.
OpenShift service certificates have a 26-month TTL and are automatically rotated at 13 months.
OpenShift Service Mesh provides transparent mTLS, L4/L7 authorization, JWT request authentication, and SPIFFE attestation.
Cluster labels common: true, group-du-sno: "", and sites: "example-sno" control which PolicyGenerator policies bind to which clusters in the ZTP hierarchy.
ClusterGroupUpgrade CR is automatically created by TALM in the ztp-install namespace for any ManagedCluster without a ztp-done label, with a 240-minute (4-hour) timeout and pre-caching disabled.
During ZTP upgrade, the clusters app uses non-cascaded delete (preserves resources) while the policies app uses cascaded delete (removes old policies).
cpuPartitioningMode: AllNodes must be set at install time for workload partitioning — it cannot be changed post-install.
The crSuppression field in SiteConfig prevents generation of specific CRs (e.g., BareMetalHost) to trigger node deprovisioning; removing the suppression and pushing triggers reprovisioning.
The ztp-done label must be applied to all existing managed clusters before upgrading GitOps ZTP to prevent them from being affected; TALM-provisioned clusters get this label automatically.
The ztp-done label is applied to a managed cluster when all ZTP policies become Compliant, signaling ZTP completion.
Including MachineConfig CRs at install time via extra manifests is more efficient than applying them post-install.
The annotation bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true on a BareMetalHost ensures both the Agent CR and node are cleaned up on deletion.
Zero Touch Provisioning (ZTP) with GitOps is a common pattern for managing fleets of edge clusters at scale.
ZTP applies ztp-running label when post-install configuration starts, replaced by ztp-done when all policies are compliant; the ztp-done label prevents TALM from recreating ClusterGroupUpgrade.
ZTP plugin v4.11 or earlier sets PTP and SR-IOV daemon selectors to master only, which prevents daemons from running on workers and must be changed to worker for expanded clusters.
ZTP creates all policies with remediation action: inform by default — RHACM reports compliance but TALM enforces the changes, not RHACM directly.
GitOps Zero Touch Provisioning (ZTP) is OpenShift's designated approach for provisioning and managing far-edge sites at scale.
Registries in the mirror registries.conf must be scoped by repository, not by registry.
BMC credentials secret and pull secret must be in a namespace matching the cluster name from SiteConfig.
The -E flag with generator install generates only MachineConfig CRs from the SiteConfig.
The ztp-site-generate container has two generator modes: generator install (Day 0 installation CRs) and generator config (Day 2 configuration CRs).
SiteConfig extraManifests.filter.inclusionDefault has two values: include (default, apply all then selectively exclude) and exclude (apply none then selectively include).
extraManifests.searchPaths supersedes the deprecated extraManifestPath in SiteConfig (since OCP 4.14); when searchPaths is defined, the pipeline stops fetching manifests from the ztp-site-generate container.
After a ZTP upgrade, changed policies appear as Non-Compliant in inform mode and are not automatically pushed to managed clusters — they require ClusterGroupUpgrade CRs via TALM.
All CRs in the same ZTP policy must share the same ztp-deploy-wave annotation value; fewer policies means faster deployment.