Docker & Kubernetes Deployment
Deploying to Kubernetes — Deployment, Service, ConfigMap, Secret
Writing full YAML specs to configure and expose Spring Boot apps inside clusters.
Interview: Kubernetes application manifests design. Expect questions on mapping Spring properties to ConfigMaps, mounting secrets securely, and exposure configurations.
Introduction
Hardcoding environment-specific settings (like database URLs or API keys) inside your container image forces you to rebuild images for every deployment stage. This violates containerization best practices, which dictate using the same image across all environments.
**Kubernetes** solves this by decoupling configurations and credentials from your application image using **ConfigMaps** and **Secrets**. These values are mounted into your container as environment variables or files at runtime.
Why It Matters
Decoupling configurations allows you to change settings (e.g. logging levels, credentials) instantly without rebuilding container images, while securing sensitive data in memory.
Spring Boot Kubernetes Decoupling Pattern
When running inside Kubernetes, map environment variables directly to your properties file placeholders:
The variables (like DB_URL) are injected by the Kubernetes container spec, pulling values from ConfigMaps and Secrets.
Practical Example
Let's write a complete Kubernetes manifest file orchestrating a ConfigMap, a Secret, a Deployment, and a ClusterIP Service:
Quick Quiz
Q1: What is the main design advantage of using ClusterIP instead of NodePort for database-dependent microservices inside the cluster?
A) It makes the service accessible from the public internet.
B) It restricts service access to within the cluster, protecting endpoints from external networks.
C) It encrypts the target database traffic.
D) It automates horizontal scaling of pods.
Answer: B — ClusterIP exposes services on an internal cluster IP, preventing external traffic from connecting directly to internal endpoints.
Scenario-Based Challenge
Production Scenario:
You apply your Deployment manifest, but the Pods remain in a CreateContainerConfigError state. What does this error mean, and how do you resolve it?
To debug and resolve the configuration error:
1. **Inspect the Error:** Run kubectl describe pod [pod-name] to find the error details.
2. **Identify the Cause:** A CreateContainerConfigError means the deployment spec references a ConfigMap or Secret (or key) that does not exist in the namespace.
3. **Apply Configurations First:** Ensure that all ConfigMap and Secret manifests are successfully created in the cluster *before* applying the Deployment manifest.
Interview Questions
1. How do you refresh Spring properties when a ConfigMap changes without restarting the Pod?
By using Spring Cloud Kubernetes or Spring Cloud Config Server combined with Spring Actuator's /actuator/refresh endpoint. Annotate configurations with @RefreshScope to allow updating bean properties dynamically at runtime when a refresh event is triggered.
Production Considerations
Avoid checking base64-encoded Secrets manifests into public git repositories. Use GitOps tools like SealedSecrets or external secrets operators (like HashiCorp Vault integrations) to manage sensitive production credentials.