Cluster Architecture, Installation & Configuration practice questions

kube-spray

Why it fails: Kube-spray is incorrect because it does not utilise etcd operators for cluster management, a specific requirement of the scenario. While kube-spray is an excellent tool for deploying highly available Kubernetes clusters on bare-metal servers using Ansible, it manages etcd directly rather than through an operator. It would be a suitable choice if the company preferred a robust, battle-tested Ansible-based deployment without the explicit need for operator-managed etcd.

minikube

Why it fails: Minikube is specifically designed for local development and testing, creating a single-node Kubernetes cluster within a virtual machine or directly on the host. It is unsuitable for deploying a multi-node, production-ready cluster on bare metal due to its inherent limitations in scalability, high availability, and resource management. Its primary purpose is to provide a quick, isolated environment for experimenting with Kubernetes APIs and applications.

kops

Why it fails: Kops is a powerful cluster lifecycle management tool primarily engineered for deploying and managing Kubernetes clusters on major cloud providers like AWS, GCP, and DigitalOcean. It deeply integrates with cloud-specific APIs to provision underlying infrastructure components such as EC2 instances, VPCs, and load balancers. Consequently, kops is fundamentally incompatible with bare-metal deployments, as it lacks the mechanisms to provision or interact with physical hardware resources outside of a cloud environment.

Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.

Why it fails: Upgrading the kubelet before upgrading kubeadm violates the Kubernetes upgrade workflow and can cause version skew issues, as kubeadm must always be upgraded first to manage the control plane components. Additionally, performing upgrades before draining the node risks unexpected workload disruption and pod eviction failures during the process.

Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.

Why it fails: Upgrading kubeadm before draining the node is not the recommended best practice because it risks control plane disruption while active workloads are still scheduled on the node. The node must be drained first to ensure a clean maintenance window before any package upgrades or control plane restarts are initiated by kubeadm.

Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.

Why it fails: Upgrading both kubeadm and the kubelet before draining the node is highly dangerous, as the kubelet upgrade requires restarting the kubelet service. Restarting the active kubelet on an undrained node can cause sudden pod terminations, unexpected state sync issues, and temporary service outages for running workloads.

The PodSecurityPolicy admission controller is not enabled.

Why it fails: If the PodSecurityPolicy admission controller were disabled, the API server would never evaluate PSP objects, and pod creation would be allowed regardless of any policy constraints. The fact that the pod is rejected with a specific PSP validation error proves the admission controller is actively enforced. Therefore, this is not the reason for the failure.

The PSP is not set to enforce read-only root filesystem.

Why it fails: The error message concerns the runAsNonRoot rule, which mandates that the container process run with a non-zero UID. A read-only root filesystem is controlled by a separate securityContext field (readOnlyRootFilesystem) and does not impact the UID of the process. Since the rejection is specifically about the user ID, this option misidentifies the cause.

The PSP is not being applied to the pod's service account.

Why it fails: In Kubernetes, a PSP must be authorized for the requesting user or service account via RBAC; if no PSP is applicable, the admission controller denies pod creation with a 'no providers available' style error, not with a rule-specific message. The presence of a runAsNonRoot violation indicates that a PSP was successfully selected and enforced. Thus the issue is not a missing application of the PSP, but a conflict between the PSP rule and the image's root user.

--cloud-controller-manager

Why it fails: --cloud-controller-manager is not a flag; it is a separate Kubernetes control plane component that runs cloud controller logic since v1.9. It takes flags like --cloud-provider and --cloud-config, but it is not passed to kubelet or API server. Confusing a component name with a kubelet flag indicates a misunderstanding: the question asks for the flag that enables cloud provider integration on the node, not the component that reconciles cloud resources.

--configure-cloud-routes

Why it fails: --configure-cloud-routes is a kube-controller-manager flag that instructs the cloud provider to set up routing rules for pods in the cluster, typically used with the --cloud-provider flag. It does not enable cloud provider support by itself; it only controls the route reconciliation behavior once the provider is already configured. This flag is about networking, not about turning on the cloud integration, so selecting it would leave the cluster without any provider awareness.

--cloud-config

Why it fails: --cloud-config is a flag that provides the path to a YAML or JSON file containing provider-specific configuration, such as credentials or region details, but it is not the flag that enables the integration. It must be used together with --cloud-provider or --cloud-controller-manager; on its own it does nothing. The presence of a config file cannot substitute for the explicit provider type flag, and many providers allow default settings without a config file, so this is not the main switch.

kubeadm upgrade plan v1.23.0

