ReviseAlgo Logo

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.

Last Updated: June 14, 2026 • 15 min read

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: 

# application.yml configuration
spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

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: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_URL: "jdbc:postgresql://postgres-svc:5432/production_db"

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  # Base64 encoded values for: dbadmin / dbpass123
  DB_USERNAME: ZGJhZG1pbg==
  DB_PASSWORD: ZGJwYXNzMTIz


apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-api-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-api
  template:
    metadata:
      labels:
        app: spring-api
    spec:
      containers:
      - name: api-container
        image: company/spring-api:1.2.0
        ports:
        - containerPort: 8080
        env:
        - name: DB_URL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DB_URL
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: DB_USERNAME
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: DB_PASSWORD


apiVersion: v1
kind: Service
metadata:
  name: spring-api-service
spec:
  selector:
    app: spring-api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

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?

View Solution

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.