Question 1

なぜ nginx.ingress.kubernetes.io/force-ssl-redirect は Traefik v3.7.0-rc2 で動作しないのですか？

Accepted Answer

これは Traefik v3.7.0-rc2 の kubernetesIngressNGINX プロバイダーにおけるリグレッションでした。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 リクエストは、レスポンスボディではなく HTTPS リダイレクトを返すはずです。一時的な回避策として、アップグレードが可能になるまで 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 プロバイダーとも一貫しています)、そのため `appProtocol` を設定しない限り、他の Gateway API 実装で動作する HTTPRoute が Traefik では異なる動作をする場合があります。

Question 3

How do I stop two Traefik installations in the same Kubernetes cluster from fighting over Gateway status and advertising the wrong load balancer address?

Accepted Answer

The conflict occurs because every Traefik instance uses the same fixed controller name, `traefik.io/gateway-controller`. When both installations share a GatewayClass, each instance reconciles all matching Gateways and repeatedly overwrites `status.addresses` and condition timestamps.

Fix it by giving each Traefik installation its own GatewayClass and restricting the provider to that class.

Installation A, for example public traffic:

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

Or with Helm:

```bash
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
```

Installation B, for example internal traffic:

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

Or:

```bash
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
```

The Helm chart labels each generated GatewayClass with `app.kubernetes.io/instance=<release-name>`, so the selector must match the release name. Make sure each Gateway references its corresponding `gatewayClassName`: `traefik` or `traefik-internal`.

Verify that the GatewayClass labels match and that continuous status updates have stopped:

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

After this change, each Traefik instance manages only its own Gateway. In the reported setup, Gateway status writes dropped from about 2,300 per minute to zero.

Question 4

なぜ Gateway API の *.foo.com のようなワイルドカードリスナーは baz.bar.foo.com のようなより深いサブドメインにマッチするのか、またそれをどう修正すればよいですか？

Accepted Answer

これは、pkg/provider/kubernetes/gateway/kubernetes.go の findMatchingHostname が strings.HasSuffix を使用しているために発生します。サフィックスチェックは、ルートホスト名が .foo.com で終わることだけを検証するため、複数ラベルのサブドメインを誤って受け入れます。Gateway API のワイルドカードは、正確に 1 つの DNS ラベルに一致する必要があります。bar.foo.com は *.foo.com に一致しますが、baz.bar.foo.com は一致してはなりません。

ワイルドカードサフィックスの前の部分にドットが含まれないことを要求することによって、マッチャーを修正します：

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
}

同等のラベル数チェックは、サフィックス一致を受け入れる前に strings.Count(string(h1), ".") == strings.Count(string(h2), ".") です。

次に、Test_findMatchingHostnames を更新して、baz.bar.foo.com が *.foo.com によって拒否され、bar.foo.com は受け入れられるようにし、次を実行します：

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

これは HTTPRoute と TLSRoute の両方に影響する動作変更であるため、リリースノートを追加してください。パッチが適用されるまで、共有 Gateway でのテナント委任にワイルドカードリスナーを使用しないでください。明示的なホスト名または追加のアタッチメント制限を使用してください。

Question 5

Why does Traefik ErrorPages middleware ignore `kind: TraefikService` and look up the error service as a Kubernetes Service?

Accepted Answer

This was a limitation in the Kubernetes CRD provider: the CRD accepted `service.kind`, but the ErrorPages parser always performed a Kubernetes Service lookup. It was fixed in PR #13087. Upgrade to a Traefik release containing that PR, then reference the TraefikService explicitly and omit `port`:
```yaml
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
```
On older Traefik versions there is no config workaround for using a TraefikService. Use a regular Kubernetes Service instead and leave `kind` unset or set it to `Service`:
```yaml
service:
  name: my-error-svc
  namespace: default
  kind: Service
  port:
    name: http
```

traefik

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト