Centralizing Helm: Why Ingress Failed and HTTPProxy Won

As organizations grow, so does the complexity of managing Kubernetes manifests. A natural evolution is moving to centralized “umbrella” Helm charts. The promise is alluring: consistency across services, reduced duplication, and a streamlined CI/CD pipeline where global policies (like security and resource limits) are enforced in one place.

However, this refactor often exposes hidden architectural limitations. Recently, our team underwent this transition to consolidate several microservices under a shared domain. What seemed like a straightforward migration quickly led to a critical deployment failure.

Here is the story of why the standard Kubernetes Ingress failed us and how switching to Project Contour’s HTTPProxy saved our GitOps workflow.

The Conflict: Ingress and the “Shared Resource”

The trouble began when we moved two services—Service A (root /) and Service B (path /app1)—into the same namespace under a centralized chart. In a decentralized world, each service manages its own Ingress resource. But in a centralized world, they began to fight.

Why Ingress Broke:

• Namespace Scoping: Kubernetes Ingress is a namespace-scoped resource. When multiple “Applications” in a tool like ArgoCD try to manage an Ingress with the same host or name in the same namespace, you hit the dreaded SharedResourceWarning.
• Lack of Native Merging: Standard Ingress doesn’t “merge” well. If two different Helm releases try to claim api.example.com, they often overwrite each other. One service “steals” the route, causing 404s for the other.
• Annotation Overload: To handle complex routing or SSL, we found ourselves drowning in vendor-specific annotations that made the YAML unreadable and fragile.

The Solution: Switching to HTTPProxy

To resolve this, we disabled the standard Ingress and implemented HTTPProxy, a Custom Resource Definition (CRD) provided by Project Contour.

Unlike Ingress, HTTPProxy was designed for multi-team, multi-service environments. It introduces a hierarchical structure that allows a “root” proxy to delegate paths to “child” proxies or simply define multiple service backends in one clean manifest.

The Transformation

Our configuration shifted from fragmented Ingress manifests to a single, unified HTTPProxy:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: centralized-router
spec:
  virtualhost:
    fqdn: app.example.com
    tls:
      secretName: global-tls-cert
  routes:
    - conditions:
        - prefix: /
      services:
        - name: service-a
          port: 80
    - conditions:
        - prefix: /app1
      services:
        - name: service-b
          port: 80

Why This Fixed Everything

1. Eliminated ArgoCD Conflicts: By using a single HTTPProxy resource to manage multiple service paths, we removed the resource ownership clash. ArgoCD now sees one clear “owner” for the routing logic, and the SharedResourceWarning vanished.
2. Built-in Multi-Tenancy: HTTPProxy allows for Delegation. If we ever want to give “Service B” control back over its own routing, we can delegate the /app1 path to a separate HTTPProxy in a different namespace without ever touching the root TLS settings or DNS.
3. “Secure First” Architecture: Project Contour follows a secure-first approach. TLS is handled natively in the spec, not hidden in annotations. It also provides better validation at creation time, preventing “broken” configurations from ever reaching the cluster.

Lessons Learned

Centralizing Helm charts is a powerful way to scale, but it forces you to confront how your cluster handles shared state.

• Ingress is “Flat”: It’s great for simple use cases but struggles with the hierarchical needs of modern, centralized Helm architectures.
• GitOps demands clarity: Tools like ArgoCD require clear resource ownership. If your ingress strategy relies on “merging” multiple resources, you’re likely to face stability issues.
• CRDs are your friend: Don’t be afraid to move beyond native resources. HTTPProxy (or the newer Gateway API) offers the precision that large-scale Kubernetes environments actually need.

By moving to HTTPProxy, we didn’t just fix a bug; we built a cleaner, more scalable foundation for our entire infrastructure.

Follow us for more Updates

• Twitter
• LinkedIn
• Facebook