Kubernetes MCQ

Explanation

Kubernetes (often abbreviated K8s) is a container orchestration platform that automates deploying, scaling, and managing containerized applications across clusters of machines.

Explanation

A Pod is the smallest deployable unit in Kubernetes, representing one or more tightly coupled containers that share network and storage resources.

Explanation

A Node is a machine (VM or physical) that is part of the cluster and runs Pods, managed by the control plane.

Explanation

The control plane (including components like the API server, scheduler, and controller manager) maintains the desired state of the cluster and makes decisions about scheduling and scaling.

Explanation

"kubectl" is the primary command-line tool for communicating with a Kubernetes cluster's API server to create, inspect, and manage resources.

Explanation

"kubectl get pods" lists pods in the current namespace, showing their name, status, restarts, and age.

Explanation

A Deployment manages a ReplicaSet of Pods, providing declarative updates, rolling updates, and rollback capabilities for stateless applications.

Explanation

A Service provides a stable IP address and DNS name to access a set of Pods, even as individual Pods are created and destroyed.

Explanation

"kubectl apply" applies a configuration to a resource, creating it if it doesn't exist or updating it to match the desired state declared in the file.

Explanation

Namespaces divide cluster resources between multiple users or teams, providing a scope for names and helping organize resources.

Explanation

A ReplicaSet maintains a stable set of replica Pods running at any given time, replacing Pods that fail or are deleted. Deployments manage ReplicaSets to enable rolling updates.

Explanation

"kubectl describe" provides detailed human-readable information about a resource, including recent events, useful for debugging issues like failed scheduling or crashes.

Explanation

ConfigMaps decouple configuration data from container images, allowing the same image to be used with different configurations across environments.

Explanation

Secrets store sensitive data separately from application code/images; by default they are base64-encoded (not encrypted at rest unless additional measures are configured).

Explanation

"kubectl logs" fetches the stdout/stderr output of a container in a pod, useful for debugging application issues.

Explanation

Labels are arbitrary key-value pairs used by selectors (in Services, Deployments, etc.) to identify and group related objects.

Explanation

"kubectl scale" updates the replica count of a Deployment (or ReplicaSet/StatefulSet), and the controller adjusts the number of running Pods to match.

Explanation

etcd is the backing store for all cluster configuration data, representing the overall state of the cluster at any given time.

Explanation

The scheduler assigns Pods to Nodes based on resource requirements, constraints, affinity rules, and other factors.

Explanation

"kubectl create namespace <name>" creates a new namespace, which can then be used to isolate resources for that environment or team.

Explanation

Kubernetes runs containers based on OCI-compliant images (commonly built with Docker), specified in a Pod's container spec via the "image" field.

Explanation

Since the Deployment continuously reconciles towards the desired replica count, deleting a managed pod causes the ReplicaSet controller to create a replacement pod automatically.

Explanation

A Pod wraps one or more containers (often one main container plus optional sidecars) that share the same network namespace and can share storage volumes.

Explanation

"kubectl get nodes" shows the nodes that make up the cluster, including their status (Ready/NotReady), roles, age, and Kubernetes version.

Explanation

The kubelet runs on every node and works with the container runtime to start, stop, and monitor containers as specified by PodSpecs assigned to that node.

Explanation

Kubernetes resources are typically defined in YAML (or JSON) manifests specifying "apiVersion", "kind", "metadata", and "spec" fields describing the desired state.

Explanation

"kind" identifies the resource type (e.g. "Pod", "Deployment", "Service") that the manifest describes.

Explanation

"kubectl port-forward <pod> <local-port>:<pod-port>" creates a temporary tunnel from your local machine to a pod, commonly used for local debugging.

Explanation

A Job creates Pods that run until successful completion, unlike Deployments which keep Pods running continuously; useful for batch tasks like data migrations.

Explanation

CronJobs run Jobs on a time-based schedule defined using cron syntax, useful for periodic tasks like backups or report generation.

Explanation

Kubernetes uses a declarative model: users specify the desired state, and controllers continuously reconcile the actual cluster state to match it.

Explanation

Similar to "docker exec", "kubectl exec -it" lets you run a command (often a shell) interactively inside a container of a running pod for debugging.

