メニュー
處理 k3s 上的 DNS 與 Let's Encrypt SSL——診斷 DNS 委派（dig +trace 從 parent 找真權威、用 MX 當指紋比對 面板 vs 對外權威、SOA serial 驗有沒有真的發布）、讓子網域指向叢集、用 cert-manager 自動簽憑證；並提供上線前 用 --resolve + 真實 ACME challenge token 預驗整條鏈路的方法。當子網域或 HTTPS 憑證沒生效要排查、DNS「設了卻 不通」、或上線前要先確認機器端 100% 就緒時使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
在 k3s 上用 Helm 部署 domain-manager（github.com/timcsy/domain-manager）與其相依的 cert-manager， 設定 Traefik ingress class 與 Let's Encrypt ClusterIssuer，並掛上 domain-manager UI 的 ingress。 當要部署 domain-manager 來用 Web UI/API/MCP 管理子網域→service 對應與自動 SSL 時使用。內含 image tag 與 admin 密碼的已知 chart 陷阱與規避方式。
在 VPS 上安裝單節點 k3s（保留內建 Traefik 與 ServiceLB），設定免 sudo 的 kubeconfig，並安裝 Helm 3。 當要從零建立 k3s 叢集、或為部署應用準備 Kubernetes 環境時使用。執行前建議先跑 k3s-preflight 確認 80/443 的處理方式；若 80/443 已被既有服務占用，安裝會即時搶占 port，需搭配 k3s-migrate-proxy。
產生可攜的 k3s kubeconfig，讓本機/CI 從任何地方操作叢集——幫 k3s API 憑證加 tls-san、把 server 從 127.0.0.1 改成 domain、確認 6443 對外可達、把 context/cluster/user 改名避免與其他 kubeconfig 撞名， 並用 .gitignore 保護內含的 cluster-admin 憑證。當要遠端 kubectl/helm 操作 k3s、或把 kubeconfig 交給 其他機器使用時用。
把 VPS 上既有的反向代理（systemd nginx/apache/caddy 等，正佔用 80/443 服務正式網站）安全遷移到 k3s 的 Traefik——後端用 external Service+Endpoints 指向原本的容器/程序、沿用既有 TLS 憑證、用 per-router middleware 做 HTTP→HTTPS 轉址，驗證無誤後才停用舊 proxy，不中斷服務。當 k3s 要接管已被占用的 80/443、或要把既有 reverse proxy 收進叢集時使用。這是條件式步驟：只有偵測到既有 80/443 服務才需要。
部署 k3s 前偵測 VPS 環境是否就緒——OS/arch、使用者與 sudo、公網 IP、資源、既有 k8s，以及最關鍵的 80/443 佔用者與既有正式服務。當要在一台 VPS 上裝 k3s、或評估某主機現況、或排查「裝 k3s 會不會打斷既有服務」時使用。 輸出一份環境摘要與建議的處理路線，供後續 k3s-install / k3s-migrate-proxy 參考。
端到端在一台 VPS 上部署 k3s + domain-manager + DNS/SSL 的總流程。依序串起六個子 skill：k3s-preflight → k3s-install →（條件式）k3s-migrate-proxy → k3s-domain-manager → k3s-dns-ssl → k3s-kubeconfig，並在每個 關卡驗證、遇到既有正式服務時停下確認。當使用者要「完整一次跑完」整套 VPS 上的 k3s 部署與 DNS/SSL 設定時使用； 若只想做其中一段，直接呼叫對應的子 skill 即可。
| name | k3s-dns-ssl |
| description | 處理 k3s 上的 DNS 與 Let's Encrypt SSL——診斷 DNS 委派（dig +trace 從 parent 找真權威、用 MX 當指紋比對 面板 vs 對外權威、SOA serial 驗有沒有真的發布）、讓子網域指向叢集、用 cert-manager 自動簽憑證；並提供上線前 用 --resolve + 真實 ACME challenge token 預驗整條鏈路的方法。當子網域或 HTTPS 憑證沒生效要排查、DNS「設了卻 不通」、或上線前要先確認機器端 100% 就緒時使用。 |
記錄加了卻不生效，最常見是改到的系統 ≠ 對外服務的系統。
H=<UI_HOST>; ZONE=<zone 如 example.com>
# 1) 從 parent 往下 trace：parent 實際委派給誰（可能跟 zone 內 NS 不一致）
dig +trace A "$H" | tail -15
# 2) 直接問「真權威」：SOA serial 沒前進＝沒 reload/發布
dig @<real-auth> SOA "$ZONE"
dig @<real-auth> A "$H"
# 3) 用一筆已知對外正常的記錄當指紋（如 MX），比對面板 vs 真權威是否同一套
dig @<real-auth> MX "$ZONE"
# 4) 公開遞迴交叉驗證（Let's Encrypt 視角）
dig @1.1.1.1 +short A "$H"; dig @8.8.8.8 +short A "$H"
判讀：
ns1.<zone>）不一定是 parent 委派的對象；以 dig +trace 看到的為準。rndc reload <zone>（或重啟 named）。cloudflare.enabled=true + token，可自助簽 wildcard 憑證（不依賴 80 port）。*.sub A <IP>：讓所有子網域一次指向本機，搭配 HTTP-01 各自簽 cert，最省事。用 --resolve 假裝 DNS 已指過來，並扮演 Let's Encrypt 抓 challenge：
IP=<node_public_ip>; H=<UI_HOST>
# 取 pending challenge 的 token/key
ssh "$SSH_TARGET" 'kubectl get challenge -A -o jsonpath="{.items[0].spec.token} {.items[0].spec.key}"'
# 扮演 LE：回傳值 == .spec.key 就證明 DNS 一生效 HTTP-01 必過、cert 會自動簽出
curl -s --resolve $H:80:$IP "http://$H/.well-known/acme-challenge/<TOKEN>"
curl -s --resolve $H:80:$IP -o /dev/null -w "UI HTTP %{http_code}\n" "http://$H/"
curl -sk --resolve $H:443:$IP -o /dev/null -w "UI HTTPS %{http_code}\n" "https://$H/"
H=<UI_HOST>
dig @<real-auth> A "$H"; dig @1.1.1.1 +short A "$H" # 對外查得到、serial 前進
ssh "$SSH_TARGET" 'kubectl get certificate -A; kubectl get challenge -A 2>/dev/null' # cert Ready、無 pending
curl -s -o /dev/null -w "HTTPS %{http_code} verify=%{ssl_verify_result}\n" "https://$H/" # verify=0
通過標準：對外 DNS 解析正確、certificate READY=True、無 pending challenge、verify=0、頁面正確。