Deploying Spring Boot Apps to Kubernetes with Helm and Kustomize
As organizations move towards cloud-native architectures, deploying Spring Boot applications on Kubernetes has become increasingly common. However, production deployment involves more than just pushing containers—it requires effective configuration management, secret handling, and deployment strategies that are scalable, secure, and maintainable.
In this article, we’ll explore how Helm and Kustomize can help you deploy Spring Boot applications on Kubernetes and how to manage configuration and secrets securely in production environments.
Why Use Kubernetes for Spring Boot?
Spring Boot makes it easy to build standalone, production-ready apps. Kubernetes provides the infrastructure to run and scale those apps in a resilient, self-healing way. Together, they form a powerful duo for building modern applications.
Benefits include:
- Container orchestration and scaling
- Service discovery and load balancing
- Rolling updates and rollbacks
- Infrastructure abstraction and portability
But as deployments grow more complex, we need tools to handle templating and configuration.
Helm: The Kubernetes Package Manager
What Is Helm?
Helm is a package manager for Kubernetes that simplifies deploying and managing applications by using charts—predefined templates that describe the resources.
Why Use Helm?
- Templating Engine: Parameterize your YAML files to avoid repetition.
- Versioned Releases: Easy rollbacks and upgrades.
- Ecosystem: Rich community of existing charts.
Deploying Spring Boot with Helm
A typical Helm chart structure for a Spring Boot app might include:
spring-boot-app/ ├── charts/ ├── templates/ │ ├── deployment.yaml │ ├── service.yaml │ └── secrets.yaml ├── values.yaml └── Chart.yaml
You can use values.yaml to parameterize your deployment:
image: repository: myrepo/spring-boot-app tag: latest env: SPRING_PROFILES_ACTIVE: prod
Run deployment:
helm install my-app ./spring-boot-app
Kustomize: Native Kubernetes Configuration Management
What Is Kustomize?
Kustomize is a Kubernetes-native configuration tool built into kubectl. Unlike Helm, it avoids templating and instead patches and overlays base YAML manifests.
Why Use Kustomize?
- No Templating Language: Pure YAML with overlays
- Declarative: Changes are made via patches
- Ideal for GitOps workflows
Deploying Spring Boot with Kustomize
Base configuration:
base/ ├── deployment.yaml ├── service.yaml └── kustomization.yaml
Production overlay:
overlays/production/ ├── kustomization.yaml └── patch-deployment.yaml
Sample patch:
apiVersion: apps/v1
kind: Deployment
metadata:
name: spring-boot-app
spec:
template:
spec:
containers:
- name: app
image: myrepo/spring-boot-app:prod
env:
- name: SPRING_PROFILES_ACTIVE
value: prod
Apply with:
kubectl apply -k overlays/production
Helm vs. Kustomize: Which to Use?
| Feature | Helm | Kustomize |
|---|---|---|
| Templating | ✅ (Go templates) | ❌ |
| Overlay Support | 🚧 (via subcharts or values) | ✅ |
| Learning Curve | Moderate | Easy |
| GitOps Integration | ✅ (via FluxCD, ArgoCD) | ✅ |
| Secret Management | Requires plugins | Native with kubectl |
Opinion:
Helm is great for reusable packages and community charts, while Kustomize shines when you want fine-grained control over environment-specific overlays. In many real-world projects, teams use both: Helm for base app packaging and Kustomize for environment overlays.
Managing Configuration in Production
Spring Boot externalizes configuration using application.properties or application.yml, which can be managed via:
- ConfigMaps (for non-sensitive data)
- Secrets (for sensitive data like API keys)
Using Kubernetes ConfigMaps
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
application.yaml: |
server:
port: 8080
spring:
datasource:
url: jdbc:mysql://db:3306/mydb
Mount as volume or use as environment variable.
Using Kubernetes Secrets
apiVersion: v1 kind: Secret metadata: name: app-secret type: Opaque data: DB_PASSWORD: bXlzdXBlcnNlY3JldA== # base64 encoded
Access in your Spring Boot app using:
spring:
datasource:
password: ${DB_PASSWORD}
Important: Avoid committing secrets to Git. Use tools like Sealed Secrets, Vault, or External Secrets Operator to manage secrets securely.
Tools for Secure Secret Management
| Tool | Description |
|---|---|
| Bitnami Sealed Secrets | Encrypt secrets into SealedSecret resources which are safe to store in Git |
| HashiCorp Vault | Centralized secret storage with dynamic secrets and access policies |
| External Secrets Operator | Sync secrets from external stores (AWS Secrets Manager, Azure Key Vault) into Kubernetes Secrets |
Best Practice:
Use a GitOps-friendly solution like Sealed Secrets or External Secrets Operator for automation, auditability, and compliance.
Conclusion
Deploying Spring Boot apps on Kubernetes isn’t just about running containers—it’s about building a maintainable, secure, and scalable deployment pipeline. Helm and Kustomize each offer powerful capabilities, and when used together, they give teams a flexible way to manage deployments across environments.
Key takeaways:
- Use Helm for packaging and reuse.
- Use Kustomize for environment-specific overlays.
- Manage configuration with ConfigMaps and secrets with Kubernetes Secrets or external secret managers.
- Ensure security with tools like Vault and Sealed Secrets.
With the right combination of tools and best practices, your Spring Boot applications will be well-prepared for production in the cloud-native world.




