如何提高 Kubernetes 環境的可視性

實現可視化，獲得洞察力

首先，我們來看幾個定義：

• 可視化 —— 能夠看到或被看到的狀態
• 洞察 —— 對人或物擁有深刻的理解

StackRox 2020 年的一項調查顯示，75% 的 Kubernetes 用戶認為可視化是一項「必備」能力。 我們也認為可視化是 Kubernetes 環境的一個關鍵要素，畢竟要想弄清其中林林總總的部署專案，談何容易。 然而，在 F5 的《2021 年應用策略現狀》（SOAS） 報告中，95% 的受訪者表示，儘管他們擁有豐富的數據， 但對於保護和發展基礎架構和業務所需的應用的性能、安全性和可用性，他們仍然無法獲取“洞察”。 洞察為何如此重要？ 如何獲得洞察？ 

洞察可説明您：

• 檢測漏洞和潛在攻擊向量，增強安全性與合規性
• 先於客戶發現問題，減少中斷和停機時間
• 查找應用問題的根源，提高故障排除效率
• 確認流量被正確地路由
• 準確瞭解 Kubernetes 環境中的運行專案及其是否得到合理配置和保護
• 根據延遲和性能歷史記錄確定您是否使用了適當的資源數量
• 基於過去的流量模式預測季節性需求
• 根據回應時間衡量性能，並根據服務等級協定 （SLA） 追蹤性能，同時用作預警系統，防止問題影響用戶體驗

要獲得洞察力，您需要兩種類型的可視化數據：實時數據和歷史數據。 實時數據可説明您診斷當前問題的來源，而歷史數據可説明您辨別正常與異常。 這兩種類型的可視化來源相結合，可提供關於應用和 Kubernetes 性能的關鍵洞察。 

與其他技術投資一樣，您還需要制定策略來幫助您實現相關收益。 SOAS 報告還指出，出於企業多方面的原因，例如招聘和員工發展、戰略和流程以及數據用途、使用情形和使用人員的分歧，人們未能獲得寶貴的洞察。 調查結果包括以下三方面：

• 相關技能 —— 高素質技術專業人員短缺已經不是什麼秘密，47% 的受訪者表示，他們很難招到想要的人才。
• 數據共享計劃 —— 只有 12% 的受訪者構建了向業務決策者報告數據的流程和策略，以便讓他們瞭解擁有彈性的技術（或缺乏彈性的技術）對業務的影響。
• 可視化的目的 —— 大多數受訪者被動地使用遙測技術（即進行故障排除），而只有 24% 的受訪者主動使用數據和洞察監控潛在的性能下降問題，16% 的受訪者主動跟蹤 SLA 性能。

下文將重點探討技術方面的洞察。 後續我們將發佈有關戰略、流程及其他主題的文章，敬請關注。

NGINX 如何助您一臂之力

我們知道大多數 Kubernetes 部署環境 已經有一個監控工具了，不再需要其他工具了。 為此，我們提供了NGINX Plus API，既可幫您輕鬆匯出指標數據，也可與 OpenTracing 以及 Grafana 和 Prometheus  等熱門工具相整合，從而為您提供集群內性能的全面洞察。 通過深度跟蹤，您可以有針對性地獲得應用性能和可用性的洞察，從而瞭解請求在微服務應用中的處理過程。 

• 出入向（南北向）流量洞察
  NGINX Ingress Controller 提供了關於進出 Kubernetes 集群流量的洞察。 
  • 基於 NGINX 開發的熱門 Ingress Controller 一共有三個，您知道嗎？ 這三個並非都可以投用生產環境，選擇錯誤可能會適得其反，導致微服務策略更加複雜。 我們的博文 《Ingress Controller 選型指南，第四部分：NGINX Ingress Controller 選項》對各個選項進行了比較，能夠説明您做出最能滿足需求的決策。 
• 東西向流量洞察
  NGINX Service Mesh 對容器化應用之間的流量提供了相關洞察。

請繼續閱讀，看看我們如何幫助您解決兩個常見問題：

• 應用運行緩慢
• 集群或平台資源耗盡

如欲查看該技術的實際應用，請觀看下方 NGINX 和 Grafana 專家進行的直播演示和問答環節。 他們演示了如何實時監控關鍵負載均衡和性能指標、將指標導出到 Prometheus，並創立了一個帶有累積性能檢視的 Grafana 儀錶盤。

問題1：應用運行很慢

您有沒有想過可能遭到了 DDOS 攻擊？ 使用者是否報告了網站的錯誤？ 您只有在找到問題所在之後才能著手解決問題。 

• 借助 NGINX Ingress Controller 進行實時監控
  基於 NGINX Plus 的 NGINX Ingress Controller 提供了一個即時活動監控儀錶盤（由 NGINX Plus API 提供支援），可顯示數百個關鍵負載和性能指標。 儀錶盤可以提供細粒度資訊，甚至細化到單個 pod 級別，可説明您快速、輕鬆地衡量應用響應時間，並診斷問題的來源。 如果您的 Kubernetes 環境不斷增長，那麼每個新增的 NGINX Ingress Controller 實例會自動獲得新儀錶盤。 
  • 例如，HTTP 上游 （HTTP Upstreams） 選項卡上的兩列直觀地顯示了應用和基礎架構狀態：
  • 請求 —— 如果每秒請求數 （Req/s） 降至給定應用標準以下（例如，每秒 5 個請求，而正常請求數為40），則表示 Ingress Controller 或應用的配置可能不正確。
  • 回應時間 —— o 如果回應時間為 10 毫秒 （ms） 或更少，則表示運行狀況良好。 延遲超過 30-40 毫秒表示上游應用出現問題。

• NGINX Ingress Controller 的基本狀態
  配合使用NGINX 開源版，NGINX Ingress Controller 提供了一個狀態頁面，報告八個基本指標。
• NGINX Service Mesh 的 OpenTracing
  NGINX Service Mesh 通過 NGINX OpenTracing 模組支援 OpenTracing。 在撰寫本文時，NGINX OpenTracing 模組支援 DataDog、LightStep、Jaeger 和 Zipkin。

問題2：集群或平臺耗盡資源

出現了 HTTP 錯誤？ 503 和 40x 錯誤表示存在資源問題，而 502 表示配置變更不成功。 您可以使用歷史數據來診斷可能會出現資源耗盡的地方。 

• 借助 NGINX Ingress Controller 進行日誌記錄
  診斷網路問題的第一步是查看 NGINX Ingress Controller 日誌，其中每個日誌條目都使用相關的Kubernetes 服務註釋。 日誌的錯誤條目會標識相關服務。 日誌包含了流經 Ingress Controller 的所有流量的詳細資訊，包括時間戳、源 IP 位址和響應狀態碼。 您還可以將日誌導出到流行的聚合器中，例如DataDog、Grafana 和 Splunk。
• Prometheus 指標
  NGINX Ingress Controller 最受歡迎的特性之一是其不斷擴展的 Prometheus 指標清單，其中包含網路性能和Ingress Controller 流量指標 。 基於 NGINX Plus 的 NGINX Ingress Controller 能夠匯出一系列相關指標，涵蓋連接、緩存、由 NGINX worker 組（在記憶體區共用數據）處理的  HTTP 和 TCP/UDP 流量、由後端伺服器組處理的 HTTP 和 TCP/UDP 流量等。 
  • NGINX Service Mesh 部署了一個 Prometheus 伺服器，該伺服器使用 NGINX Plus API 從 NGINX Service Mesh sidecar 和 NGINX Ingress Controller pod 獲取指標。 如果您希望使用現有的Prometheus 部署，我們還提供 scrape 配置，以供您添加到 Prometheus 配置檔。
• Grafana 儀錶盤
  我們為 NGINX Ingress Controller 和 NGINX Service Mesh 提供了官方 Grafana 儀錶盤，能夠將Prometheus Exporter 暴露出來的指標數據可視化。 使用者非常重視數據的粒度，包括精確到毫秒的詳細資訊、逐日覆蓋和流量峰值。 例如，NGINX Service Mesh 儀錶盤可以顯示任何一個服務或 pod 的流量以及被監控的活動 pod 的數量，以標示 pod 的運行負載情況。