在 Kubernetes 用 Loki 蒐集 log 做監控警告通知方法整理筆記

2022-04-03 338 words 2 minutes

Contents

這篇比較像我那次把環境一路建起來之後的總整理。主題是「在 Kubernetes 裡把 log 收進 Loki，接著做查詢、監控與警告通知」，但實際落地時，問題往往不只在 Loki 本身，而是會一路牽涉到主機網路、 bastion host、 Ingress、 Helm、 Grafana 與告警設定。

如果你是第一次碰這條路線，這篇可以當成導讀地圖。重點不是把每個指令全部塞在同一篇，而是先知道整套鏈路長什麼樣子，再回頭看對應的安裝細節。

先講整體架構

當時我的想法很單純：

機器先建立起來，確保能透過 bastion host 安全登入。
Kubernetes 叢集能正常運作。
Ingress Controller 能把服務對外曝光。
Loki 能把 Pod log 收進來。
Grafana 能查 log。
告警規則命中時能通知到人。

如果把資料流畫成一張圖，大概會像這樣：

flowchart LR A[Application Pod] --> B[Log Agent / Promtail] B --> C[Loki] C --> D[Grafana] D --> E[Alert Rule] E --> F[Notification Channel]

很多人剛接觸時會把注意力全部放在 Loki query 語法，但實際上「能不能收得到 log」、「能不能穩定登入節點」、「Ingress 路由有沒有通」常常才是最先卡住的地方。

這次筆記拆成哪些主題

主機建置與 Bastion Host

Kubernetes、Traefik、Loki 與監控

這幾篇合起來，才是完整的操作脈絡。單看其中一篇通常會少一段上下文。

為什麼 Loki 適合拿來做這件事

Loki 的核心概念是「像查詢 log 一樣查 log，而不是先把所有內容重度索引」。和全文索引型的方案相比，它在某些場景下會更省資源，尤其是你已經有 Grafana 生態系，想先把 Kubernetes log 集中起來做檢索與告警時，進入門檻相對低。

它常見的價值有幾個：

容器重建後，歷史 log 還能集中查詢。
可以依 namespace、pod、container 等 label 過濾。
能把錯誤關鍵字、次數門檻或特定 pattern 做成告警。
很適合搭配 Grafana 一起用，查詢、 dashboard、 alert 都能串起來。

建環境時我踩到的幾個重點

1. 先搞懂 bastion host，不然後面很容易卡遠端操作

第一次碰雲端虛擬機的 Web 管理介面，我一開始其實不太習慣。以前自己在本機玩 VirtualBox，機器開好就差不多了；但到雲端環境後，還要理解私有網路、路由器、浮動 IP、 Security Group 這些概念，剛看介面真的會有點亂。

後來我先照著文件把 bastion host 的路線打通，才發現這件事非常重要。因為一旦跳板機設定好，後面不管你是 SSH 到節點、做 kubectl 管理、 scp 傳檔，甚至 SSH tunnel 導出 Dashboard，整個維運流程都會順很多。

2. IP 與網路設定要先穩

我那次也遇到一些網卡與 IP 配置問題。以前習慣直接用 ifconfig 之類的方式處理，但現在很多 Linux 發行版都是用 netplan 或其他方式管理，邏輯已經不太一樣。像多張網卡、 DHCP 與固定 IP 混用時，如果沒有先釐清哪個 interface 在接外網、哪個在接內網，後面 Kubernetes 安裝常常會出現「看起來裝好了，但實際上 service 不通」的情況。

3. CNI 與網段衝突會讓你懷疑人生

我第一次裝 Kubernetes 時，原本以為套件裝一裝、 kubectl apply 下去就好了。結果後來發現 CNI 如果選得不對，或 Pod network CIDR 跟現有網段衝突，Service、 Pod 彼此通訊都可能出問題。

我當時用 Calico 沒順起來，後來改用 Flannel 才比較穩。這不代表哪個一定比較好，而是提醒自己：網段規劃跟 CNI 選型不能當成安裝細節，這其實是控制面與資料面能不能通的前提。

4. Ingress Controller 設定不通，Loki / Grafana 也會跟著卡

很多教學會用 Nginx Ingress Controller，我那次是想搭配 Traefik。理論上都能達成，但實際設定時， Dashboard 路由、 entrypoint、 service name、 port 等細節只要一個沒對上，就很容易 404。

這也是我後來的一個心得：觀測系統不是獨立世界。只要 Ingress、 DNS、 TLS 或 tunnel 其中一段不通，最後你看起來像是 Loki 壞掉，其實根因常常在前面的網路或反向代理。

如果你要自己重做一次，建議順序

我會建議照下面順序做，不要一開始就急著看 Loki query：

確保 bastion host 與 SSH 設定正確。
確保每台節點的 IP、 DNS、時間同步正常。
Kubernetes 與 CNI 安裝完成後，先驗證 Pod 與 Service 是否互通。
再安裝 Ingress Controller。
接著安裝 Loki / Promtail / Grafana。
最後才開始做 log query、 dashboard 與 alert rule。

這樣做的原因很簡單：越上層的功能越依賴下層基礎。如果叢集網路沒穩，後面所有觀測告警都只是在排假問題。

我這次最大的收穫

這次研究對我最大的幫助，不是單純學會「怎麼裝 Loki」，而是第一次比較完整地把雲端主機、跳板機、 Kubernetes、 Ingress、 observability 這幾塊串起來。以前看這些名詞都知道，但實際自己把路打通之後，才會真的理解它們之間的依賴關係。

像是：

ssh config 搭配 ProxyJump 可以大幅降低多跳主機的操作成本。
SSH tunnel 不只是連 DB 好用，對內部 Dashboard 測試也很實用。
Loki 告警看起來像應用層需求，但背後很仰賴叢集與網路層的穩定度。

心智圖

mindmap root((Kubernetes Loki 監控整理)) 基礎環境雲端 VM Bastion Host SSH config ProxyJump 叢集層 Kubernetes 安裝 CNI Pod Network Service 連通性入口層 Traefik Ingress Dashboard Tunnel 觀測層 Promtail Loki Grafana Alert Rule 踩雷點網段衝突 404 路由錯誤 IP 配置登入路徑不順

小結

如果你只是想要一份「Kubernetes 上 Loki 安裝全指令」，這篇不是那種一步一步照抄就完成的文章；它比較像一張全圖，幫你知道整條鏈路要看哪些元件、哪一段最容易卡、出了問題該優先懷疑哪個層次。

我自己的經驗是，先把網路與登入路線打順，再做 Loki 監控，成功率真的會高很多。