Kubernetes + Kong API Gateway：用 API Key 打造計費金庫，只算成功的每一筆！

引言：API 經濟時代，計費不能馬虎！

哈囉，各位 API 界的探險家們！在這個數位轉型的浪潮中，API 已經不再只是工程師們的專屬玩具，它更是企業間串聯服務、創造新商業模式的「金鑰匙」。想像一下，您的 API 服務就像一座寶藏礦山，客戶們透過 API Key 這把鑰匙來挖掘寶藏。那麼問題來了，您怎麼知道他們挖了多少？又該怎麼跟他們收費呢？如果只是粗略地算個總數，那豈不是虧大了？

尤其當您需要根據客戶實際「成功」呼叫的次數來計費時，這就不是簡單的加減乘除了。如果客戶呼叫了 API，結果服務掛了、回應 500 錯誤，這筆帳還要算嗎？當然不行！我們追求的是「精準計費」，只為客戶真正獲得價值的服務買單。這就像去吃到飽餐廳，您只會為您真正吃下肚的食物付錢，而不是為那些您點了卻沒吃、甚至根本沒上桌的菜色買單，對吧？

今天，身為您的部落格顧問，我將帶您深入探討一個超酷的組合：Kubernetes (K8s) 搭配 Kong API Gateway，再加上我們「自發」的 API Key 管理機制，不僅能幫您把 API 服務顧得服服貼貼，還能精準記錄每一筆 API Key 的輸入輸出結果，最重要的是，我們只會把那些「HTTP 200 OK」的成功呼叫計入，讓您的計費機制滴水不漏，每一分錢都收得心安理得！準備好了嗎？讓我們一起打造您的 API 計費金庫吧！

K8s 與 Kong：天作之合的 API 守門員

首先，我們來聊聊這對黃金搭檔：Kubernetes 和 Kong。它們就像是 API 世界裡的「最佳拍檔」，一個負責管理您的應用程式大軍，另一個則負責把守大門，確保只有對的人才能進來。

Kubernetes (K8s)：您的應用程式特種部隊指揮官

如果您還不熟悉 K8s，那您可就錯過了一個超強大的工具！Kubernetes 是一個開源的容器編排平台，它能幫您自動化部署、擴展和管理容器化的應用程式。想像一下，您的應用程式不再是單打獨鬥的士兵，而是被 K8s 訓練成一支支精銳的特種部隊，無論面對多大的流量衝擊，都能自動擴編、協同作戰，確保服務不中斷。在 K8s 上運行您的 API 服務，就像是把它們放進了一個自動化的超級工廠，穩定、高效、可靠！

Kong API Gateway：API 世界的超級守門員

而 Kong 呢，它就是您 API 服務的「超級守門員」！它是一個輕量級、高性能的 API Gateway，可以運行在任何環境中，當然也包括我們的 K8s 叢集。Kong 的主要職責就是站在您的 API 服務前面，處理所有進來的請求。它能做的事情可多了，像是：

流量管理：把請求導向正確的後端服務，就像交通警察一樣。
安全防護：驗證請求的合法性，擋掉惡意攻擊，就像保全一樣。
負載平衡：把流量均勻分配給多個後端服務，避免單點過載，就像分流器一樣。
日誌記錄與監控：記錄每一筆請求的詳細資訊，讓您對 API 流量瞭若指掌，就像監視器一樣。

當 K8s 遇上 Kong，就像是特種部隊有了超級守門員的保護。您可以輕鬆地在 K8s 上部署 Kong，無論是透過 Helm Chart 這種「一鍵安裝包」，還是手動編寫 YAML 設定檔，都能讓 Kong 快速上線，成為您 API 服務最堅實的屏障。

API Key 驗證：誰能進門，誰不能！

有了 K8s 和 Kong 這對黃金搭檔，接下來就是我們的重頭戲：API Key 驗證！這就像是給您的客戶發放「專屬通行證」，只有持有有效通行證的人才能進入您的 API 服務大門。而 Kong 的 Key Authentication Plugin，就是這套通行證系統的核心。

Key Authentication Plugin：您的專屬通行證系統

Kong 的 Key Authentication Plugin 是一個非常實用且強大的功能。它允許您為每個客戶（在 Kong 中稱為 Consumer）生成一個獨特的 API Key。當客戶發送 API 請求時，他們必須在請求頭（Header）中帶上這個 API Key。Kong 會在收到請求後，第一時間檢查這個 Key 是否有效。如果 Key 無效，或者根本沒有帶 Key，那麼抱歉，您會直接收到一個「401 Unauthorized」的回應，請求根本不會被轉發到後端服務。這就像是門禁森嚴的俱樂部，沒有會員卡，連門都別想進！

如何建立 Consumer 和綁定 API Key

在 Kong 中管理 API Key 非常直觀。您可以使用 Kong 的 Admin API 來完成這些操作。想像一下，您就是這個俱樂部的老闆，正在為您的 VIP 客戶們發放會員卡：

建立 Consumer (客戶)：每個使用您 API 的客戶，在 Kong 中都會對應一個 Consumer 物件。您可以為他們指定一個唯一的名稱，例如 customer1、vip_user_a 等等。這就像是為您的客戶建立一個檔案。
```
curl -i -X POST http://<kong-admin-api>:8001/consumers/ \
  --data username=customer1
```
執行這條命令後，您會收到一個 201 Created 的回應，表示 customer1 這個客戶已經成功註冊了。
為 Consumer 綁定 API Key：接下來，就是為這個客戶發放專屬的 API Key 了。您可以選擇讓 Kong 自動生成一個複雜的 Key，也可以手動指定一個您想要的 Key。為了方便我們的計費需求，我們通常會選擇手動指定一個有意義的 Key，或者至少知道這個 Key 是屬於哪個客戶的。
```
curl -i -X POST http://<kong-admin-api>:8001/consumers/customer1/key-auth \
  --data key=your-custom-api-key-for-customer1
```
這裡的 your-custom-api-key-for-customer1 就是您為 customer1 指定的 API Key。客戶在發送請求時，只需要在請求頭中加入 x-api-key: your-custom-api-key-for-customer1 即可。是不是很簡單呢？
小提醒：雖然您可以手動指定 Key，但在實際生產環境中，為了安全性考量，強烈建議讓 Kong 自動生成複雜的 Key，並妥善保管。手動指定 Key 通常只用於測試或特殊整合情境。

API 請求流向與驗證機制

當客戶帶著他們的 API Key 發送請求時，整個流程是這樣的：

請求抵達 Kong Gateway：所有來自客戶的 API 請求，都會先經過 Kong 這個守門員。
Key Authentication Plugin 介入：Kong 會根據您配置的 Key Authentication Plugin，檢查請求頭中是否有有效的 API Key。
驗證 Key：
- 如果沒有 API Key，或者 Key 無效（例如，這個 Key 不存在，或者它所屬的 Consumer 被禁用了），Kong 會立即回傳 401 Unauthorized，並拒絕將請求轉發到後端服務。這就像是會員卡刷不過，直接被擋在門外。
- 如果 API Key 有效，Kong 會將請求轉發到後端服務。這就像是會員卡刷過了，您可以大搖大擺地走進俱樂部，享受服務。

