Part 4 – Kubernetes Interview Questions & Answers (Q.16 to Q.20)

16. What is a Kubernetes persistent volume (PV), and how does it differ from a persistent volume claim (PVC)?
17. How do you manage configuration files (such as YAML manifests) for Kubernetes resources?
18. What is the purpose of a Kubernetes init container?
19. Explain the concept of a Kubernetes daemon set.
20. How can you perform rolling restarts for pods in a Kubernetes deployment?

16. What is a Kubernetes persistent volume (PV), and how does it differ from a persistent volume claim (PVC)?

Persistent Volume (PV): A unit of storage provisioned and managed by a Kubernetes administrator. PVs represent actual storage resources within the cluster (e.g., NFS, cloud disks, iSCSI). They have lifecycles independent of any particular pod.

Persistent Volume Claim (PVC): A request for storage made by a Kubernetes user (developer). PVCs specify storage size, access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), and optionally, storage classes. Kubernetes attempts to match PVCs with suitable PVs.

Use Cases:

PVs: Created by administrators to offer pre-configured storage options to users.
PVCs: Used by developers to request storage without dealing with low-level provisioning details.

Example:

A database pod needs persistent storage.

Admin provisions a PV (e.g., 10GiB NFS volume).
Developer creates a PVC requesting 8GiB storage with ReadWriteOnce access.
Kubernetes binds the PVC to the PV, allowing the database pod to use it.

17. How do you manage configuration files (such as YAML manifests) for Kubernetes resources?

YAML Configuration Files: Kubernetes resources are defined using YAML (or JSON) files. These describe the desired state of objects like pods, deployments, services, etc.
Version Control (e.g., Git): Configuration files are kept under version control for tracking changes, easy collaboration, and rollback capability.
Declarative Management (kubectl): The kubectl command-line tool is used to apply (create or update) resources from YAML files to the Kubernetes cluster. This enforces a declarative state management model.
Configuration Management Tools (Helm, Kustomize): These tools offer templating, customization, and more sophisticated ways to manage complex Kubernetes manifests across environments.

Use Cases:

Deployment: Creating new resources or updating existing ones with changes in YAML files.
Rollbacks: Reverting to previous application states using older manifest versions.
Collaboration: Teams work on shared configuration in version control.

18. What is the purpose of a Kubernetes init container?

Init containers are specialized containers that run to completion before the main application containers within a pod start. They perform setup tasks and must exit successfully for the pod to launch.

Use Cases:

Data Preloading: Downloading files or populating a shared volume.
Configuration: Preparing configuration files or fetching secrets.
Environment Checks: Waiting for dependencies to become available.
Tool Execution: Running a setup script or migration tool.

Example:

A pod needs a config file generated from an external system:

An init container fetches the configuration and places it in a shared volume.
The main application container reads the generated configuration on startup.

19. Explain the concept of a Kubernetes daemon set.

A Kubernetes daemon set ensures that a single instance of a pod runs on every (or a selected group of) worker nodes in the cluster. The daemon pod is scheduled automatically on new nodes as they join.

Use Cases:

Monitoring Agents: Running a log collection or monitoring daemon on every node.
Cluster Storage Daemons: Deploying storage components on each node for distributed storage solutions.
Node Maintenance Tasks: Scheduled jobs on every node.

Example:

A monitoring tool needs to collect node metrics:

A daemon set schedules a pod with the monitoring tool on all worker nodes.

20. How can you perform rolling restarts for pods in a Kubernetes deployment?

Rolling restarts in Kubernetes gracefully replace pods in a deployment for zero-downtime updates. New pods are brought up one by one, while old instances are simultaneously terminated.

Use Cases: