본문 바로가기
WIKI 기술 지식 베이스

Traefik 프로바이더 문서

원문 보기 위키 갱신

Traefik 프로바이더 문서 (Traefik Providers Documentation)

출처: Traefik Providers Documentation

본문

개요 (Overview)

프로바이더는 오케스트레이터, 컨테이너 엔진, 클라우드 프로바이더 또는 키-값 스토어 같은 인프라 구성 요소예요. 핵심 아이디어는 Traefik이 프로바이더 API에 쿼리하여 라우팅에 관한 관련 정보를 찾고, Traefik이 변경을 감지하면 경로를 동적으로 갱신한다는 것이에요.

프로바이더 범주 (Provider Categories)

각 프로바이더는 서로 다르지만, 다음 네 가지 범주 중 하나에 속한다고 생각할 수 있어요.

  • 라벨 기반(Label-based): 배포된 각 컨테이너에 라벨 집합이 붙어 있어요.
  • 키-값 기반(Key-Value-based): 배포된 각 컨테이너가 관련 정보로 키-값 스토어를 갱신해요.
  • 어노테이션 기반(Annotation-based): 어노테이션이 있는 별도의 객체가 컨테이너의 특성을 정의해요.
  • 파일 기반(File-based): 파일로 구성을 정의해요.

프로바이더 네임스페이스 (Provider Namespace)

Traefik 동적 구성에서 미들웨어, 서비스, TLS 옵션, 서버 전송(server transports) 같은 특정 객체를 선언하면, 그것들은 해당 프로바이더의 네임스페이스에 존재해요. 예를 들어 Docker 라벨로 미들웨어를 선언하면 그 미들웨어는 Docker 프로바이더 네임스페이스에 있습니다.

여러 프로바이더를 사용하고, 다른 프로바이더에 선언된 그런 객체(예: 크로스 프로바이더 객체인 미들웨어)를 참조하려면, 객체 이름 뒤에 @ 구분자와 프로바이더 이름을 붙여야 해요.

프로바이더 이름 목록은 아래의 지원되는 프로바이더 표를 참고하세요.

<resource-name>@<provider-name>

Kubernetes 네임스페이스 vs Traefik 네임스페이스

Kubernetes에도 고유한 네임스페이스 개념이 있으므로, 크로스 프로바이더 사용 맥락에서 프로바이더 네임스페이스와 리소스의 Kubernetes 네임스페이스를 혼동하면 안 돼요.

이 경우 Traefik 동적 구성 객체의 정의가 Kubernetes에 있지 않으므로, 리소스를 참조할 때 Kubernetes 네임스페이스를 지정하는 것은 의미가 없어요.

반면 미들웨어를 Kubernetes의 커스텀 리소스로 선언하고 비-CRD Ingress 객체를 사용한다면, 미들웨어의 Kubernetes 네임스페이스를 어노테이션에 -@kubernetescrd처럼 추가해야 해요.

지원되는 프로바이더 (Supported Providers)

아래는 Traefik에서 현재 지원되는 프로바이더 목록이에요.

| Provider | Type | Configuration Type | Provider Name | | Docker | Orchestrator | Label | docker | | Docker Swarm | Orchestrator | Label | swarm | | Kubernetes IngressRoute | Orchestrator | Custom Resource | kubernetescrd | | Kubernetes Ingress | Orchestrator | Ingress | kubernetes | | Kubernetes Ingress NGINX | Orchestrator | Ingress-NGINX | kubernetesIngressNGINX | | Kubernetes Gateway API | Orchestrator | Gateway API Resource | kubernetesgateway | | Consul Catalog | Orchestrator | Label | consulcatalog | | Nomad | Orchestrator | Label | nomad | | ECS | Orchestrator | Label | ecs | | File | Manual | YAML/TOML format | file | | Consul | KV | KV | consul | | Etcd | KV | KV | etcd | | ZooKeeper | KV | KV | zookeeper | | Redis | KV | KV | redis | | HTTP | Manual | JSON/YAML format | http |

더 많은 프로바이더 (More Providers)

현재 버전의 Traefik은 Traefik v2.11이 지원했던 모든 프로바이더를 아직 지원하지는 않아요. 자세한 내용은 이전 버전(v2.11)을 참고하세요.

다른 프로바이더에서 Traefik 동적 구성 객체 참조하기