Explanation

Minikube creates a local, single-node Kubernetes cluster (typically inside a VM or container) for development and learning purposes.

Explanation

restartPolicy determines the kubelet's behavior when a container in the Pod terminates — "Always" (default for Deployments), "OnFailure", or "Never" (common for Jobs).

Explanation

"create" is imperative and errors on existing resources, while "apply" is declarative, supporting both creation and incremental updates based on the desired configuration.

Explanation

A Service's selector matches Pods by their labels, determining which set of Pods receive traffic sent to that Service.

Explanation

"kubectl rollout status" streams the progress of an ongoing deployment rollout, useful for confirming when an update has finished successfully.

Explanation

Because Kubernetes abstracts infrastructure details behind APIs, the same application definitions can generally run on different clouds or on-premises with minimal changes.

Explanation

A readiness probe signals whether a Pod is ready to serve traffic; if it fails, the Pod is removed from Service endpoints until it passes again.

Explanation

"K8s" is a common numeronym shorthand for "Kubernetes", counting the eight letters ("ubernete") omitted between the first "K" and the last "s".

Explanation

Liveness probe failures cause the kubelet to restart the container; readiness probe failures simply remove the Pod from Service endpoints until it becomes ready again, without restarting it.

Explanation

PVs are cluster resources representing actual storage (e.g. a cloud disk), while PVCs are namespaced requests for storage that Pods reference, decoupling storage provisioning from consumption.

Explanation

StatefulSets provide stable network identities (e.g. "pod-0", "pod-1") and stable storage per Pod, with ordered, graceful deployment and scaling — important for clustered stateful applications.

Explanation

Ingress defines rules for routing external HTTP/HTTPS traffic to internal Services based on hostnames or paths, but requires an Ingress Controller (e.g. nginx-ingress) to actually implement those rules.

Explanation

ClusterIP provides internal-only access; NodePort exposes the service on a static port on each node's IP; LoadBalancer provisions an external load balancer (typically via a cloud provider).

Explanation

The scheduler uses requests to decide which node has enough capacity for a Pod, while limits constrain actual usage at runtime — exceeding a memory limit can result in the container being OOMKilled.

Explanation

DaemonSets ensure exactly one Pod runs per matching node, ideal for cluster-wide infrastructure services like log shippers (e.g. Fluentd) or node monitoring agents.

Explanation

"kubectl rollout undo" reverts a Deployment to a previous revision, which Kubernetes tracks via its rollout history, useful for quickly undoing a problematic update.

Explanation

nodeSelector provides exact-match scheduling constraints based on node labels, while node affinity supports more expressive matching (operators like In, NotIn) and both required (hard) and preferred (soft) rules.

Explanation

HPA scales out/in by changing the number of Pods, while VPA scales up/down by adjusting the CPU/memory allocated to individual Pods — they address different scaling dimensions and can sometimes conflict if used together carelessly.

Explanation

Taints applied to nodes repel Pods that don't have a matching toleration; this is the opposite of affinity (which attracts Pods) and is useful for dedicating nodes to specific workloads.

Explanation

Events provide a record of what has happened in the cluster (e.g. "Successfully pulled image", "Failed scheduling"), valuable for diagnosing issues with Pods or other resources.

Explanation

Helm charts package related Kubernetes manifests as templates with configurable values, making it easier to manage versioned, reusable, and parameterized application deployments.

Explanation

A rolling restart recreates Pods gradually following the same rolling update strategy, useful when underlying ConfigMaps/Secrets change but the Pod template itself hasn't, since Kubernetes doesn't automatically restart Pods on Secret/ConfigMap changes.

Explanation

Init containers run sequentially before app containers and must complete successfully; they're useful for setup tasks that should finish before the main application starts.

Explanation

Sidecars run alongside the main container, sharing its network namespace and volumes, commonly used for service mesh proxies (e.g. Envoy in Istio), log forwarders, or config reloaders.

Explanation

"kubectl top" relies on the Metrics Server add-on to collect and expose resource usage metrics, which it then displays for nodes or pods.

Explanation

RBAC defines "who can do what" within the cluster by binding permissions (verbs on resources, defined in Roles/ClusterRoles) to subjects (users, groups, or ServiceAccounts) via RoleBindings/ClusterRoleBindings.

