Cluster Installation And Management practice questions

Modify the ClusterVersion custom resource spec field.

Why it fails: The ClusterVersion resource controls the release version and channel of the OpenShift cluster, not node SSH keys.

Edit the kubelet configuration map in the kube-system namespace.

Why it fails: Kubelet configurations are managed via KubeletConfig custom resources, not direct ConfigMap edits, and SSH keys are handled via MachineConfig.

Update the authentication.config.openshift.io cluster operator resource.

Why it fails: The authentication cluster operator manages cluster-wide user authentication mechanisms, not node-level SSH access.

Inspect the clusteroperators object using 'oc describe clusteroperator base-os'.

Why it fails: The CVO's reconciling loops and errors appear in the ClusterVersion object and its operator conditions, not in a clusteroperator named base-os, which does not exist. Clusteroperators report individual component status, useful for identifying which operator is failing, not the CVO's own logic.

Check the cluster-wide events in the default namespace using 'oc get events'.

Why it fails: Cluster-wide events in the default namespace omit the CVO's reconciliation detail; the operator logs its errors in its own namespace. Events are tempting for quick triage of scheduling or image pull failures, yet they capture Kubernetes object events, not the CVO's internal reconcile loops, which require inspecting the cluster-version-operator pod.

Inspect the MachineConfigPool status in the openshift-machine-api namespace.

Why it fails: MachineConfigPool status reports node-level configuration rollout progress, not the Cluster Version Operator's own reconciliation. It is tempting because stalled MachineConfigPools often accompany upgrade stalls, and the openshift-machine-api namespace hosts machine controllers, but the CVO's detailed errors and reconcile loops live in the openshift-cluster-version namespace.

Console Operator

Why it fails: Console Operator manages the OpenShift web console interface.

Machine API Operator

Why it fails: Machine API provisions compute machines.

Cluster Version Operator

Why it fails: CVO manages the OpenShift platform version.

Static pods

Why it fails: Static pods are managed directly by the kubelet on the node and cannot be evicted via API node drain requests.

StatefulSet pods

Why it fails: StatefulSet pods are safely evicted one by one honoring ordering guarantees.

DaemonSet pods

Why it fails: DaemonSet pods are automatically ignored during drainage because they are managed node-locally and will be recreated when the node comes back.

Modify the kube-dns ConfigMap to trust external TLS certificates.

Why it fails: kube-dns handles cluster name resolution, not TLS certificate trust chains.

Update the OAuth custom resource with the CA bundle path.

Why it fails: The OAuth resource manages identity providers, not node-level container registry trust.

Restart the cluster proxy service with the '--ca-file' parameter.

Why it fails: OpenShift cluster services are managed via declarative operators, not manual command-line proxy restarts.

Placing the MachineConfig object directly inside the GPU namespace.

Why it fails: MachineConfigs are cluster-scoped resources, not namespaced.

A field in the spec named 'targetPool: gpu-worker'.

Why it fails: There is no 'targetPool' field in MachineConfig specs.

An annotation specifying 'machineconfigpool.openshift.io/target: gpu-worker'.

Why it fails: Targeting is performed via labels defined in the pool's nodeSelector, not annotations.

ClusterVersion mirror override parameter

Why it fails: ClusterVersion does not take direct mirror override parameters; registry redirection is handled at the container runtime level via ICSP/ITMS.

MachineConfig registry redirection file

Why it fails: While MachineConfig could write files, container runtime image mirroring is natively managed by ICSP/ITMS resources.

OperatorGroup mirror setting

Why it fails: OperatorGroup handles namespace scoping for OLM, not image registry mirroring.

Reboot each worker node into the previous GRUB menu entry manually via IPMI.

Why it fails: Manual GRUB rollbacks bypass the MCO and can cause state drift; MCO handles rollbacks declaratively via object deletion.

Run 'oc rollback machineconfigpool worker'.

Why it fails: MachineConfigPools do not have a rollback subcommand.

Run 'oc adm node-rollback --pool=worker'.

Why it fails: The 'oc adm node-rollback' command does not exist.

Set the MachineHealthCheck replica count to zero.

Why it fails: MachineHealthCheck resources do not use a replica count.

Stop the machine-api-operator deployment.

Why it fails: Stopping the entire operator is disruptive and unsupported; managing the MHC custom resource is the correct method.

Annotate every node with 'machinehealthcheck.openshift.io/enabled=false'.

Why it fails: MachineHealthChecks are controlled via the MHC resource spec, not node-level boolean annotations.

The kube-apiserver automatically patches the operator deployment to bypass version checks.

Why it fails: API servers do not bypass OLM version validation.

The operator runs inside a compatibility emulation container provided by the MCO.

Why it fails: MCO does not provide compatibility emulation containers for operators.

The Cluster Version Operator automatically downgrades the cluster Kubernetes API to match the Operator.

Why it fails: Core OpenShift cluster APIs are never automatically downgraded to accommodate third-party operators.

Modify the global ClusterVersion resource with the namespace-specific pull secret.

Why it fails: Global cluster pull secrets apply cluster-wide and do not support per-namespace custom overrides directly through ClusterVersion.

