Introduction

When a Helm deployment of Sentry creates an extra load balancer, the reason is usually not "Helm did something strange." Helm only rendered the chart. The real cause is that one or more Services in the chart, or in dependent infrastructure such as an ingress controller, were configured as type: LoadBalancer, so Kubernetes provisioned cloud load balancers for each of them.

Find which Service actually triggered the load balancer

The first debugging step is to list Services after the release is installed:

kubectl get svc -n sentry

Look for every Service whose TYPE is LoadBalancer. Each one can create a cloud load balancer.

In a Sentry deployment, the extra external endpoint may come from:

• the main web service
• an ingress controller installed alongside the chart
• another chart dependency or addon

Helm is just applying YAML. The Service type is what matters.

Inspect chart values, not only the cloud console

If you installed with a values.yaml, inspect the effective values:

helm get values sentry -n sentry

Then compare that with the rendered manifests:

helm get manifest sentry -n sentry

You are looking for Services declared like this:

spec:
  type: LoadBalancer

If more than one rendered Service has that type, more than one load balancer is expected.

Common Sentry deployment patterns

A typical production setup uses one of these approaches:

• keep internal Services as ClusterIP and expose Sentry through a separate Ingress
• expose exactly one Service as LoadBalancer
• run an ingress controller as the only external entry point

Problems happen when those patterns get combined unintentionally. For example, if the Sentry web service is LoadBalancer and the ingress controller Service is also LoadBalancer, you can end up paying for two external load balancers.

A common values pattern is to keep the app service internal:

service:
  type: ClusterIP

and let ingress handle public traffic:

ingress:
  enabled: true

That keeps the external surface area deliberate.

Fix the chart input, then upgrade

Once you identify the extra Service, fix the values and redeploy:

helm upgrade sentry sentry/sentry -n sentry -f values.yaml

For example, if the app should only be reachable through ingress, change the relevant Service type from LoadBalancer to ClusterIP. If ingress is not needed, disable it and keep only one external Service.

The point is to make the external topology explicit in chart values rather than cleaning up cloud resources manually after each deploy.

If you are unsure which values created the second exposure path, render the chart locally first and search for type: LoadBalancer. That usually makes the duplication obvious before another upgrade reaches the cluster.

Common Pitfalls

The most common mistake is blaming Helm for provisioning resources that were explicitly described by the chart. Helm rendered what the values requested.

Another mistake is forgetting that an ingress controller often has its own LoadBalancer Service. Teams sometimes count only the application chart and forget the controller that fronts it.

Developers also inspect only the cloud console instead of the Kubernetes manifests. The cloud load balancer is the result, not the root cause.

Finally, deleting the extra cloud load balancer directly is only a temporary fix if the Kubernetes Service still exists with type: LoadBalancer.

Summary

• Helm does not create load balancers by itself; Service objects of type LoadBalancer do.
• Check all rendered Services in the Sentry deployment and related ingress stack.
• It is common to accidentally expose both the app Service and the ingress controller externally.
• Prefer a deliberate topology, usually ClusterIP behind one ingress or one external Service.
• Fix chart values and re-upgrade instead of manually deleting the cloud resource.