Part 7 – Kubernetes Interview Questions & Answers (Q.31 to Q.35)

Q.31 What is a Kubernetes StatefulSet, and when would you use it?
Q.32 How do you handle secrets and sensitive data in Kubernetes securely?
Q.33 Discuss the benefits and drawbacks of using Helm charts for application deployment.
Q.34 What is a Kubernetes custom resource (CR), and how can you create one?
Q.35 How do you set resource limits and requests for containers in a Kubernetes pod?

Q.31 What is a Kubernetes StatefulSet, and when would you use it?

A Kubernetes StatefulSet is a controller that manages the deployment and scaling of pods with a focus on preserving state, guaranteeing ordered deployments/deletions, and providing stable network identity.

StatefulSets handle applications that rely on persistent storage (databases, message queues) or require their pods to have unique, persistent network identifiers.

Use Cases:

Databases: (e.g., MongoDB, Cassandra, or MySQL) to maintain data consistency and reliability.
Clustered Applications: Applications that need coordinated operation, such as Zookeeper or Kafka clusters.
Applications Requiring Stable Identifiers: Apps where each pod needs its own unique name/hostname (e.g., for peer-to-peer communication).

Q.32 How do you handle secrets and sensitive data in Kubernetes securely?

Kubernetes Secrets: Built-in objects designed to store small amounts of sensitive data (usernames, passwords, API tokens). Secrets are base64 encoded and not fully encrypted by default.

Best Practices:

Encryption at Rest: Consider using an external secret management solution that integrates with Kubernetes (e.g., HashiCorp Vault, AWS Secrets Manager).
RBAC (Role-Based Access Control): Strictly control access to secrets using RBAC.
Minimize Secret Exposure: Limit the number of pods with access to a secret using pod selectors. Consider injecting secrets as environment variables or via volume mounts as needed, rather than including them directly in pod definitions.

Use Cases:

Database Passwords: Avoid storing database credentials directly in Pod specs.
API Keys: Prevent hardcoding API keys into application configuration.
TLS Certificates: Securely store certificates for HTTPS connections.

Q.33 Discuss the benefits and drawbacks of using Helm charts for application deployment.

Helm: A package manager for Kubernetes that simplifies the process of defining, versioning, installing, and managing Kubernetes applications. Helm charts bundle together Kubernetes resource definitions as a single unit of deployment.

Benefits:

Reusability: Predefined Helm charts for common applications promote faster and more consistent deployments.
Versioning: Version management capabilities ease tracking, rollbacks, and upgrades.
Complexity Management: Charts allow you to define complex applications with dependencies as packaged entities.

Drawbacks:

Steeper Learning Curve: Understanding Helm concepts and syntax requires investment.
Potential Complexity: Extensive use of charts and overrides can create a maintenance burden.
Security: Be mindful of the provenance of public Helm charts and carefully review them before use.

Q.34 What is a Kubernetes custom resource (CR), and how can you create one?

Custom Resources (CRs): CRs enable the extension of the Kubernetes API to manage your own custom objects/state representing applications or infrastructure components.

Custom Resource Definitions (CRDs): A CRD defines the schema and structure of your custom resource (similar to a blueprint).

Controllers: To handle CRs, you need to develop a controller (software) that observes changes and takes action to reconcile the desired state defined in your CRs.

Use Cases:

Application Management: Create CRs to manage the lifecycle of complex applications and define custom states to control them.
Operator pattern: Develop Kubernetes Operators to automate operational tasks (backups, upgrades, etc.) related to your custom resources.
Integration of External Systems: Create CRs to represent resources in external systems and manage them via the Kubernetes API.

Q.35 How do you set resource limits and requests for containers in a Kubernetes pod?

Resource Requests: Guarantee a minimum allocation of resources (CPU, memory) for a container. Kubernetes scheduler makes placement decisions based on requests.

Resource Limits: Define the maximum CPU and memory a container is allowed to use. Prevents a container from monopolizing cluster resources.

Setting limits and requests in Pod Spec: