本文是跨 vendor migration playbook、cross-link Docker Swarm 跟 Kubernetes。跑 migration-playbook-methodology 6 維 audit 後對映 Paradigm = High（Swarm 簡單 container orchestration → K8s declarative resource model）→ Type E paradigm shift。

5 個 Swarm production cluster 撞牆數據

從 2020-2024 觀察 5 個中型 organization 的 Swarm production cluster lifecycle、典型撞牆點：

5 個共同 pattern：

• Swarm 簡單但 ceiling 100-200 service / 20-40 node
• 跨 service 治理（mesh / RBAC / secret / autoscale）需要 外掛 工具、複雜度反超 K8s
• 無 multi-region native、災備受限
• 生態縮、社群活躍度低、新 feature 緩

撞牆點不是「Swarm 跑不動」、是「Swarm 不會幫你解 跨 service 治理 問題、要自寫」。Kubernetes 不是 simpler、是 把治理問題納入框架。

為什麼遷：ceiling / ecosystem / multi-region 三條 driver

反向 driver（K8s → Swarm）：

• 純 internal tool / 小規模（< 30 service）、K8s 過度複雜
• Edge / IoT scenario、Swarm footprint 小

6 維 audit

Schema + Paradigm 雙 High → Type E paradigm shift 為主、Schema 高維獨立段。

Paradigm 對位

Schema gap：docker-compose vs K8s YAML

 1# Docker Swarm stack.yml
 2version: '3.8'
 3services:
 4  webapp:
 5    image: myapp:1.0
 6    deploy:
 7      replicas: 3
 8      update_config:
 9        parallelism: 1
10      restart_policy:
11        condition: on-failure
12    networks:
13      - frontend
14    ports:
15      - "8080:8080"

 1# K8s equivalent (Deployment + Service + Ingress)
 2apiVersion: apps/v1
 3kind: Deployment
 4metadata:
 5  name: webapp
 6spec:
 7  replicas: 3
 8  strategy:
 9    type: RollingUpdate
10    rollingUpdate:
11      maxSurge: 1
12      maxUnavailable: 0
13  selector:
14    matchLabels: { app: webapp }
15  template:
16    metadata:
17      labels: { app: webapp }
18    spec:
19      containers:
20        - name: webapp
21          image: myapp:1.0
22          ports:
23            - containerPort: 8080
24          readinessProbe:
25            httpGet:
26              path: /healthz
27              port: 8080
28          resources:
29            requests:
30              cpu: 100m
31              memory: 128Mi
32            limits:
33              cpu: 500m
34              memory: 512Mi
35---
36apiVersion: v1
37kind: Service
38metadata:
39  name: webapp
40spec:
41  selector: { app: webapp }
42  ports:
43    - port: 8080
44      targetPort: 8080

1 Swarm service → 2-3 K8s resource（Deployment + Service + 可能 Ingress / HPA）；application 不改但 deployment 端工作量 5-10x。

Migration 流程

Partial migration + 混合架構

跟 Kafka ↔ NATS / etcd → Consul 同 Type E pattern：

 11. Audit application：列所有 Swarm stack + service
 22. 分類處理 plan:
 3   - 簡單 stateless: 先切 K8s (低風險)
 4   - Stateful (DB / queue): 評估 K8s operator 或保留 Swarm
 5   - Critical service: 雙跑期確認 K8s 行為對等
 63. K8s cluster 建置:
 7   - Managed (EKS / GKE / AKS) vs self-host (kubeadm)
 8   - 配 ingress controller / cert-manager / monitoring
 94. Application 遷移 (per stack)
10   - 寫 K8s YAML / Helm chart
11   - 配 readiness/liveness probe / resource request
12   - Networking + secret 對位
135. Cutover + Swarm decommission
14   - 部分 stack 切完、評估 Swarm 是否保留 (legacy / edge)
15   - 多數 organization 完全 decommission Swarm

整體 3-6 個月、依 stack 數量跟 application 複雜度。

Production 故障演練

Case 1：Networking model 差、cross-service connectivity 失效

徵兆：cutover 後 service A 連 service B 失敗、Swarm 端 tasks.service_b DNS 對位 K8s 端 service-b.namespace.svc.cluster.local 不通。

根因：Swarm overlay network 內 service-to-service 用 short name (service_b)、K8s 用 FQDN；application 端 service URL 寫死。

修法：

1. Application 端用 short name + cluster DNS search domain
2. K8s 端設 dnsPolicy: ClusterFirst 預設、確認 kubectl get svc -A 對應
3. NetworkPolicy 預設 deny-all、明示 allow rule

Case 2：Secret rotation 從 Swarm secrets 換 Vault / Secrets Manager

徵兆：原本 Swarm 用 docker secret 旋轉 secret、切 K8s 後 K8s Secret 是 static value、rotation 不自動。

根因：K8s Secret 是 K8s-native 但 not auto-rotated、需要外部 Vault / Secrets Manager + agent (vault-agent-injector / external-secrets-operator)。

修法：

1. K8s 端 deploy external-secrets-operator + AWS Secrets Manager / Vault integration
2. Application 端 mount file or env variable、不在 code 寫死
3. Rotation 走 vendor-side、K8s 端 sidecar 自動 reload

Case 3：Readiness probe 沒設、rolling update 期間 traffic loss

徵兆：cutover 後 deploy 期間 application 5-10% request 失敗；發現 pod startup 完成前就接 traffic。

根因：Swarm 簡單 restart_policy 沒對等 probe 概念；K8s 預設 deploy 後 immediate ready、若沒 readiness probe、startup 時間長的 application 會在未 ready 時接流量。

修法：

1. 必加 readiness probe：HTTP / TCP / exec check
2. 配 initial delay：JVM application 預留 30-60s
3. 配 minReadySeconds：deployment 端設 30s 確保 stable

Case 4：HPA 預設不啟、autoscaling 失效

徵兆：Swarm 端寫了 cron-based autoscale script、切 K8s 後 script 失效、流量高峰沒 scale up。

根因：K8s HPA 不是預設啟動、需要 明示配置 + metrics-server install。

修法：

 1apiVersion: autoscaling/v2
 2kind: HorizontalPodAutoscaler
 3metadata:
 4  name: webapp-hpa
 5spec:
 6  scaleTargetRef:
 7    apiVersion: apps/v1
 8    kind: Deployment
 9    name: webapp
10  minReplicas: 3
11  maxReplicas: 20
12  metrics:
13    - type: Resource
14      resource:
15        name: cpu
16        target:
17          type: Utilization
18          averageUtilization: 70

裝 metrics-server / Keda（event-driven autoscaling）+ 配 HPA per Deployment。

Case 5：YAML 維護地獄、Helm / Kustomize 配置遲

徵兆：cutover 後 K8s YAML 從 5 個檔（Swarm stack）變 50+ 個 K8s manifest；每個 application 端要改一個 config 都要動 N 個 file。

根因：K8s YAML 是 very verbose、不像 docker-compose 簡潔；缺 templating 跟 environment 抽象。

修法：

1. Helm chart：對 application 包成 chart、用 values.yaml 抽象環境差異
2. Kustomize：base + overlay pattern、不靠 templating
3. GitOps with Argo CD / Flux：宣告式部署、降 manual kubectl 操作

Capacity / cost

判讀：< 30 service 小 organization 可不切；50+ service 開始撞 Swarm ceiling、值得評估；100+ service / multi-region 必切。

整合 / 下一步

跟 Service mesh 整合

Cutover 後 順便 評估 Istio / Linkerd / Cilium service mesh、cover mTLS / observability / traffic policy；不要在 Swarm migration 後立刻上 mesh、分階段。

跟 GitOps 整合

K8s + Argo CD / Flux 是 natural pair；migration 時直接走 GitOps、避免 manual kubectl 操作累積。

跟 Vault → AWS Secrets Manager 對齊

Swarm secrets → K8s Secret → external secrets management 是 3-step 演進、不是 1-step；migration 期間先用 K8s Secret、之後切 Vault / Secrets Manager。

