当 SSL 流量未经过 APISIX 而走了 Traefik 时，核心原因是K3s 默认使用 Traefik 作为 Ingress Controller，而 APISIX 未正确接管流量。以下是针对性解决方案：
一、确认 Ingress 资源的 Controller 归属

检查 Ingress 是否指定 APISIX 控制器
问题场景：Kubernetes Ingress 资源未声明使用 APISIX，导致 Traefik 默认处理。
解决步骤：
查看 Ingress 配置：kubectl describe ingress <ingress-name> -n <namespace>，确认是否包含以下注解：

1
2
3

metadata:
  annotations:
    kubernetes.io/ingress.class: "apisix"  # 关键注解，指定APISIX为控制器

修复示例：若缺少该注解，使用kubectl edit ingress 添加：

1
2
3

metadata:
  annotations:
    kubernetes.io/ingress.class: "apisix"

查看集群默认 Ingress Controller
问题场景：K3s 默认将 Traefik 设为默认 Ingress Controller。
解决步骤：
查看 Traefik 的 ConfigMap：kubectl get configmap traefik-config -n kube-system -o yaml，确认是否包含ingressClass: “traefik”。
若需将 APISIX 设为默认，需修改 APISIX 的 Helm 配置，添加：
1
2
3
4
5
6
7
8
9
apisix:
ingressController:
config:
controller:
ingressClass: "apisix"
ingressClassResource:
enabled: true
name: "apisix"
default: true # 设为默认控制器

重新部署 APISIX：helm upgrade apisix -f values.yaml
二、确保 APISIX 服务正确暴露 HTTPS

检查 APISIX 服务端口配置
问题场景：APISIX 未正确暴露 HTTPS 端口（默认 9443），或流量未指向该端口。
解决步骤：
查看 APISIX 服务：kubectl get svc apisix-gateway -n ，确认443:9443/TCP端口存在（NodePort 或 LoadBalancer 类型）。
若服务类型为 NodePort，测试节点 IP+NodePort 是否可达：curl https://:。
若服务类型为 LoadBalancer，测试 LB IP 是否指向 APISIX：curl https://。
验证 APISIX 的 SSL 证书配置
问题场景：APISIX 未配置证书，或证书与域名不匹配，导致流量被 Traefik 拦截（Traefik 可能有默认证书）。
解决步骤：
通过 APISIX Dashboard 或配置文件，确认 SSL 证书已正确绑定域名（如example.com）。
检查 APISIX 的 TLS 配置（Helm values）：
1
2
3
4
5
6
7
apisix:
tls:
enabled: true
certificates:
- secretName: apisix-tls-secret
hosts:
- example.com

若 Traefik 有默认证书（如TRAEFIK DEFAULT CERT），需确保 APISIX 的证书优先级更高。
三、禁用或隔离 Traefik

临时停用 Traefik（测试用）
操作步骤：
暂停 Traefik Deployment：kubectl scale deployment traefik -n kube-system –replicas=0
测试 SSL 流量是否转向 APISIX：curl -v https://example.com（查看响应头是否含server: APISIX）
若正常，说明 Traefik 确实拦截了流量，需永久调整配置。

修改 Traefik 配置避免冲突
问题场景：Traefik 仍监听 443 端口，与 APISIX 竞争流量。
解决步骤：
修改 Traefik 的监听端口（非默认 443），例如改为 9444：

# Traefik的ConfigMap中添加
apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: kube-system
data:
  traefik.yml: |
    entryPoints:
      websecure:
        address: ":9444"  # 改为非443端口

重启 Traefik 后，443 端口将由 APISIX 独占。
四、验证流量走向

查看响应头确认控制器
命令测试：
bash
访问域名，查看响应头
curl -v https://example.com 2>&1 | grep “server:”

预期结果（APISIX处理）

server: APISIX

若结果为Traefik

server: traefik

检查 Traefik 日志
操作步骤：
bash
kubectl logs -n kube-system | grep “example.com”

若存在请求记录，说明 Traefik 仍在处理流量，需回到前几步检查 Ingress 归属和端口配置。
五、典型配置示例（APISIX 接管 Ingress）

APISIX 专属 Ingress 资源

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: apisix-ingress
 namespace: my-namespace
 annotations:
 kubernetes.io/ingress.class: "apisix"  # 关键注解
spec:
 tls:
 - hosts:
     - example.com
     secretName: apisix-tls-secret
   rules:
 - host: example.com
   http:
     paths:
       - path: /
         pathType: Prefix
         backend:
           service:
             name: my-service
             port:
               number: 80

APISIX 作为默认 Ingress Controller

# Helm values.yaml中添加
apisix:
  ingressController:
    config:
      controller:
        ingressClass: "apisix"
        ingressClassResource:
          enabled: true
          name: "apisix"
          default: true  # 设为集群默认Ingress Controller

总结
流量走 Traefik 而非 APISIX 的核心原因是Ingress 资源未指定 APISIX 为控制器或Traefik 仍占用 443 端口。通过指定 Ingress 归属、调整服务端口、禁用 Traefik 冲突端口，可确保 SSL 流量正确路由至 APISIX。建议按 “配置 Ingress 注解→验证服务端口→隔离 Traefik→测试响应头” 的流程逐步排查。

访问域名，查看响应头

预期结果（APISIX处理）

若结果为Traefik