A Kubernetes cluster is split conceptually between a control plane that maintains desired cluster state and worker nodes that run application workloads. For CompTIA Cloud+ CV0-004 practitioners, this separation is useful because it turns troubleshooting into a fault-domain question: is the problem preventing the cluster from making decisions, or is the problem preventing a node from running the work it was assigned?
Kubernetes changes continuously, but the core architecture remains stable: the API server exposes the cluster API, etcd stores cluster state, the scheduler assigns unscheduled Pods to nodes, controllers reconcile desired and observed state, and node components such as kubelet and the container runtime keep workloads running. Managed Kubernetes may hide some implementation details, yet the same logical responsibilities still exist. The provider may operate the API server and etcd while the customer still owns workload configuration, node pools, network policy, storage choices, and application health. Troubleshooting should respect that operational boundary.
The API server is the control plane’s front door
Almost every cluster operation is expressed through the Kubernetes API. kubectl, controllers, schedulers, operators, admission components, and external automation all depend on the API server. If API access is unavailable, existing Pods may continue running for a time, but new desired-state changes cannot be processed normally.
Troubleshoot API problems by separating client access from server health. Check whether requests fail for every client or only one identity, network, or tool. A cluster can be healthy while a developer sees authorization errors, expired credentials, or a local kubeconfig problem. Conversely, widespread timeouts and failed controller heartbeats indicate a control-plane issue that client troubleshooting will not solve. Check authentication, authorization, certificates, DNS, load balancing, network reachability, and control-plane status. In managed services, platform health events and provider status can matter as much as node-level logs because the control plane may be outside the customer’s direct administration.
etcd is the durable source of cluster state
etcd stores Kubernetes API data and therefore represents a critical control-plane dependency. Losing healthy etcd quorum can prevent reliable updates even if worker nodes still have running containers. Backup, recovery, capacity, latency, and disk health for etcd matter in self-managed clusters; managed services typically operate this layer for the customer.
Treat etcd as control-plane state, not application storage. In self-managed clusters, monitor member health, disk latency, free space, quorum, and backup completion. Recovery procedures should be tested because restoring an inconsistent or stale etcd snapshot can bring the API back while reintroducing old objects, credentials, or configuration. Application data belongs in databases, object stores, persistent volumes, or other workload-specific systems. Mixing those responsibilities leads to poor recovery assumptions because restoring cluster state is not the same as restoring the data used by applications.
The scheduler chooses where Pods should run
The default kube-scheduler watches for Pods that do not yet have an assigned node and selects a suitable node based on resource requests, constraints, affinity, taints, topology, and other scheduling rules. A Pending Pod can therefore represent a scheduling problem even when every node is technically online.
Inspect why a Pod is unschedulable before adding capacity. Compare resource requests with allocatable node capacity rather than with raw machine size; system daemons and Kubernetes reservations reduce what Pods can use. Also review topology-spread constraints and disruption policies, which can intentionally prevent placement even when CPU and memory appear available. Common causes include insufficient requested CPU or memory, node selectors that match nothing, taints without tolerations, volume topology restrictions, anti-affinity, and namespace or quota limits. Scaling the cluster cannot fix a policy constraint that excludes every available node.
Controllers continuously reconcile desired and observed state
Controllers are loops that compare what the API says should exist with what the cluster currently has, then act to reduce the difference. Deployments, ReplicaSets, Jobs, Nodes, endpoints, and cloud integrations all rely on controllers. This reconciliation model explains why directly fixing one generated object can be temporary: the controller may recreate the desired state.
When troubleshooting, identify the owning resource. Status conditions and Kubernetes events often show which reconciliation step failed. Follow the ownership chain upward so a temporary child object is not mistaken for the source of truth. Operators who repeatedly edit generated Pods can create confusing churn while the controller continues restoring the declared configuration. A failed Pod managed by a Deployment should usually be investigated through the Deployment, ReplicaSet, configuration, image, and readiness conditions rather than treated as an isolated container. Fix the declared cause so reconciliation produces the intended result.
Worker nodes provide the runtime environment for Pods
Each worker node runs kubelet and a container runtime, plus networking components required by the cluster. kubelet watches the desired Pod assignments for its node and ensures the containers are created and kept in the expected state. A node problem can affect only the workloads placed there while the rest of the cluster remains healthy.
Differentiate node-wide symptoms from Pod-specific symptoms. Node pressure conditions such as disk pressure, memory pressure, or unavailable network resources can cause eviction and scheduling behavior that looks like an application failure. Compare node conditions, recent evictions, kubelet status, container-runtime health, and system logs before changing the workload. If many unrelated Pods on one node fail image pulls, networking, mounts, or health checks, investigate the node, runtime, disk, network, and kubelet. If only one workload fails across several healthy nodes, the application definition is a stronger suspect.
Networking crosses both control-plane and worker-node boundaries
Pods need connectivity to the API, DNS, services, other Pods, ingress paths, and external dependencies. Container Network Interface implementations, service routing, network policy, load balancers, and cloud routes can fail independently. A cluster that schedules Pods successfully can still be unusable if workload networking is broken.
Test the path layer by layer: name resolution, Pod address, service discovery, network policy, node routing, egress, and external load balancing. Include readiness and endpoint selection in the check because a Service can resolve correctly while having no healthy backends. Packet reachability and application readiness are separate questions and both need evidence. name resolution, Pod address, service discovery, network policy, node routing, egress, and external load balancing. Avoid assuming a Kubernetes Service guarantees application reachability; it only defines a virtual service abstraction over selected endpoints, and those endpoints still have to be healthy and reachable.
Storage failures often look like scheduling or startup failures
Persistent volumes create another fault domain. Stateful applications also depend on ordering, consistency, and recovery semantics that Kubernetes itself does not automatically provide. A rescheduled database Pod can start successfully and still be unhealthy if the attached data volume is stale, locked, corrupted, or unavailable in the new zone. A Pod may remain Pending because a requested volume cannot bind, may fail to start because a mount is unavailable, or may be constrained to nodes in a particular zone because the storage resource is zonal. Storage class, access mode, capacity, attachment limits, and topology all influence placement.
The existing explanation of Kubernetes persistent volume claims is useful when a workload problem involves claims and storage binding. For architecture troubleshooting, the key is to distinguish control-plane decisions about volume objects from the node and storage-system operations that make the volume usable.
Failure domains should shape workload placement
Cloud regions, zones, nodes, racks, and storage systems can fail independently. Kubernetes topology constraints, anti-affinity, replica counts, PodDisruptionBudgets, and multiple node pools help spread workloads so one failure does not remove every replica. High availability requires the application itself to tolerate that distribution. Review readiness probes, graceful shutdown, replica synchronization, and dependency timeouts so the scheduler can move workloads without turning a node failure into an application-wide failure.
Do not confuse replica count with resilience. Review control-plane and worker-node upgrade domains as well. Maintenance events, autoscaler actions, and rolling updates can remove capacity in predictable patterns, so disruption budgets and placement rules should be tested under those planned failures instead of only during unexpected outages. Three replicas on one node or one zone share the same fault domain. Three stateless replicas can also depend on one stateful backend. Map the complete service dependency chain and verify that each critical component meets the intended failure-domain design.
Use the architecture to choose the right troubleshooting starting point
A cluster issue becomes easier when symptoms are mapped to component responsibility. Control-plane unavailability, unscheduled Pods, node failures, network isolation, storage binding, and application readiness all point to different evidence. Structured Kubernetes training can build general platform familiarity, but production troubleshooting should follow the actual control flow from API declaration to node execution.
Start with desired state, inspect status and events, identify the controller or node responsible for the next step, and then examine logs and platform metrics at that layer. Keep a cluster-level observability view for API latency, scheduling failures, node readiness, Pod restarts, volume errors, and network health so recurring faults can be detected before users report an outage. Baseline normal behavior after upgrades as well. This avoids random restarts and makes Kubernetes troubleshooting a repeatable architecture exercise rather than trial and error.
Cluster services can cross the control-plane and worker boundary in ways that confuse symptom-based troubleshooting. DNS, the CNI plugin, admission components, storage controllers, and node agents may each be healthy locally while the end-to-end workload path is broken. Trace the desired-state transition from API object to scheduling, node preparation, networking, storage, and readiness so each observation is tied to the component that owns it.