File 프로바이더에서 add-foo-prefix를 선언해요.

File (YAML)

http:
  middlewares:
    add-foo-prefix:
      addPrefix:
        prefix: "/foo"

File (TOML)

[http.middlewares]
  [http.middlewares.add-foo-prefix.addPrefix]
    prefix = "/foo"

다른 프로바이더에서 add-foo-prefix 미들웨어 사용하기:

Docker & Swarm

your-container:
  image: your-docker-image

  labels:
    # Attach add-foo-prefix@file middleware (declared in file)
    - "traefik.http.routers.my-container.middlewares=add-foo-prefix@file"

IngressRoute

apiVersion: traefik.io/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.

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  namespace: appspace
  annotations:
    "traefik.ingress.kubernetes.io/router.middlewares": add-foo-prefix@file
spec:

서비스 디스커버리 범위 제한하기 (Restrict the Scope of Service Discovery)

기본적으로 Traefik은 발견된 모든 컨테이너에 대해 라우트를 만들어요.

Traefik 서비스 디스커버리의 범위를 제한하고 싶다면, 즉 일부 컨테이너에 대한 라우트 생성을 허용하지 않으려면 두 가지 방법으로 할 수 있어요.

  • Consul Catalog, Docker, ECS, Nomad, Swarm 프로바이더에서는 exposedByDefault를 false로 설정하고 노출하려는 컨테이너에 traefik.enable=true 라벨을 추가.
  • 라벨 셀렉터나 제약 조건(constraints)에 기반한 더 세분화된 메커니즘 사용.

다음 프로바이더는 제약 조건을 지원해요

  • Consul Catalog
  • Docker
  • ECS
  • Nomad
  • Swarm

다음 프로바이더는 라벨 셀렉터를 지원해요

  • Kubernetes CRD
  • Kubernetes Gateway API
  • Kubernetes Ingress

프로바이더 우선순위 (Providers Precedence)

providers.precedence

선택 사항이에요.

서로 다른 프로바이더의 두 라우터가 동일한 수치 우선순위로 같은 규칙을 정의하면, precedence 옵션이 어떤 프로바이더의 라우트가 우선하는지 결정해요.

목록은 가장 높은 우선순위부터 낮은 순서로 정렬됩니다. 먼저 나열된 프로바이더가 나중에 나열된 프로바이더보다 이깁니다.

File (YAML)

providers:
  precedence:
    - kubernetescrd
    - kubernetes
    - file

File (TOML)

[providers]
  precedence = ["kubernetescrd", "kubernetes", "file"]

CLI

--providers.precedence=kubernetescrd,kubernetes,file

기본 우선순위 (Default precedence)

precedence가 설정되지 않으면 Traefik은 다음 기본 순서(가장 높은 우선순위가 먼저)를 사용해요.

| Position | Provider name | | 1 | kubernetesgateway | | 2 | kubernetescrd | | 3 | kubernetes | | 4 | kubernetesingressnginx | | 5 | swarm | | 6 | docker | | 7 | file | | 8 | redis | | 9 | knative | | 10 | consul | | 11 | consulcatalog | | 12 | nomad | | 13 | etcd | | 14 | ecs | | 15 | http | | 16 | zookeeper | | 17 | rest |

참고 (Note)

  • precedence는 타이브레이커로만 작동합니다. 서로 다른 프로바이더의 두 라우트가 동일한 수치 우선순위 값을 공유할 때만 적용돼요. 명시적 라우터 우선순위가 항상 우선합니다.
  • precedence에 없는 프로바이더는 나열된 프로바이더에게 집니다.
  • 프로바이더 이름은 대소문자를 구분하지 않아요.

프로덕션에서 Traefik OSS를 사용하고 계신가요?

직장에서 Traefik을 사용하고 있다면 기업용 API 게이트웨이 기능이나 Traefik OSS에 대한 상용 지원을 고려해 보세요.

  • API 게이트웨이 데모 영상 보기
  • 24/7/365 OSS 지원 요청하기

Traefik OSS에 API 게이트웨이 기능을 추가하는 일은 빠르고 매끄러워요. 교체(rip and replace)가 필요 없고 모든 구성이 그대로 유지됩니다. 이 짧은 영상에서 실제 동작을 확인해 보세요.

더 알아보기 (Learn more)