Edit the CatalogSource resource to inject credentials into the CSV.

Why it fails: CatalogSources provide package manifests, not namespace pod pull credentials.

Annotate the OperatorGroup with 'olm.openshift.io/pull-secret=true'.

Why it fails: OperatorGroups do not support pull-secret annotations.

Pull secrets cannot be updated on existing nodes; nodes must be destroyed and recreated.

Why it fails: The Machine Config Operator rolls out pull-secret changes by generating a new MachineConfig, draining and cordoning each node, then rebooting it — no destruction required. Recreating nodes is tempting because immutable infrastructure rebuilds are common elsewhere, but here it would needlessly discard workloads when an automated rolling update already handles propagation.

The Cluster Version Operator requires a manual cluster reboot command to push secrets.

Why it fails: The Cluster Version Operator manages cluster version and update payloads, not pull-secret distribution; no manual reboot command exists for this. It is tempting because the CVO does coordinate cluster-wide rollouts, but the Machine Config Operator performs the drain-and-reboot cycle automatically after detecting the updated secret in openshift-config.

The administrator must manually SSH into each worker node and run 'oc-update-pull-secret'.

Why it fails: No such 'oc-update-pull-secret' command exists, and manual SSH access contradicts OpenShift's declarative, operator-driven node management. It is tempting because administrators do edit the global secret directly with oc, but the Machine Config Operator then handles node propagation automatically via a new rendered MachineConfig and rolling reboot.

kubeletConfigSelector

Why it fails: kubeletconfigselector is used in KubeletConfig resources, not Subscriptions.

machineConfigPoolSelector

Why it fails: machineConfigPoolSelector is used for MCO-related configurations, not Subscriptions.

OperatorGroup namespace restriction rules

Why it fails: OperatorGroup handles OLM installation scope, not image mirroring.

MachineHealthCheck remediation timeout settings

Why it fails: MachineHealthCheck handles node health, not image mirroring.

ClusterVersion

Why it fails: ClusterVersion manages platform versions.

MachineSet

Why it fails: MachineSet manages compute machines.

MachineConfigPool

Why it fails: MachineConfigPool manages node OS configs.

Cluster Autoscaler Operator

Why it fails: The autoscaler is managed via custom resources, not as a primary standalone control plane operator of the core set.

Operator Lifecycle Manager (OLM)

Why it fails: OLM manages add-on operators rather than being a core platform operator itself (though installed by default).

oc cluster-version nodes

Why it fails: The 'cluster-version' subcommand does not support 'nodes'.

oc get machineconfigpools --nodes

Why it fails: The '--nodes' flag does not exist for machineconfigpools.

oc get clusteroperators --nodes

Why it fails: Cluster operators do not take a '--nodes' flag.

The kernel version applied to worker nodes in the pool.

Why it fails: Kernel versions are managed via MachineConfigs and MCO, not OperatorGroups.

The cluster upgrade channel and target release version.

Why it fails: Cluster upgrades are managed via ClusterVersion resources.

The cloud provider machine instance type (e.g., m5.xlarge).

Why it fails: Machine instance types are defined in MachineSets.

Set spec.channel to stable-4.14 and leave spec.upstream unchanged.

Why it fails: Changing or confirming the channel only controls which update graphs the Cluster Version Operator follows; it does not stop automatic updates. With a valid channel and no overrides, the CVO can still recommend and apply upgrades according to its defaults. The scenario requires explicitly preventing automatic application, so setting the channel alone does not satisfy the requirement.

Patch the ClusterVersion resource to add spec.desiredUpdate with the current version and set spec.channel to an invalid placeholder.

Why it fails: Using an invalid channel placeholder may cause the Cluster Version Operator to report invalid or unknown update channels and can degrade update recommendations. The supported method to stop automatic upgrades is not to corrupt the channel field, because that field is meant to select a valid update graph. This would create misleading ClusterVersion conditions and is not an acceptable configuration.

Patch the ClusterVersion resource to set spec.desiredUpdate to the current version and add an overrides entry that blocks the CVO.

Why it fails: Setting desiredUpdate to the current version can pin the cluster temporarily, but adding an overrides entry is intended to force component image overrides, not to block the CVO. Overrides bypass normal release payload resolution and are reserved for exceptional troubleshooting. This approach is not the supported way to disable automatic updates and could interfere with future upgrades.

openshift-install create cluster --dir=install-dir

Why it fails: This command initiates the cluster installation process, which includes generating ignition configs internally, but it does not allow the administrator to first customize and inspect the ignition configs. It is used for a fully automated installation, not for creating ignition configs as a separate step.

openshift-install create config --dir=install-dir

Why it fails: This command generates the install-config.yaml file, which is used as input for creating manifests and ignition configs. It does not produce ignition configs itself; it only creates the initial configuration file that must be edited before further steps.

openshift-install create manifests --dir=install-dir

Why it fails: This command creates the Kubernetes manifests for the cluster but does not generate ignition configs. It is used when the administrator wants to modify manifests before generating ignition configs, but it does not directly produce the ignition files needed for node provisioning.