相關連結

• Target vendor：Kubernetes
• 平行 migration playbook (Type E)：Kafka ↔ NATS / Redis → Memcached / etcd → Consul / Sentry → Honeycomb
• Methodology：Migration playbook methodology

本文是跨 vendor migration playbook、cross-link Terraform（source）跟 OpenTofu（target）。Type B drop-in migration 標準形態、跑 migration-playbook-methodology 6 維 audit 後對映 6 維皆 Low → Type B drop-in；本文驗證 skill 的 Type B anatomy 在 IaC 領域成立。

HCL / state file / provider 三層 diff sample

跟前批 Redis → DragonflyDB 同為 Type B drop-in、本文用 code-led entry — 直接給 3 種 diff sample 證明「真 drop-in」：

1# 1. HCL syntax: 完全相同 (Terraform 1.5.x baseline)
2resource "aws_s3_bucket" "logs" {
3  bucket = "myapp-logs"
4  tags = {
5    Env = "production"
6  }
7}
8# 兩家 binary 都接受、執行結果一致

 1# 2. State file: 完全相同 schema
 2$ cat terraform.tfstate | jq '.version, .terraform_version'
 34
 4"1.5.7"
 5
 6# 切 OpenTofu 後 re-init、state 保留
 7$ tofu init
 8$ cat terraform.tfstate | jq '.version, .terraform_version'
 94
10"1.6.0"  # tool version 標記變、其他不變

 1# 3. Provider: registry 路徑唯一明顯差異
 2terraform {
 3  required_providers {
 4    aws = {
 5      source  = "hashicorp/aws"     # 兩家共用 source 字串
 6      version = "~> 5.0"
 7    }
 8  }
 9}
10# Terraform 從 registry.terraform.io 拉
11# OpenTofu 預設從 registry.opentofu.org 拉 (fallback 到 terraform registry)

3 層 diff sample 顯示：HCL / state schema / 主流 provider 配置完全相容；唯一明顯差異在 registry routing。

跑 6 維 diff dimension audit：

6 維皆 Low → Type B drop-in。

為什麼遷：license / governance / community 三條 driver

跟前批 Redis → DragonflyDB 不同（cost / performance driver）、Terraform → OpenTofu 主要 driver 在 governance：

反向 driver（OpenTofu → Terraform）：

• Terraform Cloud / Enterprise 特定 feature 依賴（policy as code 用 Sentinel、跟 OpenTofu 自家 OPA 不對等）
• 既有 module 在 Terraform registry 維護、未同步 OpenTofu registry

相容性 audit

Pre-cutover 必跑：

Audit output：列「100% drop-in」block + 「需處理」block；後者通常 < 5% 範圍。

Step-by-step cutover

 1# 1. Install OpenTofu (跨 OS)
 2brew install opentofu                # macOS
 3snap install --classic opentofu      # Ubuntu
 4# https://opentofu.org/docs/intro/install/
 5
 6# 2. 在 workspace 跑 tofu init
 7$ cd terraform-workspace/
 8$ tofu init -upgrade
 9# 升級 provider / module、re-init backend、保留 state
10
11# 3. Plan diff（應該 = 0 changes）
12$ tofu plan
13# Plan: 0 to add, 0 to change, 0 to destroy.
14# 如果有 diff、表示 provider version 不對齊、檢查 lock file
15
16# 4. Apply（保險起見、staging 先跑）
17$ tofu apply
18
19# 5. CI / CD pipeline 切 binary
20# Before
21terraform init
22terraform plan -out=tfplan
23terraform apply tfplan
24
25# After
26tofu init
27tofu plan -out=tfplan
28tofu apply tfplan
29# 或保留 terraform 字面、用 alias / symlink

整個 cutover 通常 < 1 天（單 workspace）；多 workspace organization 視規模 1-4 週逐個切。

Production 故障演練

Case 1：Provider version drift、staging plan 出現意外 diff

徵兆：tofu plan 顯示 100+ resource 有 in-place update、實際業務沒改任何 config。