Explanation

Roles are namespace-scoped, while ClusterRoles are cluster-scoped — they can grant access to cluster-scoped resources (like Nodes) or be reused across multiple namespaces via RoleBindings.

Explanation

"imagePullPolicy: Always" forces a fresh pull on every Pod start, ensuring the latest version of a tag is used — important when using mutable tags like "latest", though it adds startup latency and registry load.

Explanation

Headless Services skip load-balancing and cluster IP allocation, instead allowing DNS queries to resolve directly to the IPs of the backing Pods — commonly used with StatefulSets.

Explanation

Cordoning prevents new Pods from being scheduled on a node, and draining evicts existing Pods (respecting PodDisruptionBudgets) — a common workflow before performing node maintenance or upgrades.

Explanation

PDBs specify a minimum available (or maximum unavailable) number of replicas during voluntary disruptions, ensuring operations like node drains don't take down too many replicas of a critical application simultaneously.

Explanation

CrashLoopBackOff is a status indicating the kubelet is repeatedly restarting a failing container with increasing backoff delays, often signaling an application startup error that needs investigation via logs.

Explanation

"kubectl get all" covers a predefined set of common resource types but deliberately excludes some (like ConfigMaps and Secrets) — those need to be queried explicitly.

Explanation

kubeconfig files can define multiple contexts (cluster + user + namespace combinations), letting users switch which cluster/credentials kubectl targets without re-authenticating each time.

Explanation

emptyDir is ephemeral storage tied to the Pod's lifecycle (useful for scratch space or sharing data between containers in a Pod), while hostPath ties a Pod to a specific node's filesystem, which can cause issues if the Pod is rescheduled elsewhere.

Explanation

"--dry-run=client" processes the request locally without persisting it to the cluster, often combined with "-o yaml" to generate a manifest template that can be edited and applied later.

Explanation

NetworkPolicies define ingress/egress rules for Pods based on labels, namespaces, or IP blocks; they require a compatible CNI plugin (e.g. Calico) to actually enforce the rules.

Explanation

Labels are meant for identifying/grouping resources via selectors (and have size/format restrictions for indexing), while annotations can hold larger, more arbitrary metadata (like build info or tool-specific configuration) not used for selection.

Explanation

When a Pod is deleted, Kubernetes sends SIGTERM and waits up to terminationGracePeriodSeconds (default 30s) for the process to exit cleanly before sending SIGKILL.

Explanation

kustomize (built into kubectl via "kubectl apply -k") lets you maintain a base set of manifests and apply environment-specific overlays/patches without templating syntax, unlike Helm's templated approach.

Explanation

A Pod is "Guaranteed" if requests equal limits for all resources, "Burstable" if it has requests/limits but they differ, and "BestEffort" if none are set; under memory pressure, BestEffort Pods are evicted first.

Explanation

"kubectl edit" opens the live resource's configuration in your default editor; upon saving, the changes are validated and applied directly to the cluster, similar to "apply" but interactive.

Explanation

Every Pod runs under a ServiceAccount (default if not specified), which provides an identity that can be granted specific API permissions via RBAC, enabling applications to interact with the Kubernetes API securely.

Explanation

RollingUpdate (the default) incrementally replaces Pods to avoid downtime, while Recreate is simpler but causes downtime — sometimes necessary when old and new versions cannot run simultaneously.

Explanation

"kubectl explain" prints API documentation for a resource or field, helping users understand what fields are available and how to structure a manifest correctly.

Explanation

Setting replicas to 0 terminates all Pods managed by the Deployment but preserves its configuration, allowing it to be scaled back up later without redefining it.

Explanation

Unlike CPU limits which throttle, exceeding a memory limit causes the kernel's OOM killer to terminate the container, which is then reported as "OOMKilled" and restarted per the Pod's restart policy.

Explanation

"kubectl wait --for=condition=<condition>" polls a resource until the specified condition is satisfied or a timeout is reached, commonly used in CI/CD scripts to wait for rollouts to complete.

Explanation

This control loop pattern (observe, diff, act, repeat) is fundamental to Kubernetes — e.g. the Deployment controller continuously ensures the actual number of Pods matches the desired replica count.