Why it fails: kubeadm upgrade plan does not accept a version argument; running 'kubeadm upgrade plan v1.23.0' triggers an error because the 'plan' subcommand is designed to display the available upgrade versions and the required steps without applying changes. To upgrade to a specific version, you must use 'kubeadm upgrade apply v1.23.0'.

kubeadm upgrade plan

Why it fails: kubeadm upgrade plan is the correct command to check which Kubernetes versions are available for upgrade and to display a detailed plan of the upgrade process, including the steps needed for control plane and worker nodes. It performs a dry-run inspection of the cluster and prints the upgrade path without making any changes.

kubeadm upgrade diff

Why it fails: kubeadm upgrade diff is not a real kubeadm subcommand. kubeadm does not provide a command named 'diff'; the actual subcommands under 'kubeadm upgrade' are 'apply', 'node', and 'plan'. Therefore, attempting to run this command will result in an unknown command error.

--client-cert-auth

Why it fails: The --client-cert-auth flag is a Boolean switch that tells etcd to require and verify client certificates, but it does not itself point to any certificate file. Without --trusted-ca-file to define the issuing authority, this flag cannot perform validation. Therefore, although relevant to TLS client authentication, it is not one of the certificate file flags the question asks about.

--peer-cert-file

Why it fails: --peer-cert-file is used in the separate peer TLS configuration that secures communication between etcd members for raft consensus, not for client connections. While it is a certificate file flag, it belongs to the --peer-cert-file/--peer-key-file/--peer-trusted-ca-file set. The question asks for etcd's client-facing TLS, so this flag is incorrect for that purpose.

Using the --hostname-override flag.

Why it fails: The --hostname-override flag instructs the kubelet to present a different hostname to the API server than the one returned by the operating system, commonly used to masquerade a node's identity in cluster metadata. However, it has no bearing on the IP address that kubelet auto-detects or registers in the Node object's status; hostname and IP are separately resolved and reported. Because the underlying issue is the node's reachable IP, overriding the hostname alone cannot correct a wrong node IP.

Setting the --address flag in kubelet command line.

Why it fails: The --address flag historically controlled the local bind address the kubelet used for its own HTTP server (port 10250), not the IP address advertised for the node in Kubernetes objects. In modern Kubernetes versions, this flag is deprecated and effectively ignored—binding is now driven by the kubelet's configuration file or derived from --node-ip. Therefore, setting --address will not influence the node's status IP, and attempting to configure the node IP this way is invalid, especially since the deprecation makes it non-functional.

Setting the node-ip in the kubeadm-config ConfigMap.

Why it fails: The kubeadm-config ConfigMap (typically kubeadm-config in the kube-system namespace) stores the original InitConfiguration and ClusterConfiguration used to bootstrap the cluster with kubeadm. While it contains fields like localAPIEndpoint and nodeName, there is no runtime node-ip key that the kubelet reads live; the kubelet consumes its own configuration file (KubeletConfiguration) and command-line flags at startup. Editing this ConfigMap after the cluster is running does not change the kubelet's behavior, so it cannot be used to configure or correct the node's IP address.

Store the audit policy in a ConfigMap and reference it via --audit-policy-configmap.

Why it fails: There is no such kube-apiserver flag as --audit-policy-configmap; the API server accepts audit policies only as a YAML file path via --audit-policy-file. While you could store a policy in a ConfigMap, you would have to mount that ConfigMap as a file and then reference the mounted file path, not the ConfigMap object itself. Using a nonexistent flag would cause the API server to fail to start.

Restart the kubelet on the control plane node.

Why it fails: The kube-apiserver runs as a static pod on the control plane, managed by the kubelet, but restarting the kubelet does not restart the apiserver. Changes to audit configuration are made by editing the static pod manifest (e.g., /etc/kubernetes/manifests/kube-apiserver.yaml), and the kubelet detects the change and recreates the pod automatically. A kubelet restart is unnecessary for this task and could temporarily affect node management.

Use kubectl create node command from the control plane

Why it fails: There is no kubectl create node command in Kubernetes. The kubectl CLI does not expose an API action to directly create a Node object; nodes are automatically registered when a kubelet contacts the API server with valid credentials. Attempting to run this command will result in an error, and it is not a recognized way to add a worker.

Install kubelet on the worker node and it will automatically join the cluster

Why it fails: Simply installing the kubelet binary on a standalone machine does not cause it to join a cluster. The kubelet must be explicitly configured with the API server endpoint, the cluster CA, and some form of authentication, such as a bootstrap token or a pre-existing kubeconfig file. Without these, the kubelet does not know which cluster to contact and cannot authenticate its registration request, so it fails to join.

