Cluster Architecture, Installation & Configuration practice questions

kube-spray

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 kubelet is not configured with the correct node IP.

Why wrong: If the kubelet were misconfigured with an incorrect node IP, the node would fail its initial registration handshake with the control plane entirely, or report an incorrect IP in its status. It would not cause a 'context deadline exceeded' error during runtime status updates, which points to a network timeout rather than a static configuration mismatch.

The new node does not have enough disk space for container images.

Why wrong: Insufficient disk space on a worker node triggers a DiskPressure taint or causes container image pulls to fail with ErrImagePull or ImagePullBackOff. It does not disrupt the kubelet's control plane communication channel or cause API request timeouts like 'context deadline exceeded' when updating node status.

The API server is overloaded and cannot handle the node update request.

Why wrong: If the control plane's API server were genuinely overloaded, status updates from all worker nodes would fail globally, leading to widespread NotReady states across the cluster. Because only the newly added node is experiencing these timeout issues while existing nodes remain healthy, the bottleneck is localized to the new node's specific network path or configuration.

The PodSecurityPolicy admission controller is not enabled.

Why wrong: 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 wrong: 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 wrong: 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 wrong: --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 wrong: --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 wrong: --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.

Generate a join token for worker nodes.

Why wrong: Generating a bootstrap token via kubeadm is used exclusively to authenticate and register new worker nodes to the control plane. It does not resolve the pending network configuration of the control plane node itself, which is required before any workloads or worker nodes can successfully communicate.

Copy the kubeconfig to the user's home directory.

Why wrong: Copying the admin.conf file to the user's home directory is a post-initialization step that configures administrative access for the kubectl CLI tool. While necessary for cluster management, this action only affects client-side authentication and has no impact on the operational readiness of the node or the underlying cluster networking.

Check that the kubelet is running on the control plane node.

Why wrong: The kubelet daemon must already be running successfully for kubeadm init to complete its initial control plane bootstrapping phases. If the node is marked NotReady, it indicates that the kubelet is active but reporting a network plugin uninitialized error, rather than the service being stopped.

kubeadm upgrade plan v1.23.0

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: --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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

The pod is requesting 2 CPUs as a request, but the quota limits requests.

Why wrong: This explanation is incorrect because the ResourceQuota error specifically targets limits.cpu, not requests.cpu. In Kubernetes, CPU requests and CPU limits are tracked as separate metrics within a ResourceQuota. The pod's manifest specifies a CPU limit of 2, which triggers a violation of the namespace's configured limit quota, rather than its request quota.

The pod is being created in the wrong namespace.

Why wrong: While namespaces isolate resources, the admission controller error is triggered by a ResourceQuota violation within the target namespace, not an invalid namespace destination. If the namespace itself were incorrect or non-existent, the API server would return a "not found" error instead of a quota enforcement rejection. The issue is purely a capacity constraint within the active namespace.

The pod is trying to use more CPU than the node capacity.

Why wrong: Node capacity issues are evaluated by the kube-scheduler during the scheduling phase, resulting in a "Pending" pod status with a FailedScheduling event. In contrast, ResourceQuota violations are enforced at the API level by the ResourceQuota admission controller. This block occurs immediately during the creation attempt, preventing the pod object from ever being written to etcd.

Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

Why wrong: While manually deleting the static pod manifest and killing the process might free up port 6443, this approach is highly discouraged because it leaves behind other critical cluster state. Leftover assets such as etcd data in '/var/lib/etcd', TLS certificates in '/etc/kubernetes/pki', and kubelet configurations will still cause the subsequent 'kubeadm init' run to fail. Only a comprehensive reset ensures all these components are properly purged.

Use a different port for the API server by specifying --apiserver-bind-port.

Why wrong: Specifying a non-standard port using '--apiserver-bind-port' merely bypasses the immediate port conflict error without addressing the underlying dirty state of the node. The initialization will still fail or become corrupted due to existing certificates, pre-existing etcd databases, and conflicting configuration files in '/etc/kubernetes'. Furthermore, changing the default API server port complicates future cluster administration and client configurations.

Run kubeadm init with --force flag to override the errors.

Why wrong: The 'kubeadm init' command does not feature a '--force' flag to bypass preflight check failures or override existing configuration conflicts. Instead, kubeadm relies on strict preflight checks to prevent administrators from deploying a broken or unstable control plane. To bypass specific non-critical preflight errors, one must use the '--ignore-preflight-errors' flag, but this still will not resolve fundamental state conflicts like an existing etcd database.

Re-drain the node to reset its state, then uncordon again.

Why wrong: Re-draining an already-drained node is unnecessary and harmful: it flips the node back to unschedulable and evicts running pods, amplifying downtime without addressing the API server's 409 Conflict. The conflict comes from a resourceVersion mismatch on the Node object, not from an incomplete drain state. Retrying `kubectl uncordon` fetches the current resourceVersion and applies the `unschedulable: false` update, so no additional drain cycle is needed.

Restart the kubelet on the control plane node to refresh the node object.

