Question 1

nginx.ingress.kubernetes.io/force-ssl-redirect가 Traefik v3.7.0-rc2에서 왜 작동하지 않나요?

Accepted Answer

이는 Traefik v3.7.0-rc2의 kubernetesIngressNGINX provider에서 발생한 회귀였습니다. PR #13028의 수정 사항이 포함된 Traefik v3.7.0-rc.3 이상으로 업그레이드하세요. Helm을 사용하는 경우, Traefik v3.7.0-rc.3이 포함된 릴리스로 차트를 업데이트하세요. 예:
helm repo update
helm upgrade traefik traefik/traefik \
  --namespace traefik \
  --version 40.0.0-rc.3 \
  --values traefik-helm-values.yaml
업그레이드 후, nginx.ingress.kubernetes.io/ssl-redirect: "true" 및 nginx.ingress.kubernetes.io/force-ssl-redirect: "true"가 설정된 Ingress에 대한 HTTP 요청은 응답 body 대신 HTTPS redirect를 반환해야 합니다. 임시 해결 방법으로, 업그레이드가 가능할 때까지 Traefik v3.6.x를 계속 사용하세요.

Question 2

HTTPRoute backendRef가 포트 443을 사용할 때 발생하는 Traefik Gateway API 오류 "tls: first record does not look like a TLS handshake"를 해결하는 방법

Accepted Answer

Traefik은 Gateway API 프로바이더에서 Service 포트 번호를 기반으로 백엔드 스킴을 추론합니다. 포트 443을 가리키는 `backendRef`는 백엔드가 일반 HTTP만 제공하는 경우에도 Traefik이 백엔드에 TLS 연결을 시도하도록 만듭니다. 이로 인해 `tls: first record does not look like a TLS handshake` 오류와 함께 500 Internal Server Error가 발생합니다.

해결 방법: 포트 기반 스킴 감지를 재정의하려면 Service 포트의 `appProtocol` 필드를 `http`로 명시적으로 설정하세요:

```yaml
apiVersion: v1
kind: Service
metadata:
  name: apm-proxy-svc
spec:
  ports:
  - port: 443
    protocol: TCP
    appProtocol: http   # 백엔드에 대한 HTTP 스킴을 강제합니다
    targetPort: 8080
```

`appProtocol: http`를 추가하면 Service 포트를 변경하지 않고도 HTTPRoute가 작동합니다. BackendTLSPolicy는 필요하지 않습니다. 참고: 이 포트 기반 스킴 추론은 Traefik에서 의도된 동작이며(다른 Kubernetes 프로바이더들과 일관됨), 따라서 다른 Gateway API 구현에서 작동하는 HTTPRoute도 `appProtocol`을 설정하지 않으면 Traefik에서는 다르게 동작할 수 있습니다.

Question 3

같은 Kubernetes 클러스터에 있는 두 Traefik 설치가 Gateway 상태를 놓고 서로 다투고 잘못된 load balancer 주소를 광고하는 것을 어떻게 막을 수 있나요?

Accepted Answer

충돌은 모든 Traefik 인스턴스가 동일한 고정 컨트롤러 이름인 traefik.io/gateway-controller를 사용하기 때문에 발생합니다. 두 설치가 GatewayClass를 공유하면, 각 인스턴스가 일치하는 모든 Gateway를 조정하고 status.addresses와 condition 타임스탬프를 반복적으로 덮어씁니다.

각 Traefik 설치에 자체 GatewayClass를 부여하고 provider를 해당 클래스로 제한하여 수정하세요.

설치 A, 예를 들어 공용 트래픽:

providers:
  kubernetesGateway:
    enabled: true
    labelSelector: app.kubernetes.io/instance=traefik-public
gatewayClass:
  name: traefik

또는 Helm 사용:

helm upgrade traefik-public traefik/traefik \
  --set providers.kubernetesGateway.enabled=true \
  --set gatewayClass.name=traefik \
  --set providers.kubernetesGateway.labelSelector=app.kubernetes.io/instance=traefik-public

설치 B, 예를 들어 내부 트래픽:

providers:
  kubernetesGateway:
    enabled: true
    labelSelector: app.kubernetes.io/instance=traefik-internal
gatewayClass:
  name: traefik-internal

또는:

helm upgrade traefik-internal traefik/traefik \
  --set providers.kubernetesGateway.enabled=true \
  --set gatewayClass.name=traefik-internal \
  --set providers.kubernetesGateway.labelSelector=app.kubernetes.io/instance=traefik-internal

Helm chart는 생성된 각 GatewayClass에 app.kubernetes.io/instance=<release-name> 레이블을 지정하므로, selector가 release 이름과 일치해야 합니다. 각 Gateway가 해당 gatewayClassName인 traefik 또는 traefik-internal을 참조하는지 확인하세요.

GatewayClass 레이블이 일치하고 지속적인 status 업데이트가 중단되었는지 확인하세요:

kubectl get gatewayclass --show-labels
kubectl get gateways -A --watch-only

이 변경 후 각 Traefik 인스턴스는 자체 Gateway만 관리합니다. 보고된 설정에서는 Gateway status 쓰기가 분당 약 2,300회에서 0으로 떨어졌습니다.

Question 4

Why does a Gateway API wildcard listener like *.foo.com match deeper subdomains such as baz.bar.foo.com, and how do I fix it?

Accepted Answer

This happens because `findMatchingHostname` in `pkg/provider/kubernetes/gateway/kubernetes.go` uses `strings.HasSuffix`. A suffix check only verifies that the route hostname ends with `.foo.com`, so it incorrectly accepts multi-label subdomains. Gateway API wildcards must match exactly one DNS label: `bar.foo.com` matches `*.foo.com`, but `baz.bar.foo.com` must not.

Fix the matcher by requiring the part before the wildcard suffix to contain no dot:

```go
func findMatchingHostname(h1, h2 gatev1.Hostname) gatev1.Hostname {
    if h1 == h2 {
        return h1
    }
    if !strings.HasPrefix(string(h1), "*.") {
        return ""
    }

suffix := strings.TrimPrefix(string(h1), "*")
    if !strings.HasSuffix(string(h2), suffix) {
        return ""
    }

prefix := strings.TrimSuffix(string(h2), suffix)
    if prefix == "" || strings.Contains(prefix, ".") {
        return ""
    }

return h2
}
```

An equivalent label-count check is `strings.Count(string(h1), ".") == strings.Count(string(h2), ".")` before accepting the suffix match.

Then update `Test_findMatchingHostnames` so `baz.bar.foo.com` is rejected by `*.foo.com`, while `bar.foo.com` is accepted, and run:

```bash
go test ./pkg/provider/kubernetes/gateway -run Test_findMatchingHostnames
```

Add a release note because this is a behaviour change affecting both HTTPRoute and TLSRoute. Until patched, avoid using wildcard listeners for tenant delegation in shared Gateways; use explicit hostnames or additional attachment restrictions.

Question 5

Traefik ErrorPages 미들웨어는 왜 kind: TraefikService를 무시하고 오류 서비스를 Kubernetes Service로 조회하나요?

Accepted Answer

이는 Kubernetes CRD provider의 제한 사항이었습니다: CRD는 service.kind를 허용했지만, ErrorPages 파서는 항상 Kubernetes Service 조회를 수행했습니다. 이는 PR #13087에서 수정되었습니다. 해당 PR이 포함된 Traefik 릴리스로 업그레이드한 다음, TraefikService를 명시적으로 참조하고 port를 생략하세요:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: error-pages
spec:
  errors:
    status:
      - "500-599"
    service:
      name: my-error-traefikservice
      namespace: default
      kind: TraefikService
    query: /error
이전 Traefik 버전에서는 TraefikService를 사용하기 위한 구성 우회 방법이 없습니다. 대신 일반 Kubernetes Service를 사용하고 kind를 설정하지 않거나 Service로 설정하세요:
service:
  name: my-error-svc
  namespace: default
  kind: Service
  port:
    name: http

traefik

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트