根因：.terraform.lock.hcl 鎖的 provider version 在 Terraform / OpenTofu registry 不一致（同 version 但 binary checksum 微差）；OpenTofu 在 init 時拉新 checksum、視為「provider 變了」。

修法：

1. 預先對齊：tofu init -upgrade 重建 lock file、把 OpenTofu 端 checksum 寫進去
2. CI lockfile commit：lock file 進版控、不同 binary 端跑前先 lockfile 對齊
3. 若 plan 仍有差異：通常是 provider 內部 schema 對 nil 值處理不同、用 lifecycle.ignore_changes 暫忽略、後續逐項 fix

Case 2：State file lock 機制微差

徵兆：兩個 CI pipeline 同時跑 tofu apply、其中一個應該 lock 拒絕、實際兩個都跑、production 端 race condition。

根因：Terraform DynamoDB lock 跟 OpenTofu lock 用相同 schema 但 lock_id 規則略不同；舊 lock entry 殘留時 OpenTofu 端解析失敗、視為「無 lock」繼續跑。

修法：

1. DynamoDB lock table 手動清舊 entry：cutover 期間先 aws dynamodb delete-item 清舊 lock
2. 單向流量切換：cutover 期間 freeze 所有 CI、只一個 pipeline 跑、避免 race
3. 架構：用 fully replicated lock backend（如 Consul）avoid backend-specific lock 怪異

Case 3：Terraform Cloud workspace 不能直接搬

徵兆：team 已用 Terraform Cloud workspace 跑 100+ pipeline、想切 OpenTofu、發現 terraform login / workspace API / VCS integration 全 HashiCorp-specific。

根因：OpenTofu 沒對等 Terraform Cloud 服務；自家 backend 用 S3 + Atlantis / Spacelift / env0 等第三方 platform 對接、不是 1:1 替代。

修法：

1. 保留 Terraform Cloud 跑 production（OpenTofu 不替代）、用 OpenTofu 跑 dev / sandbox
2. 遷出 Terraform Cloud：state 遷 S3 + 用 Atlantis 跑 PR-based plan/apply（mature open source）
3. 評估 Spacelift / env0 商業替代、支援 OpenTofu + 對等 workspace feature

Case 4：CI pipeline 寫死 terraform binary name

徵兆：cutover 後 CI 跑 terraform plan 報「command not found」；team 100+ pipeline / GitHub Action / GitLab CI / shell script 都寫死 terraform。

根因：rollout 計畫沒 grep 全 organization 找 binary name 引用。

修法：

1. Alias 策略：CI image 內 ln -s /usr/local/bin/tofu /usr/local/bin/terraform、保留兼容 1-3 個月
2. 逐步改 tofu：跟著 IaC team 修 pipeline file、target 100% 改完才 remove alias
3. 架構：避免在 pipeline / script 寫死 binary、用 env variable IAC_BINARY=${IAC_BINARY:-tofu}

Case 5：Registry routing、自家 module 拉不到

徵兆：cutover 後 tofu init 對自家 private module 報「not found」；同 module 在 Terraform 端跑得好好的。

根因：private module 註冊在 Terraform Cloud private registry、OpenTofu 預設不知道這個 endpoint；需要顯式設 registry source URL。

修法：

1. 顯式 source URL：source = "app.terraform.io/myorg/myapp/aws" 改 git source 或自架 module registry
2. 架構：用 git-based module source（source = "git::ssh://git@github.com/myorg/myapp.git"）、避開 registry lock-in
3. 長期：自家 module 同時 publish 到 OpenTofu registry / Terraform Cloud / git、跨 tool 兼容

Capacity / cost

判讀：純 IaC 用戶切 OpenTofu 風險低 + 省 license 風險；重度依賴 Terraform Cloud feature 的 organization 保留或評估 commercial alternatives（Spacelift / env0）。

整合 / 下一步

跟 Atlantis / Spacelift / env0 整合

OpenTofu 沒對等 Terraform Cloud、需要 third-party orchestrator：

