iT邦幫忙

2025 iThome 鐵人賽

DAY 18
0
Cloud Native

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

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

  • 分享至 

  • xImage
  •  

前言

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

可觀測性的三大支柱(Three Pillars of Observability)

支柱 定義 實例 常用工具
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 等指令快速調查原因

指令

  1. 查看節點用量
    oc adm top nodes
    
    NAME                        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
    infra-1.xxxx.zzzzzzz.tw     1357m        38%    11288Mi         75%
    
  2. 查看 Pods 資源用量
    oc adm top pods -n <namespace>
    
    NAME          CPU(cores)   MEMORY(bytes)
    aaa-xxx       10m          80Mi
    bbb-zzz       15m          3684Mi
    
  3. 查看所有指標
    oc get --raw /api/v1/nodes/<node-name>/proxy/metrics
    
  4. 透過 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 模擬故障

上一篇
【Day 17】 私有 Quay Registry 與 oc mirror
下一篇
【Day 19】 從 Docker 棄坑、你需要使用 Podman 的理由
系列文
駕馭商用容器叢集,汪洋漂流術19
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言