Applications may need incoming web requests and other TCP traffic directed to services inside a cluster. Voyager provides an HAProxy-based ingress controller with its own Kubernetes resource definitions for that routing. It can carry configuration for certificates, health checks and other traffic behavior, but those settings do not necessarily translate directly to another controller. Its current compatibility needs verification, and replacing an inherited installation requires preserving the actual listener and routing behavior rather than only matching resource names.
Current guidance
The recovered identity is Voyager, now documented under voyagermesh, rather than an unrelated product with the same name. Its README describes L7/L4 routing through custom Ingress resources and cert-manager integration. It also says deprecated v11 and v12 images were removed and points to a 2022 release; repository activity alone does not establish a supported current Kubernetes/controller combination.
Existing installations should inventory the custom API group, TCP services, TLS termination, sticky sessions, health checks and cloud load-balancer settings. Those features may not map directly to a standard Ingress or Gateway API resource. HAProxy’s continued development also does not certify this particular controller or its old chart.
Before retaining Voyager, locate an explicit release support matrix and confirm that the required images and CRDs are available and compatible. For replacement, translate one representative route at a time and test host/path matching, redirects, certificates, long connections and backend failure. Preserve the old listener and traffic-switch procedure through the rollback window. Do not delete custom resources or their controller until a tested replacement owns all required routes.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Voyager is a HAProxy backed secure L7 and L4 ingress controller for Kubernetes developed by AppsCode. This can be used with any Kubernetes cloud providers including aws, gce, gke, azure, acs. This can also be used with bare metal Kubernetes clusters.
From here you can learn all about Voyager’s architecture and how to deploy and use Voyager.
- Concepts. Concepts explain some significant aspect of Voyager. This is where you can learn about what Voyager does and how it does it.
- Setup. The setup contains instructions for installing the Voyager in various cloud providers.
- Guides. Guides show you how to perform tasks with Voyager. These are organized under Ingress and Certificate.
- Reference. Detailed exhaustive lists of command-line options, configuration options, API definitions, and procedures.
Ingress
Voyager provides L7 and L4 load balancing using Kubernetes standard Ingress resource. This is built on top of the HAProxy to support high availability, sticky sessions, name and path-based virtual hosting among other features. The following diagram shows how voyager operator works. Voyager also provides a custom Ingress resource under voyager.appscode.com API group that extends the functionality of standard Ingress in a Kubernetes native way.
When Voyager is installed in a Kubernetes cluster, a pod named voyager-operator-*** starts running in Kube-system namespace by default. This operator pod watches for Kubernetes Ingress resources and Voyager’s own Ingress CRD. When an Ingress object is created, the Voyager operator creates 3 Kubernetes resources in the same namespace of the Ingress:
a Configmap named voyager-${ingress-name}: This contains the auto-generated HAProxy configuration under haproxy.cfg key.
a Deployment named voyager-${ingress-name}: This runs HAProxy pods that mount the above config map. Each pod has one container for HAProxy. This container also includes some additional binary to reload HAProxy when the respective config map updates. This also includes logic for mounting and updating SSL secrets referenced in the corresponding Ingress resource. HAProxy pods can also contain a side-car container for exporting Prometheus ready metrics if enabled.
a Service named voyager-${ingress-name}: This Kubernetes Service exposes the above HAProxy pods to the internet. The type of Service can be configured by the user via ingress.appscode.com/type annotation on the Ingress.
a Service named voyager-${ingress-name}-stats: This Kubernetes Service is used to expose Prometheus ready metrics for HAProxy pods. This service is always of type ClusterIP and only created if stats are enabled.
Certificate
Voyager can automagically provision and refresh SSL certificates issued from Let’s Encrypt using a custom Kubernetes Certificate resource.
- Provision free TLS certificates from Let’s Encrypt,
- Manage issued certificates using a Kubernetes Third Party Resource,
- Domain validation using ACME DNS-01 challenges,
- Support for multiple DNS providers,
- Auto Renew Certificates,
- Use issued Certificates with Ingress to Secure Communications.
Versioning Policy
There are 2 parts to versioning policy:
- Operator version: Voyager does not follow semver, rather the major version of operator points to the Kubernetes client-go version. You can verify this from the glide.yaml file. This means there might be breaking changes between point releases of the operator. This generally manifests as changed annotation keys or their meaning. Please always check the release notes for upgrade instructions.
- CRD version: appscode.com/v1beta1 is considered in beta. This means any change
Run Voyager with other Ingress controllers in the same cluster
voyager can be used to manager Ingress objects alongside another ingress controller. Voyager comes with its own CRD called Ingress under API version voyager.appscode.com/v1beta1. This CRD is not recognized by other ingress controllers that work with the Kubernetes official Ingress object under extensions/v1beta1 API version.
By default, Voyager will also manage Kubernetes Ingress objects under extensions/v1beta1 API version. Voyager can be configured to only handle default Kubernetes Ingress objects with ingress.class voyager. To do that, pass the flag –ingress-class=voyager in operator pod. After that
annotations:
kubernetes.io/ingress.class=voyager
Sources & further reading
Spotted something that needs another look?
Help improve this page →