這個流程確保了只有經過授權的客戶才能訪問您的 API 服務，大大提升了安全性。而且，由於驗證是在 Kong Gateway 層面完成的，您的後端服務就不需要再處理身份驗證的邏輯，可以專注於核心業務，是不是很棒呢？

API 流量監控：每一筆交易都看得到！

光是把守大門還不夠，我們還需要知道門內發生了什麼事！這就是 API 流量監控的重要性。想像一下，您是賭場老闆，不僅要確保賭客有籌碼才能進場，還要清楚知道每個賭客下了多少注、贏了多少、輸了多少，這樣才能精準地結算。在 API 世界裡，這些「下注」和「輸贏」就是每一次的 API 請求與回應。Kong 提供了多種方式來幫助我們記錄這些寶貴的資訊。

Kong 的日誌插件：您的 API 交易明細表

Kong 內建了多種日誌插件，可以將 API 請求的詳細資訊記錄下來。這些插件就像是您的「API 交易明細表」，每一筆請求的來龍去脈都清清楚楚：

File Log (檔案日誌)：最簡單直接的方式，將日誌寫入到本地檔案中。適合小型部署或開發測試。
HTTP Log (HTTP 日誌)：將日誌透過 HTTP 請求發送到另一個服務，例如日誌收集器（如 Logstash、Fluentd）或專門的日誌分析平台。這是生產環境中常用的方式，可以實現日誌的集中管理與分析。
Syslog (系統日誌)：將日誌發送到標準的 Syslog 服務。
TCP/UDP Log (TCP/UDP 日誌)：透過 TCP 或 UDP 協定發送日誌。

這些日誌插件可以記錄非常豐富的資訊，包括：

Consumer 資訊：哪個客戶（Consumer）發起的請求。
API Key：客戶使用的 API Key 是什麼。
請求資訊：請求的方法（GET/POST/PUT 等）、路徑、請求頭、請求體等。
回應資訊：回應的狀態碼（HTTP Status Code）、回應頭、回應體等。
時間戳：請求發生的時間。
延遲：請求處理的延遲時間。

有了這些詳細的日誌，您就可以對您的 API 流量進行全面的監控和分析。但光有日誌還不夠，我們需要更進階的工具來「挖掘」這些數據的價值。

第三方 API Analytics 工具：您的數據分析師

雖然 Kong 的日誌插件很棒，但它們主要負責「記錄」。如果我們要進行更深入的分析、生成報表、設定警示，甚至實現自動化計費，那麼就需要請出我們的「數據分析師」—— 第三方 API Analytics 工具了。這些工具就像是專業的會計師，能幫您把雜亂的交易明細整理得井井有條，並從中找出有價值的資訊。

常見的選擇包括：

Moesif：這是一個專為 API 分析和計費設計的平台。它能自動收集 API Key、Consumer、請求路徑、回應狀態等資訊，並提供強大的查詢、報表和警示功能。Moesif 與 Kong 有很好的整合，甚至有專門的 Kong Plugin 可以直接將日誌發送過去。對於需要精準計費的場景，Moesif 是一個非常值得考慮的選項。
ELK Stack (Elasticsearch, Logstash, Kibana)：這是一個開源的日誌管理和分析平台。您可以將 Kong 的日誌透過 Logstash 收集到 Elasticsearch 中，然後使用 Kibana 進行視覺化分析。ELK Stack 雖然功能強大，但需要一定的配置和維護成本，適合有自己日誌管理團隊的企業。
Prometheus + Grafana：這對組合主要用於監控指標（Metrics），例如 API 請求量、錯誤率、延遲等。雖然它們不直接記錄詳細的請求/回應內容，但可以提供 API 服務的整體健康狀況和性能趨勢。您可以透過 Kong 的 Prometheus Plugin 將指標暴露出來，然後用 Grafana 進行視覺化。

如何記錄 API Key 的輸入輸出結果

無論您選擇哪種日誌收集方式，關鍵在於確保日誌中包含了您計費所需的所有資訊，尤其是 API Key、Consumer 資訊以及請求的回應狀態碼。透過 Kong 的日誌插件，這些資訊通常都會被自動記錄下來。例如，在使用 HTTP Log Plugin 時，您可以配置它將請求和回應的完整內容（包括 Header 和 Body）都發送到您的日誌收集服務。這樣，您就能完整地掌握每一筆 API 交易的「輸入」和「輸出」了。

重點提示：在配置日誌時，請務必注意敏感資訊的處理。例如，如果您的 API 請求或回應中包含用戶的個人身份資訊（PII）或支付資訊，您可能需要對這些數據進行脫敏或加密，以符合法規要求並保護用戶隱私。

精準計費的藝術：只算成功的 200 OK！

好了，重頭戲來了！前面我們已經學會了如何驗證 API Key 和記錄所有 API 流量。但別忘了，我們的目標是「只統計 HTTP 200 成功呼叫」來計費。這就像是您開了一家咖啡店，只會對那些成功喝到咖啡的顧客收費，而不是對那些點了咖啡結果機器壞了、咖啡沒做出來的顧客收費，對吧？

為什麼 Kong 內建的計數插件不夠用？

您可能會問，Kong 不是有 Rate Limiting 或 Response Transformer 等插件嗎？它們可以計數啊！沒錯，但這些插件通常會將所有經過的請求都計入，無論後端服務回應的是 200 OK、404 Not Found 還是 500 Internal Server Error。這對於我們精準計費的需求來說，顯然是不夠的。我們需要一個更聰明的方法，只挑出那些「真正成功」的請求來計費。

為了解決這個問題，我們有兩種主要的方案：自訂 Kong Plugin 或 外部日誌分析。這兩種方案各有優缺點，您可以根據您的技術能力、資源投入和業務需求來選擇。

方案一：自訂 Kong Plugin (客製化計費邏輯)

如果您對 Lua 程式設計有一定了解，並且希望將計費邏輯直接嵌入到 Kong Gateway 中，那麼開發一個自訂的 Kong Plugin 是一個非常優雅的解決方案。Kong 提供了強大的 Plugin Development Kit (PDK)，讓您可以輕鬆地在請求處理的不同階段插入自己的邏輯。

我們的目標是在請求處理完成，並且 Kong 已經收到後端服務的回應後，再判斷回應狀態碼是否為 200。這個時機點，最適合在 Kong Plugin 的 log phase 進行。log phase 是在請求和回應都已經處理完畢，準備將日誌發送出去之前執行的。

以下是一個簡化的 Lua Plugin 範例，展示如何在 log phase 取得回應狀態碼並進行計數：

-- my-billing-plugin.lua

local BasePlugin = require "kong.plugins.base_plugin"
local ngx = ngx

local MyBillingPlugin = BasePlugin:extend("my-billing-plugin")

function MyBillingPlugin:new()
  MyBillingPlugin.super.new(self, "my-billing-plugin")
end

-- 在 log phase 執行
function MyBillingPlugin:log(conf)
  -- 取得回應狀態碼
  local status = kong.response.get_status()

  -- 取得 Consumer 資訊 (例如 username 或 custom_id)
  local consumer = kong.request.get_consumer()
  local consumer_id = consumer.id
  local consumer_username = consumer.username

  -- 取得 API Key (如果 Key Authentication Plugin 已經啟用)
  local api_key = kong.request.get_header("x-api-key") -- 假設 API Key 在 x-api-key 頭部

  -- 判斷是否為 200 OK
  if status == 200 then
    -- 在這裡進行計數、記錄、上報等動作
    -- 您可以將這些資訊發送到外部的計費系統、數據庫或日誌服務
    -- 例如，使用 kong.log 記錄到 Kong 的日誌中，或者使用 HTTP Client 發送到遠端服務
    kong.log.notice(string.format("API Success Call: Consumer=%s, Key=%s, Status=%d", 
                                  consumer_username or consumer_id, api_key or "N/A", status))
    
    -- 實際應用中，您可能會呼叫一個外部服務來增加計數
    -- 例如：
    -- local http = require "kong.tools.http"
    -- local res, err = http.post("http://your-billing-service.com/api/increment_count", {
    --   body = { consumer_id = consumer_id, api_key = api_key, status = status }
    -- })
    -- if err then
    --   kong.log.err("Failed to send billing data: ", err)
    -- end

  else
    kong.log.warn(string.format("API Failed Call: Consumer=%s, Key=%s, Status=%d", 
                                 consumer_username or consumer_id, api_key or "N/A", status))
  end
end

return MyBillingPlugin

如何部署自訂 Plugin？

將 Plugin 檔案放入 Kong 容器：將您的 Lua Plugin 檔案（例如 my-billing-plugin.lua）放入 Kong 容器的指定目錄中，通常是 /usr/local/share/lua/5.1/kong/plugins/my-billing-plugin/。
更新 Kong 配置：在 Kong 的配置中啟用您的自訂 Plugin。這通常涉及到修改 kong.conf 或透過環境變數 KONG_PLUGINS 來添加您的 Plugin 名稱。

啟用 Plugin：透過 Kong Admin API 為您的 Service 或 Route 啟用這個自訂 Plugin。

curl -X POST http://<kong-admin-api>:8001/services/<your-service-name>/plugins \
  --data name=my-billing-plugin

自訂 Plugin 的優點：

即時性：計數邏輯直接在 Gateway 層面執行，反應速度快。
精準控制：您可以完全控制計數的邏輯，實現非常客製化的計費規則。
減少外部依賴：計數邏輯內建於 Kong，減少了對外部日誌分析系統的依賴。

自訂 Plugin 的缺點：

開發成本：需要具備 Lua 程式設計能力，並熟悉 Kong Plugin 開發框架。
維護成本：Plugin 的部署、升級和維護需要額外的工作。
可擴展性：如果計費邏輯非常複雜，或者需要與多個外部系統整合，Plugin 可能會變得臃腫。

方案二：外部日誌分析 (後處理計費數據)

如果您不希望在 Kong Gateway 中引入太多客製化邏輯，或者您已經有成熟的日誌管理和分析平台，那麼將所有日誌發送到外部系統，然後在外部系統中進行過濾和統計，是一個更靈活的方案。這就像是把所有的交易記錄都交給專業的會計師事務所，讓他們幫您從海量的數據中篩選出有用的資訊。

流程概覽：

將所有日誌發送到外部系統：使用 Kong 的 HTTP Log Plugin 或其他日誌插件，將所有 API 請求和回應的詳細日誌發送到您的日誌收集服務（例如 Logstash、Fluentd）或直接發送到分析平台（例如 Moesif）。
在外部系統中過濾和統計：一旦日誌數據進入了您的分析平台，您就可以利用其強大的查詢和分析功能，輕鬆地過濾出那些回應狀態碼為 200 的請求，並根據 API Key 或 Consumer 進行彙總計次。
- 以 ELK Stack 為例：在 Kibana 中，您可以建立一個查詢，例如：http.response.status_code: 200，然後再使用聚合（Aggregation）功能，按 api_key 或 consumer.username 進行分組計數。您可以設定時間範圍，例如每天、每週或每月，來生成計費所需的數據。
- 以 Moesif 為例： Moesif 提供了直觀的 UI 介面，您可以輕鬆地建立自訂報表，篩選出 Response Status Code = 200 的事件，然後按 API Key 或 User ID 進行分組統計。Moesif 還可以直接與您的計費系統（如 Stripe）整合，實現自動化計費。

外部日誌分析的優點：

靈活性高：計費邏輯與 Gateway 解耦，您可以隨時調整計費規則，而無需修改 Kong 的配置或部署新的 Plugin。
可視化強大：日誌分析平台通常提供豐富的可視化功能，讓您可以直觀地看到 API 流量趨勢和計費數據。
易於整合：可以輕鬆與現有的日誌管理、監控和 BI 系統整合。
降低 Gateway 負擔：計數和分析的計算量轉移到外部系統，減輕了 Kong Gateway 的負擔。

外部日誌分析的缺點：

延遲性：數據從 Kong 發送到外部系統，再到分析完成，會有一定的延遲。對於需要極高即時性的計費場景可能不適用（但對於大多數計費場景來說，這種延遲是可以接受的）。
基礎設施成本：需要額外部署和維護日誌收集和分析平台（例如 ELK Stack），增加了基礎設施成本。
數據量大：如果 API 流量非常大，日誌數據量會非常龐大，需要考慮存儲和處理能力。

兩種方案的比較

為了讓您更清楚地選擇適合自己的方案，我們來做個簡單的比較：

特性	自訂 Kong Plugin	外部日誌分析
計費邏輯位置	Kong Gateway 內部	外部日誌分析平台（如 Moesif, ELK）
即時性	高	中（有數據傳輸和處理延遲）
開發難度	中（需 Lua 程式設計）	低（主要為配置和查詢）
維護成本	中（Plugin 部署與升級）	中（外部平台部署與維護）
靈活性	中（修改邏輯需更新 Plugin）	高（可隨時調整查詢條件）
可視化	需自行整合或輸出到外部系統	強大（平台內建豐富圖表）
擴展性	較低（複雜邏輯可能影響 Gateway 性能）	高（可獨立擴展分析平台）
適用場景	對即時性要求高、計費邏輯相對簡單的場景	對靈活性要求高、數據量大、已有日誌平台的場景

計費流程建議：讓錢包鼓起來！

無論您選擇哪種方案來統計 HTTP 200 的成功呼叫，最終的目標都是為了實現精準的計費。有了這些數據，您的計費流程就可以變得非常清晰和自動化。想像一下，您的錢包將會因為這些精準的計費而鼓起來！

依據 API Key（Consumer）與 HTTP 200 計數

這是我們計費的核心依據。您將會得到每個 API Key（或其對應的 Consumer）在特定時間段內（例如每日、每月）成功呼叫（HTTP 200）的總次數。這就像是您統計每個客戶在您的咖啡店裡成功喝了多少杯咖啡。

定期匯出計費報表

根據您的業務需求，您可以設定定期（例如每月初）從您的數據分析平台匯出計費報表。這份報表將包含每個客戶的 API Key、成功呼叫次數以及對應的費用。這份報表將是您與客戶結算的重要依據。

自動化統計與報表產出

如果您的 API 服務規模較大，手動匯出報表會非常耗時耗力。這時候，自動化就顯得尤為重要了！

利用外部分析平台：像 Moesif 這樣的平台，通常都提供自動化報表生成和發送的功能。您可以設定每個月自動生成一份計費報表，並發送到您的郵箱或直接推送到您的 CRM 系統。
自訂腳本：如果您使用 ELK Stack 或其他數據庫來存儲日誌，您可以編寫自訂腳本（例如 Python 腳本），定期執行查詢、生成報表，並將報表發送到指定的地方。您可以將這些腳本部署在 K8s 叢集中的 CronJob，實現定時自動執行。
與計費系統整合：最高級的自動化是將您的 API 分析平台直接與您的計費系統（例如 Stripe、PayPal）整合。當客戶的成功呼叫次數達到一定閾值時，系統可以自動觸發計費，甚至自動生成發票。這將大大減少您的人工操作，提高效率。

計費流程示意圖

為了讓您更直觀地理解整個計費流程，我為您準備了一個 Mermaid Diagram。這就像是計費流程的「藏寶圖」，每一步都清晰可見！

graph TD A[客戶發送 API 請求] --> B(Kong API Gateway) B --> C{API Key 驗證} C -->|驗證失敗| D[401 Unauthorized 回應] C -->|驗證成功| E(請求轉發至後端服務) E --> F(後端服務處理請求) F --> G(後端服務回應給 Kong) G --> H{判斷回應狀態碼} H -->|HTTP 200 OK| I[成功呼叫計數] H -->|非 200 OK| J[非成功呼叫，不計數] I --> K(日誌記錄與數據分析平台) J --> K K --> L[數據過濾與彙總
只統計 200 OK] L --> M[生成計費報表] M --> N[與客戶結算] N --> O[計費完成] %% 樣式設定 classDef success fill:#d4edda,stroke:#155724,stroke-width:2px classDef error fill:#f8d7da,stroke:#721c24,stroke-width:2px classDef process fill:#e2e3e5,stroke:#383d41,stroke-width:2px classDef billing fill:#fff3cd,stroke:#856404,stroke-width:2px class I,L,M,N,O success class D,J error class B,E,F,G,K process class A,C,H billing

這張圖清晰地展示了從客戶發送請求到最終計費完成的整個流程。您可以看到，無論請求成功與否，都會被記錄下來，但只有那些真正成功的 HTTP 200 呼叫才會被計入最終的計費。

總結：API 服務的價值，由您定義！

恭喜您！我們一起走過了這趟 API 計費的探險之旅。從 Kubernetes 上的 Kong API Gateway 部署，到 API Key 的嚴格驗證，再到如何精準記錄每一筆 API 交易，並最終實現只統計 HTTP 200 成功呼叫的計費機制，您現在已經掌握了打造 API 計費金庫的關鍵秘訣。

在這個 API 經濟蓬勃發展的時代，您的 API 服務就是您的核心資產。而精準的計費，不僅能確保您的收入與服務價值相符，更能讓您對業務數據瞭若指掌，為未來的決策提供有力支持。無論您選擇自訂 Kong Plugin 還是依賴強大的外部日誌分析平台，核心理念都是一致的：只為客戶真正獲得價值的服務買單。

希望這篇文章能為您帶來啟發，讓您在 API 管理和計費的道路上走得更穩、更遠。記住，您的 API 服務的價值，最終將由您精準的計費策略來定義！現在，就動手打造您的專屬 API 計費系統吧！如果您在實作過程中遇到任何問題，別忘了，我永遠是您最可靠的部落格顧問！

在 Kubernetes 上部署 Kong API Gateway：實戰教學

要在 Kubernetes 叢集上運行 Kong API Gateway，最推薦的方式是使用 Kong Ingress Controller。它將 Kong Gateway 與 Kubernetes 的 Ingress 資源緊密整合，讓您可以透過 Kubernetes 原生的方式來管理 API 流量和 Kong 的配置。想像一下，您的 K8s 叢集就像一個大型的應用程式樂園，而 Kong Ingress Controller 就是這個樂園的「總導覽員」，負責引導外部的遊客（API 請求）找到他們想玩的設施（後端服務）。

為什麼選擇 Kong Ingress Controller？

傳統上，您可以在 K8s 叢集內部獨立部署 Kong Gateway，然後再透過 LoadBalancer Service 或 NodePort 將其暴露給外部。這種方式雖然可行，但管理起來相對複雜，您需要同時維護 Kong 的配置和 K8s 的服務配置。而 Kong Ingress Controller 的優勢在於：

Kubernetes 原生整合：您可以直接使用 Kubernetes 的 Ingress、Service、Secret 等資源來配置 Kong，無需學習額外的 Kong 配置工具（Admin API 除外，用於更進階的配置）。
簡化部署與管理：透過 Helm Chart 或 YAML 檔案，可以輕鬆地將 Kong Ingress Controller 部署到 K8s 叢集。
利用 CRDs 擴展功能：Kong Ingress Controller 引入了許多 Custom Resource Definitions (CRDs)，例如 KongPlugin、KongConsumer、KongCredential 等，讓您可以透過 K8s 的方式來管理 Kong 的各種插件和配置，包括我們的 API Key 驗證和日誌記錄。
自動化配置：當您在 K8s 中創建、更新或刪除 Ingress、Service 或 Kong 的 CRDs 時，Kong Ingress Controller 會自動感知這些變化，並更新 Kong Gateway 的配置，實現自動化管理。

部署 Kong Ingress Controller (使用 Helm)

使用 Helm 是在 Kubernetes 上部署 Kong Ingress Controller 最簡單快捷的方式。Helm 就像是 K8s 的「應用程式商店」，您可以透過 Helm Chart 輕鬆地安裝、升級和管理各種應用程式，包括 Kong Ingress Controller。

步驟一：安裝 Helm

如果您的環境中還沒有安裝 Helm，請先按照官方文件進行安裝 [10]。

步驟二：添加 Kong 的 Helm Repository

首先，將 Kong 的官方 Helm Repository 添加到您的 Helm 中：

helm repo add kong https://charts.konghq.com
helm repo update

步驟三：創建一個 Namespace (可選)

建議為 Kong Ingress Controller 創建一個專門的 Namespace，以便於管理：

kubectl create namespace kong

步驟四：安裝 Kong Ingress Controller

現在，您可以使用 Helm 安裝 Kong Ingress Controller 了。這裡我們使用一個基本的安裝範例，您可以根據您的需求進行調整：

helm install kong kong/kong -n kong \
  --set ingressController.enabled=true \
  --set ingressController.createGatewayClasses=true \
  --set ingressController.createIngressClass=true

這條命令會在 kong Namespace 中安裝 Kong Ingress Controller。--set ingressController.enabled=true 啟用了 Ingress Controller 功能，--set ingressController.createGatewayClasses=true 和 --set ingressController.createIngressClass=true 則會創建必要的 GatewayClass 和 IngressClass 資源，讓您可以透過標準的 Ingress 或 Gateway API 來配置 Kong。

資料庫選擇：

Kong Ingress Controller 預設會使用一個後端的數據庫來存儲配置資訊，通常是 PostgreSQL 或 Cassandra。在生產環境中，您需要部署一個高可用的數據庫實例，並在安裝 Kong Ingress Controller 時配置連接資訊。如果您只是想快速測試，也可以使用無數據庫模式 (DB-less mode)，但這種模式功能會受到限制，不建議用於生產環境 [10]。