Run kubeadm init on the worker node and then join

Why it fails: kubeadm init is used to initialize a control-plane node, not a worker. It sets up the API server, etcd, controller-manager, scheduler, and other control-plane components, and it generates cluster certificates and configuration. On a worker node, you should use kubeadm join with a token provided by the control plane; running kubeadm init on the worker would incorrectly attempt to create a second control plane, which is not a valid way to join as a worker.

The node has insufficient memory

Why it fails: A node suffering from memory pressure would have the MemoryPressure condition set to True, but the exhibit explicitly shows MemoryPressure is False. Kubelet evaluates memory pressure based on eviction thresholds (e.g., memory.available) and reports it as a condition in NodeStatus. Even when MemoryPressure is True, the Ready condition typically remains True—the node is still able to post status; the pressure only triggers pod eviction. Since MemoryPressure is False here, insufficient memory cannot be the cause of the Unknown Ready condition.

The node is experiencing disk pressure

Why it fails: Disk pressure would manifest as the DiskPressure condition being True in NodeStatus, but the exhibit explicitly shows DiskPressure is False. Kubelet monitors filesystem usage on node roots and image filesystems against eviction thresholds (e.g., ephemeral-storage) and sets DiskPressure when limits are exceeded. Like MemoryPressure, DiskPressure being True does not change the Ready condition to Unknown; it primarily causes the kubelet to evict pods to free storage. With DiskPressure False, inadequate disk space is ruled out as the reason for worker2's unhealthy state.

The network plugin (Calico) is not running on worker2

Why it fails: The NetworkUnavailable condition reflects the network plugin's status, and the exhibit shows it is False, meaning the Calico network plugin is operational and has successfully configured pod networking on worker2. If Calico were down or failing to start, NetworkUnavailable would be True, and this would affect pod connectivity, not the kubelet's ability to report to the control plane. The kubelet posts NodeStatus directly to the API server using a secure connection; the network plugin is irrelevant to that heartbeat. Thus Calico is not the cause of the Unknown Ready condition.

Skip draining the node and proceed with the kubelet upgrade

Why it fails: Correct. Skipping the drain allows the upgrade to proceed without evicting the DaemonSet pod, preserving its running state. The DaemonSet controller will handle the pod after the kubelet restart.

Add --delete-emptydir-data to the drain command

Why it fails: Adding --delete-emptydir-data is used for pods with emptyDir volumes, not for DaemonSet eviction issues.

Cordon the node and then run kubectl drain with --force

Why it fails: Using --force would forcefully terminate the DaemonSet pod, violating the requirement that it must remain running during the upgrade. This is not the best course of action.

Initialize control plane (kubeadm init), then Install container runtime, then Configure kubectl, then Install CNI plugin, then Join worker nodes

Why it fails: This sequence fails immediately because kubeadm init relies on a pre-installed container runtime, such as containerd, to pull and run the control plane components as static pods. Attempting to initialize the control plane before installing a CRI-compliant runtime will cause the pre-flight checks to fail and halt the installation process.

Install container runtime, then Install CNI plugin, then Initialize control plane (kubeadm init), then Configure kubectl, then Join worker nodes

Why it fails: Installing the Container Network Interface (CNI) plugin before initializing the control plane is impossible because CNI plugins are typically deployed as DaemonSets within the cluster. The Kubernetes API server must be fully operational and kubectl configured so that the CNI manifest can be applied to the cluster to establish pod-to-pod networking.

Install container runtime, then Initialize control plane (kubeadm init), then Join worker nodes, then Configure kubectl, then Install CNI plugin

Why it fails: Attempting to join worker nodes before configuring kubectl and installing a CNI plugin leads to a broken cluster state. Without a CNI plugin, CoreDNS pods will remain in a Pending state, and newly joined worker nodes will transition to a NotReady status because they lack the necessary network routing configuration to communicate.

Create the Service YAML, apply it, create the Deployment YAML, apply it, verify pods, verify endpoints

Why it fails: Applying the Service before the Deployment is a race condition: for the interval between the two applies, the Service's label selector matches zero pods, so the Endpoints (or EndpointSlice) objects contain no ready addresses and any client request fails with an unreachable backend error. Although the system will eventually populate endpoints after the Deployment's pods become Ready, this order creates an avoidable downtime window and forces a subsequent 'verify endpoints' step to confirm a state that could not have been true initially. It also makes troubleshooting harder because an empty endpoint list may be misread as a Service misconfiguration rather than a missing workload.

Create the Deployment YAML, apply it, create the Service YAML, apply it, verify pods, verify endpoints

Why it fails: The flaw here is that it delays pod verification until after the Service has already been applied, so the endpoints list can be empty simply because the pods are still pulling images, running init containers, or waiting on readiness probes—not because the Service is misconfigured. This order sets up a false alarm during verification: the 'verify endpoints' step may report zero backends even though the deployment is perfectly healthy. Checking pod readiness first is essential to distinguish a Service problem from a workload-that-is-still-initializing problem.

Create the Service YAML, apply it, verify endpoints, create the Deployment YAML, apply it, verify pods

Why it fails: This order guarantees that the first endpoint verification fails because no Deployment exists to supply pods matching the Service's selector—the Endpoints controller will report zero addresses (or no Endpoints object at all), and Kubernetes does not auto-provision pods from a Service. It also inverts the dependency chain: a Service with no backing pods is just a label selector with no function. The correct diagnosis would be that the workload must exist and be Ready before any endpoint check can succeed, making this sequence not only wrong but actively misleading during verification.

ConfigMap: Stores sensitive data like passwords, tokens.

Why it fails: This statement is incorrect because it conflates ConfigMaps with Secrets. ConfigMaps are designed specifically for non-sensitive, plaintext configuration data such as environment variables, command-line arguments, or configuration files, and they are stored in etcd without any special encoding or protection. Sensitive materials like passwords, tokens, and keys belong in a Secret, which provides the appropriate safeguards such as role-based access control and optional encryption at rest.

Secret: Stores non-sensitive configuration data.

Why it fails: This statement is incorrect because it reverses the intended roles of Secrets and ConfigMaps. Secrets are purpose-built for sensitive data such as passwords, API tokens, SSH keys, and TLS certificates, and while their values are only base64-encoded in manifests, Kubernetes treats them with stricter access controls and can encrypt them at rest. Non-sensitive configuration data such as plain settings, feature flags, or public parameters should be stored in a ConfigMap, not a Secret.

runAsUser: The group ID for the container process

Why it fails: This description incorrectly swaps the meaning of runAsUser and runAsGroup; runAsUser specifically controls the numeric user ID (UID), not the group ID. The group ID of the container process is controlled by the separate runAsGroup field. Mixing these two can lead to misconfigured Pods where file permissions are evaluated based on the wrong identity, causing unexpected permission denied errors or overly broad access to resources.

privileged: Restricts container capabilities to a minimal set

Why it fails: Setting privileged: true actually grants the container broad elevated permissions, such as access to all host devices and most host namespaces, effectively removing many of the default container restriction layers. It does not restrict capabilities; rather, it adds capabilities like CAP_SYS_ADMIN and disables seccomp/AppArmor protections by default. A minimal capability set is achieved using seccomp profiles, AppArmor, and dropping capabilities via capDrop, not with the privileged flag.

The pod's resource requests exceed available capacity.

Why it fails: This is not the cause. The scheduler's events would report 'Insufficient cpu' or 'Insufficient memory' if resource requests exceeded capacity, but here every node reports 'untolerated taint.' Resource requests are irrelevant when taints are blocking scheduling, as a pod may literally request zero resources and still be unschedulable if it lacks the required toleration.

The pod has a node selector that doesn't match any node.

Why it fails: A node selector mismatch would cause events like '0/3 nodes available: 3 node(s) didn't match node selector' in the describe output. However, the exhibit shows no nodeSelector field in the pod spec, and the events point directly to taints. Node selectors and taints are independent scheduling constraints; here, the only reason given is taints, not labels.

The scheduler is not running properly.

Why it fails: The scheduler is demonstrably running because it produced 'FailedScheduling' events and updated the pod's status with those messages. If the kube-scheduler were down or malfunctioning, the pod would remain in Pending with no scheduling events at all. The scheduler can successfully evaluate constraints; it simply concludes that every node is tainted and therefore cannot place the pod.

The API server is using an incorrect etcd endpoint.

Why it fails: While an incorrect etcd endpoint could cause connection issues, it would not result in a non-TLS traffic error; the error would be a connection timeout or refusal.

The etcd pod is not using the correct certificate authority.

Why it fails: Incorrect certificate authority would cause a TLS handshake failure, not a non-TLS record error.

Kube-proxy on node2 and node3 is incorrectly configured to connect directly to etcd using HTTP instead of HTTPS.

