在 K3s 為後端自簽憑證的 https 服務建立 Ingress

我們經常會為了 http 服務部署在 K3s 之際，在 Ingress 設好合法的憑證，讓使用者能透過 https 協定訪問。但這次遇到新版的 Elasticsearch 比較特別，在初始化的時候就會有一張自簽憑證綁進來，希望外界永遠依賴 https 協定與 Elasticsearch 通訊（即便憑證不受信任）。仔細想想，這個觀點並沒什麼不好，比起傳輸內容在網路上裸奔，待信任的自簽憑證的確幫我們加密了。但問題是，我們面臨了抉擇：

• 拆掉 Elasticsearch 的自簽憑證，讓外界 https 到了 Ingress，裡面再重導到 http 服務。
• 修改服務本身或 Ingress，接受後端也可以是 https 的事實。

1. 新增 ServersTransport
2. 修改服務，參考 ServersTransport
3. Ingress 一如往常

---
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: my-transport
  namespace: default
spec:
  insecureSkipVerify: true

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
  annotations:
    traefik.ingress.kubernetes.io/service.serversscheme: https
    traefik.ingress.kubernetes.io/service.serverstransport: default-my-transport@kubernetescrd
...

網路上流傳著類似的例子，其中有些是第 18 行漏了 default- 命名空間，這招就會無效，我們可以在 kubectl logs deploy/traefik -n kube-system 看到線索：

level=error msg="servers transport not found my-transport@kubernetes" entryPointName=websecure routerName=...

又或者想要進一步確認 ServersTransport 的存在，但這個新鮮的東西還不是隨便就看得到：

kubectl get ServersTransport
No resources found in default namespace.

原來全名叫 ServersTransport.traefik.io 才對。