kubernetes 周邊生態

監控

• 以 Prometheus 項目爲核心的一套統一的方案
  • Prometheus 項目工作的核心，是使用 Pull 的方式去搜集被監控對象的 Metrics 數據（監控指標數據），然後再把這些數據保存在一個 TSDB （時間序列數據庫，比如 OpenTSDB、InfluxDB 等）當中，以便後續可以按照時間進行檢索
  • Pull模式
    • 特點
      • 被監控方提供一個server，並負責維護
      • 監控方控制採集頻率
    • 優點
      • 監控指標由用戶自己維護，使得標準化很簡單
      • 監控系統對metric採集的統一和穩定有了可靠的保證，對於數據量大的情況下很重要
    • 缺點
      • 採用輪詢拉取方式，數據延遲較高
      • 容易造成一些信息的丟失和不準確
  • 監控指標
    • 宿主機數據，包括負載，磁盤等
    • k8s組件數據，包括Controller 的工作隊列的長度、請求的 QPS 和延遲數據等
      • 是檢查 k8s本身工作情況的主要依據

日誌採集

• 容器默認採用的是日誌驅動爲 json-file 模式，採集效率極低還佔用大量 IO 讀寫效能，基本無法適應生產環境需要
• 在我們生產實踐推薦中，偏向於採用系統提供的日誌系統 systemd-journal 來接收日誌採集，然後通過 fluentd 採集代理進程，把相應的日誌按照業務規則分類匯聚，發送到 Elasticsearch 這樣的中央日誌管理系統
• 由於業務日誌量的規模擴大，日誌採集的流量速率會讓中央日誌系統處理負載過高，導致業務日誌處理不過來。所以通常採用流式消息隊列服務 Kafka 作爲日誌存儲的異步緩衝，可以極大的緩解日誌流量，並高效的解決日誌採集的匯聚難題

三種日誌方案

• 方案一： Node 上部署 logging agent，將日誌文件轉發到後端存儲裏保存起來
  • 一個節點只需要部署一個 agent，並且不會對應用和 Pod 有任何侵入性
  • 不足在於，它要求應用輸出的日誌，都必須是直接輸出到容器的 stdout 和 stderr 裏
    
• 方案二： 當容器的日誌只能輸出到某些文件裏的時候，我們可以通過一個 sidecar 容器把這些日誌文件重新輸出到 sidecar 的 stdout 和 stderr 上
  • 這樣就能夠繼續使用第一種方案了
  • 由於 sidecar 跟主容器之間是共享 Volume 的，所以這裏的 sidecar 方案的額外性能損耗並不高，也就是多佔用一點 CPU 和內存
  • 但是宿主機上實際上會存在兩份相同的日誌文件，這對磁盤是很大的浪費
    
• 方案三： 通過一個 sidecar 容器，直接把應用的日誌文件發送到遠程存儲裏面去
  • 相當於把方案一里的 logging agent，放在了應用 Pod 裏
  • 部署簡單，並且對宿主機非常友好
  • 但是這個 sidecar 容器很可能會消耗較多的資源，甚至拖垮應用容器
  • 並且由於日誌沒有輸出到 stdout 上，通過 kubectl logs 是看不到任何日誌輸出的

• 無論是哪種方案，你都必須要及時將這些日誌文件從宿主機上清理掉，或者給日誌目錄專門掛載一些容量巨大的遠程盤。否則，一旦主磁盤分區被打滿，整個系統就可能會陷入奔潰狀態