Helm Charts for Spring Boot on OpenShift

Learn how to package, configure, and deploy Spring Boot applications using Helm Charts on OpenShift. Understand Helm architecture, charts, templates, values files, releases, upgrades, rollbacks, and enterprise deployment best practices.

Introduction

Deploying a Spring Boot application to OpenShift often requires multiple Kubernetes resources.

A typical deployment includes:

Deployment
Service
Route
ConfigMap
Secret
PersistentVolumeClaim
ServiceAccount
NetworkPolicy

Managing these YAML files individually becomes difficult as applications grow.

Helm solves this problem by packaging all Kubernetes resources into a reusable Helm Chart.

Think of a Helm Chart as an installation package for Kubernetes, similar to:

Maven → JAR Dependencies
npm → JavaScript Packages
apt → Linux Packages
Helm → Kubernetes Applications

Helm simplifies deployments, upgrades, configuration management, and rollbacks.

Learning Objectives

By the end of this article, you will understand:

What is Helm?
Helm Architecture
Helm Charts
Templates
Values Files
Releases
Spring Boot Deployment
Upgrade & Rollback
Enterprise Best Practices

What is Helm?

Helm is the package manager for Kubernetes.

It packages Kubernetes manifests into reusable applications called Charts.

Benefits:

Reusable deployments
Parameterized configurations
Easy upgrades
Easy rollbacks
Environment-specific configuration
Version-controlled deployments

Helm Architecture

flowchart LR
    A[Developer]
    B[Helm Chart]
    C[Helm CLI]
    D[OpenShift API]
    E[OpenShift Cluster]

    A --> B
    B --> C
    C --> D
    D --> E

Without Helm

flowchart LR
    A[deployment.yaml]
    B[service.yaml]
    C[route.yaml]
    D[configmap.yaml]
    E[secret.yaml]

    A --> F[OpenShift]
    B --> F
    C --> F
    D --> F
    E --> F

Managing many YAML files becomes difficult.

With Helm

flowchart LR
    A[Helm Chart]
    B[Deployment]
    C[Service]
    D[Route]
    E[ConfigMap]
    F[Secret]
    G[OpenShift]

    A --> B
    A --> C
    A --> D
    A --> E
    A --> F

    B --> G
    C --> G
    D --> G
    E --> G
    F --> G

Spring Boot Deployment Workflow

sequenceDiagram
    participant Dev as Developer
    participant Helm
    participant OpenShift

    Dev->>Helm: helm install
    Helm->>OpenShift: Create Resources
    OpenShift-->>Dev: Application Running

Helm Concepts

Component	Description
Chart	Kubernetes Application Package
Release	Running Instance of a Chart
Repository	Storage for Charts
Values	Configuration Variables
Templates	Parameterized YAML Files

Helm Chart Structure

payment-chart/

├── Chart.yaml
├── values.yaml
├── charts/
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── route.yaml
    ├── configmap.yaml
    ├── secret.yaml
    └── serviceaccount.yaml

Helm Chart Architecture

flowchart TD
    A[Chart.yaml]
    B[values.yaml]
    C[Templates]

    D[Deployment]
    E[Service]
    F[Route]
    G[ConfigMap]

    A --> C
    B --> C

    C --> D
    C --> E
    C --> F
    C --> G

Chart.yaml

apiVersion: v2

name: payment-service

description: Spring Boot Payment Service

type: application

version: 1.0.0

appVersion: "1.0.0"

Chart metadata is stored here.

values.yaml

replicaCount: 2

image:
  repository: quay.io/company/payment-service
  tag: "1.0.0"

service:
  port: 8080

route:
  host: payment.apps.company.com

Configuration values are centralized.

Deployment Template

apiVersion: apps/v1

kind: Deployment

metadata:

  name: {{ .Release.Name }}

spec:

  replicas: {{ .Values.replicaCount }}

Helm replaces placeholders during deployment.

Template Rendering

flowchart LR
    A[values.yaml]
    B[Deployment Template]
    C[Rendered YAML]
    D[OpenShift]

    A --> B
    B --> C
    C --> D

