CCNA Kubernetes Fundamentals Questions

Option C is correct because a Service of type LoadBalancer provisions an external load balancer (e.g., in cloud environments like AWS, GCP, or Azure) that assigns a public IP or DNS name, making the Deployment directly accessible from the internet. This is a standard method for exposing services externally in Kubernetes.

If a container exceeds its CPU limit, it gets throttled (not killed). If it exceeds its memory limit, it is killed (OOMKilled). Here, CPU usage 600m exceeds limit 500m -> throttled; memory usage 700Mi is below limit 1Gi -> no OOM.

The scheduler cannot find a node with enough memory to satisfy the pod's resource requests.

A Deployment with a preferred nodeAffinity rule is correct because it allows the pod to be rescheduled on a different node if the current node fails, while expressing a preference for nodes in a specific availability zone. The 'preferred' (soft) rule ensures scheduling flexibility—the pod can run elsewhere if no zone-matching nodes are available—which aligns with the requirement for high availability without strict zone constraints.

A Service provides a stable virtual IP and DNS name that routes traffic to pods matching its selector.

Option C is correct because `kubectl exec pod-name -- cat /var/log/app.log` runs the `cat` command inside the container without modifying the pod or its state. This allows you to view the file contents directly from the container's filesystem, which is essential for debugging when the application logs are not written to stdout/stderr and thus not accessible via `kubectl logs`.

The scale command changes the desired number of replicas for the Deployment. The Deployment controller will then create 2 additional Pods to reach 5 replicas.

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It stores the entire cluster state, including configuration, secrets, and metadata, and is a core component of the control plane because the API server reads from and writes to it to maintain cluster integrity.

The kube-controller-manager is the control plane component that runs controller processes, including the Replication Controller, which is responsible for ensuring that the desired number of pod replicas are running at all times. It continuously watches the state of the cluster via the kube-apiserver and makes adjustments to reconcile the current state with the desired state defined in the cluster's configuration.

The kube-apiserver is the front-end of the Kubernetes control plane. It exposes the Kubernetes API, which is used to interact with the cluster. All other components communicate through it.

The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. kubelet and kube-proxy are worker node components.

apps/v1 is for Deployments, StatefulSets, etc. batch/v1 is for Jobs and CronJobs. networking.k8s.io/v1 is for NetworkPolicy and Ingress. v1 is the core API version for Pods, Services, etc.

Option D is correct. A Job is designed for running tasks that complete successfully and then terminate. A Deployment is for long-running services, a DaemonSet runs a pod on each node, and a StatefulSet is for stateful applications requiring stable identities.

Pending often indicates that the scheduler cannot find a node that meets the Pod's resource requests or other constraints.

Deployments provide rolling updates and rollback capabilities, and declarative updates. ReplicaSets do not support rolling updates natively.

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data.

Liveness probes determine if a container is running; if they fail, kubelet restarts the container.

A Pod is the smallest and simplest unit in the Kubernetes object model, representing a single instance of a running process.

The error indicates that the third pod 'web-2' is pending due to a scheduling conflict. Pod anti-affinity rules, when configured with a 'requiredDuringSchedulingIgnoredDuringExecution' policy, prevent more than one pod from the same StatefulSet from being scheduled on the same node. With only 3 nodes available and the first two pods already occupying distinct nodes, the third pod cannot be placed, causing it to remain pending.

A Job is the correct resource because it is designed to run a specified number of pods to completion and then terminate, making it ideal for batch processing tasks like processing a queue. Unlike controllers that maintain a desired state indefinitely, a Job ensures the pod runs successfully to completion, even if the pod fails and needs to be restarted, and then stops.

A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

The taint indicates a node has disk pressure, and the pod does not have a toleration for it, so it cannot be scheduled on that node.

The `kubectl logs <pod-name> --previous` command retrieves the logs from the previous instance of a crashed container. Since the Pod is in CrashLoopBackOff, the current container has already exited, and the `--previous` flag accesses the logs of the last terminated container, which contains the crash output (e.g., the non-zero exit code and error messages). This is the direct way to see why the entrypoint failed.

