Part 11 – Kubernetes Interview Questions & Answers (Q.51 to Q.55)

Q.51 What is the role of a Kubernetes admission controller, and how can you customize it?

Admission Controllers: Intercept API requests after authentication and authorization but before an object is persisted. They can validate or mutate objects according to configured rules.
Built-in Controllers: Kubernetes comes with controllers like PodSecurityPolicy, LimitRanger, etc.
Custom Admission Controllers: You can write webhooks for your own logic to enforce policies, inject sidecars, or modify submitted objects.

Use Cases:

Policy enforcement: Require labels, resource limits, or conform to specific standards.
Configuration defaults: Automatically add sidecar containers or set annotations on incoming Pods.
External integrations: Validate against external systems for security or compliance checks.

Horizontal Pod Autoscaler (HPA): Typically scales Pods based on built-in metrics like CPU and memory. Kubernetes’ Metrics Server collects these.
Custom Metrics Server: Adapt this server to expose your own metrics (e.g., requests per second, queue depth)
Custom Metrics in HPA: The HPA can then base scaling decisions on your custom metrics for more fine-tuned, application-specific autoscaling behavior.

Use Cases:

Application-specific metrics: Scale based on business-relevant data that CPU or memory don’t reflect.
External systems: Scale pods based on metrics from message queues, databases, or other services outside Kubernetes.

Example:

Custom metric tracking the number of messages in a Kafka queue. The HPA scales out if the queue depth exceeds a threshold.

There are two primary approaches to multi-tenancy in Kubernetes:

Namespace-based isolation (Soft Multi-tenancy): Separate tenants into different namespaces. Enforce security and resource usage limits using:
- Role-Based Access Control (RBAC): Control permissions
- Resource Quotas: Set limits on CPU, memory, and storage per namespace.
- Network Policies: Restricting network traffic between namespaces.
Cluster-based isolation (Hard Multi-tenancy): Each tenant gets a dedicated Kubernetes cluster. Pros: Strong isolation, avoids noisy neighbor problems. Cons: Increased management overhead.

Use Cases:

SaaS Providers: Often use namespace-based isolation to run multiple clients on shared infrastructure.
Highly Regulated Environments: Cluster-based isolation may be mandated if strong security boundaries are required.

Example:

In namespace-based multi-tenancy, define two namespaces, “tenant-a” and “tenant-b,” and isolate resources and permissions using RBAC, Resource Quotas, and Network Policies.

Kubernetes Job: Designed to run a task or workload to completion once. The Job controller ensures Pods run successfully through completion.
Kubernetes CronJob: Designed for running recurring tasks on a defined schedule (similar to traditional cron). It creates Jobs according to the schedule you provide.

Use Cases:

Jobs: Tasks with a definite start and end like batch processing, database cleanup, or report generation.
CronJobs: Periodic tasks like scheduled backups, log rotation, or sending email notifications.

Example:

Multiple etcd nodes: Deploy an odd number of etcd replicas (typically 3 or 5) to form a cluster. This tolerates individual node failures while maintaining quorum.
Distributed across failure domains: Place etcd nodes across different availability zones or datacenters to increase resilience to wider outages.
Load Balancing: Consider a load balancer in front of your etcd cluster for distributing traffic and providing a single point of access.
Regular Snapshots/Backups: Have a snapshot process or backup strategy to recover in case of data loss.

Use Cases:

Any production Kubernetes cluster: etcd is the backbone of the Kubernetes control plane. Making it highly available is crucial for cluster stability.

Example: