KCNA Sample Questions & Answers

The Horizontal Pod Autoscaler (HPA) automatically scales the number of pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or with custom metrics support, on some other application-provided metrics). This is the standard Kubernetes mechanism for scaling out stateless applications based on load.

Kubernetes Secrets are designed specifically for storing and managing sensitive information, such as passwords, OAuth tokens, and ssh keys. They can be mounted as data volumes or exposed as environment variables to a container in a Pod. While they are base64 encoded by default (not encrypted), they are the designated Kubernetes object for handling sensitive data separately from pods and ConfigMaps.

The kubelet, which runs on every worker node, is responsible for managing the lifecycle of pods on that node. It exposes a /metrics endpoint that provides detailed metrics about the node itself and the containers running on it, including container states, restarts, and resource usage. Prometheus is configured to scrape this endpoint on each node to collect these vital metrics for monitoring and alerting.

The Container Network Interface (CNI) is a standard for writing plugins to configure network interfaces for Linux containers. In Kubernetes, the kubelet uses a CNI plugin (like Calico, Flannel, or Cilium) to handle networking tasks when a pod is created or destroyed. This includes assigning an IP address to the pod, setting up routes, and ensuring it can communicate with other pods according to the cluster's networking model.

A Canary Release is a deployment strategy where the new version of an application is gradually rolled out to a small subset of users. Traffic is selectively routed to the new version, allowing teams to monitor its performance and stability in a real production environment. If the new version performs well, traffic is incrementally shifted until all users are on the new version. This matches the described scenario.

The OCI's core mission is to create open industry standards around container formats and runtimes. It maintains two key specifications: 1) The Runtime Specification (runtime-spec), which defines how to run a 'filesystem bundle' as a container. 2) The Image Specification (image-spec), which defines the format of a container image. These standards allow different runtimes (like runC, containerd) to run images created by different build tools (like Docker, Buildah).

A DaemonSet is the correct Kubernetes resource to ensure that a copy of a pod runs on all (or some) nodes. By default, DaemonSets do not run on control plane nodes because these nodes usually have taints (e.g., node-role.kubernetes.io/control-plane:NoSchedule). To run on every worker but not the control plane, a standard DaemonSet is sufficient as it won't have the necessary toleration to be scheduled on the tainted control plane nodes.

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. All objects, states, and configurations of the Kubernetes cluster are stored in etcd, making it the single source of truth for the control plane.

Spot instances (or preemptible VMs) are unused compute capacity offered by cloud providers at a significant discount compared to on-demand prices. They can be terminated with very little notice, making them ideal for fault-tolerant, interruptible workloads like batch processing. In Kubernetes, nodes from spot instance groups are typically tainted, and the batch job pods must have the corresponding toleration to be scheduled on them.

This combination correctly addresses all requirements:

1. ClusterIP Services: Creating a Service of type ClusterIP for each microservice (product-catalog, shopping-cart, payment-gateway) makes them discoverable and accessible to each other via DNS within the cluster.
2. Ingress Resource: An Ingress resource is needed to configure the Ingress controller. It will define the rule to route traffic from api.shopfast.com/products to the product-catalog Service.
3. Secret: To secure the Ingress with HTTPS, a Kubernetes Secret of type kubernetes.io/tls is used to store the TLS private key and certificate, which is then referenced in the Ingress resource.