Why wrong: Restarting the kubelet on the control plane node is irrelevant because that kubelet only heartbeats its own Node object and does not participate in updating the target node's `spec.unschedulable` field. It would also restart kubelet-managed static pods on the control plane, risking disruption to control-plane components. The conflict is an API-level optimistic concurrency error, not a kubelet liveness issue, so bouncing the kubelet cannot refresh the target node's resourceVersion or resolve the 409.

Generate a new bootstrap token and rejoin the node to the cluster.

Why wrong: Generating a new bootstrap token and rejoining the node is a drastic and inappropriate response to a transient 409 Conflict. Bootstrap tokens are only needed during initial registration; `kubectl uncordon` edits an existing Node object and does not require reauthentication or re-registration. Deleting and rejoining would recreate the Node identity, wipe node leases and associated metadata, and cause unnecessary disruption—while the actual fix is simply retrying the uncordon with the latest resourceVersion.

The etcd cluster has a leader election issue

Why wrong: If the etcd cluster were experiencing a leader election failure, the cluster would report itself as unhealthy or read-only, and client requests would fail with specific raft-related errors. Because the etcd cluster itself is healthy and operational, a localized timeout indicates a network reachability issue rather than a consensus or quorum failure.

The kube-apiserver is using the wrong etcd client port (2380 instead of 2379)

Why wrong: Port 2380 is strictly reserved for etcd peer-to-peer communication and cluster synchronization, not for client queries. If the kube-apiserver were misconfigured to use port 2380, the connection would be immediately rejected or fail to establish a valid client session, rather than causing a generic network timeout.

The etcd client certificate is expired

Why wrong: An expired client certificate would allow the TCP connection to establish but would immediately fail during the TLS handshake phase. The kube-apiserver would log explicit x509 certificate validation errors or "bad certificate" alerts instead of hanging and timing out.

kubeadm init --cidr=10.244.0.0/16

Why wrong: There is no generic --cidr flag in kubeadm init; the kubeadm command-line parser rejects unknown flags immediately. If an administrator runs this, kubeadm will fail with an error listing the flag as invalid. The correct way to specify the pod network range is the singular --pod-network-cidr flag, not a shorthand or alternate version.

kubeadm init --network-cidr=10.244.0.0/16

Why wrong: kubeadm does not recognize --network-cidr as a valid flag; this name is not part of its configuration schema. While other networking components like kube-proxy use different flags, kubeadm only exposes the pod subnet through --pod-network-cidr. Using this misspelled or misremembered flag results in a 'flag provided but not defined' error and aborts initialization.

kubeadm init --service-cidr=10.244.0.0/16

Why wrong: The --service-cidr flag configures the virtual IP range for ClusterIP services, with a default of 10.96.0.0/12, and has no effect on pod IP addressing. Passing 10.244.0.0/16 to it would assign that range to services, leaving the pod network unspecified and causing the CNI plugin to fail or misbehave. The pod CIDR must be set with --pod-network-cidr, and it should not overlap with the service CIDR.

Use kubectl create node command from the control plane

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

kubeadm init --service-cidr 10.244.0.0/16

Why wrong: The --service-cidr flag defines the virtual IP range for ClusterIP services exposed through the Kubernetes API, not the IP range used for pods. In a typical kubeadm init, this defaults to 10.96.0.0/12; overriding it to 10.244.0.0/16 would misalign service addressing and would not tell Flannel or any CNI plugin which subnet to use for pod IPs. Thus it configures the wrong network parameter.

kubeadm init --network-cidr 10.244.0.0/16

Why wrong: The option --network-cidr does not exist in kubeadm init's flag set; attempting to use it would cause kubeadm to fail with an 'unknown flag' error before any cluster initialization occurs. kubeadm intentionally uses --pod-network-cidr to make the network scope explicit, avoiding ambiguity with service networks. Since this flag is unrecognized, the command cannot succeed.

kubeadm init --apiserver-advertise-address 10.244.0.0

Why wrong: The --apiserver-advertise-address flag tells kubeadm which IP address the API server should advertise as its reachable endpoint for kubelet and control plane communication. It must be a host IP on a node interface, such as 192.168.1.10, not a network address or CIDR. Supplying 10.244.0.0, a network identifier, would be invalid and would not affect pod network configuration.

The kubelet is running out of disk space.

Why wrong: If the host runs out of disk space, the kubelet will typically trigger disk pressure taints or fail during write-heavy operations like container image pulling and logging. It would not produce a filesystem 'permission denied' error during the initial read of its static configuration files.

The kubelet is not able to reach the API server.

Why wrong: A failure to reach the Kubernetes API server due to network partitions, incorrect API endpoints, or firewall rules results in connection timeouts, 'connection refused' errors, or TLS handshake failures. It does not manifest as a local filesystem permission denied error when the kubelet process starts.

The kubelet binary is missing.

Why wrong: If the kubelet binary is absent from the host's executable paths, the systemd service manager will fail to launch the process entirely, reporting a 'file not found' or 'no such file or directory' error. It cannot execute far enough to encounter or report a permission denied error on its configuration.