Explanation

CRDs extend the Kubernetes API with custom resource types; Operators pair CRDs with custom controllers that implement domain-specific operational logic (backups, failover, scaling) for stateful applications.

Explanation

The admission control phase sits between auth and persistence; mutating webhooks (which run first) can alter incoming objects (e.g. Istio's sidecar injector), while validating webhooks (running after mutation) enforce policy by accepting or rejecting the final object.

Explanation

Raft ensures that a majority (quorum) of etcd members agree on every write before it is committed, providing strong consistency; this is why etcd clusters are typically deployed with an odd number of members (e.g. 3 or 5) to tolerate failures while maintaining quorum.

Explanation

Resource metrics (CPU/memory) come from the Metrics Server by default; scaling on custom or external metrics (like queue depth or request latency) requires registering additional APIs, commonly via the Prometheus Adapter, that the HPA controller can query.

Explanation

The CNI specification decouples Kubernetes from specific networking implementations — the kubelet calls the configured CNI plugin to set up each Pod's network namespace, letting operators choose plugins suited to their needs (e.g. Cilium for eBPF-based policy enforcement).

Explanation

Pod Security Standards define graduated policy levels enforced via the built-in Pod Security Admission controller, restricting risky configurations (privileged containers, host namespace access, etc.) to reduce the cluster's attack surface.

Explanation

etcd performance is highly sensitive to disk write latency; co-locating it with other control plane components under heavy load can cause latency spikes affecting the whole cluster, so dedicated etcd nodes (a "stacked" vs "external" topology trade-off) are common in large deployments.

Explanation

Finalizers let controllers perform cleanup logic (e.g. releasing external cloud resources) before an object is actually removed from etcd; an object stuck "Terminating" often indicates a finalizer whose controller isn't processing it.

Explanation

A core Kubernetes networking requirement is that Pods are addressable by their own IPs across the entire cluster without NAT; CNI plugins implement this via various mechanisms (overlay networks like VXLAN, or direct routing with BGP).

Explanation

Because etcd is an MVCC store, every write creates a new revision; without periodic compaction, the keyspace history grows indefinitely, eventually causing "mvcc: database space exceeded" errors and requiring maintenance.

Explanation

While anti-affinity rules can approximate spreading by avoiding co-location, topology spread constraints provide a more direct and scalable mechanism (via maxSkew and topology keys) to balance Pods evenly across zones, nodes, or other domains.

Explanation

Client-side apply relies on a client-computed diff stored in an annotation, which can conflict when multiple tools manage the same resource; server-side apply moves this logic to the API server, tracking which "manager" owns each field for more reliable collaborative management.

Explanation

Leader election via Lease objects ensures only one controller replica actively reconciles resources at a time (avoiding duplicate or conflicting actions), while standby replicas remain ready to take over quickly if the leader becomes unavailable.

Explanation

RuntimeClass can specify a "overhead" field representing the extra resources consumed by the runtime's sandboxing mechanism (beyond the container itself), which the scheduler factors in to avoid overcommitting node resources.

Explanation

While HPA/VPA adjust Pod replica counts or resource allocations within existing capacity, Cluster Autoscaler changes the underlying infrastructure (node count) to provide or reclaim capacity, often working together with HPA in cloud environments.

Explanation

By evaluating CEL expressions in-process within the API server, ValidatingAdmissionPolicy avoids the extra network hop, latency, and potential single point of failure that an external webhook server introduces, for policies expressible in CEL.

Explanation

ownerReferences establish parent-child relationships (e.g. a ReplicaSet owns its Pods); by default, deleting the owner cascades to delete dependents, though "kubectl delete --cascade=orphan" can leave dependents behind.

Explanation

IPVS uses an efficient hash table for service lookups (O(1) versus iptables' roughly linear chain traversal), making it more scalable for clusters with a very large number of Services, and supports additional load-balancing algorithms like least connection or weighted round robin.

Explanation

Because (traditionally) a Pod's resource requests/limits are immutable once set, VPA in Recreate mode must evict the Pod and let its controller recreate it with updated resources — causing a disruption, which is why VPA is often used cautiously alongside PodDisruptionBudgets.