【Day 18】 SRE 的基礎素養 / 叢集常用的周邊服務

2025 iThome 鐵人賽

DAY 18

Cloud Native

駕馭商用容器叢集，汪洋漂流術系列第 18 篇

17th鐵人賽 ocp cloud native openshift k8s

二坪山小弱砲

2025-09-04 23:56:27

89 瀏覽

分享至

前言

SRE，全名是 Site Reliability Engineering，最早由 Google 提出，目的是用軟體工程的方法解決系統運維問題。 SRE 最大的特色，就是將 DevOps 精神具體化、系統化，透過工程技術提高服務可靠性，同時保留創新速度。在 SRE 領域中，監控（Monitoring）與可觀測性（Observability）是確保系統穩定運行的關鍵核心。

可觀測性的三大支柱（Three Pillars of Observability）

延伸閱讀： Distributed Systems Observability
by Cindy Sridharan

連結：https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html

支柱	定義	實例	常用工具
Metrics	數值型資料，系統/服務健康狀態的 KPI	CPU 使用率、QPS、錯誤率	Prometheus, InfluxDB
Logs	時間序列的事件訊息，用來還原現場	應用錯誤日誌、Nginx 訪問紀錄	ELK Stack, Loki
Tracing	分散式系統的請求追蹤，知道請求去哪了	A → B → C 的延遲、瓶頸點	Jaeger, Zipkin, Tempo

SRE 關鍵觀念 / 名詞

常見的名詞縮寫，還有代表的意思，一定要記起來，才聽得懂別人在說什麼術語。

名稱	說明
SLI（Service Level Indicator）	可以量測的服務指標（如延遲 < 500ms）
SLO（Service Level Objective）	希望達到的目標（如 99.9% 成功率）
SLA（Service Level Agreement）	與客戶簽約的服務水準（有法律效力）
Error Budget	容許的錯誤餘額（SLO - 實際表現）

可觀測性：OCP 內建監控完整

使用 Prometheus Operator 收集指標
透過 Grafana Dashboards 可視化
整合 Elasticsearch + Kibana + Fluentd (EFK) 做日誌管理
使用 Jaeger/Tempo 追蹤 Service Mesh 請求路徑

SLO 管理：以服務為中心

在 OCP 上部署服務時，可定義 Probe 來標記服務健康
使用 Prometheus 計算 Error Rate
用 Alertmanager 設定 SLO 達不到時通知

Incident Response：OCP + GitOps 實現快速恢復

使用 ArgoCD / GitOps 管理配置
當設定異動時出現故障，Git revert 一鍵 Rollback
透過 oc describe, oc logs, oc adm 等指令快速調查原因

指令

查看節點用量

oc adm top nodes

NAME                        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
infra-1.xxxx.zzzzzzz.tw     1357m        38%    11288Mi         75%

查看 Pods 資源用量

oc adm top pods -n <namespace>

NAME          CPU(cores)   MEMORY(bytes)
aaa-xxx       10m          80Mi
bbb-zzz       15m          3684Mi

查看所有指標

oc get --raw /api/v1/nodes/<node-name>/proxy/metrics

透過 Prometheus 儀表板查看
```
oc get route -n openshift-monitoring
```

SRE <--> OCP 元件

🔑 SRE 核心知識點	💡 概念說明	🔧 常見對應工具/服務	📦 在 OCP 的對應元件/方法
Metrics 指標監控	可量測的數據，如 QPS、延遲、錯誤率	Prometheus、InfluxDB	`openshift-monitoring` 的 Prometheus
Logging 日誌收集	結構化紀錄系統事件，便於查錯	EFK (Elasticsearch + Fluentd + Kibana)、Loki	OpenShift Logging stack (`openshift-logging` Project)
Tracing 追蹤請求流程	跨服務追蹤，找出瓶頸和延遲來源	Jaeger、Zipkin、Tempo、OpenTelemetry	OpenShift Distributed Tracing (`jaeger-all-in-one`)
Alerting 警示系統	根據指標與規則發送通知	Prometheus Alertmanager、PagerDuty、Opsgenie	`Alertmanager` 內建於 `openshift-monitoring`
SLO / SLI / SLA	設定並監控服務水準目標	SLO 計算器、Grafana SLO panels	可用 PromQL 查詢、Grafana 呈現、結合 Alerts
Error Budget	容錯空間（1 - SLO）範圍內允許的錯誤	結合 SLI 計算公式，Grafana 顯示	使用 Prometheus rule 設定 + SLA dashboard
Runbook / Playbook	事先規劃好的故障排查 SOP	Confluence、Notion、Git repo 文字檔	儲存在 GitOps Repo / configmap / ConsoleLink
Incident Management	異常處理流程，包含通知、處置、回報	PagerDuty、Statuspage、Jira Incident	可整合 webhook 通知工具，或接收告警
Postmortem 報告	RCA 根因分析與後續行動方案	Google Docs、Markdown 模板、Incident.io	作為 CI/CD 的一部分或納入 GitOps flow
Capacity Planning 容量預估	根據歷史數據預測資源使用	Prometheus + Grafana + Forecast plugin	OpenShift Console 中資源圖表，或自建儀表板
自動化修復	系統異常時自動 rollback 或重啟服務	K8s Liveness/Readiness Probe、Argo Rollouts	OCP 中 Deployment 自動重啟、ArgoCD auto sync
可用性設計	多副本、容錯、冗餘、Failover	K8s HPA, Multi-zone Deploy, LoadBalancer	OCP 的 Route + HAProxy + HPA + readinessProbe
Blackbox Monitoring	從用戶端模擬請求驗證服務是否可用	Blackbox Exporter、curl script	安裝 blackbox-exporter 並用 ServiceMonitor 掛上
Change Management	控制部署頻率、管理風險	GitOps、Canary、Blue/Green Deploy	OpenShift GitOps (ArgoCD)、Route shifting
Chaos Engineering	故障演練、驗證系統韌性	Chaos Mesh、Gremlin、LitmusChaos	可於 dev 環境實作，或整合 K8s Job 模擬故障