• Atlantis：自架、開源、輕量、適合中小型 team
• Spacelift：SaaS、policy as code、支援 OpenTofu first-class
• env0：SaaS、cost estimation、workflow 完整

跟 Terragrunt 整合

Terragrunt（OpenTofu / Terraform 共用 wrapper）已支援 OpenTofu 1.6+；多環境配置抽象保留、底層 binary 切換無感。

反向 migration（OpenTofu → Terraform）

罕見、通常是 organization 走商業合約綁 HashiCorp Enterprise 才會做；流程鏡像對稱、注意 OpenTofu 1.6+ 自家 feature（state encryption / provider for_each）在 Terraform 端可能缺。

下一步議題

• State encryption（OpenTofu 1.7+）：sensitive state 加密、Terraform 商業版才有對等 feature
• 跨 IaC tool（Pulumi / CDK）：Pulumi / AWS CDK 是不同 paradigm（imperative）、不在本 migration scope
• Provider ecosystem 長期分裂：兩家 registry 自我演化、需要 quarterly review provider compat

相關連結

• Source vendor：Terraform
• 平行 migration playbook（Type B）：Redis → DragonflyDB
• Methodology：Migration playbook methodology / #127 Process content 結構由最大差異維度決定

本文是跨 vendor migration playbook、cross-link etcd 跟 Consul。跑 migration-playbook-methodology 6 維 audit 後對映 Paradigm = High（pure KV → service mesh paradigm）→ Type E paradigm shift；跟 Redis → Memcached（paradigm reduction）對偶、本文是 paradigm expansion（upgrade）方向。

KV + N 個 extras：feature matrix

核心差異不在「Consul 多功能」、在「Consul 是 service mesh paradigm」：service discovery / health check / Connect mTLS 是 first-class、KV 只是其中一個 sub-feature。

跑 6 維 diff dimension audit：

Paradigm = High（其他 Low-Medium）→ Type E paradigm shift；KV 是 sub-feature、不是 migration scope 全部。

為什麼遷：3 條 expansion driver

• Service mesh adoption：本來用 etcd 跑 K8s control plane、現在 application 端要 service mesh（mTLS / intentions / 流量切換）、Consul 一站式 cover
• Multi-DC strategy：etcd 不支援跨 DC、要 active-passive failover；Consul WAN federation 支援 active-active 多 DC
• Configuration management：consul-template + envconsul 比 etcd watch + 自寫 reloader 簡單

反向 driver（Consul → etcd）：

• 純 K8s control plane scenario、不需要 service discovery / health check / mesh、etcd 簡單足夠
• Resource constraint：Consul agent 比 etcd 更吃資源、low-end VM 上不夠

Paradigm expansion 路線

跟 Redis → Memcached paradigm reduction（移除 features）對偶、Consul 是 補進 features：

 1etcd KV pattern         → Consul KV API (1:1 對位)
 2etcd watch              → Consul blocking query / consul-template
 3etcd lease + lock       → Consul session + KV CAS
 4
 5(額外加進)
 6無                      → Consul service registration (services.json / API)
 7無                      → Consul health check (HTTP / TCP / TTL)
 8無                      → Consul service discovery (DNS / HTTP)
 9無                      → Consul Connect (mTLS + intentions)
10無                      → Consul WAN federation (multi-DC)
11無                      → Consul ACL token + policy

Migration 不只是 KV API 對位、是 application 增能。

API 對位

1# etcd basic KV
2etcdctl put /myapp/config/db_url 'postgres://...'
3etcdctl get /myapp/config/db_url
4
5# Consul KV (對位)
6consul kv put myapp/config/db_url 'postgres://...'
7consul kv get myapp/config/db_url

1# etcd watch
2etcdctl watch --prefix /myapp/config/
3
4# Consul blocking query (long polling)
5curl 'http://consul:8500/v1/kv/myapp/config?recurse&index=5&wait=10s'
6# X-Consul-Index header 為 watch cursor

 1# etcd transaction (multi-key atomic)
 2etcdctl txn <<EOF
 3compares:
 4mod("/myapp/lock") = "0"
 5success requests:
 6put /myapp/lock "owner1"
 7EOF
 8
 9# Consul session + KV CAS (對位)