暴露 Kong Gateway：

安裝完成後，Kong Gateway 會作為一個 Service 運行在您的 K8s 叢集中。您需要根據您的環境選擇合適的方式將其暴露給外部流量：

LoadBalancer Service：如果您的 K8s 叢集運行在雲平台上（如 GKE, EKS, AKS），並且支援 LoadBalancer Service，那麼 Helm Chart 會自動創建一個 LoadBalancer Service，並分配一個外部 IP 地址。這是最常見和推薦的方式。
NodePort Service：如果您的環境不支援 LoadBalancer Service，可以使用 NodePort Service 將 Kong 暴露在每個 Worker Node 的特定端口上。這種方式需要在防火牆中打開對應的端口。
HostPort 或 HostNetwork：在某些情況下，您也可以直接將 Kong Pod 的端口映射到 Worker Node 的端口上，或者讓 Kong Pod 使用 Host Network。但這些方式會增加 Pod 與 Node 之間的耦合度，應謹慎使用。

您可以透過 kubectl get services -n kong 命令來查看 Kong Service 的狀態，獲取外部訪問地址。

部署 Kong Ingress Controller (使用 YAML)

如果您不使用 Helm，也可以手動編寫 YAML 檔案來部署 Kong Ingress Controller。這種方式更靈活，但需要您對 K8s 的資源有更深入的了解。

步驟一：下載部署檔案

您可以從 Kong 的 GitHub Repository 下載官方提供的部署 YAML 檔案 [6]：

git clone https://github.com/Kong/kubernetes-ingress-controller.git
cd kubernetes-ingress-controller
kubectl apply -f deploy/single/all-in-one-postgres.yaml

這個 YAML 檔案包含了一個使用 PostgreSQL 作為後端數據庫的單節點部署範例。您可以根據您的需求修改這個檔案，例如更改數據庫配置、副本數量、資源限制等等。

步驟二：暴露 Kong Gateway

與使用 Helm 類似，您需要手動創建一個 Service 來暴露 Kong Gateway。以下是一個 LoadBalancer Service 的 YAML 範例：

apiVersion: v1
kind: Service
metadata:
  name: kong-proxy
  namespace: kong
spec:
  selector:
    app: ingress-kong
  type: LoadBalancer
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8000
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443

將上述內容保存為 kong-proxy-service.yaml，然後使用 kubectl apply -f kong-proxy-service.yaml -n kong 命令來創建 Service。

驗證部署

無論您使用 Helm 還是 YAML 進行部署，都可以透過以下命令來驗證 Kong Ingress Controller 是否成功運行：

kubectl get pods -n kong
kubectl get services -n kong
kubectl get ingressclasses
kubectl get gatewayclasses

您應該會看到 Kong 的 Pod 正在運行，並且 Kong Service 已經創建，並且有對應的外部訪問地址（如果是 LoadBalancer）。

API Key 管理：為您的客戶發放通行證

部署好 Kong Ingress Controller 後，接下來就是為您的 API 服務配置 API Key 驗證了。透過 Kong Ingress Controller 提供的 CRDs，您可以在 Kubernetes 中以聲明式的方式管理 Kong 的 Consumer 和 Credential (API Key)。這就像是在 K8s 的「客戶名單」上登記您的客戶，並為他們分配「通行證」。

使用 KongConsumer 和 KongCredential CRDs

Kong Ingress Controller 引入了 KongConsumer 和 KongCredential 這兩個 CRDs，讓您可以在 K8s 中創建和管理 Kong 的 Consumer 和 API Key。這比直接呼叫 Kong Admin API 更加方便，也更符合 Kubernetes 的操作習慣。

步驟一：創建 KongConsumer

首先，為您的客戶創建一個 KongConsumer 資源。例如，為客戶 customer1 創建一個 Consumer：

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: customer1
  namespace: default # 或者您的應用程式所在的 Namespace
  annotations:
    kubernetes.io/ingress.class: kong # 指定使用哪個 Ingress Class
spec:
  username: customer1

將上述內容保存為 customer1-consumer.yaml，然後使用 kubectl apply -f customer1-consumer.yaml 命令來創建。

步驟二：創建 KongCredential (API Key)

接下來，為 customer1 這個 Consumer 創建一個 KongCredential 資源，並指定 API Key。您可以選擇讓 Kong 自動生成 Key，或者手動指定一個：

apiVersion: configuration.konghq.com/v1
kind: KongCredential
metadata:
  name: customer1-key
  namespace: default # 與 KongConsumer 相同的 Namespace
  annotations:
    kubernetes.io/ingress.class: kong # 指定使用哪個 Ingress Class
spec:
  consumerRef:
    name: customer1
  plugin: key-auth
  config:
    key: your-custom-api-key-for-customer1 # 或者不指定讓 Kong 自動生成

將上述內容保存為 customer1-key.yaml，然後使用 kubectl apply -f customer1-key.yaml 命令來創建。

創建完成後，Kong Ingress Controller 會自動在後端的 Kong Gateway 中創建對應的 Consumer 和 API Key。您可以使用 Kong Admin API 來驗證是否創建成功。

將 API Key 驗證應用到特定的 Service 或 Route

創建了 Consumer 和 API Key 後，您需要告訴 Kong Ingress Controller，哪些 API 服務需要進行 API Key 驗證。這可以透過在 Ingress 或 Service 上添加 Annotation 來實現。

方法一：在 Ingress 上添加 Annotation

如果您使用 Ingress 資源來定義 API 路由，可以在 Ingress 的 Annotation 中啟用 key-auth 插件：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-api-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/plugins: key-auth # 啟用 key-auth 插件
spec:
  rules:
  - http:
      paths:
      - path: /my-api
        pathType: Prefix
        backend:
          service:
            name: my-api-service
            port:
              number: 80

方法二：在 Service 上添加 Annotation

如果您直接在 Service 上配置 Kong 插件（透過 Kong Ingress Controller 的 Service Annotation 功能），可以在 Service 的 Annotation 中啟用 key-auth 插件：

apiVersion: v1
kind: Service
metadata:
  name: my-api-service
  namespace: default
  annotations:
    konghq.com/plugins: key-auth # 啟用 key-auth 插件
spec:
  selector:
    app: my-api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

無論您選擇在哪裡添加 Annotation，效果都是一樣的：所有發往 /my-api 路徑（或 my-api-service）的請求，都必須帶有有效的 API Key 才能通過。

測試 API Key 驗證

配置完成後，您可以使用 curl 命令來測試 API Key 驗證是否生效。假設您的 Kong Gateway 外部訪問地址是 kong.example.com：

發送不帶 API Key 的請求：

curl -i http://kong.example.com/my-api

您應該會收到 401 Unauthorized 的回應，類似這樣：

HTTP/1.1 401 Unauthorized
...
{
    "message": "No API key found in request"
}

發送帶有有效 API Key 的請求：

curl -i -H 'apikey: your-custom-api-key-for-customer1' http://kong.example.com/my-api

您應該會收到後端服務的回應（如果後端服務正常運行），例如 200 OK。這表示 API Key 驗證已經成功生效了！

小提醒：apikey 是 Key Authentication Plugin 預設會查找的請求頭名稱，您可以在插件配置中修改這個名稱。