Why it fails: Kube-proxy does not connect to etcd under normal circumstances; it communicates with the API server. Therefore, this option is incorrect.

The kube-proxy configuration file on worker3 is missing.

Why it fails: If the kube-proxy configuration file were actually missing, the pod would fail immediately with a clear 'config file not found' or 'failed to load configuration' event in `kubectl describe`, and the kube-proxy ConfigMap (usually named kube-proxy) would be absent from the kube-system namespace. The exhibit instead shows a pod that was scheduled and is restarting due to crash-looping, which points to a runtime/version problem rather than a missing file. kube-proxy configuration is normally delivered as a mounted ConfigMap, not a file that must exist on the node, so this explanation does not match the observed symptoms.

The kube-proxy DaemonSet is not scheduled on worker3.

Why it fails: If the kube-proxy DaemonSet were not scheduled on worker3, the pod would remain in a Pending state with warnings about failed node affinity, taints, or resource fit, and the DaemonSet status would show scheduled pods count below desired count. The exhibit shows a pod that reached the node and then began failing (CrashLoopBackOff), which indicates the scheduler already placed it on worker3 by matching the DaemonSet selector. Therefore 'not scheduled' is contradicted by the presence of a running-but-crashing pod.

The node worker3 has insufficient resources for kube-proxy.

Why it fails: If worker3 truly lacked CPU or memory for kube-proxy, the kubelet would reject the pod during admission control and it would stay Pending with an 'Insufficient memory' or 'Insufficient cpu' event in `kubectl describe node worker3` or `kubectl get events`. Because other pods are running on the node and kube-proxy is not classified as a Guaranteed pod that needs the entire node, the crash is not explained by resource exhaustion. Resource issues also would not generate the version-related log messages that are typically visible in a CrashLoopBackOff pod.

The 'node-labels' argument is deprecated.

Why it fails: The --node-labels flag is a fully supported kubelet option and is not deprecated; it is explicitly exposed through kubeadm's nodeRegistration.kubeletExtraArgs. Kubeadm init passes these extra args directly to the kubelet on the bootstrap node. A deprecated flag would trigger a warning or removal, but since the flag is valid, deprecation cannot be the cause of the label only appearing on the control plane node.

The kubelet needs to be restarted.

Why it fails: The label is applied automatically by the kubelet when it registers the node with the API server; the kubelet reads its configuration at startup. In a kubeadm init flow, kubelet starts before node registration and immediately applies the labels specified in kubeletExtraArgs. A manual restart is unnecessary because the kubelet is already running with the correct configuration from bootstrap; restarting would only resubmit the same arguments and would not propagate the label to worker nodes.

The label key is misspelled.

Why it fails: The label key node-role.kubernetes.io/control-plane is the canonical, well-formed key used by Kubernetes to identify control-plane nodes. It follows the required DNS subdomain prefix and name format, and is not misspelled. If the key were misspelled, kubelet would still attempt to apply a label with that incorrect key, possibly creating an invalid label or failing, but the actual key here is valid, so this cannot explain the label's limited scope.

The pod's priority class is too low.

Why it fails: The PriorityClass determines a pod's scheduling priority and preemption behavior, not whether it can tolerate node taints. Even if this pod's priority were very low, the scheduler would still place it on any node that satisfies its constraints (affinity, resources, tolerations); low priority only means it may be evicted or preempted first when resources are tight. The exhibit shows a high-priority class, yet the pod is still Pending, which proves the blocker is unrelated to priority.

The node has insufficient CPU resources.

Why it fails: Insufficient CPU would be reported as an "Insufficient cpu" scheduling failure, but the exhibit's node CPU utilization is only about 50%, meaning there are ample available CPU resources for the pod's requests. The scheduler evaluates the pod's request (not limits, and not actual utilization) against the node's allocatable capacity; if the requested CPU fit within the remaining capacity, resource shortage cannot be the cause. The pod being Pending despite abundant CPU points to a scheduling constraint that is not resource-based.

The node is cordoned.

Why it fails: Cordoning a node (using `kubectl cordon`) sets its `NodeSpec.Unschedulable` field to true and prevents new pods from being scheduled regardless of tolerations, but the exhibit indicates a taint-based rejection rather than a cordoned state. While cordoning is implemented using the `node.kubernetes.io/unschedulable` taint, the user's scenario explicitly mentions a taint the pod does not tolerate, and there is no indication that the node is cordoned. The taint is the direct cause; cordoning would be a different, more global mechanism that blocks all pods, not just those missing a specific toleration.