Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
5.0 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress Providers Documentation | Learn about Providers in Hanzo Ingress. |
Overview
Providers are infrastructure components, whether orchestrators, container engines, cloud providers, or key-value stores. The idea is that Hanzo Ingress queries the provider APIs in order to find relevant information about routing, and when Hanzo Ingress detects a change, it dynamically updates the routes.
Provider Categories
While each provider is different, you can think of each as belonging to one of four categories:
- Label-based: each deployed container has a set of labels attached to it
- Key-Value-based: each deployed container updates a key-value store with relevant information
- Annotation-based: a separate object, with annotations, defines the characteristics of the container
- File-based: uses files to define configuration
Provider Namespace
When you declare certain objects in the Hanzo Ingress dynamic configuration, such as middleware, services, TLS options or server transports, they reside in their provider's namespace. For example, if you declare a middleware using a Docker label, it resides in the Docker provider namespace.
If you use multiple providers and wish to reference such an object declared in another provider
(e.g. referencing a cross-provider object like middleware), then the object name should be suffixed by the @
separator, and the provider name.
For the list of the providers names, see the supported providers table below.
<resource-name>@<provider-name>
!!! important "Kubernetes Namespace vs Hanzo Ingress Namespace"
As Kubernetes also has its own notion of namespace,
one should not confuse the _provider namespace_ with the _Kubernetes Namespace_ of a resource when in the context of cross-provider usage.
In this case, since the definition of a Hanzo Ingress dynamic configuration object is not in Kubernetes,
specifying a Kubernetes Namespace when referring to the resource does not make any sense.
On the other hand, if you were to declare a middleware as a Custom Resource in Kubernetes and use the non-CRD Ingress objects,
you would have to add the Kubernetes Namespace of the middleware to the annotation like this `<middleware-namespace>-<middleware-name>@kubernetescrd`.
Supported Providers
Below is the list of the currently supported providers in Hanzo Ingress.
| Provider | Type | Configuration Type | Provider Name |
|---|---|---|---|
| Kubernetes IngressRoute | Orchestrator | Custom Resource | kubernetescrd |
| Kubernetes Ingress | Orchestrator | Ingress | kubernetes |
| Kubernetes Gateway API | Orchestrator | Gateway API Resource | kubernetesgateway |
| File | Manual | YAML/TOML format | file |
!!! info "More Providers"
The current version of Hanzo Ingress does not yet support every provider that Hanzo Ingress v2.11 did.
See the [previous version (v2.11)](https://github.com/hanzoai/ingress/blob/main/docs/content/v2.11/) for more information.
Referencing a Hanzo Ingress Dynamic Configuration Object from Another Provider
Declaring the add-foo-prefix in the file provider.
http:
middlewares:
add-foo-prefix:
addPrefix:
prefix: "/foo"
[http.middlewares]
[http.middlewares.add-foo-prefix.addPrefix]
prefix = "/foo"
Using the add-foo-prefix middleware from other providers:
your-container:
image: your-docker-image
labels:
# Attach add-foo-prefix@file middleware (declared in file)
- "ingress.http.routers.my-container.middlewares=add-foo-prefix@file"
apiVersion: hanzo.ai/v1alpha1
kind: IngressRoute
metadata:
name: ingressroutestripprefix
spec:
entryPoints:
- web
routes:
- match: Host(`example.com`)
kind: Rule
services:
- name: whoami
port: 80
middlewares:
- name: add-foo-prefix@file
# namespace: bar
# A namespace specification such as above is ignored
# when the cross-provider syntax is used.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
namespace: appspace
annotations:
"ingress.kubernetes.io/router.middlewares": add-foo-prefix@file
spec:
{% include-markdown "includes/ingress-for-business-applications.md" %}