記錄 API 流量：捕捉每一個輸入與輸出

為了實現精準計費，我們需要記錄每一筆 API 請求的詳細資訊，包括請求的輸入（請求頭、請求體）和回應的輸出（回應頭、回應體、狀態碼）。Kong 提供了豐富的日誌插件，可以幫助我們輕鬆地完成這項任務。想像一下，這些日誌插件就像是 API 世界裡的「黑盒子」，記錄下每一次飛行的詳細數據。

Kong 的日誌插件：選擇適合您的記錄方式

Kong 支援多種日誌插件，您可以根據您的需求和現有的基礎設施選擇最合適的插件。以下是一些常用的日誌插件：

HTTP Log Plugin：將請求和回應的詳細資訊以 HTTP 請求的方式發送到指定的 URL。這是將日誌發送到外部日誌收集系統（如 Logstash、Fluentd）或分析平台（如 Moesif）的常用方式。
TCP/UDP Log Plugin：透過 TCP 或 UDP 協定將日誌發送到指定的地址和端口。適合將日誌發送到 Syslog 服務或自訂的日誌處理服務。
File Log Plugin：將日誌寫入到 Kong 容器內部的檔案中。適合開發測試或小型部署，但在生產環境中需要考慮日誌輪替和集中收集的問題。
Kafka Log Plugin：將日誌發送到 Kafka 消息隊列。適合需要高吞吐量和可擴展性的日誌處理場景。
Splunk Log Plugin：將日誌直接發送到 Splunk 平台。

配置 HTTP Log Plugin 記錄詳細資訊

為了記錄完整的輸入輸出結果，HTTP Log Plugin 是一個非常好的選擇。它可以配置發送請求和回應的完整 Header 和 Body。以下是如何在 Ingress 上配置 HTTP Log Plugin 的範例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-api-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/plugins: key-auth,http-log # 啟用 key-auth 和 http-log 插件
spec:
  rules:
  - http:
      paths:
      - path: /my-api
        pathType: Prefix
        backend:
          service:
            name: my-api-service
            port:
              number: 80

然後，您需要創建一個 KongPlugin 資源來配置 http-log 插件的詳細參數，例如日誌發送的 URL：

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: http-log-config
  namespace: default
  annotations:
    kubernetes.io/ingress.class: kong
spec:
  plugin: http-log
  config:
    http_endpoint: http://your-log-collection-service.com/log
    method: POST
    headers:
      Content-Type: application/json
    custom_fields:
      request: true # 記錄完整的請求資訊
      response: true # 記錄完整的響應資訊

將上述內容保存為 http-log-plugin.yaml，然後使用 kubectl apply -f http-log-plugin.yaml 命令來創建。這個配置會將所有經過這個 Ingress 的請求和回應的詳細資訊，以 JSON 格式發送到 http://your-log-collection-service.com/log 這個地址。

小提醒：http://your-log-collection-service.com/log 應該是您的日誌收集服務的入口地址。您需要確保這個服務能夠接收並處理 Kong 發送過來的日誌數據。

日誌內容的關鍵資訊

在配置日誌插件時，確保日誌中包含了以下關鍵資訊，這些資訊對於後續的計費和分析非常重要：

consumer.id 或 consumer.username：識別是哪個客戶發起的請求。
request.headers['x-api-key']：客戶使用的 API Key（如果使用了 x-api-key 作為 Key 名稱）。
response.status：後端服務回應的 HTTP 狀態碼。
request.uri 或 request.url：客戶請求的 API 路徑。
started_at：請求開始處理的時間戳。

HTTP Log Plugin 的 custom_fields 配置可以讓您精確控制要記錄哪些字段。通過設置 request: true 和 response: true，您可以記錄幾乎所有的請求和回應細節，包括 Header 和 Body。但請注意，記錄完整的請求和回應體可能會產生大量的日誌數據，需要考慮存儲和處理能力。

只統計 HTTP 200 成功呼叫：實現精準計費

現在我們已經能夠在 K8s 上部署 Kong，使用 API Key 驗證客戶身份，並記錄下每一筆 API 請求的詳細日誌。接下來，就是如何從這些日誌中「篩選」出那些 HTTP 200 的成功呼叫，並進行計數，以便用於計費。這就像是從一堆沙子中淘出金子，只計算那些真正有價值的「成功」交易。

前面我們提到了兩種主要的方案：自訂 Kong Plugin 和外部日誌分析。這裡我們將更詳細地探討這兩種方案的實作細節。

方案一：自訂 Kong Plugin (進階實作)

如果您選擇自訂 Kong Plugin 來實現 HTTP 200 計數，您需要在 Lua Plugin 中編寫邏輯，在 log phase 獲取回應狀態碼，並在狀態碼為 200 時觸發計數操作。這個計數操作可以有很多種實現方式：

實作方式一：將計數事件發送到外部計費服務

這是最靈活的方式，您可以編寫一個獨立的微服務作為「計費服務」，負責接收來自 Kong Plugin 的成功呼叫事件，並進行計數和存儲。計費服務可以使用數據庫（如 PostgreSQL, MongoDB）來存儲每個客戶的計數數據。

在您的 Lua Plugin 中，您可以使用 Kong PDK 提供的 kong.tools.http 模塊來發送 HTTP 請求到您的計費服務：

-- 在 MyBillingPlugin:log(conf) 函數中

local status = kong.response.get_status()

if status == 200 then
  local consumer = kong.request.get_consumer()
  local consumer_id = consumer.id
  local api_key = kong.request.get_header("x-api-key")

  local http = require "kong.tools.http"
  local res, err = http.post("http://your-billing-service.com/api/increment_count", {
    body = { 
      consumer_id = consumer_id,
      api_key = api_key,
      timestamp = ngx.now() -- 記錄時間戳
    },
    headers = { 
      ["Content-Type"] = "application/json"
    }
  })

  if err then
    kong.log.err("Failed to send billing data to billing service: ", err)
  else
    -- 檢查計費服務的回應，確保數據成功接收
    if res.status ~= 200 then
      kong.log.err("Billing service returned non-200 status: ", res.status)
    end
  end
end

