Skip to main content

Auto Discovery (Providers)

The providers are infrastructure components, whether orchestrators, container engines, cloud providers, or key-value stores. Traefik Hub API Gateway queries the provider APIs in order to find relevant information about routing, and when a change is detected, it dynamically updates the routes.

Orchestrators​

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

Supported Providers​

Below is the list of the currently supported providers in Traefik.

ProviderTypeConfiguration TypeProvider NameNote
DockerOrchestratorLabeldockerOnly documented in Traefik documentation yet
Docker SwarmOrchestratorLabelswarmOnly documented in Traefik documentation yet
Kubernetes IngressRouteOrchestratorTraefik Custom Resourceskubernetescrd
Kubernetes IngressOrchestratorIngresskubernetes
Kubernetes Gateway APIOrchestratorGateway API Resourceskubernetesgateway
Consul CatalogOrchestratorLabelconsulcatalogOnly documented in Traefik documentation yet)
NomadOrchestratorLabelnomadOnly documented in Traefik documentation yet
ECSOrchestratorLabelecsOnly documented in Traefik documentation yet
FileManualYAML/TOML formatfileOnly documented in Traefik documentation yet
ConsulKVKVconsulOnly documented in Traefik documentation yet
ETCDKVKVetcdOnly documented in Traefik documentation yet
ZooKeeperKVKVzookeeperOnly documented in Traefik documentation yet
RedisKVKVredisOnly documented in Traefik documentation yet
The Redis provider configuration is not used by the middlewares which need Redis as a Store (OIDC, Distributed Rate-Limit, etc)
HTTPManualJSON formathttpOnly documented in Traefik documentation yet

Provider Namespace​

When you declare certain objects in the Traefik 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>
Kubernetes Namespace VS Traefik Provider 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 Traefik 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.