When a ConfigMap is mounted as a volume with `subPath`, updates are not reflected automatically. Using a projected volume or a Symlink-based update (e.g., mounting the ConfigMap directly without subPath) allows automatic updates. The simplest way is to mount the ConfigMap as a volume without subPath, so updates are eventually reflected.

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. It bundles together controllers such as the Node Controller, Replication Controller, and Endpoint Controller, each responsible for specific aspects of cluster state management.

Worker nodes run kubelet, kube-proxy, and a container runtime. The API server and scheduler run on the control plane.

A Pod is the smallest and simplest Kubernetes object, representing a single instance of a running process in the cluster.

Option B is correct because the `kubectl create deployment` command is the standard Kubernetes imperative method to create a Deployment resource, and specifying `--image=nginx:1.19` directly sets the container image for the pod template. This command generates a Deployment object that manages a ReplicaSet with the specified image, ensuring declarative updates and rollback capabilities.

Namespaces provide logical isolation and are commonly used to separate teams or environments. Combined with RBAC and NetworkPolicies, they enable multi-tenancy.

Option B is correct because 'resources.limits.memory' is the valid Kubernetes field to set the maximum amount of memory a container can use. When a container exceeds this limit, it may be terminated or OOM-killed by the kubelet. This is a core concept in Kubernetes resource management for ensuring predictable application behavior.

ConfigMap is the correct Kubernetes object for storing non-confidential configuration data, such as environment variables, command-line arguments, or configuration files, that can be consumed by pods. Unlike Secrets, ConfigMaps store data in plain text and are designed for configuration that does not require encryption, making them ideal for application settings that are not sensitive.

Option C is correct because a Kubernetes Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as the underlying pods are created, destroyed, or scaled. This abstraction allows clients to reliably reach a set of pods without needing to track individual pod IPs, which are ephemeral. Services use label selectors to dynamically route traffic to matching pods, ensuring high availability and load balancing.

A Pod is the smallest and simplest unit in the Kubernetes object model that you can create and deploy. It represents a single instance of a running process in your cluster and encapsulates one or more containers with shared storage and network resources. While containers are the actual runtime environments, Kubernetes does not manage containers directly; it manages Pods, which are the atomic unit of scheduling and lifecycle management.

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It is responsible for ensuring that containers described in a PodSpec are running and healthy, by interacting with the container runtime (e.g., containerd, CRI-O) to create, start, and monitor pods. The kubelet does not manage containers that were not created by Kubernetes.

Service can only forward traffic to pods that are ready (i.e., pass readiness probes). If readiness probe fails, pod is removed from Service endpoints.

Deployments are stable in the apps/v1 API group.

Option B is correct because 'kubectl edit deployment' is a built-in kubectl command that opens the Deployment's manifest in the default editor, allowing in-place modifications without any additional plugins. It directly interacts with the Kubernetes API to update the resource.

The kube-controller-manager is the control plane component that runs controller loops, which are continuous processes that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. Each controller (e.g., ReplicaSet, Node, Deployment) is a separate loop that handles a specific aspect of cluster management, ensuring that the actual cluster state matches the desired configuration defined in the API objects.

A Job creates one or more pods and ensures they run successfully to completion. For batch processing that terminates, a Job is appropriate.

A pod remains Pending if the scheduler cannot find a node that satisfies its resource requests or other constraints.

The kube-scheduler is responsible for assigning pending pods to worker nodes based on resource availability and constraints.

A StatefulSet with a Headless Service is correct because StatefulSets assign each Pod a stable, unique network identity (e.g., pod-name-0.service-name.namespace.svc.cluster.local) that persists across rescheduling. A Headless Service (clusterIP: None) disables load balancing and DNS round-robin, allowing direct DNS resolution to individual Pod IPs for peer-to-peer communication. This matches the requirement for unique DNS names for each Pod.

A Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as Pods are created or destroyed. This enables reliable network access to a dynamic set of Pods selected via labels, abstracting away Pod IP volatility.

StatefulSet provides stable network identities and persistent storage per pod, suitable for stateful applications like databases.

A Kubernetes Service provides a stable network endpoint (IP address and DNS name) to access a set of pods, which are ephemeral and can be rescheduled with different IPs. It acts as an abstraction layer, enabling load-balanced traffic to the pods via kube-proxy and iptables/IPVS rules. This is the core purpose of a Service, as defined in the Kubernetes API.

kubectl logs is used to fetch container logs. When a pod has multiple containers, the -c flag specifies the container. Options A and B have incorrect syntax; option D is for running commands in a container, not viewing logs.

Use `kubectl logs` with the `-c` flag to specify the container name when a pod has multiple containers.

kubectl get pods lists all pods in the current namespace with basic status.

The 'scale' command is used to change the number of replicas in a Deployment.

Option B is correct because a Pod is the smallest and most fundamental deployable unit in Kubernetes. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. You cannot deploy a container directly; you must always wrap it in a Pod.

A NetworkPolicy is used to control ingress and egress traffic to pods based on labels and other selectors. It can be used to restrict communication between pods.

The kube-controller-manager is the control plane component that runs controller processes, each of which watches the current state of the cluster via the kube-apiserver and makes changes to drive the actual state toward the desired state defined in etcd. This reconciliation loop pattern is fundamental to Kubernetes' self-healing behavior, ensuring that resources like deployments, replica sets, and nodes match their specifications.

First install runtime and Kubernetes tools, then init control plane, add network plugin, and join workers.

kube-apiserver and etcd are control plane components. kubelet and kube-proxy are worker node components.

A failing liveness probe causes the kubelet to restart the container according to the pod's restart policy.

The kubelet does not perform scheduling; scheduling is done by the kube-scheduler.

ResourceQuota uses 'spec.hard' with resource names like 'limits.cpu' and 'limits.memory'.

Namespaces provide a mechanism to logically isolate groups of resources within a single cluster. They are useful for separating environments (e.g., dev, prod) or teams.

Option A is correct because a Kubernetes Service uses a label selector to identify which Pods should receive traffic. When a Service is created with a selector matching certain labels, the endpoint controller dynamically updates the Service's Endpoints object to include the IP addresses of all Pods with those labels, enabling traffic routing.

kubectl, curl, and client libraries are common API interaction methods.

kubectl describe pod provides detailed information including events, status, and configuration.

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

A Service provides a stable endpoint for a set of Pods, enabling discovery and load balancing across them.

Option C (NodePort) is correct because a NodePort service exposes the application on a static port (30080) on each node's IP address, making it accessible from outside the cluster via <NodeIP>:30080. This is the appropriate choice when you need to expose pods to external traffic using a specific port number without requiring a cloud load balancer.

CrashLoopBackOff means the container is repeatedly crashing after starting, and Kubernetes is backing off from restarting it.

Option B is correct because the kube-controller-manager includes the EndpointSlice controller (or the legacy Endpoints controller), which is responsible for creating and updating Endpoints (and EndpointSlice) objects to reflect the IP addresses and ports of Pods that match a Service's label selector. This ensures that the Service's DNS or iptables rules point to healthy Pods.

Increasing the replicas to at least 2 ensures that if one pod crashes, the other replica(s) can continue serving traffic, maintaining availability. With only a single replica, the service becomes unavailable every time the pod restarts. This is the most direct way to provide redundancy and fault tolerance for a stateless microservice.

A Pod is the smallest deployable unit, encapsulating one or more containers with shared storage and network.

A pod stays pending when it cannot be scheduled to a node, typically due to insufficient resources or node selector issues.

The kubelet ensures containers are running and healthy, and reports node status. Options A and D are correct.

The kubelet is the primary node agent that ensures containers are running as expected.