diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000000000000000000000000000000000000..ba0fd1822157a7b6604d85946d37292d29769365 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +reasons.db +reasons.db-shm +reasons.db-wal diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000000000000000000000000000000000000..a5f5c390abb8fbb7cde8e4ab670e3d569b6191d6 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,41 @@ +# CLAUDE.md — OpenShift Expert + +Expert agent for explaining OpenShift Container Platform behavior, architecture, and operational patterns. Knowledge is stored in `reasons.db` — a justified belief network with retraction cascades, not a flat knowledge base. + +## Mission + +Help humans and LLM agents understand OpenShift platform architecture, operator lifecycle, networking, security, virtualization, and edge deployment patterns. Answers should be grounded in the belief network (`reasons.db`), not parametric knowledge. Use `reasons search`, `reasons explain`, and `reasons show` to find and cite beliefs before answering. + +## How to Answer Questions + +1. `reasons search "relevant terms"` to find beliefs +2. `reasons explain NODE` to trace justification chains +3. Synthesize an answer grounded in the beliefs found +4. Cite node IDs so the questioner can audit the chain + +## What This Expert Knows + +- Platform model: operator-driven immutable infrastructure, RHCOS, MCO +- Hosted Control Planes (HCP): multi-tenancy, topology variants +- Networking: OVN-Kubernetes, Multus, SR-IOV, IPsec, egress firewalls, network policies +- Virtualization: OpenShift Virtualization (CNV/OCP-Virt), live migration, VM management +- Operators & OLM: Operator Lifecycle Manager, OperatorHub, File-Based Catalogs +- Security: SCCs, RBAC, OAuth, webhook admission, network policies +- Builds & CI/CD: S2I, Shipwright, Jenkins, GitOps, image streams +- Edge: ZTP, TALM, Single Node OpenShift (SNO), vDU workloads +- Observability: monitoring, logging, Network Observability (NetObserv) +- Storage: CSI drivers, dynamic provisioning, OADP backup +- Installation: IPI/UPI, platform-specific (AWS, Nutanix, IBM Cloud, bare metal, Power) +- Node management: MachineConfig, autoscaling, health checks, tuned profiles + +## Skills Available + +```bash +reasons search QUERY # Find beliefs by keyword +reasons show NODE # Full details + dependents +reasons explain NODE # Trace justification chain +reasons list # All nodes with status +reasons list --premises # Foundation beliefs +reasons list --has-dependents # Load-bearing beliefs +reasons export-markdown -o beliefs.md # Export readable snapshot +``` diff --git a/README.md b/README.md new file mode 100644 index 0000000000000000000000000000000000000000..12e76d5a5eda24c8d21cd82bd7d782c076689f43 --- /dev/null +++ b/README.md @@ -0,0 +1,163 @@ +--- +schema_version: "1.0" +type: eem +project_name: openshift-expert +domain: + - openshift + - kubernetes + - container-platform + - cloud-infrastructure +license: mit +base_network: null +source_repos: [] +beliefs_total: 3820 +beliefs_in: 3820 +beliefs_out: 0 +premises: 3670 +derived: 150 +nogoods: 0 +generator: ftl-reasons/0.41.0 +--- + +# OpenShift Expert + +Expert knowledge base for **OpenShift Container Platform** architecture, operations, and deployment patterns. Contains 3,820 justified beliefs covering the operator-driven platform model, networking, virtualization, security, edge deployments, and 50+ subsystems. + +## What is this? + +This is an **External Epistemic Memory** (EEM) — a model-agnostic knowledge base that any LLM can use via the `reasons` CLI or tool calling. Unlike a LoRA or fine-tune, this knowledge is not baked into model weights. It is external, inspectable, correctable, and works with any model. + +## Stats + +| Metric | Value | +|--------|-------| +| Total beliefs | 3,820 | +| Status | 3,820 IN / 0 OUT | +| Premises (observations) | 3,670 | +| Derived (justified conclusions) | 150 | +| Nogoods (contradictions) | 0 | +| Retraction rate | 0% | +| Max derivation depth | 7 | + +## Top Topics + +| Topic | Beliefs | +|-------|---------| +| ocp | 560 | +| default | 312 | +| api | 224 | +| cluster | 192 | +| operator | 192 | +| openshift | 159 | +| namespace | 124 | +| node | 120 | +| hcp | 110 | +| config | 108 | +| network | 99 | +| image | 91 | +| virt | 91 | +| install | 85 | +| supported | 74 | +| policy | 72 | + +## Domain Coverage + +- **OCP Core Platform**: operator-driven immutable model, cluster versioning, install-time constraints, platform topology variants (511 beliefs) +- **Hosted Control Planes (HCP)**: multi-tenant control planes, NodePool management, hosted cluster lifecycle (107 beliefs) +- **CLI & API**: `oc` commands, API resources, resource management, debugging (63 beliefs) +- **OpenShift Virtualization (CNV)**: VM lifecycle, live migration, virtual networking, storage for VMs (82 beliefs) +- **Networking — OVN-Kubernetes**: default CNI, pod networking, service routing, hybrid overlay (27 beliefs) +- **Networking — Policy & Firewalls**: network policies, egress firewalls, admin network policies, user-defined networks (40 beliefs) +- **Networking — SR-IOV**: hardware-accelerated networking, VF management, node policies (28 beliefs) +- **Networking — Ingress & Routes**: HAProxy ingress controller, route configuration, TLS termination (34 beliefs) +- **Networking — IPsec & Encryption**: IPsec tunnel configuration, node-to-node encryption (12 beliefs) +- **Operators & OLM**: Operator Lifecycle Manager, OperatorHub, File-Based Catalogs, bundle management (87 beliefs) +- **Etcd**: cluster database, backup/restore, performance tuning, defragmentation (37 beliefs) +- **Security — SCCs & RBAC**: Security Context Constraints, role-based access control, project isolation (28 beliefs) +- **Security — OAuth & Authentication**: OAuth server, identity providers, token management (24 beliefs) +- **Security — Webhook Admission**: validating/mutating webhooks, enforcement model (16 beliefs) +- **Builds & Images**: S2I builds, Shipwright, image streams, image registry, samples operator (70 beliefs) +- **CI/CD & GitOps**: Jenkins pipelines, OpenShift GitOps (ArgoCD), deployment strategies (36 beliefs) +- **Edge — ZTP & SNO**: Zero Touch Provisioning, Single Node OpenShift, TALM upgrades, vDU workloads (53 beliefs) +- **Node Management**: MachineConfig Operator, machine sets, autoscaling, health checks, tuned profiles (57 beliefs) +- **Observability**: monitoring stack, logging, Network Observability (NetObserv), flow collection (54 beliefs) +- **Console**: web console, console plugins, developer/admin perspectives (43 beliefs) +- **Storage**: CSI drivers, dynamic provisioning, persistent volumes (10 beliefs) +- **Backup & DR**: OADP, etcd backup, cluster restore (13 beliefs) +- **Platform Variants**: Nutanix, IBM Cloud, IBM Power, bare metal, ROSA, OCI (101 beliefs) +- **RHCOS & Node OS**: Red Hat CoreOS, immutable OS, ignition, ostree updates (13 beliefs) +- **Additional topics**: NMState, MetalLB, templates, jobs, probes, ConfigMaps, HPA, PDB, scheduler, RHOSO, RHOAI (remaining beliefs) + +## How to Use + +### Import into a reasons database + +```bash +reasons init +reasons import-json network.json +``` + +### Query beliefs + +```bash +reasons search "operator lifecycle" +reasons explain operator-driven-immutable-platform-model +reasons show install-time-irreversible-constraints +``` + +### Use as an MCP tool or CLI + +Any LLM agent that can call `reasons search`, `reasons show`, and `reasons explain` can use this knowledge base. The agent does not need to be told it is an expert — the knowledge base speaks for itself. + +## Key Beliefs + +| Node | Summary | +|------|---------| +| `operator-driven-immutable-platform-model` | The entire OpenShift platform operates through an operator-driven model with immutable infrastructure | +| `install-time-irreversible-constraints` | Multiple cluster-defining decisions are permanently locked at install time and cannot be changed | +| `observability-follows-platform-enablement-pattern` | OpenShift observability is a specific instance of the platform-wide multi-component enablement pattern | +| `edge-fleet-management-pipeline` | Edge cluster lifecycle follows a managed pipeline: ZTP + GitOps provisions, TALM orchestrates upgrades | +| `multi-cni-network-architecture` | OpenShift uses a layered CNI architecture: OVN-Kubernetes primary, Multus for additional networks | +| `webhook-admission-enforcement-model` | Webhook admission follows a constrained enforcement model with TLS requirements | +| `node-config-immutable-delivery-pipeline` | Node configuration follows an immutable delivery pipeline via MachineConfig Operator | +| `complete-software-delivery-from-build-to-console` | OpenShift provides a unified software delivery model covering application and operator lifecycles | +| `platform-model-with-topology-variants` | Single operator-driven platform model recognizing two sanctioned topology variants | +| `consoleplugin-compat-level-1` | ConsolePlugin has Compatibility Level 1: stable for at least 12 months or 3 minor releases | + +## Sources + +Built from exploration of OpenShift Container Platform documentation, API references, and operational experience across networking, virtualization, security, edge, and platform management subsystems. + +## Files + +| File | Description | +|------|-------------| +| `network.json` | Full belief network (machine-readable, portable) | +| `reasons.db` | SQLite database (gitignored, regenerate with `reasons import-json network.json`) | +| `CLAUDE.md` | Agent instructions for using this knowledge base | +| `entries/` | 904 exploration entries — raw observations behind the premises | + +## Quality + +- All 3,820 beliefs are IN (none retracted) +- 3,670 premises grounded in direct observations of OpenShift behavior and documentation +- 150 derived beliefs justified from premises via SL justifications +- 0 nogoods — no contradictions detected +- Max derivation depth of 7, indicating multi-step reasoning chains +- Built and reviewed using ftl-reasons derive and review-beliefs pipeline + +## Limitations + +- Focused on OpenShift Container Platform as of mid-2026 +- OpenShift evolves across minor releases; some beliefs may become stale +- Heavier coverage of networking, virtualization, and operators than storage or serverless +- Platform variant coverage (Nutanix, IBM, bare metal) varies in depth +- No ATMS or assumption-based beliefs (single-context TMS only) + +## Authors + +- Ben Thomasson ([@benthomasson](https://github.com/benthomasson)) + +## License + +mit diff --git a/entries/2026/03/05/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md b/entries/2026/03/05/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md new file mode 100644 index 0000000000000000000000000000000000000000..c49649da4c76756dd33d5c0d6fc14f00bdd1e271 --- /dev/null +++ b/entries/2026/03/05/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md @@ -0,0 +1,35 @@ +--- +source_url: https://docs.redhat.com/documentation/red_hat_openshift_cluster_observability_operator/1-latest/html/about_red_hat_openshift_cluster_observability_operator/index +source: sources/documentation-red_hat_openshift_cluster_observability_operator-1-latest-html-abo.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:11 + + + +## Overview +The Red Hat OpenShift Cluster Observability Operator (COO) is an operator that provides observability features for OpenShift clusters. This page serves as the introductory landing page for the COO documentation (version 1-latest), covering its purpose and linking to release notes and support information. + +## Key Concepts +- **Cluster Observability Operator (COO)** is a dedicated operator for cluster-level observability in OpenShift +- It is a separate product/operator from the built-in monitoring stack (which uses the Cluster Monitoring Operator) +- Versioned as "1-latest," indicating it is an independently released component outside the core OpenShift release cycle +- Maintained by Red Hat as an officially supported operator + +## Commands and Syntax +No commands or configuration syntax are provided on this introductory page. + +## Relationships +- **Cluster Monitoring Operator (CMO)**: The built-in OpenShift monitoring stack; COO is a complementary/alternative observability solution +- **OperatorHub / OLM**: COO is installed via the Operator Lifecycle Manager as an optional operator +- **Observability stack components**: COO likely integrates with or manages Prometheus, Alertmanager, and other observability tooling +- **OpenShift platform**: Runs on top of OpenShift Container Platform and provides cluster-wide observability + +## Exam-Relevant Points +- The Cluster Observability Operator is a **separate operator** from the default Cluster Monitoring Operator +- COO is an **optional, installable operator** — not part of the default OpenShift installation +- Know the distinction between COO (newer, dedicated observability operator) and the built-in monitoring stack +- COO has its own independent versioning ("1-latest") separate from the OpenShift platform version + diff --git a/entries/2026/03/05/en-documentation-builds_for_red_hat_openshift-17.md b/entries/2026/03/05/en-documentation-builds_for_red_hat_openshift-17.md new file mode 100644 index 0000000000000000000000000000000000000000..930b4e6323947cb4e00cd4c59dd9053d5c01ab76 --- /dev/null +++ b/entries/2026/03/05/en-documentation-builds_for_red_hat_openshift-17.md @@ -0,0 +1,49 @@ +--- +source_url: https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift/1.7 +source: sources/en-documentation-builds_for_red_hat_openshift-17.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:11 + + + +## Overview + +Builds for Red Hat OpenShift is a standalone product (version 1.7) that provides build capabilities for OpenShift. This is the top-level documentation landing page, serving as a table of contents for the product's documentation set covering installation, configuration, usage, shared resources, authentication, observability, and lifecycle management. + +## Key Concepts + +- **Builds for Red Hat OpenShift** is a distinct product from OpenShift's built-in build system (BuildConfig/Build APIs) — it is separately installed, configured, and uninstalled via an operator. +- The product is versioned independently (1.0 through 1.7), indicating it follows its own release cadence apart from OpenShift platform versions. +- **Shared Resources CSI Driver** is a component that integrates with Builds, enabling shared resources to be mounted into build pods. +- The product has its own **authentication model** for runtime operations, separate from but building on OpenShift's auth. +- **Build controller observability** is a first-class concern with dedicated documentation, suggesting metrics/monitoring integration. + +## Commands and Syntax + +No specific commands on this landing page. The documentation sections map to operator lifecycle phases: + +1. **Install** — Deploy the Builds operator +2. **Configure** — Set up build environments and defaults +3. **Work with Builds** — Create and manage build workloads +4. **Work with Shared Resources** — Configure CSI-based shared resources +5. **Uninstall** — Remove the operator cleanly + +## Relationships + +- **Shipwright** — Builds for Red Hat OpenShift is the Red Hat productized version of the upstream Shipwright project. +- **Tekton/OpenShift Pipelines** — Builds for Red Hat OpenShift uses Tekton TaskRuns under the hood to execute builds. +- **OpenShift BuildConfig (legacy)** — This is the modern replacement/alternative to the built-in OpenShift build system (S2I, Docker, Custom strategies). +- **Shared Resources CSI Driver** — A separate but tightly coupled component for injecting shared secrets/ConfigMaps into builds. +- **OLM (Operator Lifecycle Manager)** — The product is installed and managed as an operator. + +## Exam-Relevant Points + +- Builds for Red Hat OpenShift is a **separately installable operator**, not part of the default OpenShift installation. +- It is distinct from the legacy OpenShift `Build`/`BuildConfig` API — know the difference. +- The documentation structure reveals the product's key components: the build controller, shared resources CSI driver, and authentication layer. +- Shared Resources CSI Driver is documented as its own section, indicating it may be tested as a separate concept. +- The product supports **observability** features for the build controller (likely Prometheus metrics). + diff --git a/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md b/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md new file mode 100644 index 0000000000000000000000000000000000000000..282d033ed48478de1e0534f92dec400c782f6767 --- /dev/null +++ b/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md @@ -0,0 +1,111 @@ +--- +source_url: https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.17/html/managing_alerts/managing-alerts-as-an-administrator +source: sources/en-documentation-monitoring_stack_for_red_hat_openshift-417-html-managing_alerts.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:12 + +## Overview +This page covers how OpenShift Container Platform administrators manage alerts, silences, and alerting rules through the web console's Alerting UI. It details navigating the Administrator perspective, creating and modifying alerting rules for both core platform and user-defined projects, and managing silences to suppress alert notifications. + +## Key Concepts +- **Alerting UI** has three main pages: **Alerts**, **Silences**, and **Alerting rules**, accessed via **Observe → Alerting** in the Administrator perspective +- **Silences** suppress alert notifications for a defined duration; they are replicated across Alertmanager pods but can be lost without persistent storage +- **Editing a silence** expires the existing one and creates a new one with updated configuration +- **Expired silences** cannot be deleted; they are garbage collected after **120 hours** +- Two resource types for platform alerting rules: + - **`AlertingRule`** (apiVersion: `monitoring.openshift.io/v1`) — for creating new platform alerting rules + - **`AlertRelabelConfig`** (apiVersion: `monitoring.openshift.io/v1`) — for modifying/relabeling existing platform alerts before Alertmanager routes them +- **`PrometheusRule`** (apiVersion: `monitoring.coreos.com/v1`) — for user-defined project alerting rules +- Both `AlertingRule` and `AlertRelabelConfig` **must** be created in the `openshift-monitoring` namespace +- `PrometheusRule` resources go in the user's project namespace +- A **project label is automatically enforced** on user-defined alerting rules, even if a rule with the same name exists in another project + +## Commands and Syntax + +**Create a platform alerting rule (`AlertingRule`):** +```yaml +apiVersion: monitoring.openshift.io/v1 +kind: AlertingRule +metadata: + name: example + namespace: openshift-monitoring # MUST be openshift-monitoring +spec: + groups: + - name: example-rules + rules: + - alert: ExampleAlert + for: 1m + expr: vector(1) + labels: + severity: warning + annotations: + message: This is an example alert. +``` +```bash +oc apply -f example-alerting-rule.yaml +``` + +**Modify platform alerts with `AlertRelabelConfig`:** +```yaml +apiVersion: monitoring.openshift.io/v1 +kind: AlertRelabelConfig +metadata: + name: watchdog + namespace: openshift-monitoring # MUST be openshift-monitoring +spec: + configs: + - sourceLabels: [alertname,severity] + regex: "Watchdog;none" + targetLabel: severity + replacement: critical + action: Replace +``` +Relabel actions: `Replace` (default), `Keep`, `Drop`, `HashMod`, `LabelMap`, `LabelDrop`, `LabelKeep` + +**Create a user-defined project alerting rule (`PrometheusRule`):** +```yaml +apiVersion: monitoring.coreos.com/v1 +kind: PrometheusRule +metadata: + name: example-alert + namespace: ns1 +spec: + groups: + - name: example + rules: + - alert: VersionAlert + for: 1m + expr: version{job="prometheus-example-app"} == 0 + labels: + severity: warning + annotations: + message: This is an example alert. +``` + +**Remove a user-defined alerting rule:** +```bash +oc -n delete prometheusrule +``` + +## Relationships +- **Alertmanager** receives and routes alerts; silences and `AlertRelabelConfig` modify what Alertmanager processes +- **Persistent storage for Alertmanager** is required to prevent silence loss across pod restarts +- **User-defined monitoring** must be enabled before creating `PrometheusRule` resources +- **RBAC roles**: `cluster-admin` for full access; `cluster-monitoring-view` + `monitoring-alertmanager-edit` for non-admin silence management; `monitoring-rules-edit` for managing user-defined alerting rules +- Platform alerting rules use the `monitoring.openshift.io/v1` API; user-defined rules use the `monitoring.coreos.com/v1` (Prometheus Operator) API + +## Exam-Relevant Points +- `AlertingRule` and `AlertRelabelConfig` resources **must** be in the `openshift-monitoring` namespace — they are silently rejected otherwise +- Platform alerting rules use `kind: AlertingRule`; user-defined project rules use `kind: PrometheusRule` — different API groups +- `AlertRelabelConfig` modifies alerts **before** Alertmanager routes them (not after) +- A silence **requires a comment** before it can be saved +- Expired silences are garbage collected after **120 hours** +- Silences are **replicated across Alertmanager pods** but require persistent storage to survive pod restarts +- Non-admin users need both `cluster-monitoring-view` and `monitoring-alertmanager-edit` roles to manage silences +- Non-admin users need the `monitoring-rules-edit` role to create alerting rules in their projects +- If you create a custom `AlertingRule` based on an existing platform rule, you should **silence the original** to avoid conflicting alerts +- Alerting rules require `alert`, `for`, `expr`, `labels.severity`, and `annotations.message` fields + diff --git a/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-421.md b/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-421.md new file mode 100644 index 0000000000000000000000000000000000000000..7bd2a6aa458875c7cceb6d7dfd3235e5413afe3b --- /dev/null +++ b/entries/2026/03/05/en-documentation-monitoring_stack_for_red_hat_openshift-421.md @@ -0,0 +1,44 @@ +--- +source_url: https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.21 +source: sources/en-documentation-monitoring_stack_for_red_hat_openshift-421.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:12 + +## Overview +The Monitoring stack for Red Hat OpenShift 4.21 is a dedicated documentation suite covering the built-in monitoring capabilities of OpenShift Container Platform. It spans core platform monitoring (cluster components) and user workload monitoring (application-level), built on Prometheus and Alertmanager, with guidance on configuration, metrics access, alerting, and troubleshooting. + +## Key Concepts +- **Monitoring stack** is a separate product documentation set ("Monitoring stack for Red Hat OpenShift"), distinct from the main OCP docs but tightly integrated. +- **Core platform monitoring** — monitors cluster infrastructure components; configured by cluster admins. +- **User workload monitoring** — optional feature enabling non-admin users to monitor their own projects/namespaces. +- **Cluster Monitoring Operator (CMO)** — the operator that manages the monitoring stack; has its own ConfigMap reference and alert reference. +- **Prometheus** and **Alertmanager** are the underlying components of the monitoring stack. +- **RHOSO integration** — special configuration exists for clusters running on Red Hat OpenStack Services on OpenShift (metric correlation). +- **Observability** is a broader umbrella (Red Hat OpenShift Observability) that includes monitoring plus additional tooling for application and infrastructure performance analysis. + +## Commands and Syntax +No specific CLI commands are provided on this landing page. The page serves as a table of contents pointing to sub-guides. Key configuration areas referenced: +- Core platform monitoring configuration (ConfigMap-based via CMO) +- User workload monitoring enablement and configuration +- Alert and silence management +- Metrics access configuration + +## Relationships +- **Cluster Monitoring Operator** → manages Prometheus, Alertmanager, and related components +- **User workload monitoring** → extends core platform monitoring to user namespaces; must be explicitly enabled +- **Red Hat OpenShift Observability** → superset that includes monitoring plus logging, tracing, and other observability tools +- **RHOSO** → specialized monitoring configuration for OpenStack-based OCP deployments +- **Monitoring APIs** → documented under the main OCP 4.21 API reference, not the monitoring stack docs + +## Exam-Relevant Points +- Monitoring is split into **core platform** (always on) and **user workload** (opt-in) — know the distinction. +- The **Cluster Monitoring Operator** is the central operator; configuration is done via **ConfigMaps**, not CRDs. +- User workload monitoring must be **explicitly enabled** for non-admin users to monitor their projects. +- Prometheus and Alertmanager are the key components managed by the stack. +- There is a **supported configuration** boundary — only documented configuration methods are supported (see "Support for monitoring"). +- Alerting rules are **built-in** and managed by the CMO; custom alerting rules can also be created. +- OpenShift Observability is broader than just monitoring — distinguishing monitoring from the full observability suite is important. + diff --git a/entries/2026/03/05/en-documentation-openshift_cluster_manager-1-latest.md b/entries/2026/03/05/en-documentation-openshift_cluster_manager-1-latest.md new file mode 100644 index 0000000000000000000000000000000000000000..6da092d9ee29e2c9f46cadcde13b456ccd8e6b21 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_cluster_manager-1-latest.md @@ -0,0 +1,34 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_cluster_manager/1-latest +source: sources/en-documentation-openshift_cluster_manager-1-latest.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:12 + +## Overview +This is the top-level landing page for **OpenShift Cluster Manager (OCM)** documentation (version 1-latest). It serves as a navigation hub pointing to the main guide for managing clusters, Red Hat Lightspeed integration, and reference material for subscriptions and pay-as-you-go billing. + +## Key Concepts +- **OpenShift Cluster Manager (OCM)** is a Red Hat-hosted service for working with OpenShift clusters — creating, managing, and monitoring them from a central interface. +- OCM is a **SaaS console** (accessible at console.redhat.com), distinct from the per-cluster OpenShift web console. +- The primary documentation area is **"Managing Clusters"** — covering day-to-day cluster operations through OCM. +- **Red Hat Lightspeed** is referenced as an integrated AI assistant capability within the Red Hat documentation ecosystem. +- Subscription and billing models include traditional **Subscription Management** (via Subscription Central) and **Pay-as-You-Go** (via Red Hat Marketplace). + +## Commands and Syntax +No commands or configuration syntax are present on this index page. Operational content lives under the linked "Managing Clusters" guide. + +## Relationships +- **OpenShift Cluster Manager → Managed OpenShift services**: OCM is the control plane for ROSA (AWS), ARO (Azure), and OSD (GCP/AWS) managed clusters, as well as self-managed OCP clusters registered with Red Hat. +- **Subscription Central**: Handles entitlements and subscription tracking for clusters managed through OCM. +- **Red Hat Marketplace / Pay-as-You-Go**: Alternative consumption-based billing model for OpenShift clusters. +- **Red Hat Lightspeed**: AI-powered documentation assistant integrated across Red Hat products. + +## Exam-Relevant Points +- Know that **OpenShift Cluster Manager** is the centralized SaaS interface at `console.redhat.com` used to manage the lifecycle of OpenShift clusters. +- Understand the distinction between OCM (fleet-level management) and the individual cluster's web console (cluster-level management). +- Be aware that OpenShift supports both **subscription-based** and **pay-as-you-go** billing models. +- OCM is relevant for both managed services (ROSA, ARO, OSD) and self-managed OCP clusters that are registered with Red Hat. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-410-html-single-storage-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-410-html-single-storage-index.md new file mode 100644 index 0000000000000000000000000000000000000000..67d34700347d3113f8643df86dc357eebec19d75 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-410-html-single-storage-index.md @@ -0,0 +1,89 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.10/html-single/storage/index +source: sources/en-documentation-openshift_container_platform-410-html-single-storage-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:13 + +## Overview +This page provides a comprehensive overview of storage in OpenShift Container Platform 4.10, covering ephemeral and persistent storage concepts, the PV/PVC lifecycle, access modes, reclaim policies, volume types, and the Container Storage Interface (CSI). It serves as the foundational reference for configuring and managing storage in an OCP cluster. + +## Key Concepts + +- **Two storage categories**: Ephemeral storage (transient, pod-scoped) and Persistent storage (survives pod lifecycle) +- **Persistent Volume (PV)**: Cluster-scoped resource representing a piece of storage, provisioned statically by an admin or dynamically via StorageClass +- **Persistent Volume Claim (PVC)**: Project-scoped request for storage by a developer; once bound to a PV, that PV is scoped to the binding project's namespace +- **PVs are not namespace-scoped** — they can be shared across the cluster, but once bound to a PVC they are effectively scoped to that PVC's namespace +- **Access Modes**: ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP) +- **Reclaim Policies**: `Retain` (manual cleanup), `Recycle` (deprecated in OCP 4), `Delete` (removes PV and external storage asset) +- **Dynamically provisioned volumes are always deleted** when released +- **Storage Object in Use Protection**: Prevents deletion of PVCs actively used by pods and PVs bound to PVCs (enabled by default) +- **Ephemeral storage** uses two partitions: **root** (`/var/lib/kubelet/`, `/var/log/`) and optional **runtime** (overlay filesystems, image layers) +- **Ephemeral storage provides no IOPS or throughput SLAs** +- **Container Storage Interface (CSI)**: Vendor-neutral API for managing container storage across orchestration systems +- **Dynamic Provisioning**: Creates storage volumes on-demand, eliminating need for admin pre-provisioning +- **OpenShift Data Foundation**: Provides agnostic persistent storage supporting file, block, and object storage + +## Commands and Syntax + +**Monitor ephemeral storage:** +```bash +df -h /var/lib +``` + +**PV definition example:** +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0001 +spec: + capacity: + storage: 5Gi + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Retain +``` + +**Delete a PV (manual reclaim):** +```bash +oc delete pv +``` + +**Change reclaim policy:** +```bash +oc patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' +``` + +**List persistent volumes:** +```bash +oc get pv +``` + +## Relationships + +- **StorageClass** → enables Dynamic Provisioning → creates PVs automatically when PVCs are submitted +- **PVC** → binds to → **PV** → backed by storage plugin (NFS, EBS, Cinder, vSphere, etc.) +- **CSI** is the modern interface replacing in-tree volume plugins and FlexVolume +- **OpenShift Data Foundation** provides the managed storage layer on top of these primitives +- **Ephemeral storage** relates to node resource management, pod eviction, and resource quotas +- **RBAC** controls who can provision and consume storage resources +- **StatefulSets** depend on persistent storage for stateful application deployments + +## Exam-Relevant Points + +- **Recycle reclaim policy is deprecated in OCP 4** — dynamic provisioning is the recommended replacement +- **Dynamically provisioned volumes always use the Delete reclaim policy** +- **PVs are cluster-scoped; PVCs are project/namespace-scoped** +- **A PV bound to a PVC cannot be bound to additional PVCs** — effectively one-to-one binding +- **Storage Object in Use Protection is enabled by default** — prevents data loss from premature deletion +- **Claims remain unbound indefinitely** if no matching PV exists (they do not fail — they wait) +- **OCP binds PVCs to the smallest PV that matches** all criteria to minimize waste +- **Four access modes**: RWO, ROX, RWX, RWOP — know which storage backends support which modes +- **Supported PV plugins**: AWS EBS, AWS EFS, Azure Disk, Azure File, Cinder, Fibre Channel, GCE PD, HostPath, iSCSI, Local volume, NFS, OpenStack Manila, ODF, VMware vSphere, AliCloud Disk, IBM VPC Block +- **Manual PV reclaim procedure**: delete PV → clean up data on storage asset → delete or reuse storage asset → create new PV +- **`oc patch pv`** is the command to change reclaim policy on an existing PV +- **Ephemeral storage** can cause pod eviction if local storage fills up; pods cannot request guaranteed local storage + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md new file mode 100644 index 0000000000000000000000000000000000000000..7d3083cc42aea4c00dfb9f50e1934f08b20c7ebf --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md @@ -0,0 +1,66 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/cli_tools/openshift-cli-oc +source: sources/en-documentation-openshift_container_platform-415-html-cli_tools-openshift-cli-o.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:13 + +## Overview +This page covers the OpenShift CLI (`oc`), the primary command-line tool for managing OpenShift Container Platform clusters. It details installation methods across platforms (Linux, Windows, macOS), authentication procedures, and basic usage commands for project and application management. + +## Key Concepts +- The `oc` CLI is the primary tool for managing OCP projects and applications from the terminal +- `oc` is ideal for: working with source code, scripting operations, and managing projects when the web console is unavailable +- The `oc` binary must match the cluster version — earlier versions cannot complete all commands for OCP 4.15 +- When `oc` runs inside a pod without a namespace specified, it defaults to the pod's namespace +- Authentication headers are only sent over HTTPS transport +- HTTP proxy access is supported via `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables +- The `--web` flag for `oc login` runs a localhost HTTP server (not HTTPS) — use with caution on multi-user workstations + +## Commands and Syntax + +**Installation:** +- Binary download: `tar xvf `, then move `oc` to a directory on `PATH` +- RPM (RHEL 8 only, not RHEL 9): `yum install openshift-clients` (requires subscription and enabling `rhocp-4.15-for-rhel-8-x86_64-rpms` repo) +- Homebrew (macOS): `brew install openshift-cli` +- Web console: **?** → **Command Line Tools** → download appropriate binary + +**Authentication:** +- `oc login -u user1` — interactive login with username/password +- `oc login --web` — browser-based login (opens browser automatically) +- `oc login --web --callback-port 8280` — specify callback port +- Copy login command from web console (top-right username dropdown → **Copy login command**) — includes token + +**Common operations:** +- `oc new-project my-project` — create a project +- `oc new-app https://github.com/sclorg/cakephp-ex` — create an app from source +- `oc get pods -o wide` — list pods with extended info +- `oc logs ` — view pod logs +- `oc project` — show current project +- `oc status` — show project status (services, deployments, build configs) +- `oc api-resources` — list supported API resources +- `oc help` — general help +- `oc --help` — help for a specific command +- `oc explain ` — describe fields of a resource + +## Relationships +- **Web Console**: Alternative interface; also provides CLI download links and "Copy login command" feature +- **Projects/Namespaces**: `oc` operates within the context of a project; `oc new-project` creates them +- **Source-to-Image (S2I)**: `oc new-app` with a Git URL triggers S2I builds +- **RBAC/Authentication**: `oc login` authenticates via identity providers configured on the cluster +- **Subscription Manager**: RPM installation requires an active OCP subscription via RHSM +- **kubectl**: `oc` extends `kubectl` with OpenShift-specific commands (projects, new-app, etc.) + +## Exam-Relevant Points +- **RPM install is NOT supported on RHEL 9** — must use binary download instead +- The `oc` version must match the cluster version (earlier versions are incompatible) +- `oc login --web` uses HTTP (not HTTPS) on localhost — security warning for shared workstations +- `oc status --suggest` provides additional recommendations beyond basic status +- Proxy environment variables (`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) are respected by `oc` +- `oc api-resources` shows short names (e.g., `cm` for ConfigMaps, `cs` for ComponentStatus) and whether resources are namespaced +- The web console login command (Copy login command) includes an authentication token — avoids interactive prompts +- macOS arm64 requires a specific binary variant (`OpenShift v4.15 macOS arm64 Client`) +- When running `oc` inside a pod, the pod's namespace is used by default if none is specified + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md new file mode 100644 index 0000000000000000000000000000000000000000..2ddfcb1efc44c9ac1a43686eadd61cc3cf4ab6a9 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md @@ -0,0 +1,141 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/operators/understanding-operators +source: sources/en-documentation-openshift_container_platform-415-html-operators-understanding-o.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:14 + +## Overview + +This page covers the foundational concepts of Operators in OpenShift Container Platform 4.15, including what Operators are, the Operator Framework ecosystem (SDK, OLM, Registry, OperatorHub), the Operator maturity model, packaging formats (bundle format and file-based catalogs), and the catalog system used by Operator Lifecycle Manager (OLM) to discover and install Operators. + +## Key Concepts + +- **Operators** encode human operational knowledge into software; they package, deploy, and manage Kubernetes applications using Kubernetes APIs and CRDs +- **Operator Framework** consists of four components: Operator SDK, OLM, Operator Registry, and OperatorHub +- **OLM** (Operator Lifecycle Manager) controls installation, upgrade, and RBAC of Operators; deployed by default in OCP 4.15 +- **Operator maturity model** defines five phases: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot +- **Bundle format**: a single Operator version packaged as a non-runnable container image containing Kubernetes manifests and metadata +- **Bundle requirements**: at least one channel, exactly one CSV per bundle, owned CRDs must be present +- **File-based catalogs (FBC)**: plain text (JSON/YAML) declarative format replacing deprecated SQLite format; default since OCP 4.11 +- **FBC properties**: editability, composability, extensibility +- **Three FBC schemas**: `olm.package` (one per package), `olm.channel` (at least one per package), `olm.bundle` (one or more per package) +- **olm.deprecations schema**: marks packages, channels, or bundles as deprecated +- **Dependency types**: `olm.package` (version-based), `olm.gvk` (group/version/kind), `olm.constraint` (generic) +- **Channel upgrade edges**: `replaces`, `skips`, `skipRange` control upgrade paths +- **CatalogSource** object references a catalog image; OLM polls it at regular intervals +- **`.indexignore`** files work like `.gitignore` to exclude non-catalog files +- **All `olm.*` schemas are reserved** for OLM-defined schemas; custom schemas need unique prefixes +- Service brokers vs Operators: brokers are not long-running, cannot handle Day 2 operations + +## Commands and Syntax + +```bash +# opm CLI - create and maintain Operator catalogs +opm validate # Validate a file-based catalog +opm init # Initialize FBC package +opm render # Render bundle into FBC format + +# Build bundle image +podman build -f bundle.Dockerfile -t /: +podman push /: +``` + +**Bundle directory structure:** +``` +etcd +├── manifests +│ ├── etcdcluster.crd.yaml +│ └── etcdoperator.clusterserviceversion.yaml +└── metadata + ├── annotations.yaml + └── dependencies.yaml +``` + +**File-based catalog structure:** +``` +catalog +├── packageA +│ └── index.yaml +├── packageB +│ ├── .indexignore +│ ├── index.yaml +│ └── objects/ +└── packageC + ├── index.json + └── deprecations.yaml +``` + +**annotations.yaml keys:** +```yaml +annotations: + operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" + operators.operatorframework.io.bundle.manifests.v1: "manifests/" + operators.operatorframework.io.bundle.metadata.v1: "metadata/" + operators.operatorframework.io.bundle.package.v1: "test-operator" + operators.operatorframework.io.bundle.channels.v1: "beta,stable" + operators.operatorframework.io.bundle.channel.default.v1: "stable" +``` + +**dependencies.yaml example:** +```yaml +dependencies: + - type: olm.package + value: + packageName: prometheus + version: ">0.27.0" + - type: olm.gvk + value: + group: etcd.database.coreos.com + kind: EtcdCluster + version: v1beta2 +``` + +**olm.deprecations example:** +```yaml +schema: olm.deprecations +package: my-operator +entries: + - reference: + schema: olm.package + message: "Package is end of life" + - reference: + schema: olm.channel + name: alpha + message: "Channel is deprecated" + - reference: + schema: olm.bundle + name: my-operator.v1.0.0 + message: "Bundle has a CVE" +``` + +## Relationships + +- **OLM** uses **CatalogSource** objects to reference catalog images and poll for updates +- **Operator SDK** supports building Operators with **Helm**, **Go**, and **Ansible** (mapped to maturity model capabilities) +- **Bundle images** are stored in **container registries** (e.g., Quay) and referenced by catalogs +- **CRDs** define the custom resources that Operators manage; CSV declares which CRDs an Operator owns/requires +- **Channels** provide upgrade paths; **Subscriptions** connect users to channels +- **File-based catalogs** replaced **SQLite database format** (deprecated since OCP 4.11) +- **`opm` CLI** bridges bundle format and catalog management +- Connects to: CatalogSource configuration, Subscription objects, OperatorHub UI, disconnected installation mirroring + +## Exam-Relevant Points + +- OLM is deployed **by default** in OpenShift Container Platform 4.15 +- OperatorHub is deployed **by default** in OpenShift Container Platform +- The five Operator maturity levels: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot +- A bundle must have **exactly one CSV** and **at least one channel** +- File-based catalogs became the **default format since OCP 4.11**; SQLite format is **deprecated** +- Three required FBC schemas per package: `olm.package` (exactly one), `olm.channel` (at least one), `olm.bundle` (one or more) +- **`annotations.yaml` is authoritative** over other sources in case of mismatch +- Three dependency types: `olm.package`, `olm.gvk`, `olm.constraint` +- **`skipRange`** prunes skipped versions from the update graph — they become uninstallable +- Use both `skipRange` and `replaces` together to skip versions while keeping them installable +- Duplicate packages/bundles within a package are **not permitted** in file-based catalogs +- `opm validate` is the command to validate catalogs +- Optional bundle objects (ConfigMap, Secret, Service, ServiceMonitor, etc.) have their lifecycle managed by OLM alongside the CSV +- The `olm.deprecations` schema requires a `package` value matching an existing `olm.package`, and each entry's `message` is required + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md new file mode 100644 index 0000000000000000000000000000000000000000..f3d1427af7ad581b528acfc57521c5d8712efeec --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md @@ -0,0 +1,148 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/operators/user-tasks +source: sources/en-documentation-openshift_container_platform-415-html-operators-user-tasks.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:14 + +## Overview +This page covers user-facing tasks for working with Operators in OpenShift Container Platform 4.15, including creating applications from installed Operators, installing Operators from OperatorHub (via web console and CLI), and managing Operator updates (approval, upgrading, and deletion). It focuses on the self-service capabilities available to developers and non-admin users through Operator Lifecycle Manager (OLM). + +## Key Concepts + +- **Cluster Service Version (CSV)**: The resource that represents a particular version of an installed Operator; used to launch and manage the Operator's software. Check with `oc get csv`. +- **PackageManifest**: Represents an Operator available in a catalog; describes install modes, channels, and versions. Lives in `openshift-marketplace`. +- **OperatorGroup**: Defines target namespaces for RBAC generation; only **one OperatorGroup per namespace** is allowed. Required for `SingleNamespace` install mode; `openshift-operators` already has `global-operators` for `AllNamespaces` mode. +- **Subscription**: The object that subscribes a namespace to an Operator from a catalog source, specifying channel, source, and approval strategy. +- **Install Modes**: `OwnNamespace`, `SingleNamespace`, `MultiNamespace`, `AllNamespaces` — each Operator declares which modes it supports. +- **Approval Strategy**: **Automatic** (OLM upgrades automatically) vs **Manual** (admin must approve each update via InstallPlan). Manual is recommended for cloud token auth clusters (AWS STS, Entra Workload ID). +- **Catalog Sources**: Default catalogs — Red Hat Operators, Certified Operators, Community Operators — served from `openshift-marketplace`. +- Users with the `edit` role can create/manage/delete application instances from installed Operators in a self-service manner. +- Community Operators are **not certified by Red Hat**; a warning must be acknowledged. +- Installing an Operator with Manual approval in a namespace causes **all Operators in that namespace** to use Manual approval and update together. Install into separate namespaces for independent updates. + +## Commands and Syntax + +**List installed Operators:** +```bash +oc get csv +``` + +**List available Operators from OperatorHub:** +```bash +oc get packagemanifests -n openshift-marketplace +``` + +**Inspect an Operator's install modes, channels, versions:** +```bash +oc describe packagemanifests -n openshift-marketplace +``` + +**Filter by specific catalog:** +```bash +oc get packagemanifest \ + --selector=catalog= \ + --field-selector metadata.name= \ + -n -o yaml +``` + +**Grant edit role for self-service Operator usage:** +```bash +oc policy add-role-to-user edit -n +``` + +**OperatorGroup for SingleNamespace mode:** +```yaml +apiVersion: operators.coreos.com/v1 +kind: OperatorGroup +metadata: + name: + namespace: +spec: + targetNamespaces: + - +``` + +**Subscription object:** +```yaml +apiVersion: operators.coreos.com/v1alpha1 +kind: Subscription +metadata: + name: + namespace: # openshift-operators for AllNamespaces +spec: + channel: + name: + source: + sourceNamespace: openshift-marketplace + config: + env: [...] + envFrom: [...] + volumes: [...] + volumeMounts: [...] + tolerations: [...] + resources: {requests: {...}, limits: {...}} + nodeSelector: {key: value} +``` + +**Pin to a specific version (requires Manual approval):** +```yaml +spec: + channel: stable-3.7 + installPlanApproval: Manual + startingCSV: example-operator.v3.7.10 +``` + +**AWS STS config in Subscription:** +```yaml +spec: + config: + env: + - name: ROLEARN + value: "" +``` + +**Entra Workload ID config in Subscription:** +```yaml +spec: + config: + env: + - name: CLIENTID + value: "" + - name: TENANTID + value: "" + - name: SUBSCRIPTIONID + value: "" +``` + +**Verify installation:** +```bash +oc describe subscription -n +oc describe operatorgroup -n +``` + +## Relationships + +- **OLM (Operator Lifecycle Manager)**: The backend that manages Operator installation, upgrades, and lifecycle — Subscriptions, CSVs, and InstallPlans are all OLM resources. +- **OperatorHub**: The discovery UI frontend that works with OLM; sources from CatalogSources. +- **RBAC / Permissions**: Cluster admins must delegate Operator installation permissions; the `edit` role grants self-service instance management. +- **Cloud Provider Auth**: AWS STS and Microsoft Entra Workload ID clusters require special Subscription config and Manual approval strategy. +- **CatalogSource / openshift-marketplace**: The namespace housing default catalog sources that PackageManifests are read from. +- **InstallPlan**: Created by OLM when Manual approval is set; must be approved to complete installation or upgrade. + +## Exam-Relevant Points + +- `oc get packagemanifests -n openshift-marketplace` lists all available Operators — know this command. +- **Only one OperatorGroup per namespace** — this is a hard constraint. +- For `SingleNamespace` mode, you must create an OperatorGroup manually (CLI); the web console handles this automatically. +- For `AllNamespaces` mode, `openshift-operators` namespace already has `global-operators` group — skip OperatorGroup creation. +- The `Subscription` object requires: `channel`, `name`, `source`, `sourceNamespace`. +- To install a **specific version**: set `startingCSV` and `installPlanApproval: Manual`. +- **Manual approval in a namespace affects all Operators in that namespace** — they all update together. Use separate namespaces for independent updates. +- AWS STS / Entra Workload ID clusters **must use Manual approval** for Operator subscriptions. +- The `config` section of a Subscription can set `env`, `envFrom`, `volumes`, `volumeMounts`, `tolerations`, `resources`, and `nodeSelector` on the Operator pod. +- After installation, CSV status should show **Succeeded** in the target namespace (or **Copied** in other namespaces for AllNamespaces mode). +- The `edit` role is what grants users self-service ability to create Operator-managed application instances. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-index.md new file mode 100644 index 0000000000000000000000000000000000000000..882741cf20718aaf8d29561259400dd735a30b73 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-index.md @@ -0,0 +1,31 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/index +source: sources/en-documentation-openshift_container_platform-417-html-about-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:14 + +## Overview +This is the landing page for the "About" section of OpenShift Container Platform 4.17 documentation. It introduces OCP as a platform and serves as the entry point to the product's feature overview. The page itself contains minimal content — it primarily links to the full introduction document. + +## Key Concepts +- **OpenShift Container Platform (OCP)** is a Red Hat product built on Kubernetes for deploying and managing containerized applications at scale. +- **Version 4.17** is the documented release; OCP has a long version history spanning 3.x through 4.x lines. +- Documentation is maintained by the **Red Hat OpenShift Documentation Team**. +- The "About" section provides a **feature overview** of the platform — it is the conceptual starting point before operational docs. + +## Commands and Syntax +No commands or configuration syntax are present on this page. + +## Relationships +- This is the **root "About" page** — it connects to deeper introductory topics covering OCP architecture, features, and platform concepts. +- It sits above operational documentation sections (installation, networking, storage, security, etc.). +- The version selector shows OCP spans **3.x (legacy)** through **4.x (current)** — the 3.x to 4.x transition was a major architectural shift (from standalone orchestration to Kubernetes-native). + +## Exam-Relevant Points +- OCP 4.x is the current platform generation; know that it is **Kubernetes-based**. +- The version numbering convention: **4.17** is a specific minor release of OCP 4. +- Red Hat maintains formal documentation per version — version-specific behavior differences can appear on exams. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md new file mode 100644 index 0000000000000000000000000000000000000000..0ba0d4e092eb2757dcbc4ba12ffa5eb9335dd6bc --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md @@ -0,0 +1,52 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/learn_more_about_openshift +source: sources/en-documentation-openshift_container_platform-417-html-about-learn_more_about_op.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:15 + +## Overview +This page serves as a learning roadmap for OpenShift Container Platform 4.17, organizing documentation resources by persona and task area. It maps out what cluster administrators, developers, SREs, and other roles need to learn, covering architecture, installation, cluster management, observability, storage, application development, and hosted control planes. + +## Key Concepts +- **Persona-based organization**: Documentation is structured around roles — Cluster Administrator, Developer, App SRE — each with distinct learning paths +- **Architecture foundations**: Enterprise Kubernetes, OVN-Kubernetes networking, security/compliance, and backup/restore form the architectural base +- **Installation modes**: Standard installation, restricted/disconnected network installation, and installation into existing networks (existing VPC/VNet) are distinct paths +- **Cluster capabilities**: OpenShift 4.17 supports optional cluster capabilities that can be selectively enabled +- **Machine management**: Compute and control plane machines are managed via machine sets, with support for machine health checks and autoscaling +- **Hosted control planes (HCP)**: A deployment model where control planes run as hosted workloads, deployable on OpenShift Virtualization, AWS, bare metal, IBM Z, and IBM Power +- **Observability stack**: Includes distributed tracing (Red Hat build of OpenTelemetry), Network Observability, monitoring, and power monitoring (Tech Preview) +- **Developer tooling**: Includes odo (developer CLI), OpenShift Pipelines (CI/CD), Dev Spaces, Topology view, and application export capabilities + +## Commands and Syntax +No specific commands on this page — it is a navigation/index page. Key referenced tools and interfaces: +- **odo** — developer-focused CLI for application development +- **OpenShift Pipelines** — CI/CD pipeline creation +- **OpenShift Update Service** — cluster updates in disconnected environments +- **Machine API** — programmatic machine management +- **CRDs** — extending cluster with custom resource definitions + +## Relationships +- **Installation → Restricted Networks**: Disconnected installs require image mirroring; supported on AWS, GCP, vSphere, IBM Cloud, IBM Z/LinuxONE, IBM Power, bare metal +- **Cluster Admin → Operators**: Operators are central to managing cluster components and extending functionality +- **Networking → CNO**: Cluster Network Operator manages networking; supports multiple network interfaces and network policy +- **Observability → Monitoring**: Remote health monitoring, distributed tracing, and network observability are complementary monitoring capabilities +- **Hosted Control Planes → Virtualization/Cloud**: HCP can run on OpenShift Virtualization, AWS, bare metal, IBM Z, IBM Power — and in disconnected environments +- **Developer → Builds/Images**: Application development ties into build strategies, image management, and deployment mechanisms +- **Storage → CSI/ODF**: Storage management connects to Red Hat OpenShift Data Foundation + +## Exam-Relevant Points +- OpenShift 4.17 has **optional cluster capabilities** that can be selectively enabled/disabled +- **Disconnected/restricted network** installations require mirroring installation images +- Installation into **existing VPC** (AWS, GCP) or **existing VNet** (Azure) is a supported pattern +- Machine management uses **machine sets** for both compute and control plane nodes +- **Machine health checks** and **cluster autoscaling** are distinct but related features +- Cluster updates can be performed via **web console**, **CLI**, or **OpenShift Update Service** (disconnected) +- **Hosted control planes** are a distinct deployment model with specific platform support and sizing requirements +- **RHCOS image layering** is available as an advanced installation capability +- **FIPS mode** is an installation-time option +- **Resource quotas** and **pruning** are key cluster management tasks +- **Network Observability** and **Power Monitoring** (Tech Preview) are part of the observability stack + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-oke-about.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-oke-about.md new file mode 100644 index 0000000000000000000000000000000000000000..1ecd50604db8a084c22e931535b757da5a47b285 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-oke-about.md @@ -0,0 +1,43 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/oke-about +source: sources/en-documentation-openshift_container_platform-417-html-about-oke-about.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:15 + +## Overview +OpenShift Kubernetes Engine (OKE), formerly Red Hat OpenShift Container Engine, is a lower-cost subset of OpenShift Container Platform (OCP). It uses the same binary distribution and installation process as OCP but offers a reduced feature set focused on core Kubernetes orchestration, enterprise security, and infrastructure services — excluding developer-oriented tools, service mesh, serverless, pipelines, and logging. + +## Key Concepts +- **Same binary, different entitlement**: OKE and OCP are the same download/product; OKE is a subscription that limits which features are supported, not a separate binary. +- **Renamed in April 2020**: "OpenShift Container Engine" → "OpenShift Kubernetes Engine" +- **Includes**: Automated installers (IPI/UPI), OTA upgrades, enterprise Kubernetes, `oc`/`kubectl`, OLM, admin console, cluster monitoring (Prometheus), OpenShift Virtualization, RHEL/RHCOS entitlements, all storage/network plugins, Helm, OVN/OVS SDN, MetalLB, Multus, Route API, HAProxy ingress, Compliance Operator, Local Storage Operator, SR-IOV, VPA, OADP, embedded registry, OperatorHub +- **Excludes (requires OCP)**: Developer console, developer catalog, S2I/builder automation, OpenShift Pipelines (Jenkins/Tekton), Service Mesh (Istio/Kiali), Distributed Tracing, Serverless (Knative/Kourier), Platform Logging, User Workload Monitoring, OpenShift GitOps, Dev Spaces, `odo` CLI, sandboxed containers, Web Terminal, Migration Toolkit for Containers +- **Separate subscription required (for both OKE and OCP)**: RHACM, ACS, ODF, Red Hat Quay, Gatekeeper, Ansible Automation Platform, various middleware/integration products +- **Windows Containers**: OKE includes the Community Windows Machine Config Operator; OCP includes the Red Hat-supported version (separate subscription) + +## Commands and Syntax +No unique commands — OKE uses the same `oc`, `kubectl`, and installer tooling as OCP. The difference is purely a subscription/support entitlement. + +## Relationships +- **OCP superset**: OKE is a strict subset of OCP; understanding OKE means knowing what OCP features are excluded +- **OpenShift Virtualization**: Included in OKE (kubevirt-based) +- **ODF**: Compatible with OKE but requires separate purchase +- **RHACM**: Compatible with OKE but requires separate purchase +- **Red Hat Quay**: Compatible with OKE but requires separate purchase +- **Networking**: Full CNI, OVN-Kubernetes, Multus, Network Policy support — but no Service Mesh or Kourier +- **Monitoring**: Cluster monitoring included; User Workload Monitoring excluded +- **Logging**: Log forwarding included; Platform Logging (Elasticsearch/Fluentd/Kibana stack) excluded + +## Exam-Relevant Points +- OKE and OCP are the **same binary download** — the difference is subscription entitlement only +- OKE **includes** OpenShift Virtualization, cluster monitoring, OLM, admin console, all storage plugins, full networking (OVN, Multus, Network Policy, egress controls) +- OKE **excludes** the developer experience: no developer console, no S2I, no Pipelines, no `odo`, no Dev Spaces +- OKE **excludes** Service Mesh, Serverless, Distributed Tracing, Platform Logging, and sandboxed containers +- **User Workload Monitoring** is NOT included in OKE (cluster monitoring IS included) +- **Log forwarding** is included in OKE; **Platform Logging** is not +- OKE receives the **same SLAs, bug fixes, and CVE protection** as OCP +- Products requiring **separate subscriptions regardless of OKE or OCP**: RHACM, ACS, ODF, Quay, Gatekeeper + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md new file mode 100644 index 0000000000000000000000000000000000000000..02a0279d54b6a27c5dc38c9fc71c1090ec2fdb44 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md @@ -0,0 +1,13 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/providing-feedback-on-red-hat-documentation +source: sources/en-documentation-openshift_container_platform-417-html-about-providing-feedback-.md +--- +# En Documentation Openshift_Container_Platform 417 Html About Providing Feedback + +**Date:** 2026-03-05 +**Time:** 13:15 + + + +This page is just about how to submit documentation feedback via Jira — it has no technical content relevant to OpenShift expertise or certification. There's nothing worth summarizing into study notes from this page. Let me skip it. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-welcome-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-welcome-index.md new file mode 100644 index 0000000000000000000000000000000000000000..37451727589d8a035779d5dfe98771802a6280e3 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about-welcome-index.md @@ -0,0 +1,29 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about/welcome-index +source: sources/en-documentation-openshift_container_platform-417-html-about-welcome-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:15 + +## Overview +This is the top-level landing page for OpenShift Container Platform 4.17 documentation. It serves as an entry point and navigation hub, directing users to explore OCP features via the navigation bar or curated task-based links. + +## Key Concepts +- OpenShift Container Platform (OCP) is a Red Hat product with documentation spanning versions 3.0 through 4.21. +- Version 4.17 is one of many supported releases, each with its own documentation set. +- Documentation is available in multi-page, single-page, and PDF formats. + +## Commands and Syntax +No commands or configuration syntax on this page. + +## Relationships +- This is the root of the OCP 4.17 doc tree; all other 4.17 topics branch from here. +- Links to the "Learn more about OpenShift Container Platform" task-oriented guide for onboarding. +- Part of the broader Red Hat product documentation ecosystem. + +## Exam-Relevant Points +- OCP versioning follows a `major.minor` scheme (e.g., 4.17); knowing which version you're working with matters for exam scenarios. +- Documentation availability varies by version — not all docs exist for all versions. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about.md new file mode 100644 index 0000000000000000000000000000000000000000..27ea7f9345c1ae7dcafc51a6618a03a95e528a47 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-about.md @@ -0,0 +1,31 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/about +source: sources/en-documentation-openshift_container_platform-417-html-about.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:16 + +## Overview +This is the landing page for the "About" section of OpenShift Container Platform 4.17 documentation. It serves as an introduction to OpenShift Container Platform and provides an overview of its features. The page itself contains minimal content — it is primarily a navigation entry point. + +## Key Concepts +- **OpenShift Container Platform (OCP)** is a Red Hat product built on Kubernetes for enterprise container orchestration. +- Version **4.17** is the documented release on this page. +- OCP has a long version history spanning from **3.0** through **4.21**, indicating a mature, actively developed platform. +- The version jump from **3.x to 4.x** reflects the major architectural shift from standalone Docker/Kubernetes to an operator-driven, immutable infrastructure model (RHEL CoreOS, Cluster Version Operator). + +## Commands and Syntax +None — this is an introductory/overview page with no commands or configuration syntax. + +## Relationships +- This page is the entry point to the broader OCP documentation set, which covers installation, networking, storage, security, operators, CI/CD, and cluster management. +- It connects to the **Legal Notice** for Red Hat documentation licensing. +- The "About" section typically leads into topics like OCP architecture, platform lifecycle, and feature highlights. + +## Exam-Relevant Points +- OCP 4.x is the current major version family; know that 4.17 exists as a supported release. +- Red Hat maintains documentation across many versions simultaneously (3.x and 4.x lines), which reflects the product's enterprise support lifecycle (EUS, standard, and extended support). +- Understanding the version you are working with is critical — exam questions often reference specific version capabilities. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md new file mode 100644 index 0000000000000000000000000000000000000000..ff195d9fc43e57d7adad911602b5a0b9987b2c25 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md @@ -0,0 +1,52 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/associating-secondary-interfaces-metrics-to-network-attachments +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-assoc.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:16 + +## Overview + +This page describes how OpenShift administrators can associate secondary network interface metrics with their corresponding `NetworkAttachmentDefinition` resources using the `pod_network_name_info` metric. This solves the problem of identifying which secondary interface (added via Multus CNI) belongs to which network when monitoring container network metrics. + +## Key Concepts + +- **Secondary interfaces** are additional network interfaces added to pods (e.g., via Multus CNI); their names depend on the order they are added, making identification difficult from metrics alone. +- **Network Metrics Daemon** is a daemonset that collects and publishes network-related metrics, supplementing kubelet's built-in `container_network_*` metrics. +- **`pod_network_name_info`** is a gauge metric with a fixed value of `0`, published by the Network Metrics Daemon. Its purpose is to carry labels that map interface names to network attachment definitions. +- The `network_name` label is derived from the `k8s.v1.cni.cncf.io/network-status` annotation added by Multus — formatted as `/`. +- Standard kubelet metrics (e.g., `container_network_receive_bytes_total`) include pod name, namespace, and interface name, but do **not** identify the network purpose of the interface. + +## Commands and Syntax + +**PromQL join pattern** — enrich any `container_network_*` metric with the network name: + +```promql +(container_network_receive_bytes_total) + on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info ) +``` + +This pattern uses `group_left(network_name)` to pull the `network_name` label from `pod_network_name_info` onto the existing container network metric, joining on `namespace`, `pod`, and `interface`. + +**Example metric output:** + +``` +pod_network_name_info{interface="net0",namespace="namespacename",network_name="nadnamespace/firstNAD",pod="podname"} 0 +``` + +## Relationships + +- **Multus CNI**: Adds secondary interfaces and the `k8s.v1.cni.cncf.io/network-status` annotation that this metric relies on. +- **NetworkAttachmentDefinition (NAD)**: The network name label is derived from the NAD resource name and namespace; different NADs distinguish different network classes/CNIs. +- **Prometheus / Monitoring stack**: The PromQL queries assume the OpenShift monitoring stack (Prometheus) is scraping these metrics. +- **Kubelet metrics**: `pod_network_name_info` is designed to be joined with existing kubelet `container_network_*` metrics — it has no value on its own. + +## Exam-Relevant Points + +- The `pod_network_name_info` metric always has a fixed value of **0** — it exists solely as a label carrier for PromQL joins. +- The `network_name` label format is `/`. +- The PromQL join technique uses `+ on(namespace,pod,interface) group_left(network_name)` to enrich existing container network metrics. +- There are **8** standard kubelet `container_network_*` metrics (4 receive, 4 transmit: bytes, errors, packets, packets_dropped). +- Without `pod_network_name_info`, secondary interface metrics are ambiguous because interface names (e.g., `net0`) don't indicate which network they belong to. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md new file mode 100644 index 0000000000000000000000000000000000000000..a80791512073ce4292b7e737910af8cdb413011b --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md @@ -0,0 +1,99 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/changing-cluster-network-mtu +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-chang.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:17 + +## Overview +This page describes how to change the maximum transmission unit (MTU) for an OpenShift Container Platform cluster network after installation. The process is disruptive, requiring multiple rolling reboots of all cluster nodes, and is only supported with the OVN-Kubernetes network plugin. The migration involves a multi-step process: initiating the migration via CNO configuration, updating hardware MTU on nodes, and finalizing the migration. + +## Key Concepts +- **Hardware MTU** vs **Cluster Network MTU**: The cluster network MTU is always less than the hardware MTU to account for overlay overhead. For OVN-Kubernetes, the overhead is **100 bytes**. +- MTU is auto-detected during installation from the primary network interface; post-install changes follow a migration workflow. +- **Only OVN-Kubernetes** supports changing the MTU value post-installation. +- If nodes have different MTU values, the cluster network MTU must be set to the **lowest node MTU minus the overlay overhead** (e.g., nodes with 9001 and 1500 → cluster MTU = 1400). +- The migration requires **at least two rolling reboots** of all nodes (one to prepare, one to finalize). +- You **cannot roll back** MTU during migration, only after migration completes. +- The Machine Config Operator (MCO) reboots **one node per pool at a time** by default. +- Use `ip -d link` to verify the maximum MTU (`maxmtu`) accepted by a network interface. + +## Commands and Syntax + +**Check current cluster MTU:** +```bash +oc describe network.config cluster +``` + +**Find primary network interface on a node:** +```bash +oc debug node/ -- chroot /host nmcli -g connection.interface-name c show ovs-if-phys0 +``` + +**Begin MTU migration (patch CNO):** +```bash +oc patch Network.operator.openshift.io cluster --type=merge --patch \ + '{"spec": { "migration": { "mtu": { "network": { "from": , "to": } , "machine": { "to" : } } } } }' +``` +- ``: current cluster network MTU +- ``: target cluster network MTU (must be `` minus 100 for OVN-Kubernetes) +- ``: target hardware MTU + +**Check machine config pool status:** +```bash +oc get machineconfigpools +# Success: UPDATED=true, UPDATING=false, DEGRADED=false +``` + +**Verify node machine config state:** +```bash +oc describe node | egrep "hostname|machineconfig" +``` + +**Finalize MTU migration:** +```bash +oc patch Network.operator.openshift.io cluster --type=merge --patch \ + '{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": }}}}' +``` + +**Verify node interface MTU after migration:** +```bash +oc adm node-logs -u ovs-configuration | grep configure-ovs.sh | grep mtu | grep | head -1 +``` + +**DHCP MTU configuration (dnsmasq):** +``` +dhcp-option-force=26, +``` + +**NetworkManager conf.d file format:** +```ini +[connection--mtu] +match-device=interface-name: +ethernet.mtu= +``` + +**Butane config** creates MachineConfig objects that place the NetworkManager MTU config at `/etc/NetworkManager/conf.d/99--mtu.conf` with separate configs for `master` and `worker` roles. + +## Relationships +- **Cluster Network Operator (CNO)**: Validates migration parameters and writes temporary network configuration. +- **Machine Config Operator (MCO)**: Performs rolling reboots during migration steps; applies MachineConfig objects. +- **OVN-Kubernetes**: The only supported network plugin for MTU changes; has 100-byte overlay overhead. +- **Butane**: Used to generate MachineConfig YAML from `.bu` config files for NetworkManager settings. +- **NetworkManager**: Manages interface-level MTU on RHCOS nodes. +- Related to bare-metal/PXE installation networking, DHCP configuration, and jumbo frame support on switches/hypervisors. + +## Exam-Relevant Points +- OVN-Kubernetes overlay overhead is exactly **100 bytes** — cluster MTU = hardware MTU - 100. +- Only **OVN-Kubernetes** supports post-install MTU changes (not OpenShift SDN). +- The migration is a **3-phase process**: (1) patch CNO with migration spec, (2) update hardware MTU on nodes, (3) finalize by setting `spec.migration` to `null` and updating `ovnKubernetesConfig.mtu`. +- The command to check current MTU is `oc describe network.config cluster`. +- The `Network.operator.openshift.io` resource (not `network.config`) is patched for migration. +- MCO updates **one machine per pool at a time** by default. +- Successful node update: `UPDATED=true`, `UPDATING=false`, `DEGRADED=false`. +- Node readiness is confirmed when `currentConfig` equals `desiredConfig` and state is `Done`. +- Three methods for hardware MTU: NetworkManager connection profile (default), DHCP, kernel command line/PXE. +- With mixed-MTU nodes, always use the **lowest** MTU minus overhead. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md new file mode 100644 index 0000000000000000000000000000000000000000..3f96042f6084d82914c5e706fdf820ddf6b46818 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md @@ -0,0 +1,38 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/index +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:17 + +## Overview +This is the landing page for the Advanced Networking section of OpenShift Container Platform 4.17 documentation. It serves as an index for specialized networking topics beyond basic cluster networking, covering MTU changes, connectivity verification, Stream Control Transmission Protocol (SCTP), Precision Time Protocol (PTP) hardware, and secondary interface metrics. + +## Key Concepts +- **Advanced networking** is a distinct category from basic OCP networking, covering specialized use cases +- Topics grouped under advanced networking include: + - **MTU changes** — modifying Maximum Transmission Unit size for cluster networks + - **Connectivity verification** — validating network connectivity within the cluster + - **SCTP (Stream Control Transmission Protocol)** — a transport-layer protocol alternative to TCP/UDP, relevant for telecom workloads + - **PTP (Precision Time Protocol) hardware** — hardware-based time synchronization for latency-sensitive workloads + - **Secondary interface metrics** — monitoring and metrics for additional (non-primary) network interfaces on pods + +## Commands and Syntax +No commands or configuration syntax provided on this landing page — content is in the sub-pages. + +## Relationships +- Falls under the broader **Networking** domain in OCP +- **SCTP and PTP** are particularly relevant to **telecom/5G/NFV** use cases (closely related to OCP's role in edge and telco deployments) +- **Secondary interface metrics** relates to **Multus CNI** and multiple network attachments on pods +- **MTU changes** connect to the **cluster network operator** and **OVN-Kubernetes / OpenShift SDN** CNI plugins +- **Connectivity verification** relates to **network diagnostics** and cluster health + +## Exam-Relevant Points +- Know that SCTP is supported in OCP as a transport protocol (not just TCP/UDP) +- PTP hardware support is an advanced networking feature in OCP — relevant for time-sensitive applications +- MTU changes are a post-installation advanced networking operation +- Secondary interfaces (via Multus) can expose metrics — understand that OCP supports multiple network interfaces per pod +- Connectivity verification is a built-in cluster capability for network troubleshooting + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md new file mode 100644 index 0000000000000000000000000000000000000000..66a5840bd625fc33d3eb22c9dc5241ed64b8a7bd --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md @@ -0,0 +1,11 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/legal-notice +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-legal.md +--- +# En Documentation Openshift_Container_Platform 417 Html Advanced_Networking Legal + +**Date:** 2026-03-05 +**Time:** 13:17 + +This is just a legal notice/copyright page — it contains no technical content relevant to OpenShift expertise or certification study. No summary worth creating here. Skip this page. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md new file mode 100644 index 0000000000000000000000000000000000000000..84518c5e34c97ebdfd005fa5356b2b0672468669 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md @@ -0,0 +1,92 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/network-bonding-considerations +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-netwo.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:17 + +## Overview +Network bonding (link aggregation) in OpenShift Container Platform combines multiple physical network interfaces into a single logical interface for fault tolerance and load balancing. OpenShift supports two bonding types: Open vSwitch (OVS) bonding and kernel bonding, each with different modes, capabilities, and configuration approaches. + +## Key Concepts +- **Network bonding / link aggregation**: Combining multiple NICs into one logical interface for redundancy and/or load balancing +- **OVS bonding**: Uses Open vSwitch to create bonds; MAC address management is centralized at the OVS bridge level; physical MAC addresses do not handle traffic directly +- **OVS `active-backup` mode**: One active port handles traffic; standby ports monitor link status and take over on failure; all ports share the same MAC address +- **OVS `balance-slb` mode**: Source load balancing across multiple physical interfaces without requiring switch-side negotiation; balances only across different MAC/VLAN combinations +- **Limitation of balance-slb**: All OVN-Kubernetes pod traffic uses the same MAC and VLAN, so pod traffic **cannot** be load-balanced across interfaces — balance-slb is useful for VM workloads with different MACs +- **OVS bridge architecture**: `br-ex` receives VM traffic → patch ports connect to `br-phy` → `br-phy` controls the SLB bond → physical NICs (e.g., `eno0`, `eno1`) +- **Kernel bonding**: Built-in Linux kernel feature; bond interfaces exist **outside** the bridge data path; default if no OVS bonds are configured; less customizable than OVS bonding +- **Kernel bonding `fail_over_mac`**: Only value `0` (`none`) is supported by Red Hat — all interfaces share the bond's MAC. Values `1` (`active`) and `2` (`follow`) are **not supported** + +## Commands and Syntax + +**NMState config for OVS balance-slb bond** (key fragment): +```yaml +- name: br-phy + type: ovs-bridge + state: up + bridge: + allow-extra-patch-ports: true + port: + - name: patch-phy-to-ex + - name: ovs-bond + link-aggregation: + mode: balance-slb + port: + - name: enp2s0 + - name: enp3s0 +``` + +**Base64-encode NMState config for MachineConfig embedding:** +```bash +base64 -w0 .yml +``` + +**MachineConfig manifest to apply bonding config:** +```yaml +apiVersion: machineconfiguration.openshift.io/v1 +kind: MachineConfig +metadata: + labels: + machineconfiguration.openshift.io/role: master + name: 10-br-ex-master +spec: + config: + ignition: + version: 3.2.0 + storage: + files: + - contents: + source: data:text/plain;charset=utf-8;base64, + mode: 0644 + overwrite: true + path: /etc/nmstate/openshift/cluster.yml +``` + +**Procedure summary:** +1. Define network interfaces in `install-config.yaml` under `networkConfig` +2. Create NMState `NodeNetworkConfigurationPolicy` with bridge/bond definitions +3. Base64-encode the NMState config +4. Embed in `MachineConfig` manifests for `master` and/or `worker` roles +5. Save manifests to `/manifests`; MCO applies via rolling update + +## Relationships +- **OVN-Kubernetes CNI plugin**: OVS bonding integrates natively with it +- **NMState operator**: Used to define network interface configurations (`NodeNetworkConfigurationPolicy`) +- **MachineConfig / MCO**: Delivers bonding configuration to nodes via Ignition +- **NetworkAttachmentDefinition (NAD)**: VMs connect to localnet NADs to access physical networks through the bonded interfaces +- **install-config.yaml**: Network interfaces must be defined here for bare-metal hosts +- **br-ex bridge**: Central OVS bridge in OVN-Kubernetes networking; bonding extends its connectivity via `br-phy` + +## Exam-Relevant Points +- OVS bonding supports two modes: **`active-backup`** and **`balance-slb`** +- `balance-slb` does **not** load-balance OVN-Kubernetes pod traffic (same MAC/VLAN) — it benefits **VM workloads** with distinct MACs +- Kernel bonding only supports `fail_over_mac=0` (`none`); values `1` and `2` are **unsupported** +- Kernel bonding is the **default** when no OVS bonds are configured +- OVS manages MAC addresses at the **bridge level**, not at individual physical interfaces +- The NMState config is base64-encoded and delivered via **MachineConfig** at path `/etc/nmstate/openshift/cluster.yml` +- The `br-phy` bridge acts as the **SLB bond controller**; patch ports connect `br-ex` to `br-phy` +- MTU must be **manually set** on bond ports for `br-ex` + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md new file mode 100644 index 0000000000000000000000000000000000000000..c52eb20d1a7f92b9b02bd6e6ab6675221f954a05 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md @@ -0,0 +1,115 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/using-ptp-hardware +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-using.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:18 + +## Overview +This page covers Precision Time Protocol (PTP) hardware configuration in OpenShift Container Platform 4.17. It explains PTP concepts (grandmaster, boundary, and ordinary clocks), the linuxptp and gpsd software packages used for synchronization, how to install and configure the PTP Operator, and how to set up various clock configurations including grandmaster clocks with GNSS sources, boundary clocks, and dual/triple NIC setups for telco RAN deployments. + +## Key Concepts +- **PTP (Precision Time Protocol)** provides sub-microsecond clock accuracy using hardware support, more accurate than NTP +- **Three PTP clock types**: Grandmaster (authoritative time source, syncs to GNSS), Boundary (relays timing between upstream/downstream), Ordinary (single-port, source or destination) +- **Best Master Clock (BMC) algorithm** automatically creates and updates the leader-follower clock hierarchy +- **linuxptp package** provides `ts2phc`, `ptp4l`, `phc2sys`, and `pmc` daemons +- **gpsd package** provides `ubxtool`, `gpspipe`, `gpsd` for GNSS clock synchronization +- **PTP Operator** discovers PTP-capable devices, manages linuxptp services, and provides clock event notifications +- PTP Operator works **only on bare-metal infrastructure** +- **NTP/chronyd must be disabled** before enabling PTP (use MachineConfig CR) +- GNSS timing supported **only with Intel E810 Westport Channel NICs** +- **DPLL (Digital Phase-Locked Loop)** synchronizes clock phases between PTP nodes +- **Leap seconds** can disrupt RAN networks if unhandled +- **Fast event notifications** use pub-sub REST API via `cloud-event-proxy` sidecar over HTTP +- **Dual-NIC** configurations: one NIC gets GNSS, second receives timing via SMA1 Tx/Rx connections +- **3-card NIC** grandmaster clocks supported for D-RAN configurations +- **Highly available boundary clocks** use dual NICs with A-BMCA algorithm (ITU-T G.8275.1) to maintain sync if one source fails +- UDP hardware timestamping doesn't work with OVN-Kubernetes on `br-ex` interface (migration concern from openshift-sdn) + +## Commands and Syntax + +**Install PTP Operator (CLI):** +```bash +# Create namespace +oc create -f ptp-namespace.yaml # namespace: openshift-ptp + +# Create OperatorGroup +oc create -f ptp-operatorgroup.yaml + +# Subscribe +oc create -f ptp-sub.yaml # channel: "stable", source: redhat-operators + +# Verify +oc get csv -n openshift-ptp -o custom-columns=Name:.metadata.name,Phase:.status.phase +``` + +**Discover PTP devices:** +```bash +oc get NodePtpDevice -n openshift-ptp -o yaml +``` + +**Key CRDs:** +- `NodePtpDevice.ptp.openshift.io` — auto-created per node listing PTP-capable NICs +- `PtpConfig` — configures linuxptp services (ptp4l, phc2sys, ts2phc) + +**PtpConfig CR structure (grandmaster example):** +```yaml +apiVersion: ptp.openshift.io/v1 +kind: PtpConfig +metadata: + name: grandmaster + namespace: openshift-ptp +spec: + profile: + - name: "grandmaster" + ptp4lOpts: "-2 --summary_interval -4" + phc2sysOpts: -r -u 0 -m -N 8 -R 16 -s $iface_master -n 24 + ptpSchedulingPolicy: SCHED_FIFO + ptpSchedulingPriority: 10 + plugins: + e810: + enableDefaultConfig: false + settings: + LocalMaxHoldoverOffSet: 1500 + LocalHoldoverTimeout: 14400 + MaxInSpecOffset: 1500 +``` + +**Namespace YAML:** +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: openshift-ptp + annotations: + workload.openshift.io/allowed: management + labels: + name: openshift-ptp + openshift.io/cluster-monitoring: "true" +``` + +## Relationships +- **PTP Operator** → installed via OLM (Subscription, OperatorGroup in `openshift-ptp` namespace) +- **MachineConfig** → used to disable chronyd before enabling PTP +- **OVN-Kubernetes** → migration from openshift-sdn affects UDP hardware timestamping on br-ex +- **Telco RAN / vRAN** → primary consumer of PTP; loss of sync can shut down radios +- **cloud-event-proxy sidecar** → delivers PTP fast event notifications to applications +- **Intel E810 NIC plugin** → hardware-specific configuration in PtpConfig CR +- **ITU-T G.8275.1** → standard for A-BMCA algorithm used in HA boundary clock leader selection + +## Exam-Relevant Points +- PTP provides **sub-microsecond** accuracy with hardware support; more accurate than NTP +- PTP Operator runs **only on bare-metal** infrastructure +- **NTP must be disabled** (chronyd via MachineConfig) before enabling PTP +- GNSS sources require **Intel E810 Westport Channel NICs only** +- PTP Operator namespace is `openshift-ptp` with label `openshift.io/cluster-monitoring: "true"` +- The Operator auto-discovers PTP devices and creates `NodePtpDevice` CRs per node +- Three clock types: **Grandmaster** (GNSS-synced), **Boundary** (multi-port relay), **Ordinary** (single port) +- `ptp4l` implements boundary and ordinary clocks; `ts2phc` is used for grandmaster clock configs +- `phc2sys` synchronizes the **system clock to the PHC** on the NIC +- Fast event notifications use **pub-sub REST API** via `cloud-event-proxy` sidecar +- Dual-NIC boundary clocks provide **high availability** — node maintains sync if one timing source fails +- E810 NIC configuration uses a **plugin** stanza in the `PtpConfig` CR + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md new file mode 100644 index 0000000000000000000000000000000000000000..08622aaac36df4d0fc61cd8b13af8727c14b32f7 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md @@ -0,0 +1,93 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking/verifying-connectivity-endpoint +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking-verif.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:18 + + + +## Overview +This page documents OpenShift's built-in network connectivity verification system. The Cluster Network Operator (CNO) runs a connectivity check controller that automatically performs TCP connection health checks between cluster resources every minute, storing results in `PodNetworkConnectivityCheck` objects in the `openshift-network-diagnostics` namespace. + +## Key Concepts +- The **connectivity check controller** is managed by the CNO and runs connection tests every minute in parallel +- **Health check source**: a single pod replica set (Deployment) that initiates connections to endpoints specified in `PodNetworkConnectivityCheck` objects +- **Health check target**: a DaemonSet pod running on every node, listening for inbound health checks — enables testing connectivity to each node +- Results are stored in `PodNetworkConnectivityCheck` custom resources (API group: `controlplane.operator.openshift.io/v1alpha1`) +- All diagnostic resources live in the `openshift-network-diagnostics` namespace +- Connectivity checks verify TCP reachability to: Kubernetes API server (service + endpoints), OpenShift API server (service + endpoints), load balancers (internal + external), and health check targets (service + endpoints on every node) +- Diagnostics mode is configured via the `Network` CR (`config.openshift.io/v1`) named `cluster`, under `spec.networkDiagnostics` +- Mode can be `"All"` (default), `"Disabled"`, or empty string (equivalent to `All`) +- Pod placement for source/target pods is configurable via `nodeSelector` and `tolerations` under `sourcePlacement` and `targetPlacement` +- Node labels must be applied **before** updating the network diagnostics configuration — labels applied after are ignored +- Connection log reasons: `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError` +- The `PodNetworkConnectivityCheck` status tracks: `conditions`, `failures`, `successes`, and `outages` (with start/end logs) + +## Commands and Syntax + +```bash +# Edit connectivity check pod placement +oc edit network.config.openshift.io cluster + +# Verify network diagnostics are enabled +oc get network.config.openshift.io cluster -o yaml +# Look for: status.conditions[].type: NetworkDiagnosticsAvailable with status: "True" + +# List all connectivity check objects +oc get podnetworkconnectivitycheck -n openshift-network-diagnostics + +# View detailed connectivity check results +oc get podnetworkconnectivitycheck -n openshift-network-diagnostics -o yaml + +# Verify source/target pod placement +oc get pods -n openshift-network-diagnostics -o wide +``` + +**Network diagnostics configuration YAML:** +```yaml +apiVersion: config.openshift.io/v1 +kind: Network +metadata: + name: cluster +spec: + networkDiagnostics: + mode: "All" # "All", "Disabled", or "" (empty = All) + sourcePlacement: + nodeSelector: + checkNodes: groupA + tolerations: + - key: myTaint + effect: NoSchedule + operator: Exists + targetPlacement: + nodeSelector: + checkNodes: groupB + tolerations: + - key: myOtherTaint + effect: NoExecute + operator: Exists +``` + +## Relationships +- **Cluster Network Operator (CNO)**: manages the connectivity check controller and deploys source/target pods +- **Network CR** (`config.openshift.io/v1`): central configuration point for network diagnostics settings; also relates to `network.operator.openshift.io` CR's `spec.disableNetworkDiagnostics` field (the `networkDiagnostics` stanza overrides it) +- **Node scheduling**: ties into Kubernetes node selectors and tolerations for pod placement +- **Troubleshooting workflows**: use connectivity checks to diagnose or eliminate network issues when investigating cluster problems +- Source pod names follow the pattern `network-check-source-*`, targets follow `network-check-target-*` +- Object naming convention: `-to-` where target includes identifiers like `kubernetes-apiserver-endpoint`, `load-balancer-api-external`, `openshift-apiserver-service-cluster`, etc. + +## Exam-Relevant Points +- Connectivity checks run **every minute** in parallel +- All objects are in the `openshift-network-diagnostics` namespace +- The `PodNetworkConnectivityCheck` object name format is `-to-` +- Diagnostics are configured on the `Network` CR named `cluster` (API: `config.openshift.io/v1`) +- Three diagnostics modes: `All`, `Disabled`, empty string (= `All`) +- Source pod is a **Deployment** (single replica); target pods are a **DaemonSet** (every node) +- Node labels must exist **before** updating diagnostics configuration +- To check if diagnostics are enabled, look for condition type `NetworkDiagnosticsAvailable` with status `"True"` +- Connection log `reason` values: `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError` +- Requires `cluster-admin` role to verify connectivity + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking.md new file mode 100644 index 0000000000000000000000000000000000000000..787b4693c775de1698f6b0bc2eeb7ddbaac8d393 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-advanced_networking.md @@ -0,0 +1,36 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/advanced_networking +source: sources/en-documentation-openshift_container_platform-417-html-advanced_networking.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:18 + +## Overview +The Advanced Networking section in OpenShift Container Platform 4.17 covers specialized networking topics beyond basic cluster networking, including MTU changes, connectivity verification, Stream Control Transmission Protocol (SCTP), Precision Time Protocol (PTP) hardware, and secondary interface metrics. + +## Key Concepts +- **MTU changes** — Modifying Maximum Transmission Unit sizes for cluster networks +- **Connectivity verification** — Tools/mechanisms to verify network connectivity within the cluster +- **SCTP (Stream Control Transmission Protocol)** — A transport-layer protocol supported as an advanced networking feature in OCP +- **PTP (Precision Time Protocol) hardware** — Hardware-based precision time synchronization for nodes +- **Secondary interface metrics** — Monitoring and metrics collection for secondary (non-primary) network interfaces + +## Commands and Syntax +No specific commands provided on this index page — each subtopic has its own detailed page. + +## Relationships +- Builds on top of the base **Cluster Networking** configuration (SDN/OVN-Kubernetes) +- **SCTP** relates to workloads requiring multi-streaming transport (e.g., telecom/5G) +- **PTP** relates to **node configuration** and is critical for telco/RAN workloads requiring sub-microsecond time sync +- **Secondary interface metrics** connects to **Multus CNI** and multiple network attachments +- **MTU changes** affect both **cluster network operator** configuration and **node network state** + +## Exam-Relevant Points +- Know that OCP supports SCTP as an advanced protocol option beyond TCP/UDP +- PTP hardware support is a distinct advanced networking feature (important for telco use cases) +- MTU changes are classified as an advanced networking operation (not a day-1 install config change) +- Secondary interfaces can be monitored via dedicated metrics (ties into Multus/multiple networks) +- Connectivity verification is a built-in capability for troubleshooting network issues + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md new file mode 100644 index 0000000000000000000000000000000000000000..236715de6d78331344f80e23664dc5210f6b8601 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md @@ -0,0 +1,78 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/api-index +source: sources/en-documentation-openshift_container_platform-417-html-api_overview-api-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:19 + +## Overview + +This page provides the complete API index for OpenShift Container Platform 4.17, listing every API resource available in the platform alongside its API group. It serves as a reference catalog mapping resource kinds to their fully qualified API group versions, covering both upstream Kubernetes APIs and OpenShift-specific extensions. + +## Key Concepts + +- **API Groups** organize related resources under a common path (e.g., `apps/v1`, `config.openshift.io/v1`) +- **Core APIs** (API group `v1`) include fundamental resources: Pod, Service, ConfigMap, Secret, Namespace, Node, PersistentVolume, PersistentVolumeClaim, Endpoints, Event, LimitRange, ResourceQuota, ServiceAccount +- **OpenShift-specific API groups** extend Kubernetes with platform capabilities: + - `config.openshift.io/v1` — cluster-wide configuration (OAuth, Image, Network, Ingress, Infrastructure, Proxy, Scheduler, DNS, FeatureGate, ClusterVersion, ClusterOperator, APIServer, etc.) + - `operator.openshift.io/v1` — operator management resources + - `build.openshift.io/v1` — Build, BuildConfig, BuildLog, BuildRequest + - `route.openshift.io/v1` — Route (OpenShift's ingress mechanism) + - `image.openshift.io/v1` — ImageStream and related resources + - `apps.openshift.io/v1` — DeploymentConfig (legacy) + - `security.openshift.io/v1` — SecurityContextConstraints (SCC) + - `project.openshift.io/v1` — Project, ProjectRequest + - `quota.openshift.io/v1` — ClusterResourceQuota + - `oauth.openshift.io/v1` — OAuth tokens and clients + - `user.openshift.io/v1` — User, Group, Identity + - `template.openshift.io/v1` — Template, TemplateInstance +- **Some resources exist in multiple API groups** (e.g., ClusterRole exists in both `authorization.openshift.io/v1` and `rbac.authorization.k8s.io/v1`; DNS in both `config.openshift.io/v1` and `operator.openshift.io/v1`) +- **OLM (Operator Lifecycle Manager) APIs** under `operators.coreos.com` — CatalogSource, ClusterServiceVersion, Subscription, InstallPlan, OperatorGroup, OperatorCondition, OLMConfig +- **Monitoring APIs** — Prometheus, Alertmanager, PrometheusRule, ServiceMonitor, PodMonitor (under `monitoring.coreos.com/v1`); AlertingRule, AlertRelabelConfig (under `monitoring.openshift.io/v1`) +- **Machine management APIs** under `machine.openshift.io` — Machine, MachineSet, MachineHealthCheck, ControlPlaneMachineSet +- **Machine configuration APIs** under `machineconfiguration.openshift.io/v1` — MachineConfig, MachineConfigPool, KubeletConfig, ContainerRuntimeConfig +- **OVN networking APIs** under `k8s.ovn.org/v1` — EgressFirewall, EgressIP, EgressQoS, EgressService +- **Bare metal APIs** under `metal3.io/v1alpha1` — BareMetalHost, FirmwareSchema, Provisioning, etc. +- **Storage APIs** — CSIDriver, CSINode, StorageClass, VolumeSnapshot, VolumeSnapshotClass, VolumeSnapshotContent + +## Commands and Syntax + +No commands on this page — it is a pure reference index. To interact with these APIs: + +```bash +# List all API resources on a cluster +oc api-resources + +# Get resources from a specific API group +oc get clusterversion # config.openshift.io/v1 +oc get machineconfig # machineconfiguration.openshift.io/v1 +oc get route -n # route.openshift.io/v1 + +# Explain a resource's schema +oc explain route.spec +``` + +## Relationships + +- **config.openshift.io/v1** resources define cluster-wide settings consumed by operators tracked via **ClusterOperator** +- **operator.openshift.io/v1** resources configure individual operators that reconcile the config.openshift.io resources +- **OLM resources** (CatalogSource → Subscription → InstallPlan → ClusterServiceVersion) form the operator installation lifecycle +- **Machine API** chain: MachineSet → Machine → Node; MachineConfigPool → MachineConfig applies OS-level configuration +- **RBAC** resources (Role, ClusterRole, RoleBinding, ClusterRoleBinding) in `rbac.authorization.k8s.io/v1` mirror OpenShift's `authorization.openshift.io/v1` equivalents +- **Networking** spans multiple groups: NetworkPolicy (k8s), EgressFirewall/EgressIP (OVN), Route (OpenShift), Ingress (k8s), IngressController (operator) + +## Exam-Relevant Points + +- Know which API group a resource belongs to — especially `config.openshift.io/v1` vs `operator.openshift.io/v1` +- **SecurityContextConstraints** is under `security.openshift.io/v1` (OpenShift-specific, not standard Kubernetes) +- **Route** is `route.openshift.io/v1` — OpenShift's native ingress, distinct from Kubernetes Ingress (`networking.k8s.io/v1`) +- **DeploymentConfig** (`apps.openshift.io/v1`) is OpenShift-specific and legacy; **Deployment** (`apps/v1`) is the standard Kubernetes resource +- **ClusterVersion** (`config.openshift.io/v1`) tracks the cluster's current and desired version — key for upgrades +- **ClusterOperator** (`config.openshift.io/v1`) reports operator status — essential for troubleshooting +- Core v1 resources (Pod, Service, ConfigMap, Secret, Namespace, Node, PV, PVC) have no API group prefix +- **ImageStream** (`image.openshift.io/v1`) is OpenShift-specific for image management +- **MachineConfigPool** and **MachineConfig** are under `machineconfiguration.openshift.io/v1` — critical for node configuration +- **Project** vs **Namespace**: Project (`project.openshift.io/v1`) wraps Namespace (`v1`) with additional policy + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md new file mode 100644 index 0000000000000000000000000000000000000000..477db5d60637b1fe08c29b2d384f39978970731a --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md @@ -0,0 +1,48 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/compatibility-guidelines +source: sources/en-documentation-openshift_container_platform-417-html-api_overview-compatibilit.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:19 + +## Overview +This page defines Red Hat's API compatibility guidelines for OpenShift Container Platform, covering how APIs are maintained across releases, what exceptions exist, and key terminology around release types and support tiers. It is essential reading for understanding what is and isn't guaranteed to remain stable between OCP versions. + +## Key Concepts + +- **Forward compatibility only**: Applications built for OCP 4.14 are not guaranteed to work on 4.13 — they must run on an environment as new or newer than the one they target. +- **No direct etcd access**: All etcd operations must go through the API server or documented backup/restore procedures. +- **`unsupported` prefix**: API fields with this prefix have zero compatibility guarantees across or within releases. +- **Undocumented annotations**: Usage of annotations not explicitly mentioned in product docs is not assured across minor releases. +- **RHCOS filesystem modifications**: Not preserved across minor releases unless made through a supported Operator (MCO, Node Tuning Operator). +- **Cloud infrastructure modifications**: Not preserved unless made through a public product interface or documented supported configuration. +- **Functional defaults may differ**: A fresh install of version X may have different defaults than a cluster upgraded to version X from an earlier version. +- **API availability varies by topology**: Not all APIs are present in every installation topology (e.g., some topologies may restrict or omit certain APIs). +- **z-stream releases never break API/AOE compatibility** except for critical security issues. +- **EUS deprecation policy**: Deprecation is defined across minor releases, not EUS releases — EUS users may need to respond to deprecations when migrating between EUS versions by upgrading through each minor release sequentially. + +## Commands and Syntax + +No specific CLI commands on this page. The guidelines are policy-oriented, not procedural. + +## Relationships + +- **Machine Config Operator / Node Tuning Operator**: The supported interfaces for host OS modifications on RHCOS. +- **RHEL compatibility guidelines**: OCP inherits and extends RHEL ABI compatibility principles (avoid `proc`/`sys`/`debug` filesystems, `ioctls`, direct `cgroups` interaction). +- **API tiers**: References a tiered support model (defined elsewhere) that determines compatibility guarantees per API. +- **Cloud provider integrations**: Dynamic volume provisioning, service load balancers, pod workload identity, and compute management are integration points subject to both OCP and cloud vendor compatibility windows. +- **Developer Preview vs Technology Preview**: Two distinct pre-GA support levels — Developer Preview is unsupported and opt-in (may render cluster unsupportable); Technology Preview is partially supported but not production-ready. + +## Exam-Relevant Points + +- **Release versioning**: In `4.13.2` → 4 = major, 13 = minor, 2 = z-stream. +- **z-stream = no breaking changes** (except critical security). +- **AOE definition**: Containerized environment sharing the host kernel but isolated from host OS libraries/binaries. Does not include CNI plugin selection or admission hooks. +- **EUS**: Extended User Support — extended support window for critical fixes on select minor releases; upgrade path requires sequential minor release adoption. +- **Developer Preview**: Opt-in, unsupported, may render cluster unsupportable, can be removed at any time. +- **Technology Preview**: Opt-in, not fully supported, not for production use, provides early access to upcoming features. +- **Never depend on**: specific kernel versions, `proc`/`sys`/`debug` filesystems, direct `cgroups` interaction, `ioctls`, `unsupported`-prefixed fields, undocumented annotations, or system package config files. +- **Always use**: published client libraries, Operator-provided APIs over direct config file modification, API server for all cluster state access. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md new file mode 100644 index 0000000000000000000000000000000000000000..cd83635b87f6dcc6d2b9afb86da8d76f0d525d12 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md @@ -0,0 +1,87 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/editing-kubelet-log-level-verbosity +source: sources/en-documentation-openshift_container_platform-417-html-api_overview-editing-kube.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:20 + +## Overview +This page covers how to modify kubelet log verbosity levels in OpenShift Container Platform for troubleshooting node issues. It describes both temporary (one-time) and persistent methods for changing log levels, explains the meaning of each verbosity level, and provides commands for gathering kubelet logs from cluster nodes. + +## Key Concepts +- **Kubelet log verbosity** is controlled via the `KUBELET_LOG_LEVEL` environment variable, configured through systemd drop-in files +- The **default log level is 2**, which provides useful steady-state information and is the recommended default +- Log levels **0–4 are debug-level**; levels **5–8 are trace-level** +- Systemd drop-in files use numeric ordering — `30-logging.conf` overrides `20-logging.conf` +- **One-time changes** are made directly on the node and don't survive reboots +- **Persistent changes** use a `MachineConfig` object, which survives reboots and is managed by the Machine Config Operator + +## Commands and Syntax + +**One-time kubelet log level change (via debug node):** +```bash +oc debug node/ +chroot /host +systemctl cat kubelet # check current log level +echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf +systemctl daemon-reload +systemctl restart kubelet +``` + +**Revert one-time change:** +```bash +rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf +systemctl daemon-reload +systemctl restart kubelet +``` + +**Persistent log level via MachineConfig:** +```yaml +apiVersion: machineconfiguration.openshift.io/v1 +kind: MachineConfig +metadata: + labels: + machineconfiguration.openshift.io/role: master + name: 99-master-kubelet-loglevel +spec: + config: + ignition: + version: 3.2.0 + systemd: + units: + - name: kubelet.service + enabled: true + dropins: + - name: 30-logging.conf + contents: | + [Service] + Environment="KUBELET_LOG_LEVEL=2" +``` + +**Gathering logs:** +```bash +oc adm node-logs --role master -u kubelet # master kubelet logs +oc adm node-logs --role worker -u kubelet # worker kubelet logs +journalctl -b -f -u kubelet.service # from inside the node +sudo tail -f /var/log/containers/* # container logs on node +# All nodes at once: +for n in $(oc get node --no-headers | awk '{print $1}'); do oc adm node-logs $n | gzip > $n.log.gz; done +``` + +## Relationships +- **MachineConfig / Machine Config Operator (MCO)**: Persistent log level changes are applied through MachineConfig objects, which the MCO rolls out to nodes +- **`oc debug node`**: The primary mechanism for accessing node internals for one-time troubleshooting +- **systemd**: Kubelet runs as a systemd service; log level is configured via systemd drop-in files +- **`oc adm node-logs`**: The cluster-external way to retrieve node-level service logs without SSH +- **Ignition**: MachineConfig uses Ignition spec (v3.2.0) to define systemd unit drop-ins + +## Exam-Relevant Points +- The default kubelet log level is **2** (`KUBELET_LOG_LEVEL=2`) +- Log levels 0–4 = debug; 5–8 = trace +- One-time log changes go in `/etc/systemd/system/kubelet.service.d/30-logging.conf` and require `systemctl daemon-reload && systemctl restart kubelet` +- `oc adm node-logs --role -u kubelet` gathers kubelet logs by node role without needing SSH +- Persistent changes require a **MachineConfig** with the `machineconfiguration.openshift.io/role` label targeting the correct pool (master/worker) +- `oc debug node/` followed by `chroot /host` is the standard way to access a node's filesystem for troubleshooting + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-index.md new file mode 100644 index 0000000000000000000000000000000000000000..98c1a0e67d48088e97b72edef0aeaade901a3c8c --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-index.md @@ -0,0 +1,32 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/index +source: sources/en-documentation-openshift_container_platform-417-html-api_overview-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:20 + +## Overview +This is the landing page for the OpenShift Container Platform 4.17 API overview documentation. It serves as an entry point to the API reference material but contains minimal substantive content itself — it primarily links to the detailed API documentation sections. + +## Key Concepts +- OpenShift Container Platform exposes its functionality through a comprehensive **REST API** +- The API documentation covers OCP version **4.17** (with docs available across versions 3.0–4.21) +- The API overview is maintained by the **Red Hat OpenShift Documentation Team** +- Documentation is available in **multi-page**, **single-page**, and **PDF** formats + +## Commands and Syntax +No commands or syntax are provided on this landing page. The actual API endpoints and usage are documented in sub-pages. + +## Relationships +- **Kubernetes API**: OCP's API extends the upstream Kubernetes API with additional resources (Routes, DeploymentConfigs, BuildConfigs, etc.) +- **oc CLI**: The `oc` command-line tool is the primary client for interacting with the OCP API +- **OAuth/Authentication**: API access is governed by OCP's authentication and authorization mechanisms +- **Operators**: Many OCP APIs are provided by Operators via Custom Resource Definitions (CRDs) + +## Exam-Relevant Points +- OpenShift Container Platform is **API-driven** — all cluster operations can be performed via the API +- The API is versioned and version-specific documentation exists for each OCP release +- Understanding the API structure is foundational for topics like automation, CI/CD integration, and custom controller development + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md new file mode 100644 index 0000000000000000000000000000000000000000..f2fbd8320a15900594486ce80c16a6fec8f198ff --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md @@ -0,0 +1,51 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview/understanding-api-support-tiers +source: sources/en-documentation-openshift_container_platform-417-html-api_overview-understandin.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:20 + +## Overview +This page defines the API compatibility tier system used by Red Hat OpenShift Container Platform. It classifies all commercially supported APIs, components, and features into four tiers (1–4) with decreasing stability guarantees, maps specific API groups to those tiers, and describes the deprecation policy governing how and when APIs can be removed. + +## Key Concepts +- **API Tier 1**: Stable within a major release. Cannot be removed until a subsequent major release. Highest compatibility guarantee. +- **API Tier 2**: Stable for at least 9 months or 3 minor releases from deprecation announcement, whichever is longer. +- **API Tier 3**: Component-specific lifetime; minor-to-minor compatibility is not guaranteed. Default tier for API groups without explicit assignment. Operators from OperatorHub fall here. +- **API Tier 4**: No compatibility guaranteed. Can change at any time. `v1alpha1` APIs default to this tier. Internal CRDs used by Operators should be annotated as tier 4 via `operators.operatorframework.io/internal-objects`. +- **AOE (Application Operating Environment)**: The runtime environment compatibility level, governed by the same tier system. +- Cloud-specific and hardware-specific integrations have no compatibility beyond what the vendor provides. +- Developers should only depend on formally documented API behavior, not implementation-specific behavior or bugs. +- Deprecation policy covers: REST resources (API objects), fields, annotations (excluding version-specific qualifiers), and enumerated/constant values. +- Tier 1 rules: elements removed only by incrementing group version; round-trip between versions without info loss; cannot deprecate until an equally stable version exists. + +## Commands and Syntax +No CLI commands on this page, but relevant annotations and conventions: +- `operators.operatorframework.io/internal-objects` — CSV annotation marking CRDs as internal/tier 4 +- API group suffixes determine governance: + - `*.k8s.io` or `version.` — Kubernetes deprecation policy + - `*.openshift.io` — OpenShift deprecation policy + - `monitoring.coreos.com` — All versions (including alpha/beta) are Tier 1 + - `operators.coreos.com` — All versions (including alpha) are Tier 1 + +## Relationships +- **Kubernetes deprecation policy**: OCP inherits and normalizes upstream Kubernetes API versioning conventions (v1→Tier 1, v1beta1→Tier 2, v1alpha1→Tier 4). +- **Operator Lifecycle Manager (OLM)**: APIs under `operators.coreos.com` are all Tier 1 regardless of version suffix. +- **OperatorHub / Operators**: Components delivered via OperatorHub are Tier 3 by default — developers must consult per-component compatibility docs. +- **CLI deprecation**: CLI elements inherit API tier of their underlying API, defaulting to Tier 1 for GA, Tier 3 for Tech Preview, Tier 4 for Developer Preview. +- **Component removal**: Governed by the highest-tier API the component exposes. + +## Exam-Relevant Points +- **Tier 1 = stable within major release; Tier 2 = 9 months or 3 releases; Tier 3 = component-specific; Tier 4 = no guarantee.** +- `v1alpha1` APIs default to **Tier 4** (no compatibility), except for `monitoring.coreos.com` and `operators.coreos.com` where alpha is **Tier 1**. +- Any API group without an explicit tier assignment defaults to **Tier 3**. +- `route.openshift.io/v1`, `config.openshift.io/v1`, `oauth.openshift.io/v1` are all **Tier 1**. +- `console.openshift.io/v1` is notably **Tier 2**, not Tier 1. +- `security.openshift.io/v1` is Tier 1 **except** `RangeAllocation` (Tier 4) and `*Reviews` (Tier 2). +- GA CLI flags/commands are **Tier 1**; Tech Preview CLI elements are **Tier 3**; Developer Preview are **Tier 4**. +- Tier 1 APIs must round-trip between versions without information loss. +- Component deprecation timeline is dictated by its **highest-tier** API. +- This guidance does **not** cover layered OCP offerings. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview.md new file mode 100644 index 0000000000000000000000000000000000000000..c04c00b6a652420e871452e491fb445884d5aba9 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-api_overview.md @@ -0,0 +1,33 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/api_overview +source: sources/en-documentation-openshift_container_platform-417-html-api_overview.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:21 + +## Overview +This is the landing page for the OpenShift Container Platform 4.17 API overview documentation. It serves as an entry point to API reference material for OCP, providing navigation to detailed API documentation. The page itself contains minimal substantive content beyond framing. + +## Key Concepts +- OpenShift Container Platform exposes a comprehensive **API** that underpins all platform operations +- The API documentation is versioned per OCP release (this covers **4.17**) +- API docs are available in multi-page, single-page, and PDF formats +- The API is the foundational interface through which all OCP resources (pods, deployments, routes, builds, etc.) are managed + +## Commands and Syntax +No specific commands or syntax are provided on this landing page. + +## Relationships +- **Kubernetes API**: OCP's API extends the upstream Kubernetes API with additional resource types (Routes, BuildConfigs, DeploymentConfigs, ImageStreams, etc.) +- **oc CLI**: The `oc` command-line tool interacts with these APIs +- **Custom Resources (CRDs)**: Operators extend the API surface with custom resource definitions +- **RBAC**: API access is governed by role-based access control policies + +## Exam-Relevant Points +- OpenShift Container Platform builds on and extends the Kubernetes API +- Every `oc` command corresponds to an underlying API call +- Understanding the API group structure (e.g., `apps.openshift.io`, `route.openshift.io`, `build.openshift.io`) is important for RBAC and resource management +- API versions follow the OCP release versioning (docs are version-specific) + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md new file mode 100644 index 0000000000000000000000000000000000000000..9edcc4252937c7bf3c9fbfbc9426ab48791422a4 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md @@ -0,0 +1,47 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/about-the-multicluster-engine-for-kubernetes-operator +source: sources/en-documentation-openshift_container_platform-417-html-architecture-about-the-mu.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:21 + +## Overview +The multicluster engine for Kubernetes Operator addresses the challenge of managing the lifecycle of multiple Kubernetes clusters at scale. It provides full lifecycle management for OpenShift Container Platform clusters and partial lifecycle management for other Kubernetes distributions. It is available either as a standalone operator included with OpenShift Container Platform / OpenShift Kubernetes Engine subscriptions, or as part of Red Hat Advanced Cluster Management for Kubernetes (RHACM). + +## Key Concepts +- **Multicluster engine Operator**: An operator for managing the lifecycle of a fleet of Kubernetes clusters at scale +- **Two delivery modes**: Standalone operator (included with OCP subscription) or as part of RHACM +- **Delivered separately** from the core OCP payload — must be installed after deploying OCP +- **Full lifecycle management** for managed OCP clusters; **partial lifecycle** for other Kubernetes distributions +- **RHACM relationship**: Multicluster engine is an integral part of RHACM and is enabled by default when RHACM is installed + +## Commands and Syntax +No specific CLI commands are documented on this page. Installation is referenced via the RHACM documentation: "Installing and upgrading multicluster engine operator." + +## Key Capabilities (when enabled on OCP) +- **Hosted control planes** (based on HyperShift): Operate OCP clusters in a hyperscale manner with centralized hosted control planes +- **Hive**: Provisions self-managed OCP clusters to the hub and performs initial cluster configuration +- **klusterlet agent**: Registers managed clusters to the hub +- **Infrastructure Operator**: Manages Assisted Service deployment for on-premise bare metal and vSphere OCP installations (including single-node OpenShift). Includes **GitOps Zero Touch Provisioning (ZTP)** for fully automated bare metal and vSphere provisioning using GitOps workflows +- **Open cluster management**: Provides resources for managing Kubernetes clusters + +## Relationships +- **OpenShift Container Platform**: Multicluster engine runs on top of OCP and extends it with fleet management +- **Red Hat Advanced Cluster Management (RHACM)**: Multicluster engine is a subset of RHACM; RHACM provides additional capabilities beyond what multicluster engine alone offers +- **HyperShift**: The upstream project that hosted control planes are based on +- **Assisted Service / Infrastructure Operator**: Ties into bare metal and vSphere provisioning workflows +- **GitOps ZTP**: Integrates with the Infrastructure Operator for automated edge/bare metal deployments +- **Hive**: The provisioning component for self-managed clusters + +## Exam-Relevant Points +- Multicluster engine is **included with OCP subscription** but **delivered separately** from the core payload — it must be explicitly installed +- It provides **full lifecycle** for OCP clusters but only **partial lifecycle** for non-OCP Kubernetes +- **Hosted control planes** (HyperShift-based) enable hyperscale cluster operations +- **Hive** provisions self-managed clusters; **klusterlet** registers managed clusters to the hub +- **Infrastructure Operator** handles bare metal and vSphere installations, including single-node OpenShift +- **GitOps ZTP** automates bare metal and vSphere cluster creation with GitOps workflows +- If you need capabilities **beyond** what multicluster engine provides, use **RHACM** +- Multicluster engine is **enabled by default** in RHACM + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md new file mode 100644 index 0000000000000000000000000000000000000000..91610187ad489d9d7cdafa5e0de06c5ed0161c7d --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md @@ -0,0 +1,79 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/admission-plug-ins +source: sources/en-documentation-openshift_container_platform-417-html-architecture-admission-pl.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:21 + +## Overview +Admission plugins in OpenShift Container Platform intercept API requests after authentication and authorization to enforce policies such as security, resource limits, and configuration requirements. They run sequentially in an admission chain, and the chain can be extended dynamically using webhook admission plugins that call external webhook servers. + +## Key Concepts +- **Admission chain**: Plugins run in sequence; if any plugin rejects a request, the entire chain aborts and returns an error +- **Two types of webhook admission plugins**: mutating (runs first, can modify resources and validate) and validating (runs after mutating, validates only) +- **Default plugins**: OCP 4.17 ships with a large set of default validating and mutating plugins that are required for proper cluster functioning +- **Webhook parallelism**: When webhooks are called, they are called in parallel; all must approve or the request is denied (only the first denial reason is returned) +- **Failure policy**: Webhooks can be configured with `Fail` (deny on error) or `Ignore` (accept on error); `Ignore` can cause unpredictable behavior +- **TLS required**: Communication between webhook admission plugin and webhook server must use TLS +- **Maximum webhook timeout**: 13 seconds (cannot be changed) +- **Highly privileged 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 like pod security admission, SCCs, cluster resource quotas, and image reference resolution + +## Commands and Syntax + +**Webhook configuration resources:** +- `MutatingWebhookConfiguration` (kind) — `admissionregistration.k8s.io/v1beta1` +- `ValidatingWebhookConfiguration` (kind) — `admissionregistration.k8s.io/v1beta1` + +**Key fields in webhook config:** +```yaml +webhooks: +- name: + clientConfig: + service: + namespace: default + name: kubernetes + path: + caBundle: # PEM-encoded, base64 + rules: + - operations: [create, update, delete, connect] + apiGroups: [""] + apiVersions: ["*"] + resources: [] + failurePolicy: Fail | Ignore + sideEffects: None +``` + +**Deploying a dynamic webhook (high-level procedure):** +1. Build and publish webhook server container image +2. Create CA key/cert, sign webhook server's CSR +3. `oc new-project my-webhook-namespace` +4. Define and apply RBAC rules: `oc auth reconcile -f rbac.yaml` +5. Deploy webhook as DaemonSet: `oc apply -f webhook-daemonset.yaml` +6. Create TLS secret: `oc apply -f webhook-secret.yaml` +7. Create ServiceAccount and Service: `oc apply -f webhook-service.yaml` +8. Register as aggregated API server via `APIService` resource +9. Create the `ValidatingWebhookConfiguration` or `MutatingWebhookConfiguration` + +## Relationships +- **Security Context Constraints (SCCs)**: `security.openshift.io/SecurityContextConstraint` is a default admission plugin +- **Resource Quotas**: Both `ResourceQuota` and `quota.openshift.io/ClusterResourceQuota` are default validating plugins +- **RBAC**: Webhook servers use RBAC for access control; `system:auth-delegator` ClusterRole is used for authentication delegation +- **API Server**: Admission plugins are part of the API server request processing pipeline (after authn/authz, before persistence) +- **Pod Security**: Pod security admission does not work in highly privileged projects +- **Aggregated API Servers**: Webhook servers are typically configured as aggregated API servers for internal credential use and RBAC integration +- **SR-IOV, Scheduling, Networking**: Specific default plugins handle network policy, node selectors, tolerations, and ingress + +## Exam-Relevant Points +- Mutating admission plugins run **before** validating admission plugins +- If **any** plugin in the admission chain rejects, the **entire chain** is aborted +- The maximum webhook timeout is **13 seconds** and **cannot be changed** +- `failurePolicy: Ignore` unconditionally accepts requests when the webhook is unavailable — this is risky +- Default projects (`default`, `kube-public`, `kube-system`, `openshift`, `openshift-infra`, `openshift-node`) are highly privileged and **bypass** admission plugin functionality like SCCs, pod security admission, and cluster resource quotas +- Webhook communication **must** use TLS +- When multiple webhooks deny a request, only the **first denial reason** is returned +- Common webhook use cases: namespace reservation, SR-IOV network resource limiting, toleration definitions, pod priority class validation +- The two webhook configuration resource kinds are `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration` +- Webhooks are called **in parallel**, not sequentially (the overall mutating/validating phases are sequential, but webhooks within each phase run in parallel) + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-architecture.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-architecture.md new file mode 100644 index 0000000000000000000000000000000000000000..8578c01b69596fa7756fd2ba24564126c34b2dc3 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-architecture.md @@ -0,0 +1,79 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/architecture-rhcos +source: sources/en-documentation-openshift_container_platform-417-html-architecture-architecture.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:22 + +## Overview + +Red Hat Enterprise Linux CoreOS (RHCOS) is the immutable, container-optimized operating system that underpins OpenShift Container Platform 4.x. It is the **only supported OS for control plane nodes** and the default for worker nodes (though RHEL can be used for workers). RHCOS is configured at provisioning time via Ignition config files, and all subsequent changes are managed remotely through the Machine Config Operator (MCO), enforcing a "controlled immutability" model. + +## Key Concepts + +- **RHCOS is based on RHEL** — same kernel, RPM packages, systemd init system, and security standards. +- **Controlled immutability** — the OS is mostly read-only; configuration is managed by the cluster, not by admins logging into nodes. +- **CRI-O is the only container engine** in OpenShift clusters (not Docker). It can use `runC` or `crun` as the container runtime. +- **Container tools**: `podman` (run/manage containers), `skopeo` (copy/sign images), `crictl` (CRI-O debugging) replace the Docker CLI. Direct use on RHCOS is discouraged except for debugging. +- **rpm-ostree** delivers transactional, atomic OS upgrades via container images. Rollback is a single reboot. +- **bootupd** handles firmware and bootloader updates (UEFI and legacy BIOS) on x86_64, ppc64le, aarch64. +- **Filesystem layout**: + - `/usr` — read-only (OS binaries/libraries) + - `/etc`, `/boot`, `/var` — writable, but only intended to be changed by the MCO + - `/var/lib/containers` — container image graph storage +- **Ignition** is the first-boot provisioning utility; it runs from initramfs, configures disks/files/users, and the machine is ready without a reboot. +- **Ignition is declarative** — partial configurations are not possible; if setup fails, the machine is not added to the cluster. +- **Ignition supports RAID but not LVM**. +- Ignition config files contain certificates that **expire after 24 hours**; use them within **12 hours** of generation. +- **Default user**: `core` (SSH key injected via Ignition). + +## Commands and Syntax + +```bash +# Generate Ignition config files +openshift-install create ignition-configs --dir $HOME/testconfig +# Produces: bootstrap.ign, master.ign, worker.ign + +# View Ignition config contents +cat $HOME/testconfig/bootstrap.ign | jq + +# Decode base64-encoded file content from Ignition +echo | base64 --decode + +# List machine config pools +oc get machineconfigpools + +# List all machine configs +oc get machineconfig + +# See files managed by a specific machine config +oc describe machineconfigs 01-worker-container-runtime | grep Path: +``` + +## Relationships + +- **Machine Config Operator (MCO)** — manages all post-installation OS configuration and upgrades for RHCOS nodes; applies MachineConfig objects. +- **MachineConfigPool** — groups nodes (master/worker) and their rendered machine configs. +- **Ignition** — handles first-boot configuration; MCO takes over afterward using the same Ignition config spec format. +- **install-config.yaml** — feeds into `openshift-install` which generates Ignition configs. +- **Day-1 vs Day-2 customizations** — Day-1 via Ignition/manifests during install; Day-2 via MachineConfig CRs or Operator custom resources after cluster is running. +- **Bootstrap machine** — serves Ignition configs to control plane nodes; workers get configs from control plane nodes (via API endpoint on port 22623). +- **ContainerRuntimeConfig CR** — used to switch between `runC` and `crun`. + +## Exam-Relevant Points + +- RHCOS is **mandatory for control plane nodes**; workers can optionally run RHEL. +- The container engine is **CRI-O** (not Docker) — this is frequently tested. +- Ignition runs **only on first boot** from initramfs; subsequent changes go through the MCO. +- Ignition is **declarative, not procedural** — machines cannot be partially configured. +- Ignition config certificates expire after **24 hours**; best practice is to use within **12 hours**. +- Machine configs are applied in **lexicographic order** (00* through 99*); last file wins for conflicts. +- The rendered MachineConfig is a **union** of all input MachineConfig objects for a pool. +- `/usr` is **read-only**; `/etc`, `/boot`, `/var` are writable but MCO-managed. +- Worker Ignition configs reference the bootstrap/control plane via `https://api.:22623/config/worker`. +- Prefer **Kubernetes workload objects** (DaemonSet, Deployment) over node-level customization to reduce upgrade risk. +- Day-1 customization examples: kernel arguments, disk encryption (FIPS), kernel modules, chronyd settings. +- `rpm-ostree` upgrades are **atomic** with single-reboot rollback capability. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md new file mode 100644 index 0000000000000000000000000000000000000000..1f586a914065404947481ecbea7ff23ac98cca3b --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md @@ -0,0 +1,70 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/control-plane +source: sources/en-documentation-openshift_container_platform-417-html-architecture-control-plan.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:22 + +## Overview +The OpenShift Container Platform control plane consists of control plane (master) machines that manage the cluster and its worker nodes. It relies on machine config pools (MCPs) for node configuration management, Operators (both cluster and add-on) for managing cluster functions, and etcd as the persistent data store. The Cluster Version Operator (CVO) and Machine Config Operator coordinate upgrades across the cluster. + +## Key Concepts + +- **Control plane machines** manage workloads on compute/worker machines; cluster upgrades are driven by the CVO, MCO, and individual Operators +- **Machine Config Pools (MCPs)** group machines by role for unified configuration management; two defaults: `master` and `worker` +- **Custom MCPs** inherit from the worker pool; they can target changes to specific node groups (e.g., `infra`) while still receiving worker pool changes +- **A node can only belong to one MCP** — custom pools take priority over the worker pool based on node labels +- **Configuration drift** occurs when a node's actual config doesn't match its MCP's machine config; the MCD detects this and marks the node `degraded` +- **Degraded nodes** are online and operational but cannot be updated +- **Infra nodes** labeled with the `infra` role running only infra workloads do **not** count toward subscription charges (must also use taints to prevent user workload scheduling) +- **Exactly three control plane nodes** are required for production; bare metal clusters can scale up to five +- **Control plane and node versions must match** (temporary skew allowed during upgrades) +- **kubelet must not be newer than kube-apiserver**; can be up to 1 minor version older (odd OCP versions) or 2 minor versions older (even OCP versions) +- **CRI-O** is the container engine (not Docker); both CRI-O and kubelet run as **systemd services** directly on the host +- **Worker node services**: CRI-O, kubelet, service proxy, runC/crun container runtime +- **Kubernetes control plane components**: API server, etcd, controller manager, scheduler +- **OpenShift-specific control plane components**: OpenShift API server, OpenShift controller manager, OpenShift OAuth API server, OpenShift OAuth server +- **Two Operator management systems**: Cluster Operators (managed by CVO, installed by default) and add-on Operators (managed by OLM, optional) +- **OLM does not manage cluster Operators** — those are managed by the CVO +- **OperatorHub** catalog sources: Red Hat Operators, certified Operators, community Operators, and custom catalogs +- **etcd** is a consistent, distributed key-value store; the primary data store for Kubernetes; requires fast, low-latency I/O + +## Commands and Syntax + +No direct CLI commands in this page, but key administrative references: + +- View Cluster Operators: **Administration → Cluster Settings** in the web console +- `ClusterOperator` objects represent each cluster Operator +- `installer-*` and `revision-pruner-*` pods run as root, writing to `/etc/kubernetes` in namespaces: + - `openshift-etcd` + - `openshift-kube-apiserver` + - `openshift-kube-controller-manager` + - `openshift-kube-scheduler` + +## Relationships + +- **MCO ↔ MCPs**: MCO manages MCPs and facilitates updates; MCD detects configuration drift +- **CVO ↔ Cluster Operators**: CVO manages all default cluster Operators +- **OLM ↔ Add-on Operators**: OLM manages optional Operators installed via OperatorHub +- **etcd ↔ Control Plane**: etcd stores all cluster state; watched by controllers and schedulers +- **Machine API ↔ Compute Machine Sets**: machine sets under `machine-api` namespace control compute machines (distinct from MCPs under MCO namespace) +- **Control Plane Machine Sets**: manage control plane machines on supported cloud providers +- **Operator SDK → Custom Operators → OLM**: developers author Operators, bundle them into custom catalogs + +## Exam-Relevant Points + +1. **Default MCPs are `master` and `worker`** — custom MCPs for control plane are not supported +2. **Custom MCPs inherit from the worker pool** — non-inheriting custom pools are unsupported by the MCO +3. **A node belongs to exactly one MCP** — custom pools take priority over worker pool +4. **Infra nodes don't count toward subscriptions** if properly labeled and tainted +5. **Removing `worker` label without a custom pool makes a node unmanaged** by the MCO +6. **Three control plane nodes required for production** (up to five on bare metal) +7. **kubelet version skew**: up to 1 minor version older for odd OCP releases, up to 2 for even releases +8. **CRI-O is the container engine**, not Docker — runs as a systemd service +9. **Two Operator systems**: CVO for cluster Operators, OLM for add-on Operators — they are separate +10. **etcd requires fast, low-latency I/O** due to high-frequency small writes +11. **Configuration drift** → node marked `degraded` → online but cannot be updated +12. **MCO applies pool updates independently** — pools update in parallel with each other + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-index.md new file mode 100644 index 0000000000000000000000000000000000000000..c2f25930a364c92f26cac012ad07062bc195224a --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-index.md @@ -0,0 +1,33 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/index +source: sources/en-documentation-openshift_container_platform-417-html-architecture-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:23 + +## Overview +This is the top-level landing page for the OpenShift Container Platform 4.17 Architecture documentation. It serves as an entry point to detailed architectural topics covering platform and application architecture in OpenShift Container Platform. + +## Key Concepts +- OpenShift Container Platform 4.17 has a dedicated **Architecture** documentation section covering both **platform architecture** and **application architecture** +- The architecture docs are available across many OCP versions (from 3.0 through 4.21), indicating architecture is a foundational documentation area +- This is a hub page — the substantive content lives in sub-pages beneath it + +## Commands and Syntax +None on this page (it is a navigation/landing page). + +## Relationships +- Parent topic for all architecture sub-pages (likely covering control plane, worker nodes, networking architecture, storage architecture, etc.) +- Connects to the broader OCP 4.17 documentation set +- Architecture understanding is foundational to installation, operations, networking, and security topics + +## Exam-Relevant Points +- OpenShift Container Platform distinguishes between **platform architecture** (infrastructure, control plane, operators) and **application architecture** (how workloads are structured and deployed) +- The current version documented here is **4.17** — version awareness matters for exam contexts + +--- + +*Note: This source page is a table-of-contents landing page with minimal substantive content. The real architectural detail will be in the child pages beneath this section.* + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md new file mode 100644 index 0000000000000000000000000000000000000000..4f82b24f274ab3b1b1a9f545865e08bafc0217fe --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md @@ -0,0 +1,49 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/ocm-overview-ocp +source: sources/en-documentation-openshift_container_platform-417-html-architecture-ocm-overview.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:23 + +## Overview +Red Hat OpenShift Cluster Manager (OCM) is a managed service providing a single dashboard to install, modify, operate, and upgrade OpenShift clusters. It supports OpenShift Container Platform (self-managed), Red Hat OpenShift Service on AWS (ROSA), and OpenShift Dedicated clusters, offering lifecycle management from installation through ongoing operations. + +## Key Concepts +- **OpenShift Cluster Manager (OCM)** — centralized web-based management console for all OpenShift clusters in an organization +- Accessible at `console.redhat.com/openshift` with a Red Hat account that belongs to an OpenShift organization +- Supports three cluster types: OCP (self-installed), ROSA, and OpenShift Dedicated +- **Cluster ID** — unique identifier used for CLI commands against the cluster +- **Domain prefix** — defaults to the cluster name, used throughout the cluster +- **Delete Protection** — can be enabled/disabled per cluster to prevent accidental deletion +- **Insights Advisor** — leverages Remote Health functionality to identify risks to security, performance, availability, and stability +- **Machine pools** — groupings of compute nodes that can be created/edited if quota is available +- **Update strategy** — can be automatic (scheduled day/time) or manual + +## Commands and Syntax +No CLI commands are described on this page. All interactions are through the web UI at: +``` +https://console.redhat.com/openshift +``` + +## Relationships +- **Insights Advisor** connects to the Remote Health / Telemetry subsystem of OCP +- **Access control tab** relates to identity providers and RBAC — cluster owners can grant "Cluster Editor" roles +- **Machine pools** relate to cluster scaling, node labels, taints, and AWS security groups +- **OIDC configuration** ties into authentication and identity management +- **Networking tab** relates to cluster network configuration (address/prefix) +- OCM is the management layer above the individual cluster — it does not replace the in-cluster web console but complements it (the "Open console" action launches the cluster's own web console) + +## Exam-Relevant Points +- OCM URL: `console.redhat.com/openshift` +- Prerequisites: Red Hat account in an OpenShift organization; organization must have specified quota for cluster creation +- Key cluster tabs: Overview, Access control, Add-ons, Networking, Insights Advisor, Machine pools, Support, Settings +- The **Cluster ID** is used when issuing CLI commands to the cluster +- Update strategy options: automatic (specific day/time) or manual +- Cluster owners can grant the **Cluster Editor** role to other users via the Access control tab +- Notification contacts for cluster alerts are configured in the **Support** tab +- Machine pool editing allows changing node count per availability zone, node labels, and taints +- The **Control plane type** field only appears for clusters using hosted control plane architecture +- Availability zones can be **single** or **multizone** + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-understandin.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-understandin.md new file mode 100644 index 0000000000000000000000000000000000000000..0cf6441374dfd7a4366228affc975fa5bc4186d9 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture-understandin.md @@ -0,0 +1,75 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture/understanding-development +source: sources/en-documentation-openshift_container_platform-417-html-architecture-understandin.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:23 + +## Overview +This page covers the fundamentals of developing containerized applications for OpenShift Container Platform, progressing from building simple containers through creating Kubernetes manifests to developing Operators. It explains the tools, base images, registries, workload types, and supporting components available in the OCP ecosystem. + +## Key Concepts +- **Container development lifecycle**: Build image → push to registry → create K8s manifest → store in Git → optionally create an Operator +- **Container build tools**: `buildah`, `podman`, and `skopeo` are daemonless, rootless tools preferred over Docker; they produce industry-standard OCI images +- **CRI-O** is the container engine running on every worker and control plane node in OCP clusters (not supported standalone outside OCP) +- **Red Hat Universal Base Images (UBI)**: Freely redistributable base images (standard, init, minimal variants) based on RHEL — no Red Hat subscription required to share +- **Source-to-Image (S2I)**: Special runtime base images that let you insert code into a ready-to-run environment (Node.js, Perl, Python, etc.) +- **Pods** are the basic deployable unit in Kubernetes (not containers); pods can contain multiple containers sharing network, storage, and IPC +- **Services** group pods together, provide stable IP addresses, and enable load balancing; they persist until explicitly deleted +- **Red Hat Registry**: `registry.redhat.io` (authenticated, current) and `registry.access.redhat.com` (unauthenticated, deprecated) +- **Quay.io**: Red Hat-owned public registry; stores OCP components, container images, Helm charts, and Operators +- **Red Hat Quay**: Private registry option with geo-replication, Git build triggers, and Clair image scanning +- **OCP includes a built-in private container registry** installed with the cluster +- **OperatorHub**: Marketplace for Operators from Red Hat, certified partners, and community — available in every OCP 4.x cluster +- **Templates**: One-off application definitions with parameterized resource lists; shared templates often placed in the `openshift` namespace (accessible from all namespaces) + +## Commands and Syntax +```bash +# Build a container image using buildah +buildah build-using-dockerfile . + +# Build using docker +docker build . + +# Push image to registry +podman push quay.io/myrepo/myapp:latest +docker push quay.io/myrepo/myapp:latest + +# Pull and run +podman run +docker run + +# Apply a Kubernetes manifest +oc apply -f +``` + +## Relationships +- **Workload types map to application needs**: + - Run-to-completion → `Job` / `CronJob` + - Long-running → `Deployment` / `DeploymentConfig` + - High availability → `Deployment` with `ReplicaSet` + - Every-node → `DaemonSet` + - Identity/numbering requirements → `StatefulSet` + - Lifecycle management → `Operator` (with OLM) +- **Networking**: `NetworkPolicy` for fine-grained control; `Ingress` for external-to-internal routing +- **Storage**: `Volumes` and `PersistentVolumes` for on-disk storage needs +- **CI/CD and GitOps**: Manifests stored in Git; CI pipelines build images and push to registries +- **Operator Lifecycle Manager (OLM)**: Manages Operator installation and updates; cluster admins expose Operators to selected namespaces + +## Exam-Relevant Points +- **Docker as container runtime is deprecated** in Kubernetes 1.20 (but Docker-built images still work with all runtimes including CRI-O) +- **CRI-O** runs on every node in OCP — it is the container runtime, not Docker +- **UBI images are freely redistributable** without a Red Hat subscription +- **S2I images** are accessible from the Developer perspective → +Add → Developer Catalog +- **`registry.redhat.io`** requires authentication; `registry.access.redhat.com` is deprecated +- **Pods** (not containers) are the basic unit of deployment, scaling, and management in Kubernetes +- **Services** provide stable networking; resolved by name within the cluster +- **StatefulSets** are for apps needing stable identity/numbering and independent storage (databases, zookeeper) +- **DaemonSets** ensure a pod runs on every node (or a subset via node labels) — used for DNS, monitoring +- **Templates** go in the `openshift` namespace for cluster-wide availability +- **OperatorHub** is available in every OCP 4.x cluster +- **`oc apply`** is the command to deploy Kubernetes manifests +- Operators encode operational knowledge (backups, upgrades, scaling) and automate maintenance tasks + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture.md new file mode 100644 index 0000000000000000000000000000000000000000..06da30a926fa6a8a295f704117ba67a7ce6fd9be --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-architecture.md @@ -0,0 +1,36 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/architecture +source: sources/en-documentation-openshift_container_platform-417-html-architecture.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:24 + +## Overview +This is the top-level landing page for the OpenShift Container Platform 4.17 Architecture documentation. It serves as an index page introducing the architecture section, which covers the platform and application architecture of OpenShift Container Platform. The page itself contains no substantive technical content — it links to sub-pages that contain the actual architectural details. + +## Key Concepts +- OpenShift Container Platform 4.17 is the version documented +- The architecture section covers both **platform architecture** (infrastructure, control plane, nodes) and **application architecture** (how workloads run on the platform) +- Documentation is maintained by the Red Hat OpenShift Documentation Team +- Available in multi-page, single-page, and PDF formats + +## Commands and Syntax +None on this page (index/landing page only). + +## Relationships +- This is the parent page for all architecture sub-topics, which typically include: + - **Installation and update architecture** — how the platform is deployed + - **Control plane architecture** — API server, etcd, controllers, scheduler + - **Node architecture** — kubelet, CRI-O, worker nodes + - **Networking architecture** — SDN/OVN-Kubernetes, Services, Routes + - **Storage architecture** — persistent volumes, CSI drivers + - **RHCOS (Red Hat Enterprise Linux CoreOS)** — the immutable OS layer +- Foundational to understanding all other OCP documentation sections + +## Exam-Relevant Points +- OpenShift Container Platform 4.17 is a current supported version +- Understanding the distinction between **platform architecture** and **application architecture** is fundamental to the exam +- The architecture section is the conceptual foundation — exam questions often test understanding of how components relate to each other at the architectural level + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authentication_and_author.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authentication_and_author.md new file mode 100644 index 0000000000000000000000000000000000000000..87793dcbc122e78be2211312cf40ec52a12f2511 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authentication_and_author.md @@ -0,0 +1,11 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authentication_and_authorization/legal-notice +source: sources/en-documentation-openshift_container_platform-417-html-authentication_and_author.md +--- +# En Documentation Openshift_Container_Platform 417 Html Authentication_And_Author + +**Date:** 2026-03-05 +**Time:** 13:24 + +This is just a legal notice / copyright page — it contains no technical content relevant to OpenShift expertise or certification. No summary needed; skipping. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md new file mode 100644 index 0000000000000000000000000000000000000000..c677dbe28b605e6782eb2bec9be7d05900d7cd07 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md @@ -0,0 +1,58 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/authorization-apis +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-author.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:24 + +## Overview +This page catalogs the Authorization API resources available in OpenShift Container Platform 4.17. These APIs span two API groups — the OpenShift-native `authorization.openshift.io/v1` and the upstream Kubernetes `authorization.k8s.io/v1` and `authentication.k8s.io/v1` — and provide mechanisms for checking user/group permissions, requesting tokens, and reviewing authentication status. + +## Key Concepts +- **Two parallel API groups** exist for authorization: OpenShift's `authorization.openshift.io/v1` (6 resources) and Kubernetes' `authorization.k8s.io/v1` (4 resources). Both provide similar access review capabilities. +- **AccessReview resources** answer "can user X do action Y?" — they are the mechanism for programmatic authorization checks. +- **Local vs. cluster-scoped**: Resources prefixed with "Local" (e.g., `LocalSubjectAccessReview`, `LocalResourceAccessReview`) are namespace-scoped; non-local variants operate cluster-wide. +- **ResourceAccessReview** returns *which* users/groups can perform an action (OpenShift-only, no Kubernetes equivalent listed). +- **SubjectAccessReview** checks whether a *specific* user/group can perform an action. +- **SelfSubjectAccessReview / SelfSubjectRulesReview** let the *current* user check their own permissions. +- **SelfSubjectRulesReview** (k8s) explicitly warns: should be used for UI show/hide only, **NOT** for driving external authorization decisions (confused deputy / cache concerns). +- **SubjectRulesReview** (OpenShift) lets you check what *another* user can do in a namespace. +- **TokenRequest** requests a token for a service account. +- **TokenReview** authenticates a bearer token to a known user; results may be cached by the webhook token authenticator. +- **SelfSubjectReview** (authentication) returns the user info the API server has about the requesting user; respects impersonation. +- All OpenShift authorization resources are **Compatibility level 1** — stable within a major release for ≥12 months or 3 minor releases. + +## Commands and Syntax +No specific CLI commands are shown on this reference page, but these APIs are typically consumed via: +```bash +# Check if you can perform an action +oc auth can-i [-n ] + +# Check if another user can perform an action +oc auth can-i --as= + +# List your permissions in a namespace +oc auth can-i --list [-n ] + +# Create a TokenRequest for a service account +oc create token +``` +Programmatically, these are `POST`-based resources (you create a review object and the API server responds with the result). + +## Relationships +- **RBAC**: These APIs *query* the RBAC system (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) — they don't define policy, they evaluate it. +- **Authentication APIs**: `TokenRequest`, `TokenReview`, and `SelfSubjectReview` bridge authentication and authorization — establishing identity before checking permissions. +- **Service Accounts**: `TokenRequest` ties directly to service account token management (bound tokens with audience/expiry). +- **Impersonation**: `SelfSubjectReview` reflects impersonated identity, connecting to the `--as` / impersonation header mechanism. +- **OAuth / Identity Providers**: These APIs operate downstream of authentication — once identity is established by OAuth or other providers, these APIs evaluate what that identity can do. + +## Exam-Relevant Points +- Know the difference between **OpenShift** (`authorization.openshift.io`) and **Kubernetes** (`authorization.k8s.io`) authorization API groups — OpenShift has `ResourceAccessReview` and `SubjectRulesReview` which Kubernetes does not. +- **`SelfSubjectRulesReview`** should NOT be used for external authorization decisions — only for UI hints. `SubjectAccessReview` is the correct API for authorization decisions. +- **`LocalSubjectAccessReview`** is namespace-scoped, making it easier to grant namespace-scoped permissions that include the ability to check permissions. +- **`TokenReview`** responses may be **cached** by the webhook authenticator — important for understanding token revocation behavior. +- `oc auth can-i` is the CLI equivalent of creating SubjectAccessReview / SelfSubjectAccessReview resources. +- All listed OpenShift authorization resources are type `object` with **Compatibility level 1** stability guarantees. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md new file mode 100644 index 0000000000000000000000000000000000000000..e4b0f4b988168f07c501c53435dd4ef164744620 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md @@ -0,0 +1,38 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/index +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:24 + +## Overview +This is the reference landing page for OpenShift Container Platform 4.17 Authorization API objects. It serves as an index to the detailed specifications of all authorization-related API resources in OpenShift. + +## Key Concepts +- **Authorization APIs** are a distinct category of API objects in OpenShift Container Platform, separate from other API groups (e.g., networking, storage, workloads) +- These APIs govern **access control** — determining who can do what within a cluster +- The authorization API group covers the Kubernetes and OpenShift-specific resources that enforce RBAC and permissions +- Available across OCP versions from 3.x through 4.17+ + +## Commands and Syntax +No specific commands or syntax provided on this index page. Authorization API objects are typically interacted with via: +```bash +oc api-resources --api-group=authorization.openshift.io +oc api-resources --api-group=rbac.authorization.k8s.io +``` + +## Relationships +- **RBAC resources**: Roles, ClusterRoles, RoleBindings, ClusterRoleBindings are core authorization API objects +- **OpenShift-specific authorization**: SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview, SelfSubjectRulesReview +- Connects to **Authentication APIs** (authn establishes identity; authz determines permissions) +- Relates to **Security Context Constraints (SCCs)** which control pod-level permissions +- Ties into **OAuth and identity providers** for determining user/group membership used in bindings + +## Exam-Relevant Points +- Authorization APIs are a **separate API group** from authentication — know the distinction +- OpenShift extends Kubernetes RBAC with additional authorization API objects (e.g., `authorization.openshift.io` group) +- Understanding which API objects fall under "authorization" vs other categories is testable +- The authorization API reference covers OCP-specific objects beyond standard Kubernetes RBAC + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md new file mode 100644 index 0000000000000000000000000000000000000000..efaa46435923d4d5f56ffd229c66df682dfe0e08 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md @@ -0,0 +1,11 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/legal-notice +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-legal-.md +--- +# En Documentation Openshift_Container_Platform 417 Html Authorization_Apis Legal + +**Date:** 2026-03-05 +**Time:** 13:24 + +This is just a legal notice/copyright page — it contains no technical content relevant to OpenShift expertise or certification. There's nothing meaningful to summarize here. Skip this page. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md new file mode 100644 index 0000000000000000000000000000000000000000..cf12e30f1d721916268960d42c3c4b70bb67b883 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md @@ -0,0 +1,65 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/localresourceaccessreview-authorization-openshift-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-localr.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:25 + +## Overview +LocalResourceAccessReview is an OpenShift-specific authorization API resource (`authorization.openshift.io/v1`) that allows querying which users and groups are authorized to perform a specified action within a particular namespace. It is a Compatibility Level 1 resource, meaning it is stable within a major release for at least 12 months or 3 minor releases. + +## Key Concepts +- **Purpose**: Determines *who* (users and groups) can perform a specific action on a specific resource in a given namespace +- **Namespace-scoped**: Unlike `ResourceAccessReview` (cluster-wide), this is scoped to a particular namespace +- **Request-only resource**: You POST a review request describing an action; the response lists authorized users/groups +- **Required fields**: `namespace`, `verb`, `resourceAPIGroup`, `resourceAPIVersion`, `resource`, `resourceName`, `path`, `isNonResourceURL` +- **Supported verbs**: `get`, `list`, `watch`, `create`, `update`, `delete` +- **Non-resource URLs**: Can also check access to non-resource URL paths (outside the resource hierarchy) via `isNonResourceURL` and `path` fields +- **API group**: `authorization.openshift.io/v1` — this is an OpenShift-specific API, not the upstream Kubernetes `authorization.k8s.io` API + +## Commands and Syntax + +**API Endpoint:** +``` +POST /apis/authorization.openshift.io/v1/namespaces/{namespace}/localresourceaccessreviews +``` + +**Example request body structure:** +```json +{ + "apiVersion": "authorization.openshift.io/v1", + "kind": "LocalResourceAccessReview", + "namespace": "my-project", + "verb": "create", + "resource": "pods", + "resourceAPIGroup": "", + "resourceAPIVersion": "v1", + "resourceName": "", + "path": "", + "isNonResourceURL": false +} +``` + +**Query parameters:** +- `dryRun` — set to `All` to validate without persisting +- `fieldValidation` — `Ignore` (default pre-v1.23), `Warn` (default v1.23+), or `Strict` + +**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized + +## Relationships +- **LocalResourceAccessReview vs ResourceAccessReview**: Local is namespace-scoped; `ResourceAccessReview` is cluster-scoped +- **LocalResourceAccessReview vs LocalSubjectAccessReview**: LocalResourceAccessReview asks "who can do X?"; `LocalSubjectAccessReview` asks "can user Y do X?" +- **RBAC connection**: Results reflect the effective RBAC policies (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings) +- **OpenShift-specific**: Part of the `authorization.openshift.io` API group, complementing the upstream Kubernetes `SubjectAccessReview` in `authorization.k8s.io` +- **CLI equivalent**: `oc adm policy who-can -n ` uses this API under the hood + +## Exam-Relevant Points +- LocalResourceAccessReview answers **"who can do this?"** within a namespace — distinguish from SubjectAccessReview which answers **"can this user do this?"** +- The API group is `authorization.openshift.io/v1` (OpenShift-specific, not upstream Kubernetes) +- It is **namespace-scoped** — the namespace is part of the URL path +- The only HTTP method supported is **POST** (it's a create-only subresource) +- Know the distinction: `LocalResourceAccessReview` (namespace) vs `ResourceAccessReview` (cluster-wide) +- Compatibility Level 1 = stable API guaranteed for 12 months or 3 minor releases + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md new file mode 100644 index 0000000000000000000000000000000000000000..30436197226aa48bf3dfe4a2143d8f6f356954e6 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md @@ -0,0 +1,70 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/localsubjectaccessreview-authorization-k8s-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-locals.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:25 + + + +## Overview +LocalSubjectAccessReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) that checks whether a user or group can perform a specific action within a given namespace. It is namespace-scoped, making it easier to grant namespace-level policies that include permissions checking. + +## Key Concepts +- **Namespace-scoped authorization check**: Unlike `SubjectAccessReview` (cluster-scoped), `LocalSubjectAccessReview` operates within a specific namespace +- **Spec is required**: The `spec` field is the only required field and describes the access request +- **Two attribute types** (exactly one must be set): + - `resourceAttributes` — for resource requests (e.g., can user X get pods?) + - `nonResourceAttributes` — for non-resource requests (e.g., can user X access /healthz?) +- **Status fields**: + - `allowed` (required boolean) — whether the action would be permitted + - `denied` (optional boolean) — explicit denial; if both `allowed` and `denied` are false, the authorizer has no opinion + - `evaluationError` — indicates an error during the check, but authorization may still proceed + - `reason` — explains why access was allowed or denied +- The `user` field without `groups` is interpreted as "what if user were not a member of any groups" +- Wildcard `"*"` can be used for group, resource, verb, and version fields to mean "all" + +## Commands and Syntax +**API Endpoint:** +``` +POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessreviews +``` + +**Query parameters:** `dryRun`, `fieldValidation` (Ignore/Warn/Strict) + +**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized + +**Example spec structure:** +```yaml +apiVersion: authorization.k8s.io/v1 +kind: LocalSubjectAccessReview +metadata: + namespace: my-namespace +spec: + user: "jane" + groups: ["developers"] + resourceAttributes: + namespace: "my-namespace" + verb: "get" + resource: "pods" + group: "" + version: "v1" +``` + +## Relationships +- **SubjectAccessReview** — cluster-scoped equivalent for checking permissions across the entire cluster +- **SelfSubjectAccessReview** — allows a user to check their own permissions +- **RBAC (Roles/RoleBindings)** — the authorization backend that typically evaluates these reviews +- **Namespace policies** — LocalSubjectAccessReview is the mechanism for programmatically verifying namespace-scoped RBAC grants + +## Exam-Relevant Points +- LocalSubjectAccessReview is **namespace-scoped**; SubjectAccessReview is **cluster-scoped** +- Exactly **one of** `resourceAttributes` or `nonResourceAttributes` must be set in the spec +- The `allowed` field in `.status` is **required**; `denied` is optional +- When `allowed=false` and `denied=false`, the authorizer has **no opinion** (not the same as denied) +- The `verb` field in `resourceAttributes` uses Kubernetes API verbs (`get`, `list`, `watch`, `create`, `update`, `delete`, `proxy`), not HTTP verbs +- The `verb` field in `nonResourceAttributes` uses standard **HTTP verbs** +- Empty string `""` for namespace in LocalSubjectAccessReview defaults to the review's own namespace + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md new file mode 100644 index 0000000000000000000000000000000000000000..9d38f531aa3de4967ec62b59fe055f74e4b49bd6 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md @@ -0,0 +1,63 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/resourceaccessreview-authorization-openshift-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-resour.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:25 + +## Overview +ResourceAccessReview is an OpenShift-specific authorization API resource (`authorization.openshift.io/v1`) that allows requesting a list of which users and groups are authorized to perform a specified action. It is a cluster-scoped review (not namespace-scoped) and is classified as Compatibility Level 1, meaning it is stable within a major release for at least 12 months or 3 minor releases. + +## Key Concepts +- **Purpose**: Determines *who* (users and groups) can perform a given action, as opposed to determining *whether* a specific user can perform an action (which is what SubjectAccessReview does). +- **Cluster-scoped**: The endpoint has no namespace prefix — it operates at the cluster level. +- **Required fields**: `namespace`, `verb`, `resourceAPIGroup`, `resourceAPIVersion`, `resource`, `resourceName`, `path`, `isNonResourceURL`. +- **Verb values**: One of `get`, `list`, `watch`, `create`, `update`, `delete`. +- **Non-resource URLs**: Supports checking access to non-resource URL paths (outside the resource hierarchy) via `isNonResourceURL` and `path`. +- **OpenShift-specific**: This is an OpenShift extension (`authorization.openshift.io/v1`), not a upstream Kubernetes API. + +## Commands and Syntax + +**API Endpoint:** +``` +POST /apis/authorization.openshift.io/v1/resourceaccessreviews +``` + +**Example body structure:** +```json +{ + "apiVersion": "authorization.openshift.io/v1", + "kind": "ResourceAccessReview", + "namespace": "my-namespace", + "verb": "get", + "resource": "pods", + "resourceAPIGroup": "", + "resourceAPIVersion": "v1", + "resourceName": "", + "path": "", + "isNonResourceURL": false +} +``` + +**Query parameters:** +- `dryRun` — simulate without persisting (valid value: `All`) +- `fieldValidation` — controls handling of unknown/duplicate fields (`Ignore`, `Warn`, `Strict`) + +**Response codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized. + +## Relationships +- **LocalResourceAccessReview**: The namespace-scoped counterpart — checks who can perform an action within a specific namespace. +- **SubjectAccessReview / SelfSubjectAccessReview**: The inverse question — checks whether a *specific* user/subject can perform an action, rather than listing *all* authorized users. +- **RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings)**: ResourceAccessReview evaluates the results of RBAC policies to produce its answer. +- **`oc adm policy who-can`**: The CLI command that likely uses this API under the hood to answer "who can perform action X on resource Y." + +## Exam-Relevant Points +- ResourceAccessReview answers "who can do X?" — it returns users and groups authorized for a specific action. +- It is an OpenShift-specific API under `authorization.openshift.io/v1`, not a standard Kubernetes API. +- The API is cluster-scoped (no namespace in the URL path). +- Required fields include `verb`, `resource`, `namespace`, `resourceAPIGroup`, and `resourceAPIVersion`. +- Valid verbs are: `get`, `list`, `watch`, `create`, `update`, `delete`. +- Compatibility Level 1 means stable for 12 months or 3 minor releases minimum. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md new file mode 100644 index 0000000000000000000000000000000000000000..2e4bdc14b78f2392f15be9c3cbe03590a3f4eefb --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md @@ -0,0 +1,75 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/selfsubjectrulesreview-authorization-k8s-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-selfsu.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:26 + +## Overview + +SelfSubjectRulesReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) that enumerates the set of actions the current user can perform within a specific namespace. It is designed for UI purposes (show/hide actions) and quick permission reasoning, but explicitly should **not** be used by external systems for authorization decisions. + +## Key Concepts + +- **Purpose**: Lets the current user discover what actions they are allowed to perform in a given namespace +- **Results may be incomplete**: The returned list depends on the server's authorization mode and any errors during evaluation +- **Additive rules model**: If a rule appears in the results, the subject definitely has that permission, even if the list is incomplete +- **Not for authorization decisions**: External systems should use `SubjectAccessReview` or `LocalAccessReview` instead — using SelfSubjectRulesReview raises confused deputy, caching, and correctness concerns +- **Two rule categories in status**: + - `resourceRules` — actions allowed on Kubernetes resources (verbs: get, list, watch, create, update, delete, proxy) + - `nonResourceRules` — actions allowed on non-resource URLs (verbs: get, post, put, delete, patch, head, options) +- **`incomplete` flag**: Boolean in status indicating whether the results are partial (e.g., when an external authorizer doesn't support rules evaluation) +- **`evaluationError`**: String field reporting errors during rule evaluation + +## Commands and Syntax + +**API Endpoint:** +``` +POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews +``` + +**Spec** (required field): +```yaml +spec: + namespace: "my-namespace" # Required — namespace to evaluate rules for +``` + +**Status response structure:** +```yaml +status: + incomplete: false + evaluationError: "" + resourceRules: + - apiGroups: [""] + resources: ["pods"] + resourceNames: [] + verbs: ["get", "list", "watch"] + nonResourceRules: + - nonResourceURLs: ["/healthz"] + verbs: ["get"] +``` + +**Query parameters:** `dryRun`, `fieldValidation` (Ignore/Warn/Strict) + +**HTTP responses:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized + +## Relationships + +- **SubjectAccessReview / LocalSubjectAccessReview**: The correct alternatives for programmatic authorization decisions (SelfSubjectRulesReview is only for UI/informational use) +- **RBAC**: The rules returned reflect the cumulative effect of Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings +- **Namespace-scoped**: Requires a namespace in the spec; evaluates permissions within that namespace context +- **Wildcard `*`**: Used across apiGroups, resources, resourceNames, verbs, and nonResourceURLs to mean "all" + +## Exam-Relevant Points + +- SelfSubjectRulesReview is for **UI display purposes only**, not for driving authorization decisions +- The correct APIs for authorization decisions are **SubjectAccessReview** and **LocalSubjectAccessReview** +- Results can be **incomplete** — the `incomplete` boolean and `evaluationError` string indicate this +- Authorization rules are **additive** — presence in the list confirms permission even if the list is incomplete +- The spec requires a **namespace** field +- The API group is `authorization.k8s.io/v1` +- Only supports **POST** (create) — no GET/LIST/DELETE operations +- `resourceRules` cover API resources; `nonResourceRules` cover URL paths like `/healthz` + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md new file mode 100644 index 0000000000000000000000000000000000000000..cc077765feb3af9c5bcb7f555069b21ea2ba53d4 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md @@ -0,0 +1,66 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/subjectaccessreview-authorization-k8s-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-subjec.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:26 + +## Overview +SubjectAccessReview is a Kubernetes authorization API resource (`authorization.k8s.io/v1`) used in OpenShift to programmatically check whether a specific user or group can perform a given action. It enables imperative authorization queries against the cluster's authorization layer (typically RBAC). + +## Key Concepts +- **SubjectAccessReview** checks if a user/group is authorized to perform an action — returns allowed/denied status +- The `spec` field is required and must contain exactly one of `resourceAttributes` or `nonResourceAttributes` +- **ResourceAttributes**: checks access to Kubernetes resources (pods, services, etc.) with fields for group, name, namespace, resource, subresource, verb, and version +- **NonResourceAttributes**: checks access to non-resource URL paths (e.g., `/healthz`) using HTTP verbs +- The `user` field specifies the subject to test; if `groups` is omitted, the check treats the user as having no group memberships +- `extra` maps to authenticator-provided extra info (passed through to the authorizer) +- **Status fields**: `allowed` (required boolean), `denied` (optional boolean), `reason` (human-readable explanation), `evaluationError` (error during check that may not be fatal) +- If both `allowed` and `denied` are false, the authorizer has no opinion (neither permits nor denies) +- Wildcard `"*"` can be used for group, resource, verb, and version to mean "all" + +## Commands and Syntax + +**API Endpoint:** +``` +POST /apis/authorization.k8s.io/v1/subjectaccessreviews +``` + +**Example: Check if user "jane" can get pods in namespace "dev":** +```yaml +apiVersion: authorization.k8s.io/v1 +kind: SubjectAccessReview +spec: + user: "jane" + resourceAttributes: + namespace: "dev" + verb: "get" + resource: "pods" +``` + +**Using `oc` CLI:** +```bash +oc auth can-i get pods --as=jane -n dev +``` + +**Query parameters:** `dryRun` (skip persistence), `fieldValidation` (Ignore/Warn/Strict for unknown fields) + +**HTTP responses:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized + +## Relationships +- **SelfSubjectAccessReview**: similar but checks the calling user's own permissions (no `user`/`groups` fields) +- **LocalSubjectAccessReview**: namespace-scoped variant (defaults empty namespace to the target namespace) +- **RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings)**: the authorization backend that SubjectAccessReview queries against +- **Authentication/User Info**: the `user`, `groups`, `uid`, and `extra` fields mirror what the authenticator provides +- **`oc auth can-i`**: CLI wrapper around SubjectAccessReview and SelfSubjectAccessReview + +## Exam-Relevant Points +- SubjectAccessReview is **cluster-scoped** (not namespaced) — there is a single endpoint, not per-namespace +- Exactly **one of** `resourceAttributes` or `nonResourceAttributes` must be set in the spec +- The `allowed` field in `.status` is **required**; `denied`, `reason`, and `evaluationError` are optional +- Empty string for `namespace` in resourceAttributes means **"all namespaces"** for namespace-scoped resources in SubjectAccessReview +- Resource verbs are Kubernetes verbs (`get`, `list`, `watch`, `create`, `update`, `delete`, `proxy`), not HTTP verbs — HTTP verbs are used only for nonResourceAttributes +- The `oc auth can-i --as=` command is the practical CLI equivalent of creating a SubjectAccessReview + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md new file mode 100644 index 0000000000000000000000000000000000000000..5a602a3fa8169446f8eb76d1c70d487518beeb8f --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md @@ -0,0 +1,59 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis/tokenreview-authentication-k8s-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis-tokenr.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:26 + + + +## Overview +The TokenReview resource (`authentication.k8s.io/v1`) is a Kubernetes API object used to authenticate a bearer token and resolve it to a known user. OpenShift exposes TokenReview through both the standard Kubernetes endpoint and an OpenShift-specific OAuth endpoint. TokenReview requests may be cached by the webhook token authenticator plugin in the kube-apiserver. + +## Key Concepts +- **TokenReview** is a `POST`-only API — it validates a token and returns user identity information; it does not create persistent resources. +- The `spec` field is **required** and contains the opaque bearer token to validate. +- **Audiences**: Both `spec` and `status` carry an `audiences` field. The spec declares which audiences the token should be valid for; the status returns the intersection of requested and actual audiences. +- If no audiences are specified in the spec, the default audience is the Kubernetes API server itself. +- The `status.authenticated` boolean indicates whether the token mapped to a known user. +- `status.user` returns resolved identity: `username`, `uid`, `groups`, and optional `extra` key-value pairs. +- A `uid` uniquely identifies a user across time — if a user is deleted and recreated with the same name, the UID will differ. + +## Commands and Syntax +**API Endpoints (POST only):** +- `/apis/authentication.k8s.io/v1/tokenreviews` — standard Kubernetes endpoint +- `/apis/oauth.openshift.io/v1/tokenreviews` — OpenShift OAuth endpoint + +**Query Parameters:** +- `dryRun=All` — process all stages without persisting (though TokenReview is non-mutating anyway) +- `fieldValidation` — `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), or `Strict` + +**Response Codes:** 200 OK, 201 Created, 202 Accepted, 401 Unauthorized + +**Example spec structure:** +```yaml +apiVersion: authentication.k8s.io/v1 +kind: TokenReview +spec: + token: "" + audiences: + - "https://kubernetes.default.svc" +``` + +## Relationships +- **Authentication & Authorization chain**: TokenReview is the programmatic way to verify tokens, used by webhook token authenticators and API server authentication plugins. +- **OAuth tokens**: The OpenShift-specific endpoint (`oauth.openshift.io/v1`) ties into OpenShift's OAuth server and OAuth access tokens. +- **ServiceAccount tokens**: Projected service account tokens can be validated via TokenReview with audience restrictions. +- **RBAC**: After TokenReview resolves identity, authorization decisions (via SubjectAccessReview, Roles, ClusterRoles) use the returned user/group info. +- Related APIs: **SubjectAccessReview** (authorization check), **SelfSubjectAccessReview**, **OAuthAccessToken**. + +## Exam-Relevant Points +- TokenReview has **two endpoints** in OpenShift: the Kubernetes-native one and the OpenShift OAuth one. +- The `spec` field is the only **required** field on the TokenReview object. +- `status.authenticated = true` with an empty `status.audiences` means the token is valid for the Kubernetes API server audience specifically. +- Audience-aware clients **must** validate that a compatible audience is returned in `status.audiences`. +- TokenReview results **may be cached** by the webhook token authenticator — this is a performance and security consideration. +- The API group is `authentication.k8s.io/v1` (Kubernetes-native) or `oauth.openshift.io/v1` (OpenShift). + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis.md new file mode 100644 index 0000000000000000000000000000000000000000..72316024123c0a3bc8bf3cc071f146abe1818e36 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-authorization_apis.md @@ -0,0 +1,36 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authorization_apis +source: sources/en-documentation-openshift_container_platform-417-html-authorization_apis.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:27 + +## Overview +This is the reference landing page for OpenShift Container Platform 4.17 Authorization API objects. It serves as an index to detailed specifications for all authorization-related API resources. The page itself contains minimal content, acting as an entry point to the individual API object documentation. + +## Key Concepts +- **Authorization APIs** are a distinct category of API objects in OpenShift Container Platform, separate from other API groups (e.g., networking, storage, workloads) +- These APIs govern **access control** — who can do what within the cluster +- The documentation covers API object specifications (fields, status, spec structures) rather than usage guides +- Available across many OCP versions (3.x through 4.17), indicating authorization is a long-standing, stable API surface + +## Commands and Syntax +No commands or configuration syntax are provided on this landing page. The individual sub-pages (linked from here) contain the actual API object specs, typically including: +- `oc api-resources --api-group=authorization.openshift.io` — to list authorization API resources +- `oc explain ` — to inspect fields of a specific authorization API object + +## Relationships +- **RBAC** — Authorization APIs underpin Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects +- **Authentication APIs** — Authorization depends on authentication (identity must be established before access decisions) +- **Security Context Constraints (SCCs)** — Related authorization mechanism specific to OpenShift +- **OAuth / ServiceAccounts** — Token-based identities that authorization policies evaluate +- **SubjectAccessReview / SelfSubjectAccessReview** — API objects for programmatically checking permissions + +## Exam-Relevant Points +- Know that OpenShift has its **own authorization API group** (`authorization.openshift.io`) in addition to Kubernetes-native RBAC (`rbac.authorization.k8s.io`) +- Authorization APIs are **cluster-scoped and namespace-scoped** depending on the resource (ClusterRole vs Role) +- Understanding the distinction between **API reference documentation** and **task-based documentation** — the exam may reference specific API fields +- Authorization is a core exam domain: expect questions on roles, bindings, and access reviews + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-autoscale-.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-autoscale-.md new file mode 100644 index 0000000000000000000000000000000000000000..c03c962581c8c700f71eae03c66bf5d3c70dcb84 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-autoscale-.md @@ -0,0 +1,38 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/autoscale-apis +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-autoscale-.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:27 + +## Overview +This page provides a reference index of the Autoscale APIs available in OpenShift Container Platform 4.17. It lists the four API resources used for autoscaling workloads and infrastructure, spanning both OpenShift-specific and upstream Kubernetes autoscaling API groups. + +## Key Concepts +- **ClusterAutoscaler** (`autoscaling.openshift.io/v1`) — OpenShift-specific resource that configures cluster-level autoscaling (automatically adjusts the number of nodes in the cluster). +- **MachineAutoscaler** (`autoscaling.openshift.io/v1beta1`) — OpenShift-specific resource that configures autoscaling for MachineSets (controls min/max replicas of machines within a MachineSet). +- **HorizontalPodAutoscaler (HPA)** (`autoscaling/v2`) — Kubernetes-native resource that automatically scales the replica count of any resource implementing the scale subresource, based on specified metrics. +- **Scale** (`autoscaling/v1`) — Kubernetes-native subresource representing a scaling request for a resource (the target that HPA writes to). +- All four resources are typed as `object`. +- OpenShift autoscaling APIs live under the `autoscaling.openshift.io` API group; Kubernetes-native ones under `autoscaling`. +- MachineAutoscaler is `v1beta1` (not yet GA in the OpenShift API group), while ClusterAutoscaler is `v1`. + +## Commands and Syntax +No commands or configuration examples are provided on this index page — it serves as a navigational reference to the individual API object documentation. + +## Relationships +- **ClusterAutoscaler → MachineAutoscaler**: ClusterAutoscaler must exist before MachineAutoscalers can function; it sets cluster-wide scaling policy while MachineAutoscalers set per-MachineSet boundaries. +- **MachineAutoscaler → MachineSet**: Each MachineAutoscaler targets a specific MachineSet to control node scaling. +- **HorizontalPodAutoscaler → Deployments/ReplicaSets**: HPA adjusts pod replicas on resources that implement the scale subresource. +- **Scale subresource**: The common interface that HPA uses to read and write replica counts on target resources. +- Node-level autoscaling (ClusterAutoscaler + MachineAutoscaler) and pod-level autoscaling (HPA) are complementary — HPA scales pods, which may trigger ClusterAutoscaler to add nodes if resources are insufficient. + +## Exam-Relevant Points +- Know the distinction between **ClusterAutoscaler** (cluster-wide, one per cluster) and **MachineAutoscaler** (per-MachineSet, many per cluster). +- ClusterAutoscaler is a **prerequisite** for MachineAutoscaler to work. +- HPA uses the `autoscaling/v2` API (not v1) in OCP 4.17 — v2 supports custom and external metrics, not just CPU. +- OpenShift-specific autoscaling resources use the `autoscaling.openshift.io` API group, distinguishing them from upstream Kubernetes `autoscaling` resources. +- MachineAutoscaler's `v1beta1` status signals it may evolve; ClusterAutoscaler at `v1` is stable. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-clusteraut.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-clusteraut.md new file mode 100644 index 0000000000000000000000000000000000000000..a5b64d5e9c883296a9cc4cc0124850df75f35cf8 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-clusteraut.md @@ -0,0 +1,88 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/clusterautoscaler-autoscaling-openshift-io-v1 +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-clusteraut.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:27 + + + +## Overview + +The ClusterAutoscaler is an OpenShift-specific custom resource (`autoscaling.openshift.io/v1`) that configures cluster-level autoscaling behavior. It controls how the cluster autoscaler scales node groups up and down, sets resource limits (cores, memory, GPUs, total nodes), and configures scale-down policies. It is a cluster-scoped (non-namespaced) singleton resource. + +## Key Concepts + +- **ClusterAutoscaler** is a cluster-scoped resource — there is only one per cluster, not per namespace. +- **API Group**: `autoscaling.openshift.io/v1` (OpenShift-specific, not upstream Kubernetes). +- **balanceSimilarNodeGroups**: Keeps node groups with the same instance type and labels at balanced sizes. +- **balancingIgnoredLabels**: Labels the autoscaler should ignore when determining node group similarity (e.g., `topology.ebs.csi.aws.com/zone`). +- **Expanders** control how the autoscaler chooses which node group to scale out: + - **LeastWaste** — minimizes idle CPU (then memory) after scale-up. + - **Priority** — user-assigned priority ranking. + - **Random** — random selection (default). + - Expanders can be ordered; output of one feeds into the next (e.g., `[LeastWaste, Random]`). +- **resourceLimits** constrain total cluster resources: + - `cores` — min/max CPU cores cluster-wide. + - `memory` — min/max GiB of memory cluster-wide. + - `gpus` — min/max per GPU type (identified by `cluster-api/accelerator` node label). + - `maxNodesTotal` — absolute cap on total nodes across all node groups. +- **scaleDown** configuration: + - `enabled` (required) — whether scale-down is active. + - `delayAfterAdd` — cooldown after scale-up before scale-down evaluation resumes. + - `delayAfterDelete` — cooldown after node deletion (defaults to scan-interval). + - `delayAfterFailure` — cooldown after a failed scale-down attempt. + - `unneededTime` — how long a node must be unneeded before eligible for removal. + - `utilizationThreshold` — requested resources / capacity ratio below which a node is considered for scale-down. +- **skipNodesWithLocalStorage**: If true (default), never delete nodes with pods using EmptyDir or HostPath. +- **ignoreDaemonsetsUtilization**: If true, DaemonSet pod resource usage is excluded from scale-down calculations (default: false). +- **podPriorityThreshold**: Pods below this priority won't trigger scale-up ("best-effort" pods). +- **maxNodeProvisionTime**: Maximum time to wait for a node to become ready. +- **maxPodGracePeriod**: Grace period given to pods before scale-down eviction. +- **logVerbosity**: Default 1; level 4 for debugging, level 6 for near-complete logging. Overrides `CLUSTER_AUTOSCALER_VERBOSITY` env var. + +## Commands and Syntax + +**API Endpoints:** +``` +# Collection operations +GET /apis/autoscaling.openshift.io/v1/clusterautoscalers +POST /apis/autoscaling.openshift.io/v1/clusterautoscalers +DELETE /apis/autoscaling.openshift.io/v1/clusterautoscalers + +# Individual resource +GET /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name} +PUT /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name} +PATCH /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name} +DELETE /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name} + +# Status subresource +GET /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name}/status +PUT /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name}/status +PATCH /apis/autoscaling.openshift.io/v1/clusterautoscalers/{name}/status +``` + +**fieldValidation** parameter accepts: `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), `Strict`. + +## Relationships + +- **MachineAutoscaler** — works alongside ClusterAutoscaler; defines per-MachineSet min/max replicas. ClusterAutoscaler sets cluster-wide policy, MachineAutoscaler sets per-node-group bounds. +- **MachineSets** — the node groups that the autoscaler scales. +- **Pod Priority and Preemption** — `podPriorityThreshold` integrates with Kubernetes pod priority classes. +- **DaemonSets** — `ignoreDaemonsetsUtilization` affects how DaemonSet resource usage factors into scale-down decisions. +- **Cluster API / Machine API** — GPU type matching uses the `cluster-api/accelerator` label on nodes. + +## Exam-Relevant Points + +- ClusterAutoscaler uses API group `autoscaling.openshift.io/v1` — distinct from upstream Kubernetes HPA/VPA autoscaling APIs. +- Default expander is **Random**; available options are LeastWaste, Priority, Random. +- `scaleDown.enabled` is the only **required** field under `.spec.scaleDown`. +- `cores` and `memory` resource limits require both `min` and `max` (both required fields). +- GPU limits require `type`, `min`, and `max` — the `type` matches the `cluster-api/accelerator` label value on nodes. +- `skipNodesWithLocalStorage` defaults to **true** — nodes with EmptyDir/HostPath pods are protected by default. +- `ignoreDaemonsetsUtilization` defaults to **false**. +- `maxNodesTotal` is the hard cap on cluster node count across all node groups. +- The ClusterAutoscaler is cluster-scoped (no namespace), and only one instance is expected per cluster. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-horizontal.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-horizontal.md new file mode 100644 index 0000000000000000000000000000000000000000..75d16860b85beb19833d180f3116c51dfe2211d0 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-horizontal.md @@ -0,0 +1,109 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/horizontalpodautoscaler-autoscaling-v2 +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-horizontal.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:28 + +## Overview + +The HorizontalPodAutoscaler (HPA) is a Kubernetes/OpenShift resource in the `autoscaling/v2` API group that automatically adjusts the replica count of any scalable resource (Deployments, ReplicaSets, etc.) based on observed metrics. It calculates desired replicas by comparing current metric values against target values and supports multiple metric types including CPU, memory, custom, and external metrics. + +## Key Concepts + +- **API group/version**: `autoscaling/v2` — this is the full-featured HPA API (not the older `autoscaling/v1`) +- **Required spec fields**: `scaleTargetRef` (what to scale) and `maxReplicas` (upper bound) +- **minReplicas** defaults to 1; can be set to 0 only with the `HPAScaleToZero` alpha feature gate AND at least one Object or External metric configured +- **Default metric**: If no metrics are specified, defaults to **80% average CPU utilization** +- **Replica calculation**: `desiredReplicas = currentReplicas × (currentMetricValue / targetMetricValue)` +- **Metrics must be inversely proportional to pod count** — they must decrease as pods increase +- **When multiple metrics are specified, the maximum replica count across all metrics wins** +- **Five metric source types**: + - `Resource` — built-in CPU/memory per pod + - `ContainerResource` — CPU/memory for a specific container (requires `HPAContainerMetrics` feature gate) + - `Pods` — custom per-pod metrics, averaged across pods + - `Object` — metric from a specific Kubernetes object (e.g., Ingress hits-per-second) + - `External` — metric not tied to any Kubernetes object (e.g., cloud queue length) +- **MetricTarget types**: `Utilization` (percentage of request), `Value` (absolute), `AverageValue` (per-pod average) +- **`averageUtilization` is only valid for Resource metric source type** +- **Behavior configuration** controls scaling velocity separately for scaleUp and scaleDown: + - **stabilizationWindowSeconds**: prevents flapping by choosing the safest value within the window + - Scale up default: **0 seconds** (no stabilization) + - Scale down default: **300 seconds** (5 minutes) + - Maximum: 3600 seconds (1 hour) + - **selectPolicy**: `Max` (default), `Min`, or `Disabled` — selects which policy to apply + - **policies[]**: each policy has `type`, `value`, and `periodSeconds` (1–1800 seconds / 30 min max) +- **scaleTargetRef** uses `CrossVersionObjectReference` with `kind`, `name`, and optional `apiVersion` + +## Commands and Syntax + +```yaml +apiVersion: autoscaling/v2 +kind: HorizontalPodAutoscaler +metadata: + name: example-hpa +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: my-app + minReplicas: 2 + maxReplicas: 10 + metrics: + - type: Resource + resource: + name: cpu + target: + type: Utilization + averageUtilization: 70 + - type: Pods + pods: + metric: + name: requests-per-second + target: + type: AverageValue + averageValue: "1k" + behavior: + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 60 + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Pods + value: 4 + periodSeconds: 60 + selectPolicy: Max +``` + +**Status fields** (read-only, set by the controller): +- `currentReplicas`, `desiredReplicas`, `lastScaleTime` +- `currentMetrics[]` — last observed values for each configured metric +- `conditions[]` — with `type`, `status` (True/False/Unknown), `reason`, `message` + +## Relationships + +- **Targets**: Deployments, ReplicaSets, StatefulSets, or any resource implementing the scale subresource +- **Metrics Server**: Requires a metrics source (metrics-server for Resource metrics, Prometheus adapter or similar for custom/external) +- **Cluster Autoscaler**: HPA scales pods; when nodes are exhausted, the Cluster Autoscaler adds nodes +- **VPA (Vertical Pod Autoscaler)**: Complementary — VPA adjusts resource requests/limits, HPA adjusts replica count. Avoid using both on the same resource metric +- **Feature gates**: `HPAScaleToZero` (scale to 0 replicas), `HPAContainerMetrics` (per-container metrics) + +## Exam-Relevant Points + +- HPA uses `autoscaling/v2` (v2 supports multiple metrics and custom metrics; v1 only supports CPU) +- `scaleTargetRef` and `maxReplicas` are **required**; `minReplicas` defaults to 1 +- Default metric when none specified: **80% average CPU utilization** +- Scale-down stabilization window defaults to **300 seconds**; scale-up defaults to **0** +- `minReplicas: 0` requires **both** the `HPAScaleToZero` feature gate **and** at least one Object or External metric +- `ContainerResource` metric type requires the `HPAContainerMetrics` feature gate +- When multiple metrics are defined, HPA uses the **maximum** calculated replica count +- `averageUtilization` is only valid for `Resource` type metrics (percentage of pod's resource request) +- Policy `periodSeconds` maximum is **1800** (30 min); stabilization window maximum is **3600** (1 hour) +- `selectPolicy` defaults to `Max` — the policy allowing the most change is used + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-index.md new file mode 100644 index 0000000000000000000000000000000000000000..906fe0012fce8341575a6184caace4f8c36cff97 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-index.md @@ -0,0 +1,33 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/index +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:28 + +## Overview +This is the landing page for the Autoscale APIs reference in OpenShift Container Platform 4.17. It serves as an index to the API objects related to autoscaling workloads, covering their specifications and usage. The actual API details are in sub-pages not included here. + +## Key Concepts +- **Autoscale APIs** are a category of OpenShift API objects dedicated to automatically scaling workloads +- These are part of the OpenShift Container Platform REST API surface (not upstream Kubernetes alone) +- The APIs are version-specific — this references OCP 4.17 + +## Commands and Syntax +No specific commands or syntax are provided on this landing page. The detailed API object specifications (fields, spec/status structures, example manifests) reside in the linked sub-pages. + +## Relationships +- **HorizontalPodAutoscaler (HPA)** — scales pod replicas based on CPU/memory or custom metrics +- **ClusterAutoscaler** — controls cluster-level autoscaling decisions (node scaling) +- **MachineAutoscaler** — scales MachineSets to add/remove nodes +- **VerticalPodAutoscaler (VPA)** — adjusts resource requests/limits on pods +- These APIs connect to the broader Machines API, Metrics/Monitoring stack, and workload controllers (Deployments, StatefulSets) + +## Exam-Relevant Points +- Know the distinction between **HorizontalPodAutoscaler** (scales replicas), **ClusterAutoscaler** (cluster-wide node scaling policy), and **MachineAutoscaler** (scales specific MachineSets) +- Autoscale API objects are OpenShift-specific extensions on top of Kubernetes autoscaling APIs +- ClusterAutoscaler is a cluster-scoped singleton; MachineAutoscaler references a specific MachineSet +- Understanding which API object to use for pod-level vs. node-level scaling is a common exam topic + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-legal-noti.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-legal-noti.md new file mode 100644 index 0000000000000000000000000000000000000000..5e75790b080a632a340c36cbbdab38183aee5534 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-legal-noti.md @@ -0,0 +1,11 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/legal-notice +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-legal-noti.md +--- +# En Documentation Openshift_Container_Platform 417 Html Autoscale_Apis Legal Noti + +**Date:** 2026-03-05 +**Time:** 13:28 + +This is just a legal notice/copyright page — it contains no technical content relevant to OpenShift expertise or certification study. Skipping summarization as there are no meaningful concepts, commands, or exam-relevant points to extract. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-machineaut.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-machineaut.md new file mode 100644 index 0000000000000000000000000000000000000000..df4b6c8dd67e164531089da2c912516aff395d85 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-machineaut.md @@ -0,0 +1,82 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/machineautoscaler-autoscaling-openshift-io-v1beta1 +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-machineaut.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:29 + + + +## Overview +The MachineAutoscaler is an OpenShift-specific custom resource (API group `autoscaling.openshift.io/v1beta1`) that defines scaling constraints for machine-level resources (MachineSets). It specifies minimum and maximum replica counts for a referenced scalable target, enabling the cluster autoscaler to automatically adjust the number of machines in a MachineSet based on workload demand. + +## Key Concepts +- **MachineAutoscaler** is a namespaced, OpenShift-specific CR — not a upstream Kubernetes resource +- API group: `autoscaling.openshift.io/v1beta1` (note: still beta) +- The `.spec` has three **required** fields: `minReplicas`, `maxReplicas`, and `scaleTargetRef` +- `scaleTargetRef` points to the scalable resource (typically a MachineSet) by `kind` and `name`; both are required +- `scaleTargetRef` does **not** include a namespace — scalable resources are expected to exist in the **same namespace** +- `.status.lastTargetRef` tracks the most recently observed scalable resource reference +- The resource is of type `object` at the top level + +## Commands and Syntax +**API Endpoints:** +``` +# List all MachineAutoscalers cluster-wide +GET /apis/autoscaling.openshift.io/v1beta1/machineautoscalers + +# Namespaced CRUD operations +GET /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers +POST /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers +DELETE /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers + +# Individual resource operations +GET /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers/{name} +PUT /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers/{name} +PATCH /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers/{name} +DELETE /apis/autoscaling.openshift.io/v1beta1/namespaces/{namespace}/machineautoscalers/{name} + +# Status subresource +GET .../machineautoscalers/{name}/status +PUT .../machineautoscalers/{name}/status +PATCH .../machineautoscalers/{name}/status +``` + +**Example resource structure:** +```yaml +apiVersion: autoscaling.openshift.io/v1beta1 +kind: MachineAutoscaler +metadata: + name: worker-us-east-1a + namespace: openshift-machine-api +spec: + minReplicas: 1 + maxReplicas: 12 + scaleTargetRef: + apiVersion: machine.openshift.io/v1beta1 + kind: MachineSet + name: worker-us-east-1a +``` + +**Query parameters for mutating operations:** +- `dryRun=All` — process all stages without persisting +- `fieldValidation` — `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), or `Strict` + +## Relationships +- **ClusterAutoscaler**: The MachineAutoscaler works in conjunction with the ClusterAutoscaler; the ClusterAutoscaler must be enabled for MachineAutoscalers to take effect +- **MachineSet**: The primary target of `scaleTargetRef` — MachineAutoscaler controls how many replicas a MachineSet can scale to +- **Machine API**: Part of the `openshift-machine-api` namespace ecosystem alongside Machines, MachineSets, and MachineHealthChecks +- **HorizontalPodAutoscaler (HPA)**: Complementary — HPA scales pods, MachineAutoscaler scales the underlying nodes to accommodate pod demand + +## Exam-Relevant Points +- The three **required** spec fields are `minReplicas`, `maxReplicas`, and `scaleTargetRef` +- The `scaleTargetRef` requires `kind` and `name` (not namespace — must be same namespace) +- API group is `autoscaling.openshift.io/v1beta1` — distinct from upstream `autoscaling/v1` +- MachineAutoscaler is **namespaced** (typically `openshift-machine-api`) +- The status subresource is separately accessible (GET/PUT/PATCH) from the main resource +- `minReplicas` sets the floor — the autoscaler will not scale below this even if machines are idle +- `maxReplicas` sets the ceiling — prevents runaway scaling costs +- The cluster-wide list endpoint exists without namespace for cross-namespace visibility + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-scale-auto.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-scale-auto.md new file mode 100644 index 0000000000000000000000000000000000000000..3b61b1381c0904cedc730485ed8c4a14a223d070 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis-scale-auto.md @@ -0,0 +1,66 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis/scale-autoscaling-v1 +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis-scale-auto.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:29 + + + +## Overview + +The Scale resource (`autoscaling/v1`) represents a scaling request for a resource in OpenShift Container Platform. It is a subresource that provides a uniform interface to read and update the replica count of Deployments, ReplicaSets, StatefulSets, and ReplicationControllers via the Kubernetes API. + +## Key Concepts + +- **Scale** is a subresource (not a standalone resource) — it's accessed as a child endpoint of scalable resources +- The Scale object has two key sections: + - **spec.replicas** (integer): the *desired* number of instances + - **status.replicas** (integer, required): the *actual/observed* number of instances +- **status.selector**: a label selector string matching pods that count toward the replica total +- API group: `autoscaling/v1` +- The Scale subresource is the mechanism that HorizontalPodAutoscalers use to adjust replica counts + +## Commands and Syntax + +**API Endpoints** — each supports GET, PATCH, and PUT: + +| Resource | Endpoint | +|---|---| +| Deployment | `/apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale` | +| ReplicaSet | `/apis/apps/v1/namespaces/{namespace}/replicasets/{name}/scale` | +| StatefulSet | `/apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/scale` | +| ReplicationController | `/api/v1/namespaces/{namespace}/replicationcontrollers/{name}/scale` | + +**HTTP Methods:** +- **GET** — read current scale (returns 200 or 401) +- **PATCH** — partially update scale (returns 200/201 or 401) +- **PUT** — replace scale entirely (returns 200/201 or 401) + +**Common Parameters for PATCH/PUT:** +- `dryRun`: set to `All` to validate without persisting +- `fieldValidation`: `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), or `Strict` (fail on unknown/duplicate fields) + +**CLI equivalent:** +```bash +oc scale deployment/ --replicas= +``` + +## Relationships + +- **HorizontalPodAutoscaler (HPA)** uses the Scale subresource to adjust replicas automatically based on metrics +- Applies to workload resources: **Deployments**, **ReplicaSets**, **StatefulSets**, and **ReplicationControllers** +- The **status.selector** field ties back to **label selectors** on pods +- Note: ReplicationControllers use the core API (`/api/v1/`) while the others use the apps API (`/apis/apps/v1/`) + +## Exam-Relevant Points + +- The Scale subresource is part of `autoscaling/v1`, not `apps/v1` +- **spec.replicas** = desired count; **status.replicas** = actual observed count — know the difference +- Four resource types support the Scale subresource: Deployment, ReplicaSet, StatefulSet, ReplicationController +- `fieldValidation` defaults changed at Kubernetes v1.23: `Ignore` → `Warn` +- The `dryRun=All` parameter lets you validate scale changes without applying them +- Scale is a *subresource*, accessed via `/{resource-name}/scale` — not a top-level API object + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis.md new file mode 100644 index 0000000000000000000000000000000000000000..282fe42bbf36ee8e8cc6c31b6de793958ad5e041 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-autoscale_apis.md @@ -0,0 +1,36 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/autoscale_apis +source: sources/en-documentation-openshift_container_platform-417-html-autoscale_apis.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:29 + +## Overview +This is a reference landing page for the OpenShift Container Platform 4.17 Autoscale API objects. It serves as an index to detailed specifications for the autoscaling-related API resources. The page itself contains no substantive technical content beyond introducing the section. + +## Key Concepts +- **Autoscale APIs** are a category of API objects in OpenShift Container Platform that govern automatic scaling behavior +- These APIs are part of the OpenShift REST API surface and follow Kubernetes-style API resource patterns +- The autoscale API group typically includes resources such as: + - **HorizontalPodAutoscaler (HPA)** — scales pod replicas based on CPU/memory or custom metrics + - **ClusterAutoscaler** — controls cluster-level autoscaling decisions (adding/removing nodes) + - **MachineAutoscaler** — scales MachineSets to add or remove worker nodes + - **VerticalPodAutoscaler (VPA)** — adjusts pod resource requests/limits automatically + +## Commands and Syntax +No commands or configuration syntax are provided on this landing page. The detailed API specs (fields, status, spec definitions) are in the linked sub-pages. + +## Relationships +- **Cluster infrastructure**: ClusterAutoscaler and MachineAutoscaler tie into the Machine API and MachineSets +- **Workload management**: HPA connects to Deployments, ReplicaSets, and the metrics pipeline (Prometheus/metrics-server) +- **Resource management**: VPA relates to resource requests/limits and scheduling +- **Monitoring**: Autoscaling decisions depend on metrics collected via the OpenShift monitoring stack + +## Exam-Relevant Points +- Know the distinction between **HorizontalPodAutoscaler** (scales replicas) vs **ClusterAutoscaler** (scales nodes) vs **MachineAutoscaler** (scales MachineSets) +- ClusterAutoscaler is a **cluster-scoped singleton** resource; MachineAutoscaler references a specific MachineSet +- HPA is a **namespaced** resource that targets a scalable workload (Deployment, ReplicaSet, etc.) +- Autoscale APIs are part of the OpenShift API surface and can be managed via `oc` CLI or YAML manifests + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-backup.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-backup.md new file mode 100644 index 0000000000000000000000000000000000000000..558b8af31fb00cf40d9132ffb5f072f192d0c173 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-backup.md @@ -0,0 +1,49 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/backup-restore-overview +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-backup.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:30 + +## Overview +This page covers the two main categories of backup and restore in OpenShift Container Platform 4.17: **control plane backup/restore** (centered on etcd) and **application backup/restore** (using OADP/Velero). It describes when and why backups are needed, the tools involved, and the requirements for each approach. + +## Key Concepts +- **etcd** is the key-value store that persists the state of all resource objects in OpenShift — backing it up is essential for disaster recovery +- **Graceful shutdown/restart** — clusters can be stopped and restarted; etcd must be backed up *before* shutdown +- **Cluster certificates expire one year after installation** — expired control plane certs are auto-retrieved, but CSRs must still be manually approved +- **OADP (OpenShift API for Data Protection)** — the supported method for application-level backup and restore; built on Velero +- **OADP operates at namespace granularity** — backs up Kubernetes resources, internal images, and persistent volumes +- **PV backup methods**: native cloud snapshots, CSI snapshots, or file-system backup (Kopia/Restic) +- **Restic** is installed by default with the OADP Operator as a non-snapshot PV backup option +- **CloudStorage API for S3** is Technology Preview only — not supported for production +- **OADP 1.1.x** is required for CSI backup on OCP 4.11+; OADP 1.0.x uses `snapshot.storage.k8s.io/v1beta1` which is absent on 4.11+ + +## Commands and Syntax +- **Backup CR** — create a `Backup` custom resource to back up applications +- **Restore CR** — create a `Restore` custom resource to restore applications +- **Backup hooks** — run commands before/after backup operations +- **Restore hooks** — run commands in init containers or app containers during restore +- **Scheduled backups** — configurable through OADP + +## Relationships +- **etcd** ↔ control plane health, quorum, disaster recovery +- **OADP** ↔ Velero, CSI, storage providers (AWS, Azure, GCP, ODF, Ceph) +- **Machine lifecycle hooks** — quorum protection during machine deletion relates to etcd member management +- **Certificate management** — cluster restart depends on cert validity; ties to CSR approval process +- **Graceful shutdown/restart** — prerequisite workflow before/after etcd backup + +## Exam-Relevant Points +- You **must** back up etcd before shutting down a cluster +- etcd backup is used to restore cluster state after disaster (quorum loss, accidental deletion, node failure) +- Cluster certificates expire **one year** after installation +- OADP requires **cluster-admin** role and **object storage** (S3-compatible, AWS, Azure, GCP, ODF, IBM Cloud) +- OADP uses **Velero** under the hood +- For CSI snapshots on OCP 4.11+, you need **OADP 1.1.x** (not 1.0.x) +- Restic/Kopia is the alternative when snapshot APIs are unavailable +- CloudStorage API for S3 is **Technology Preview** — not production-supported +- Three disaster scenarios: non-functional cluster after restart, accidental deletion, control plane host loss (etcd quorum loss) +- You can replace an unhealthy etcd member without full cluster restore + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-contro.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-contro.md new file mode 100644 index 0000000000000000000000000000000000000000..643c691ec62a363e4246cfa74e0e9ea7d85298fd --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-contro.md @@ -0,0 +1,120 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/control-plane-backup-and-restore +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-contro.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:30 + +## Overview +This page covers the procedures for backing up and restoring the etcd key-value store in OpenShift Container Platform 4.17. etcd persists the state of all resource objects in the cluster. The page details manual backup procedures, automated backup (Technology Preview), and disaster recovery scenarios including restoring to a previous cluster state and recovering from expired control plane certificates. + +## Key Concepts +- **etcd** is the key-value store that persists the state of all OpenShift resource objects +- Backups should be stored in a secure location **outside** the OCP environment +- **Do not** take an etcd backup before the first certificate rotation (24 hours after install) — backup will contain expired certificates +- Take backups during **non-peak hours** due to high I/O cost of etcd snapshots +- **Only back up from a single control plane host** — do not take backups from each control plane host +- Backup must match the **same z-stream release** for restore (e.g., 4.17.5 backup for 4.17.5 cluster) +- Backup produces two files: + - `snapshot_.db` — the etcd snapshot + - `static_kuberesources_.tar.gz` — static pod resources (and encryption keys if etcd encryption is enabled) +- If etcd encryption is enabled, store the static resources file **separately** from the snapshot for security; however, it is **required** to restore +- etcd encryption only encrypts **values**, not keys (resource types, namespaces, object names remain unencrypted) +- **Automated etcd backups** are a Technology Preview feature requiring `TechPreviewNoUpgrade` feature gate +- Enabling `TechPreviewNoUpgrade` **prevents minor version updates** and **cannot be disabled** +- Retention types for automated backups: `RetentionNumber` (default: 15 backups) or `RetentionSize` + +## Commands and Syntax + +### Manual etcd Backup +```bash +# 1. Start debug session on control plane node +oc debug --as-root node/ + +# 2. Chroot to host filesystem +chroot /host + +# 3. (If proxy enabled) Export proxy variables +export HTTP_PROXY=http://:8080 +export HTTPS_PROXY=https://:8080 +export NO_PROXY= + +# 4. Run backup script +/usr/local/bin/cluster-backup.sh /home/core/assets/backup +``` + +### Check if cluster-wide proxy is enabled +```bash +oc get proxy cluster -o yaml +``` + +### Enable Automated Backups (Tech Preview) +```yaml +apiVersion: config.openshift.io/v1 +kind: FeatureGate +metadata: + name: cluster +spec: + featureSet: TechPreviewNoUpgrade +``` + +### Single Automated Backup CR +```yaml +apiVersion: operator.openshift.io/v1alpha1 +kind: EtcdBackup +metadata: + name: etcd-single-backup + namespace: openshift-etcd +spec: + pvcName: etcd-backup-pvc +``` + +### Recurring Backup CR +```yaml +apiVersion: config.openshift.io/v1alpha1 +kind: Backup +metadata: + name: etcd-recurring-backup +spec: + etcd: + schedule: "20 4 * * *" # cron schedule + timeZone: "UTC" + pvcName: etcd-backup-pvc +``` + +### Cloud Provider Storage Classes for Recurring Backups +| Provider | accessModes | storageClassName | +|----------|-------------|------------------| +| AWS | ReadWriteMany | efs-sc | +| Google Cloud | ReadWriteMany | filestore-csi | +| Azure | ReadWriteMany | azurefile-csi | + +### Verify backup CRDs exist +```bash +oc get crd | grep backup +``` + +## Relationships +- **etcd Cluster Operator** — maintains the `cluster-backup.sh` script (wrapper around `etcdctl snapshot save`) +- **Disaster Recovery** — backup is prerequisite for restoring cluster state +- **Certificate Rotation** — first rotation at 24 hours post-install; backups before this are invalid +- **Cluster Updates** — always take etcd backup before upgrading; restore requires matching z-stream version +- **etcd Encryption** — affects what's included in the static resources tar file +- **FeatureGate / TechPreviewNoUpgrade** — required for automated backup feature; blocks minor version upgrades +- **PersistentVolumes/PVCs** — automated backups require storage provisioning in the `openshift-etcd` namespace +- **Static Pods** — backup includes kube-apiserver, kube-controller-manager, kube-scheduler, and etcd pod resources + +## Exam-Relevant Points +- etcd backup must be taken from **only one** control plane host, not all +- The backup script path is `/usr/local/bin/cluster-backup.sh` +- You must `oc debug --as-root node/` then `chroot /host` before running the backup +- Do **not** back up before the first certificate rotation (24 hours after install) +- Restore requires a backup from the **same z-stream release** +- Two files are produced: a `.db` snapshot and a `.tar.gz` of static pod resources +- Automated backups require `TechPreviewNoUpgrade` feature gate — this is **irreversible** and blocks minor version updates +- The `EtcdBackup` CR (single) uses API `operator.openshift.io/v1alpha1`; the `Backup` CR (recurring) uses `config.openshift.io/v1alpha1` +- PVC for etcd backups must be in the `openshift-etcd` namespace +- Retention types: `RetentionNumber` (default 15) or `RetentionSize` + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-gracef.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-gracef.md new file mode 100644 index 0000000000000000000000000000000000000000..9580ca43bd7e476aca6b1aea2d211ea46e5fe0cc --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-gracef.md @@ -0,0 +1,88 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/graceful-restart-cluster +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-gracef.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:30 + + + +## Overview +This page describes the procedure to gracefully restart an OpenShift Container Platform 4.17 cluster after it has been gracefully shut down. It covers powering on nodes, uncordoning them, approving pending CSRs, and verifying cluster health. It also notes conditions under which the cluster may fail to recover (etcd corruption, hardware failure, network issues) and points to the etcd restore procedure as a fallback. + +## Key Concepts +- A graceful restart assumes a prior **graceful shutdown** was performed +- The cluster **may not recover** even after a graceful restart due to etcd data corruption, node hardware failure, or network connectivity issues +- **Control plane nodes must come up first**, then worker nodes +- Nodes are **cordoned** during shutdown and must be **uncordoned** during restart to become schedulable +- **Certificate Signing Requests (CSRs)** may be pending after restart and must be manually approved for nodes to reach `Ready` state +- If `admin.kubeconfig` is unavailable, the **`localhost-recovery.kubeconfig`** file on a control plane node can be used as an alternative +- Wait approximately **10 minutes** after starting machines before checking control plane node status +- Cluster health is verified by checking that all **ClusterOperators** are not degraded and all nodes are `Ready` + +## Commands and Syntax + +**Uncordon a specific node:** +```bash +oc adm uncordon +``` + +**Check control plane node status:** +```bash +oc get nodes -l node-role.kubernetes.io/master +``` + +**Check worker node status:** +```bash +oc get nodes -l node-role.kubernetes.io/worker +``` + +**List pending CSRs:** +```bash +oc get csr +``` + +**Inspect a CSR:** +```bash +oc describe csr +``` + +**Approve a CSR:** +```bash +oc adm certificate approve +``` + +**Uncordon all nodes at once:** +```bash +for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done +``` + +**Verify cluster operators:** +```bash +oc get clusteroperators +``` + +**Verify all nodes:** +```bash +oc get nodes +``` + +## Relationships +- **Graceful shutdown** — this procedure is the counterpart; shutdown must precede restart +- **etcd backup and restore** — if restart fails, the fallback is restoring cluster state from an etcd backup +- **CSR approval** — ties into node certificate management and the kubelet certificate rotation mechanism +- **ClusterOperators** — post-restart health check relies on the ClusterOperator status framework (AVAILABLE, PROGRESSING, DEGRADED) +- **Node scheduling** — uses the cordon/uncordon mechanism shared with node maintenance workflows + +## Exam-Relevant Points +- The restart order is: **control plane nodes first, then worker nodes** +- You must **uncordon** nodes after restart — they remain cordoned from the graceful shutdown +- If nodes are not `Ready`, check for **pending CSRs** and approve them with `oc adm certificate approve` +- The label selector for control plane nodes is `node-role.kubernetes.io/master`; for workers it is `node-role.kubernetes.io/worker` +- Use `oc get clusteroperators` to verify no operator has `DEGRADED=True` after restart +- The `localhost-recovery.kubeconfig` file is the alternative credential when `admin.kubeconfig` is unavailable +- If the cluster fails to recover, **restore from etcd backup** is the documented recovery path +- The `cluster-admin` role is required to perform this procedure + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-index.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-index.md new file mode 100644 index 0000000000000000000000000000000000000000..a087c926e9797ab435b5564509b91a602274b0a8 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-index.md @@ -0,0 +1,39 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/index +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-index.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:31 + +## Overview +This is the landing page for the **Backup and Restore** section of OpenShift Container Platform 4.17 documentation. It serves as an index for instructions on backing up cluster data and recovering from various disaster scenarios. The actual detailed content lives in sub-pages. + +## Key Concepts +- **Backup and restore** is a top-level documentation category in OpenShift, indicating its importance to cluster operations +- Covers both **backing up cluster data** and **recovering from disaster scenarios** +- Applies to OpenShift Container Platform 4.17 (with versions available back to 3.x) +- This is a multi-page documentation set (available in multi-page, single-page, and PDF formats) + +## Commands and Syntax +No commands or configuration syntax are present on this index page. Detailed procedures are in child pages covering topics such as: +- etcd backup and restore +- Application backup via OADP (OpenShift API for Data Protection) +- Control plane recovery +- Disaster recovery procedures + +## Relationships +- **etcd**: The primary datastore for cluster state; etcd backup/restore is the core of cluster-level backup +- **OADP (OpenShift API for Data Protection)**: The supported solution for application-level backup and restore, built on Velero +- **Disaster recovery**: Procedures for recovering from scenarios like lost control plane nodes or corrupted etcd +- **Cluster administration**: Backup and restore is a critical cluster-admin responsibility +- **Storage / Persistent Volumes**: Application data protection depends on storage provider snapshot capabilities + +## Exam-Relevant Points +- Backup and restore is a **distinct top-level topic** in OpenShift — expect exam questions on it +- Know the difference between **cluster-level backup** (etcd snapshots) and **application-level backup** (OADP/Velero) +- etcd backup is the primary mechanism for protecting cluster state (API objects, configuration) +- OADP is the Red Hat-supported operator for backing up application workloads and persistent volumes +- Disaster recovery procedures are documented for multiple failure scenarios (this suggests scenario-based exam questions) + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-legal-.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-legal-.md new file mode 100644 index 0000000000000000000000000000000000000000..3d6c14ef4d37b1860b817bcfada28ea87e45c740 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-legal-.md @@ -0,0 +1,13 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/legal-notice +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-legal-.md +--- +# En Documentation Openshift_Container_Platform 417 Html Backup_And_Restore Legal + +**Date:** 2026-03-05 +**Time:** 13:31 + +This is just the Legal Notice page for OpenShift Container Platform documentation. It contains no technical content — only copyright, licensing (Apache 2.0), and trademark attributions. There's nothing worth summarizing for study notes or domain expertise. + +**Skip this page** — it has no exam-relevant or technical content. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-oadp-a.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-oadp-a.md new file mode 100644 index 0000000000000000000000000000000000000000..b225ab672c5bc742a81e1a3640b884973ba0f622 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore-oadp-a.md @@ -0,0 +1,81 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/oadp-application-backup-and-restore +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore-oadp-a.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:31 + +## Overview +This page covers the OpenShift API for Data Protection (OADP), Red Hat's solution for backing up and restoring customer applications on OpenShift Container Platform. OADP protects applications, cluster resources, persistent volumes, internal images, and virtual machines. It is built on top of Velero and supports multiple backup strategies including CSI snapshots, file system backups, and the Data Mover feature. + +## Key Concepts +- **OADP** safeguards customer workloads but is **not** a disaster recovery solution for etcd or OpenShift Operators +- **Full cluster backup and restore are not supported** — only workload namespaces and cluster-scoped resources +- OADP provides five core APIs: **Backup**, **Restore**, **Schedule**, **BackupStorageLocation**, **VolumeSnapshotLocation** +- **Data Mover** enables moving snapshots to remote object storage (uses Kopia under the hood) +- **Velero** is the upstream project; OADP 1.4 uses Velero 1.14 +- **Kopia** is used for file system backup and data mover operations; supports configurable hash, encryption, and splitter algorithms +- **VolumePolicy** feature allows backing up different volumes in the same namespace with `skip`, `snapshot`, or `fs-backup` actions +- **CSI snapshots** are the preferred PV backup method; the CSI plugin is now built into Velero (no init container needed as of OADP 1.4) +- **BackupStorageLocation (BSL)** defines where backup data is stored (S3-compatible, Azure, GCP) +- **DataProtectionApplication (DPA)** is the primary CR for configuring OADP +- OADP installs in the `openshift-adp` namespace by default +- `must-gather` tool collects OADP diagnostic data and generates a Markdown summary (as of 1.4.5) + +## Commands and Syntax + +**Save DPA configuration before upgrade:** +```bash +oc get dpa -n openshift-adp -o yaml > dpa.orig.backup +``` + +**Two-step restore workaround (for Deployments referencing ImageStreams):** +```bash +# Step 1: Restore excluding Deployments +velero restore create \ + --from-backup \ + --exclude-resources=deployment.apps + +# Step 2: Restore only Deployments +velero restore create \ + --from-backup \ + --include-resources=deployment.apps +``` + +**Verify OADP upgrade:** +```bash +oc get dpa -n openshift-adp -o yaml +``` + +**DPA fields for tuning:** +- `spec.configuration.velero.client-qps` (default: 100) +- `spec.configuration.velero.client-burst` (default: 100) +- `spec.containerImagePullPolicy` — overrides image pull policy +- `spec.backupLocations[].velero.config.checksumAlgorithm` — checksum config for BSL + +## Relationships +- **etcd backup** is separate from OADP — etcd uses its own backup/restore mechanism +- **Velero** is the upstream engine; OADP wraps it with OpenShift integration +- **CSI drivers** are required for CSI snapshot-based backups +- **Kopia** handles file system backup and data mover repository operations +- **OpenShift Virtualization (KubeVirt)** — OADP can back up VMs via the `kubevirt` Velero plugin (v0.7.1 in OADP 1.4.3) +- **OLM (Operator Lifecycle Manager)** manages OADP Operator installation and upgrades via subscription channels +- **ImageStreams** can cause restore issues with Deployments due to trigger-based pod rollouts + +## Exam-Relevant Points +- OADP does **not** back up etcd or Operators — these require separate procedures +- Full cluster backup/restore is **not supported** +- OADP version support matrix: **OADP 1.4** supports OCP 4.14–4.17; **OADP 1.3** supports OCP 4.12–4.15 +- Upgrades must be sequential — **never skip minor versions** (1.1→1.2→1.3→1.4) +- Default namespace is `openshift-adp` +- OADP 1.4 changed default `checksumAlgorithm` from `""` to `CRC32` in upstream, but DPA-created BSLs default to `""` for backward compatibility +- Velero client QPS/burst defaults changed from 30/20 to 100/100 in OADP 1.4 +- CSI plugin no longer requires a separate init container in OADP 1.4 +- When using Noobaa (MCG) as backup location, `checksumAlgorithm` must be explicitly set or left empty +- Known issue: Cassandra pods may enter `CrashLoopBackoff` after restore — fix by deleting affected StatefulSet pods +- `resourceTimeout` Velero argument can resolve `context deadline exceeded` errors during large-scale restores +- DPA namespace names longer than 37 characters previously caused labeling failures (fixed in 1.4.1) +- `must-gather` data must be attached to all customer support cases + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore.md new file mode 100644 index 0000000000000000000000000000000000000000..b323718df92b24a7f0f84736b018f090ea47543c --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-backup_and_restore.md @@ -0,0 +1,38 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore +source: sources/en-documentation-openshift_container_platform-417-html-backup_and_restore.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:32 + +## Overview +This is the top-level landing page for the **Backup and Restore** section of OpenShift Container Platform 4.17 documentation. It introduces the overall topic of backing up cluster data and recovering from disaster scenarios. The page itself serves as an index to more detailed sub-topics rather than containing substantive technical content. + +## Key Concepts +- **Backup and restore** is a first-class operational concern in OpenShift Container Platform +- The scope covers both **backing up cluster data** and **recovering from disaster scenarios** +- This applies to OCP 4.17 (and is available across many versions from 3.x through 4.x) + +## Commands and Syntax +No specific commands or configuration syntax are provided on this index page. Detailed procedures are found in the child pages covering: +- etcd backup and restore +- Application backup (typically via OADP — OpenShift API for Data Protection) +- Control plane recovery +- Disaster recovery procedures + +## Relationships +- **etcd**: The primary backing store for all cluster state; etcd backup is the core of cluster backup +- **OADP (OpenShift API for Data Protection)**: The supported method for backing up and restoring applications, built on Velero +- **Disaster Recovery**: Closely related — restore procedures are the response to disaster scenarios +- **Cluster Administration**: Backup and restore is a key cluster-admin responsibility +- **Storage / Persistent Volumes**: Application data on PVs must be backed up separately from cluster state + +## Exam-Relevant Points +- Know that **etcd backup** is the fundamental cluster-level backup mechanism in OpenShift +- Understand the difference between **cluster backup** (etcd/control plane) and **application backup** (OADP/Velero) +- Backup and restore is a documented operational procedure — expect questions on when and how to perform etcd snapshots +- OADP is the Red Hat-supported solution for application-level backup and restore on OpenShift +- Disaster recovery scenarios (e.g., loss of control plane nodes) require etcd restore procedures + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-app.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-app.md new file mode 100644 index 0000000000000000000000000000000000000000..16b0763caf477c059293f81fabdae2566afd58e3 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-app.md @@ -0,0 +1,107 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/building_applications/application-health +source: sources/en-documentation-openshift_container_platform-417-html-building_applications-app.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:32 + + + +## Overview + +This page covers how to monitor application health in OpenShift Container Platform 4.17 using health check probes. It explains the three types of probes (readiness, liveness, and startup), the three test mechanisms (HTTP GET, container command, TCP socket), configurable probe parameters, and how to set up and manage health checks via both the CLI and the Developer perspective in the web console. + +## Key Concepts + +- **Readiness probe** — determines if a container is ready to accept service requests. On failure, the kubelet removes the pod from available service endpoints; on recovery, it re-adds it. +- **Liveness probe** — determines if a container is still running. On failure, the kubelet kills the container; the pod then responds based on its `restartPolicy` (`Always` or `OnFailure` → restart). +- **Startup probe** — indicates whether the application within a container has started. All other probes are disabled until the startup probe succeeds. If it doesn't succeed in time, the container is killed per `restartPolicy`. +- **Probe test types:** + - **HTTP GET** — succeeds if HTTP response code is between 200–399. Supports `scheme` (HTTP/HTTPS), `path`, `port`, `httpHeaders`. + - **Container Command (`exec`)** — succeeds if the command exits with status `0`. + - **TCP Socket** — succeeds if a TCP connection can be established on the specified port. +- **Probe parameters and defaults:** + - `initialDelaySeconds` — delay before first probe (default: `0`) + - `periodSeconds` — interval between probes (default: `10`; must be > `timeoutSeconds`) + - `timeoutSeconds` — probe timeout (default: `1`; must be < `periodSeconds`) + - `successThreshold` — consecutive successes to reset status (default: `1`; **must be `1` for liveness probes**) + - `failureThreshold` — allowed failures before action (default: `3`) +- **Failure consequences by probe type:** + - Liveness → container is restarted + - Readiness → pod is marked `Unready` + - Startup → container is killed, subject to `restartPolicy` +- You **cannot** use the CLI to add or edit health checks for an existing pod — you must edit the `DeploymentConfig` object or use the Developer web console. + +## Commands and Syntax + +**Creating a pod with health checks:** +```bash +oc create -f .yaml +``` + +**Verifying health check status:** +```bash +oc describe pod my-application +``` + +**Combined probe example (all three probe types on one container):** +```yaml +spec: + containers: + - name: my-container + image: registry.k8s.io/goproxy:0.1 + livenessProbe: + tcpSocket: + port: 8080 + initialDelaySeconds: 15 + periodSeconds: 20 + timeoutSeconds: 10 + readinessProbe: + httpGet: + host: my-host + scheme: HTTPS + path: /healthz + port: 8080 + startupProbe: + exec: + command: + - cat + - /tmp/healthy + failureThreshold: 30 + periodSeconds: 20 + timeoutSeconds: 10 +``` + +**Startup probe to delay liveness probe (slow-starting apps):** +```yaml +startupProbe: + httpGet: + path: /healthz + port: 8080 + failureThreshold: 30 + periodSeconds: 10 +# Max startup time: 30 × 10s = 300s (5 minutes) +``` + +## Relationships + +- **Pods and Deployments** — probes are defined in pod specs within Deployments or DeploymentConfigs. +- **Services and Endpoints** — readiness probes directly affect whether a pod receives traffic via Services (kubelet manages endpoint list). +- **Restart Policies** — liveness and startup probe failures interact with `restartPolicy` (`Always`, `OnFailure`, `Never`). +- **Developer Perspective / Topology View** — the web console provides GUI-based probe management and health check failure monitoring under the Observe tab. +- **Scheduling and Resource Management** — probes inform the platform about container health, which affects rolling deployments, scaling decisions, and self-healing behavior. + +## Exam-Relevant Points + +- Know the three probe types and their distinct behaviors: readiness (removes from endpoints), liveness (kills/restarts container), startup (gates other probes). +- Know the three test mechanisms: HTTP GET (200–399 = success), exec command (exit 0 = success), TCP socket (connection = success). +- `timeoutSeconds` must be **lower** than `periodSeconds`. +- `successThreshold` **must be 1** for liveness probes. +- Default values: `initialDelaySeconds=0`, `periodSeconds=10`, `timeoutSeconds=1`, `successThreshold=1`, `failureThreshold=3`. +- Startup probe formula: `failureThreshold × periodSeconds` = maximum startup time allowed. +- You cannot add health checks to an existing pod via CLI — must edit the DeploymentConfig or use the web console. +- HTTP GET probe default scheme is `HTTP`; when `host` is not defined, `PodIP` is used. +- If `initialDelaySeconds` < `periodSeconds`, the first readiness probe may fire at an unpredictable time between the two values. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-bui.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-bui.md new file mode 100644 index 0000000000000000000000000000000000000000..c2d0773258f9141a8d10d39bfe4d9ba3b879f14f --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-bui.md @@ -0,0 +1,42 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/building_applications/building-applications-overview +source: sources/en-documentation-openshift_container_platform-417-html-building_applications-bui.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:32 + +## Overview +This page provides a high-level overview of building applications in OpenShift Container Platform 4.17, covering the lifecycle from project creation through application deployment, including the tools (web console, CLI, Operators) and resources (Deployments, Helm) available for each stage. + +## Key Concepts +- **Projects** are the organizational unit for managing applications in isolation; they control access, roles, and resource boundaries. +- Applications can be created from multiple sources: **Git repositories, JAR files, devfiles, developer catalog, Operators, source/binary code, images, and templates**. +- Three primary interfaces for application management: **Developer perspective (web console)**, **OpenShift CLI (`oc`)**, and **installed Operators**. +- **Idling** allows cluster administrators to reduce resource consumption by scaling down unused application resources. +- **Red Hat Marketplace** provides certified container-based software for both public cloud and on-premise environments. + +## Commands and Syntax +- No specific commands shown on this overview page; it references deeper docs for: + - Project creation/management via CLI (including impersonation for creating projects as a different user) + - Application creation via `oc` CLI + - Deployment management via `Deployment` and `DeploymentConfig` objects + +## Relationships +- **Projects** → prerequisite for application creation; tied to RBAC (roles and permissions) +- **Deployments / DeploymentConfig** → mechanism for running applications; connects to deployment strategies +- **Helm** → alternative deployment method for applications and services +- **Operators** → installed by cluster admins; used to create applications from the web console +- **Monitoring** → post-deployment activity using Developer perspective metrics +- **Self-provisioning** → cluster admin can disable authenticated users from creating their own projects + +## Exam-Relevant Points +- You **must have a project** (or access to one with appropriate roles) before creating an application. +- Applications can be created via **three methods**: Developer perspective, CLI (`oc`), or installed Operators. +- Cluster admins can **prevent self-provisioning** of new projects by authenticated user groups. +- Project provisioning uses a **customizable template** via an API endpoint. +- **`Deployment` and `DeploymentConfig`** are the two object types for deploying applications. +- **Idling scalable resources** is an admin function to reduce resource consumption for idle applications. +- Deployment strategies are used to **reduce downtime** during application changes or upgrades. + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-con.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-con.md new file mode 100644 index 0000000000000000000000000000000000000000..e2425c53b31e2e22e0697d237eef76a7251f26a2 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-con.md @@ -0,0 +1,96 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/building_applications/config-maps +source: sources/en-documentation-openshift_container_platform-417-html-building_applications-con.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:33 + +## Overview +ConfigMaps in OpenShift Container Platform provide a mechanism to decouple configuration data from container images, keeping applications portable. They store key-value pairs that can be consumed by pods as environment variables, command-line arguments, or mounted configuration files in volumes. + +## Key Concepts +- **ConfigMap** is a Kubernetes/OpenShift object that holds key-value pairs of configuration data +- Supports both text data (`data` field) and binary data (`binaryData` field, Base64-encoded) +- Similar to Secrets, but designed for non-sensitive string data +- Three consumption methods: environment variables, command-line arguments, volume mounts +- ConfigMaps are **namespace-scoped** — they can only be referenced by pods in the same project +- ConfigMaps **must be created before** pods that reference them (unless marked optional) +- Only pods created via the API server (CLI, replication controllers) can use ConfigMaps — not pods from `--manifest-url`, `--config` flag, or node REST API + +## Commands and Syntax + +**Creating a ConfigMap (YAML):** +```yaml +kind: ConfigMap +apiVersion: v1 +metadata: + name: example-config + namespace: my-namespace +data: + key1: value1 + key2: value2 +binaryData: + bar: L3Jvb3QvMTAw # Base64-encoded binary data +``` + +**Consuming as environment variables (individual keys):** +```yaml +env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: special.how + optional: true # pod starts even if key/configmap missing +``` + +**Consuming all keys as environment variables:** +```yaml +envFrom: + - configMapRef: + name: env-config +``` + +**Using in command-line arguments** (via Kubernetes substitution syntax): +```yaml +command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] +``` + +**Mounting as a volume (all keys become files):** +```yaml +volumes: + - name: config-volume + configMap: + name: special-config +``` + +**Mounting with custom paths:** +```yaml +volumes: + - name: config-volume + configMap: + name: special-config + items: + - key: special.how + path: path/to/special-key +``` + +## Relationships +- **Secrets**: ConfigMaps are analogous but for non-sensitive data; Secrets handle sensitive data with additional protections +- **Pods/Containers**: ConfigMaps are consumed by pods through env vars, args, or volume mounts +- **Volumes**: ConfigMap data can be projected into volumes as files +- **Projects/Namespaces**: ConfigMaps are scoped to a namespace and cannot be shared across projects +- **Replication Controllers/Deployments**: Pods created by controllers can consume ConfigMaps + +## Exam-Relevant Points +- ConfigMaps **must exist before** the pod starts (unless `optional: true` is set) +- ConfigMaps are **project/namespace-scoped** — cannot be referenced cross-namespace +- `env` + `configMapKeyRef` injects individual keys; `envFrom` + `configMapRef` injects all keys +- `optional: true` on a `configMapKeyRef` allows the pod to start even if the ConfigMap or key doesn't exist +- When mounted as a volume, each key becomes a filename and each value becomes file content +- The `items` field in a volume's `configMap` spec controls which keys are projected and their file paths +- `binaryData` field is used for non-UTF8 content (e.g., binary files), stored as Base64 +- ConfigMaps differ from Secrets in that they are designed for non-sensitive configuration data + diff --git a/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-cre.md b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-cre.md new file mode 100644 index 0000000000000000000000000000000000000000..bc893a26da768ddc7a6e89b4a53373f8d22747e4 --- /dev/null +++ b/entries/2026/03/05/en-documentation-openshift_container_platform-417-html-building_applications-cre.md @@ -0,0 +1,142 @@ +--- +source_url: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/building_applications/creating-applications +source: sources/en-documentation-openshift_container_platform-417-html-building_applications-cre.md +--- +# Overview + +**Date:** 2026-03-05 +**Time:** 13:33 + +## Overview +This page covers OpenShift Container Platform templates — a mechanism for defining, parameterizing, and instantiating sets of Kubernetes/OpenShift objects. It explains how to upload, use, modify, and write templates, including parameter handling, labels, descriptions, and exposing templates in the service catalog via the Template Service Broker. + +## Key Concepts +- A **template** describes a parameterized set of objects (services, build configs, deployment configs, etc.) that OCP can create +- Templates can be uploaded to a **project** or to the **global `openshift` project** for cluster-wide availability +- Templates support **parameters** with default values, descriptions, and auto-generation via regex-like expressions (`generate: expression`, `from: '[A-Z0-9]{8}'`) +- Parameters can be **required** (`required: true`) — processing fails if not supplied and no default/generator exists +- Template **labels** are applied to every object created from the template; labels support parameter expansion on both keys and values +- The **`message` field** displays instructional text after instantiation, supporting parameter substitution +- **Quick start templates** are pre-built examples (Rails, Django, Node.js, CakePHP, Dancer) that reference public GitHub repos +- Quick start database templates use **ephemeral storage** by default — data is lost on pod restart +- Image streams must have the `builder` tag in annotations to appear as builder images in the web console +- The **Template Service Broker** (TSB) exposes templates from the `openshift` project as services in the service catalog (deprecated in OCP 4.x but still documented) +- Templates can expose **infrastructure objects** (routes, services) via annotations like `expose` and `expose-with-route` + +## Commands and Syntax + +**Upload a template:** +```bash +oc create -f +oc create -f -n +``` + +**Process a template (generate object list):** +```bash +oc process -f +oc process +``` + +**Process and create objects in one step:** +```bash +oc process -f | oc create -f - +``` + +**Add labels during processing:** +```bash +oc process -f -l name=otherLabel +``` + +**List template parameters:** +```bash +oc process --parameters -f +oc process --parameters -n openshift +``` + +**Override parameters:** +```bash +oc process -f my-rails-postgresql -p POSTGRESQL_USER=bob -p POSTGRESQL_DATABASE=mydatabase +``` + +**Use a parameter file:** +```bash +oc process -f my-rails-postgresql --param-file=postgres.env +``` + +**Read params from stdin:** +```bash +sed s/bob/alice/ postgres.env | oc process -f my-rails-postgresql --param-file=- +``` + +**List available quick start templates:** +```bash +oc get templates -n openshift +``` + +**Edit an uploaded template:** +```bash +oc edit template