您的計費服務 (http://your-billing-service.com) 需要提供一個 /api/increment_count 的接口，接收包含 consumer_id、api_key 和 timestamp 的 JSON 數據，並將對應客戶的成功呼叫計數加一。

實作方式二：將計數事件記錄到 Kong 的日誌中，再由日誌收集器處理

如果您不想額外部署一個計費服務，也可以將成功呼叫事件記錄到 Kong 的日誌中，然後再由後端的日誌收集器（如 Logstash）進行處理和計數。這種方式相對簡單，但需要在日誌收集器中編寫處理邏輯。

在您的 Lua Plugin 中，您可以使用 kong.log.notice 或 kong.log.info 將成功呼叫的資訊以特定格式記錄下來：

-- 在 MyBillingPlugin:log(conf) 函數中

local status = kong.response.get_status()

if status == 200 then
  local consumer = kong.request.get_consumer()
  local consumer_id = consumer.id
  local api_key = kong.request.get_header("x-api-key")

  -- 以特定格式記錄成功呼叫事件，方便後續解析
  kong.log.notice(string.format("BILLING_SUCCESS: consumer_id=%s, api_key=%s, timestamp=%d", 
                                consumer_id, api_key or "N/A", ngx.now()))
end

然後，在您的日誌收集器（例如 Logstash）中，您可以配置一個 Grok Filter 來解析這些特定格式的日誌行，提取出 consumer_id、api_key 和 timestamp 等字段，再將這些事件發送到 Elasticsearch 或其他數據庫進行存儲和計數。

部署自訂 Plugin 到 K8s：

將自訂 Lua Plugin 部署到 K8s 中的 Kong Ingress Controller 需要一些額外的步驟：

創建 ConfigMap：將您的 Lua Plugin 檔案內容存儲在一個 ConfigMap 中：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-billing-plugin
  namespace: kong # Kong Ingress Controller 所在的 Namespace
data:
  my-billing-plugin.lua: |
    -- my-billing-plugin.lua 的內容
    local BasePlugin = require "kong.plugins.base_plugin"
    local ngx = ngx
    ...

修改 Kong Ingress Controller 部署：修改 Kong Ingress Controller 的 Deployment 或 StatefulSet 配置，將 ConfigMap 作為 Volume 掛載到 Kong 容器中，並更新 KONG_PLUGINS 環境變數，將您的自訂 Plugin 名稱添加到列表中。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-kong
  namespace: kong
spec:
  template:
    spec:
      containers:
      - name: ingress-controller
        env:
        - name: KONG_PLUGINS
          value: bundled,my-billing-plugin # 添加您的自訂 Plugin 名稱
        volumeMounts:
        - name: my-billing-plugin-volume
          mountPath: /usr/local/share/lua/5.1/kong/plugins/my-billing-plugin # 掛載到 Kong Plugin 目錄
      volumes:
      - name: my-billing-plugin-volume
        configMap:
          name: my-billing-plugin

重啟 Kong Pods：應用修改後的 Deployment 配置，K8s 會自動重啟 Kong Pods，載入新的 Plugin。

創建 KongPlugin 資源：最後，創建一個 KongPlugin 資源來啟用您的自訂 Plugin，並將其應用到特定的 Service 或 Route 上，就像前面配置 HTTP Log Plugin 那樣。

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-billing-plugin-config
  namespace: default
  annotations:
    kubernetes.io/ingress.class: kong
spec:
  plugin: my-billing-plugin
  # 如果您的 Plugin 需要配置參數，可以在這裡添加 config 字段
  # config:
  #   some_parameter: some_value

將這個 KongPlugin 資源應用到您的 Ingress 或 Service 上，您的自訂計費 Plugin 就會開始工作了。

方案二：外部日誌分析 (詳細步驟)

如果您選擇外部日誌分析方案，核心思想是將所有日誌發送到一個集中的日誌平台，然後利用平台的查詢和分析能力來統計 HTTP 200 的成功呼叫。這就像是把所有的交易記錄都匯總到一個大型數據庫，然後用 SQL 語句來查詢和統計。

步驟一：配置 Kong 的日誌插件

使用 HTTP Log Plugin 或其他適合您日誌平台的插件，將日誌發送到外部系統。確保日誌中包含了 consumer.id (或 username) 和 response.status 這兩個關鍵字段。前面我們已經提供了 HTTP Log Plugin 的配置範例，您可以參考使用。

步驟二：部署和配置日誌收集與分析平台

選擇一個適合您的日誌平台，並將其部署在 K8s 叢集內部或外部。這裡我們以 ELK Stack (Elasticsearch, Logstash, Kibana) 為例，這是一個非常流行的開源日誌平台。

部署 Elasticsearch：用於存儲日誌數據。您可以在 K8s 上部署 Elasticsearch 集群，或者使用雲服務商提供的 Elasticsearch 服務。
部署 Logstash：用於收集、解析和轉換來自 Kong 的日誌數據。Logstash 可以配置一個 HTTP Input 插件來接收 Kong 發送過來的日誌，然後使用 Filter 插件（如 JSON Filter, Grok Filter）來解析日誌內容，提取出關鍵字段。
部署 Kibana：用於日誌數據的可視化和分析。您可以透過 Kibana 的 UI 介面來查詢、過濾和聚合 Elasticsearch 中的日誌數據。

在 Logstash 的配置中，您需要定義一個 Input 來接收來自 Kong 的 HTTP 請求，並定義 Filter 來解析日誌內容。以下是一個簡化的 Logstash 配置範例：

input {
  http {
    port => 8080 # Logstash 接收 Kong 日誌的端口
    codec => json # Kong HTTP Log Plugin 預設發送 JSON 格式的日誌
  }
}

filter {
  # 如果需要，可以在這裡添加 Grok 或其他 Filter 來解析日誌內容
  # 例如，從日誌中提取 consumer_id 和 status
  # grok {
  #   match => { "message" => "..." }
  # }
}

output {
  elasticsearch {
    hosts => ["http://your-elasticsearch-host:9200"]
    index => "kong-logs-%{+YYYY.MM.dd}" # 將日誌寫入到 Elasticsearch，按日期分索引
  }
}

將上述配置應用到 Logstash 後，它就會開始接收來自 Kong 的日誌，並將其發送到 Elasticsearch。您需要在 K8s 中部署 Logstash，並確保 Kong 能夠訪問到 Logstash 的 HTTP Input 端口。

步驟三：在 Kibana 中進行數據分析和計數

一旦日誌數據進入了 Elasticsearch，您就可以使用 Kibana 來進行分析和計數了。在 Kibana 的 Discover 頁面，您可以先確認日誌數據是否成功導入。然後，您可以切換到 Visualize 頁面，創建一個新的可視化圖表來統計成功呼叫次數。

選擇圖表類型：選擇一個適合計數的圖表類型，例如 Vertical Bar Chart 或 Data Table。
選擇索引模式：選擇您存儲 Kong 日誌的索引模式（例如 kong-logs-*）。
配置 Metric：添加一個 Metric，選擇 Aggregation 為 Count，這會計算符合條件的文檔數量。
配置 Buckets (分組)：添加一個 Buckets，選擇 Aggregation 為 Terms，Field 選擇 consumer.username.keyword (或 consumer.id.keyword)，這會按客戶進行分組。您還可以添加另一個 Buckets，選擇 Aggregation 為 Date Histogram，Field 選擇 started_at，按時間進行分組（例如每天、每月）。
配置 Filter (過濾)：添加一個 Filter，條件設置為 response.status: 200，這會只統計回應狀態碼為 200 的日誌。您還可以添加其他過濾條件，例如按時間範圍過濾。

配置完成後，Kibana 就會生成一個圖表或表格，顯示每個客戶在指定時間範圍內成功呼叫的次數。您可以將這個可視化保存下來，並添加到 Dashboard 中，方便隨時查看。

使用 Moesif 進行 API 分析和計費：

如果您選擇使用專門的 API 分析平台如 Moesif，流程會更簡單。Moesif 提供了 Kong Plugin，您可以直接將其部署到 Kong 中，並配置您的 Moesif Application Id。Plugin 會自動收集 API 流量數據並發送到 Moesif 平台 [3][6][11]。

在 Moesif 平台中，您可以利用其內建的分析功能，輕鬆地篩選出 HTTP 200 的事件，並按 API Key 或 User ID 進行分組計數。Moesif 還提供了計費功能，可以直接與 Stripe 等支付平台整合，實現自動化計費。

計費流程自動化：讓錢自動流進來！

有了精準的成功呼叫數據，接下來就是如何將這些數據轉化為實際的收入了。自動化計費流程可以大大提高效率，減少人工錯誤。想像一下，您的計費系統就像一個自動印鈔機，根據您的 API 使用數據自動生成賬單。

定期生成計費報表

無論您使用自訂 Plugin + 計費服務，還是外部日誌分析平台，您都需要定期（例如每月）生成一份計費報表，其中包含每個客戶的成功呼叫次數和應付金額。這份報表可以透過以下方式生成：

計費服務生成報表：如果您開發了自訂計費服務，可以在服務中實現報表生成功能，並提供 API 接口或定時任務來匯出報表。
日誌分析平台報表功能：ELK Stack (透過 Kibana Reporting) 或 Moesif 都提供了報表生成功能，您可以設定定時任務自動生成報表並發送到指定的地方。
自訂腳本生成報表：如果您將數據存儲在數據庫中，可以編寫腳本（如 Python 腳本）定期查詢數據庫，生成報表（例如 CSV 或 PDF 格式），並透過郵件或其他方式發送給客戶或內部團隊。

與計費系統整合

最高級的自動化是將您的計費數據直接推送到專門的計費系統（如 Stripe, Chargebee, Zuora）。這些系統提供了豐富的計費模型（按次數、按用量、訂閱制等）和支付處理功能。您可以透過以下方式進行整合：

API 整合：您的計費服務或自訂腳本可以呼叫計費系統提供的 API，將客戶的成功呼叫次數上報，由計費系統自動計算費用並生成賬單。
Webhook 整合：計費系統通常支援 Webhook，當有新的計費事件發生時（例如生成賬單、支付成功），可以觸發您的系統進行相應的處理。
Moesif 整合：Moesif 提供了與 Stripe 等計費系統的直接整合，可以自動將 API 使用數據同步到計費系統中。

計費流程自動化示意圖

以下是一個更詳細的計費流程自動化示意圖，展示了數據如何從 Kong 流向計費系統：

graph TD A[客戶發送 API 請求] --> B(Kong API Gateway) B --> C{API Key 驗證} C -->|驗證失敗| D[401 Unauthorized 回應] C -->|驗證成功| E(請求轉發至後端服務) E --> F(後端服務處理請求) F --> G(後端服務回應給 Kong) G --> H{判斷回應狀態碼} H -->|HTTP 200 OK| I[成功呼叫事件] H -->|非 200 OK| J[非成功呼叫，不計數] I --> K(自訂計費 Plugin 或日誌插件) J --> K K --> L(日誌收集器或計費服務) L --> M(數據庫或日誌分析平台) M --> N[數據過濾與彙總
只統計 200 OK] N --> O[定期生成計費報表] N --> P(與計費系統整合) O --> Q[發送報表給客戶] P --> R[自動生成賬單] R --> S[客戶支付] S --> T[計費完成] %% 樣式設定 classDef success fill:#d4edda,stroke:#155724,stroke-width:2px classDef error fill:#f8d7da,stroke:#721c24,stroke-width:2px classDef process fill:#e2e3e5,stroke:#383d41,stroke-width:2px classDef billing fill:#fff3cd,stroke:#856404,stroke-width:2px classDef report fill:#cce5ff,stroke:#0066cc,stroke-width:2px class I,N,O,P,Q,R,S,T success class D,J error class B,E,F,G,K,L,M process class A,C,H billing

這張圖更詳細地展示了數據流動和各個組件之間的關係。您可以根據這張圖來規劃您的計費系統架構。

總結：打造您的 API 商業模式

通過本文的介紹，您應該已經對如何在 Kubernetes 上使用 Kong API Gateway，結合自發 API Key 驗證，記錄 API 輸出入結果，並實現只統計 HTTP 200 成功呼叫的精準計費有了全面的了解。這不僅是一個技術實現的過程，更是一個打造可持續 API 商業模式的關鍵步驟。

選擇適合您的部署方式（Helm 或 YAML）、API Key 管理方式（Admin API 或 CRDs）、日誌記錄方式和計數方案（自訂 Plugin 或外部分析），並將計費流程自動化，將幫助您更有效地管理您的 API 服務，並確保您的收入與您提供的價值相符。

記住，API 經濟的成功在於提供有價值的服務並實現合理的變現。精準計費是實現這一目標的重要手段。希望這篇文章能為您提供實用的指導，祝您在 API 商業化的道路上取得巨大成功！

參考資料

[1] https://docs.konghq.com/gateway/latest/get-started/key-authentication/ [2] https://konghq.com/blog/engineering/kong-gateway-key-authentication [3] https://www.moesif.com/blog/technical/stripe/kong/End-To-End-Monetization-With-Kong-Stripe-And-Moesif/ [4] https://discuss.konghq.com/t/rate-limit-for-200-success-responses-only/11755 [5] https://docs.konghq.com/gateway/latest/plugin-development/pdk/kong.response/ [6] https://www.moesif.com/blog/technical/kong/How-to-Best-Monitor-Kong-Performance-and-API-Usage-with-the-Moesif-API-Analytics-Plugin/ [7] https://docs.konghq.com/kubernetes-ingress-controller/latest/get-started/key-authentication/ [8] https://www.youtube.com/watch?v=4qmu7jSODoY [9] https://www.descope.com/blog/post/kong-gateway-authentication [10] https://docs.konghq.com/kubernetes-ingress-controller/latest/install/kubernetes/ [11] https://www.moesif.com/implementation/log-http-calls-from-kong-api-gateway?platform=kong-api-gateway&flow=1pDoLEQc [12] https://apiconnects.co.nz/kong-api-key-management/ [13] https://docs.konghq.com/hub/kong-inc/key-auth/ [14] https://stackoverflow.com/questions/78051465/kong-api-gateway-api-keys-custom-logics [15] https://support.konghq.com/support/s/article/Why-is-Kong-returning-two-different-status-codes-200-and-401-for-a-single-API-request-sent-from-pega [16] https://repost.aws/questions/QUSD6udgoyS_OgRy5N6g5qXA/api-gateway-gives-status-200-but-browser-reports-error-403 [17] https://docs.aws.amazon.com/zh_tw/apigateway/latest/developerguide/api-gateway-method-settings-method-response.html [18] https://www.youtube.com/watch?v=rTcj7znJVZc [19] https://blog.csdn.net/zhangshenglu1/article/details/145633866 [20] https://systemsdigest.com/videos/how-use-kong-gateway-key-authentication-plugin [21] https://fusionauth.io/docs/extend/examples/api-gateways/kong-gateway [22] https://appsec.sa/assets/publications/AppSec%20-%20Kong%20API%20Gateway%20Security%20Benchmark%201.0.pdf [23] https://stackoverflow.com/questions/55492954/kong-api-key-strategy [24] https://docs.api7.ai/enterprise/api-security/rate-limiting [25] https://www.atatus.com/observability/kong-analytics [26] https://github.com/Kong/kong/discussions/8158 [27] https://docs.konghq.com/gateway/latest/production/logging/log-reference/