10SESSION_ID=$(curl -X PUT 'http://consul:8500/v1/session/create' | jq -r .ID)
11curl -X PUT 'http://consul:8500/v1/kv/myapp/lock?acquire='$SESSION_ID -d 'owner1'
12# 若失敗 lock 已被別人持有

Application 重設計

 1# Before: etcd
 2import etcd3
 3etcd = etcd3.client(host='etcd', port=2379)
 4etcd.put('/myapp/config/db_url', 'postgres://...')
 5db_url = etcd.get('/myapp/config/db_url')[0]
 6
 7# After: Consul (KV-only)
 8import consul
 9c = consul.Consul(host='consul', port=8500)
10c.kv.put('myapp/config/db_url', 'postgres://...')
11_, kv = c.kv.get('myapp/config/db_url')
12db_url = kv['Value']
13
14# (額外加進) After: Consul service discovery
15c.agent.service.register(
16    name='myapp',
17    service_id='myapp-1',
18    address='10.0.0.10',
19    port=8080,
20    check=consul.Check.http('http://10.0.0.10:8080/health', '10s', '5s', '30s')
21)
22
23# DNS-based discovery (其他 service 找 myapp)
24# dig +short myapp.service.consul SRV

Migration 流程

 11. Pre-migration audit
 2   - 列 etcd 使用的所有 application
 3   - 評估每個 application 是否 *需要* Consul extras（service discovery / health / mesh）
 4   - 純 KV use case 標 *low-effort migration*、用得到 extras 標 *value-add migration*
 5
 62. Consul cluster build
 7   - 跨 DC 設計（WAN federation 規劃）
 8   - ACL system 配置（不要 default open）
 9   - 性能 sizing（Consul agent 比 etcd 重）
10
113. Application migration（per-app）
12   - 純 KV: SDK 換、API 對位、cutover
13   - Service discovery: 加 registration + health check + DNS lookup
14   - Service mesh: 加 Connect proxy + intentions
15
164. Dual-run period
17   - etcd 仍跑、application 漸進切到 Consul
18   - 每 application cutover 後驗證
19
205. etcd decommission
21   - 確認所有 application 已切
22   - K8s control plane（如果是 etcd 唯一 user）保留不切

整體 2-4 個月、依 application 數量跟 extras 採用程度。

Production 故障演練

Case 1：KV API 對位看似 1:1、watch event model 不同

徵兆：application 端從 etcd watch 切 Consul blocking query 後、event 處理 latency 從 50ms 漲到 1-5s；應用以為 event push 即時、實際變 polling。

根因：etcd watch 是 gRPC stream、event 即時 push；Consul blocking query 是 long-polling、有 wait timeout、event 在 timeout 內到才即時收到。

修法：

1. 降 wait timeout 跟業務需求對齊（default 5min、可設 10s）
2. 多 instance 並發 polling：N 個 application instance 各自 polling、降單點 event 延遲
3. 架構：critical event 用 Consul event API（PUT /v1/event/fire/<name>）+ blocking query event endpoint、跟 KV change 分開
4. 保留 etcd for critical watch：mission-critical watch 用 etcd 不切

Case 2：Session-based lock 跟 etcd lease 差

徵兆：原本 etcd lease 5s TTL、lease holder application 失聯時 5s 內 lock 自動釋放；切 Consul session 後、session TTL 仍生效、但 health check 整合複雜、偶發 lock not released。

根因：Consul session 有兩種模式 — delete（session expire 時 release lock）vs release（release lock 但 KV 保留）；TTL 配 health check 時行為複雜。

修法：

1# 明示 session behavior
2session_id = c.session.create(
3    name='myapp-lock',
4    ttl=15,           # 15s TTL
5    behavior='delete' # session 過期時 lock 自動 release
6)
7c.kv.put('myapp/lock', 'owner1', acquire=session_id)

session TTL 範圍 10s-86400s、不能 < 10s（etcd 可以 1s）；critical low-latency lock 不適用 Consul。

