Deploying a simple application to kubernetes with Helm

Shipping an application to a Kubernetes cluster often feels heavier than the application itself, especially when the same handful of files is being copied between environments. Helm steps into that gap by treating a bundle of manifests, defaults, and templates as a single chart that can be versioned, shared, and reinstalled. Instead of wrestling with raw YAML on every release, operators describe what they want and let the tool reconcile the cluster toward that state. The result is a deployment flow that reads more like publishing a package than orchestrating infrastructure by hand.

A chart is really a small directory with a purpose. Inside, a values file acts as the public surface area, exposing the knobs that other developers are expected to touch. Templates reference those values, fill in defaults, and produce the resources the cluster needs. Because the inputs and outputs are both plain text, the same chart can be inspected in code review, diffed between releases, and rolled back with a single command. Reviewing what changed becomes a habit rather than an afterthought.

Getting started does not require a production-sized cluster. A local environment is enough to install the Helm CLI, add a repository, and push a freshly built image into a simple deployment. From there, the focus shifts toward clarity: naming conventions for releases, sensible defaults for replicas and resources, and a values file that documents itself through comments. Helm’s commands read like a deployment language, describing intent rather than procedure, which makes the learning curve forgiving for teams new to container orchestration.

Beyond the basics, Helm earns its keep when applications grow. Multiple environments can share one chart and diverge only where they must, such as domain names, replica counts, or feature flags. Hooks let pre-upgrade jobs run migrations before new pods start, and subcharts keep shared dependencies tidy. With a tidy structure in place, the chart doubles as living documentation of how the service is meant to run, which is invaluable when onboarding new engineers or handing the project to another team.

Like any tool that promises simplicity, Helm rewards discipline. Keeping templates close to upstream, avoiding clever logic, and treating the values file as an API all make upgrades and rollbacks smoother. Pairing Helm with a visual dashboard or a diff tool adds another layer of confidence, since reviewers can see the rendered manifests before they ever reach the cluster. Used well, the result is a deployment pipeline that feels less like pushing artifacts and more like publishing a versioned release that anyone on the team can reason about.

To get started, it's necessary to create your cluster on Google Cloud. Once you get your cluster created, we can now create our html page that will be our "application".

Creating and Pushing the docker image

Let's create a HTML page and publish it to a docker image.

mkdir simple-app
cd simple-app
touch index.html
vim index.html

The Dockerfile would be something really simple, for example:

FROM nginx:alpine
COPY . /usr/share/nginx/html

The docker image should be in a Docker Registry .

Using helm

If you never used helm, it helps you deploy and manage your kubernetes applications. In this tutorial, helm will be used to kick start our kubernetes deployment.

You should install helm first.

helm create simple-app

This will create all the files from helm.

  .
  ├── Chart.yaml
  ├── charts
  ├── templates
  │   ├── NOTES.txt
  │   ├── _helpers.tpl
  │   ├── deployment.yaml
  │   ├── ingress.yaml
  │   ├── service.yaml
  │   └── tests
  │       └── test-connection.yaml
  └── values.yaml

Let’s open the file values.yaml . We need to point the repository to our container registry URL, and also the tag.

image:
  repository: <YOUR CONTAINER REGISTRY GOES HERE>
  tag: <YOUR TAG GOES HERE>
  pullPolicy:IfNotPresent

In the same file, let’s change the service that comes to be a LoadBalancer and set this to the port 80.

service:
  type:LoadBalancer
  port:80

This will make helm create our external load balancer, and it automatically links it to our application. That's all, the application can be deployed.

helm install ./simple-app

The helm install command creates the external load balancer and setup our application in the cluster.

Once it is deployed, it is possible to run kubectl get services and see that the load balancer is there.

Updating the application

In case you want to update the application, for example, if you want to change the content of our HTML page. You can use the helm upgrade command.

To do it, you need to push a new tag of your container, and run:

  helm upgrade ./simple-app

And helm handles everything for you!

Today we saw how to use helm to deploy a kubernetes application, and how to update it. In this example, just a simple HTML page was used, it was intentional just to show how easy a deploy with kubernetes can be.

Deploying a simple application to kubernetes with Helm

GraphQL: Zero to Awesome

Creating and Pushing the docker image

Using helm

Updating the application

SMOOTH TERMINAL