Install Helm Chart

helm install payment payment-chart

Creates a new Release.

Release Architecture

flowchart LR
    A[Helm Chart]
    B[Release]
    C[Deployment]
    D[Pods]

    A --> B
    B --> C
    C --> D

Upgrade Application

Update image version.

image:

  tag: "2.0.0"

Deploy

helm upgrade payment payment-chart

Upgrade Flow

flowchart LR
    A[Version 1.0]
    B[Helm Upgrade]
    C[Version 2.0]

    A --> B
    B --> C

Rollback

View Release History

helm history payment

Rollback

helm rollback payment 1

Rollback Workflow

flowchart LR
    A[Release 1]
    B[Release 2]
    C[Release 3]
    D[Rollback]

    C --> D
    D --> B

Environment Configuration

Different environments use different values files.

values-dev.yaml

values-qa.yaml

values-prod.yaml

Deploy Development

helm install payment payment-chart \
-f values-dev.yaml

Deploy Production

helm install payment payment-chart \
-f values-prod.yaml

Multi-Environment Architecture

flowchart LR
    A[Helm Chart]

    B[Dev Values]

    C[QA Values]

    D[Prod Values]

    E[OpenShift Dev]

    F[OpenShift QA]

    G[OpenShift Prod]

    A --> B
    A --> C
    A --> D

    B --> E
    C --> F
    D --> G

Enterprise Banking Example

flowchart LR
    A[Developer]
    B[Git Repository]
    C[Tekton Pipeline]
    D[Container Registry]
    E[Helm Chart]
    F[Argo CD]
    G[OpenShift Production]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G

Tekton builds the image.

Helm packages the deployment.

Argo CD deploys the Helm release.

Helm Repository

Store reusable charts.

Examples:

Harbor
JFrog Artifactory
Nexus
GitHub Pages
OCI Registry

Common Helm Commands

Create Chart

helm create payment-chart

Install

helm install payment payment-chart

Upgrade

helm upgrade payment payment-chart

Rollback

helm rollback payment 1

List Releases

helm list

Delete Release

helm uninstall payment

Enterprise Deployment Flow

flowchart LR
    A[Git Commit]
    B[Tekton]
    C[Build Image]
    D[Push Registry]
    E[Update Helm Values]
    F[GitOps Repository]
    G[Argo CD]
    H[OpenShift]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H

Common Problems

Template Error

Check

helm lint payment-chart

Invalid YAML

Render templates locally.

helm template payment-chart

Upgrade Failed

Review

helm status payment

Rollback Required

Execute

helm rollback payment 2

Production Best Practices

Keep one Helm Chart per microservice.
Use separate values files for each environment.
Store Secrets outside Helm values.
Version every chart.
Validate charts using helm lint.
Use immutable image tags.
Store charts in a central repository.
Integrate Helm with Argo CD.
Review chart changes through Pull Requests.
Keep templates reusable and modular.

Common Mistakes

❌ Hardcoding environment values.

❌ Using the same values file for every environment.

❌ Storing passwords in values.yaml.

❌ Skipping helm lint.

❌ Deploying directly without versioning.

❌ Using mutable image tags like latest.

Advantages

Reusable deployments
Parameterized configuration
Easy upgrades
Easy rollback
Environment-specific deployments
Version control
GitOps friendly
Enterprise ready

Summary

Helm simplifies deploying Spring Boot applications on OpenShift by packaging multiple Kubernetes resources into reusable Charts.

Key takeaways:

Helm Charts package Kubernetes manifests into deployable units.
Templates and values files make deployments reusable and configurable.
Releases enable version tracking, upgrades, and rollbacks.
Environment-specific values improve deployment consistency.
Combining Helm, Tekton, and Argo CD creates a modern enterprise deployment platform.

Interview Questions

What is Helm?
What is a Helm Chart?
What is the purpose of values.yaml?
What is the difference between a Chart and a Release?
How does Helm template rendering work?
How do you upgrade a Helm release?
How do you roll back a failed deployment?
Why should different environments use different values files?
How does Helm integrate with Argo CD?
What are the best practices for Helm Charts?