Case 3：Multi-DC failover、KV 寫到 wrong DC

徵兆：跨 DC 部署後、某 application 寫 KV、但 read 不到；發現 application 端 hardcode 一個 DC 端點、write 到 us-east 但 read 來自 us-west。

根因：Consul WAN federation 跨 DC 不自動同步 KV；KV 是 per-DC、跨 DC sync 需要 Consul Enterprise license 或自管 consul-replicate。

修法：

1. 每 application instance 連 local DC Consul：write/read 同 DC
2. KV replication 跨 DC：用 consul-replicate 自管、或升 Enterprise
3. Architecture：跨 DC 共享 config 改用 DB-backed config（持久 + 跨 DC）+ Consul KV 只存 DC-local config

Case 4：ACL system 預設 open、cutover 後曝險

徵兆：Consul cluster 上線 1 個月後 SOC 跑 audit、發現任何 application 都能 read 任何 KV；ACL 沒設、所有 token 都全權限。

根因：Consul ACL 預設 disabled、需要 bootstrap；很多 setup tutorial 簡化跳過 ACL、cutover 後沒補。

修法：

 1# Bootstrap ACL system
 2consul acl bootstrap
 3# 生成 management token、保留為 root credential
 4
 5# 建 policy
 6consul acl policy create -name 'myapp-readonly' \
 7  -rules 'key_prefix "myapp/" { policy = "read" }'
 8
 9# 建 token 給 application
10consul acl token create -policy-name 'myapp-readonly'

Production setup 第一步就 bootstrap ACL、不可以延後。

Case 5：Health check failure 連鎖、service discovery 失效

徵兆：某 application instance 因 GC pause 5 秒未 respond health check、被 Consul 標 failed；DNS query 不返回該 instance；流量切走；GC 結束後 instance 仍 healthy 但 Consul 端 still failed、需要 minutes recover。

根因：Consul health check 失敗後進入 critical state、需要 連續 N 次成功 才回 passing；default 1-2 次成功即可、但實際時間視 check interval 而定。

修法：

1. success_before_passing 設低（1）讓快速恢復
2. failures_before_critical 設高（3-5）容忍 transient failure
3. Multi-check strategy：HTTP + TCP + script check 三軸、不靠單 check
4. Application-side hint：JVM application 配 MaxGCPauseMillis 限制 GC pause < health check interval

Capacity / cost

判讀：純 KV use case 走 etcd；service mesh / multi-DC / discovery 需求大走 Consul；混合 deployment 是 long-term default（K8s control plane 仍跑 etcd、service mesh 跑 Consul）。

整合 / 下一步

跟 Kubernetes 對位

K8s control plane 永遠 用 etcd、不切 Consul；Consul 是 K8s 外 的 service mesh + 跨 cluster discovery。兩者並存、不互斥。

跟 Vault 整合

Consul + Vault 是 HashiCorp 同生態、Consul 跑 service discovery / mesh、Vault 跑 secrets；Consul ACL token 可從 Vault dynamic engine 取得。

跟 Istio / Linkerd 對位

Consul Connect 是 service mesh paradigm、跟 Istio / Linkerd 並列；多數 K8s-native organization 用 Istio / Linkerd、Consul 強項在 跨 K8s + VM + multi-DC mesh。

反向 migration（Consul → etcd）

少數 organization 簡化 stack 時做、流程鏡像對稱、但 退掉 service mesh / multi-DC 是有意識降級、不能假裝功能等價。

下一步議題

• Consul Connect production rollout：mesh adoption 是 incremental、per-service intentions 漸進
• Multi-DC topology 設計：active-active vs active-passive、依 RPO/RTO 跟 cost trade-off
• 跟 Kubernetes Gateway API 整合：service mesh paradigm 在 K8s 內 vs 外整合策略

相關連結

• Target vendor：Consul
• 平行 migration playbook (Type E)：Redis → Memcached（paradigm reduction 對偶）/ Kafka ↔ NATS
• 平行整合：HashiCorp Vault
• Methodology：Migration playbook methodology