CKA Course Notes

A Kubernetes cluster is controlled through the control plane. The kube-apiserver is the front door for cluster changes, the scheduler chooses suitable nodes for unscheduled Pods, the controller manager runs controllers that drive actual state toward desired state, and etcd stores the cluster state that those components depend on.

• Treating kube-apiserver, scheduler, controller manager, and etcd as interchangeable control-plane pieces instead of recognizing each component’s job.

• API request problems often involve authentication, authorization, admission, or kube-apiserver availability.

Kubernetes works through reconciliation. Controllers watch the API server, compare desired state with actual state, and create, update, or delete resources until the cluster matches the declared objects.

• Calling the kubelet a controller; kubelet is the node agent, while controllers reconcile API objects from the control plane.

• Control loop clues point to watching desired state, comparing actual state, and reconciling differences.

kubeadm join adds a new node to an existing kubeadm-managed cluster. The command uses discovery information and bootstrap credentials so the node can contact the API server, prove it is allowed to join, and begin kubelet registration.

• Using a ClusterRoleBinding when the requirement only needs namespace-scoped access through a RoleBinding.

• Role is namespace-scoped; ClusterRole is cluster-scoped or reusable across namespaces.

Namespaces divide many Kubernetes object names into separate administrative spaces. They are useful for team, environment, or application boundaries, but they do not isolate every resource type and they are not a security boundary by themselves.

• Treating namespaces as full security isolation; they organize namespaced objects but still need RBAC, quotas, and policies.

• RoleBindings are namespace-scoped even when they bind a ClusterRole.

Deployments manage stateless replicated workloads through ReplicaSets. The Deployment owns rollout history and update strategy, while each ReplicaSet maintains a matching set of Pods for a specific Pod template revision.

• Using a Deployment for finite work when the clue asks for completion; Jobs and CronJobs handle run-to-completion tasks.

• Deployment rollout clues point to rollout status, history, pause, resume, and undo.

Services provide stable access to changing Pods. A Service selector matches Pod labels, Kubernetes creates EndpointSlices for the matching backends, and clients use the Service name or virtual IP instead of tracking Pod IP changes directly.

• Troubleshooting a Service from DNS first when the real issue is a selector mismatch or no EndpointSlices.

• ClusterIP is internal-only stable Service access; NodePort opens a port on each node.

Ingress manages HTTP and HTTPS routing from outside the cluster to Services inside the cluster. The Ingress object defines host and path rules, but an Ingress controller must be installed to implement those rules.

• Creating an Ingress object without an Ingress controller and expecting traffic to route automatically.

• Ingress handles HTTP and HTTPS host/path routing to Services through an installed controller.

PersistentVolumes are cluster storage resources, while PersistentVolumeClaims are user requests for storage. A PVC binds to a matching PV or triggers dynamic provisioning when an appropriate StorageClass is available.

• Confusing PV and PVC; PV is the storage resource, while PVC is the namespaced request for storage.

• Dynamic provisioning clues point to PVC plus StorageClass plus provisioner.

Pending Pods usually mean the scheduler cannot place the Pod. Start with kubectl describe pod and read Events for insufficient CPU or memory, missing PVCs, node selectors, taints, affinity rules, or unavailable nodes.

• Troubleshooting a Pending Pod by reading container logs even though the container never started; Events and scheduling constraints matter first.

• Pending Pods point to describe output and Events for resources, PVCs, taints, selectors, affinity, or node availability.

CoreDNS troubleshooting starts by separating DNS failure from application failure. Check CoreDNS Pods, the kube-dns Service, endpoints, CoreDNS logs, the CoreDNS ConfigMap, and whether a test Pod can resolve service names in the expected namespace.

• Assuming NotReady is a Pod problem when node conditions, kubelet, runtime, or network plugin health may be the cause.

• CoreDNS issues require checking CoreDNS Pods, Services, endpoints, logs, ConfigMap, and test Pod lookup.