Day 16 的 api-a-test NodePort 讓 API Client 可以從電腦呼叫 api-a。接下來想用瀏覽器驗證前端畫面呼叫 API。

首先要分清楚一點：request 是從瀏覽器發出，還是從叢集裡的 Pod 發出？因為都是對同一個後端 API 發送 request，但兩邊能使用的位址不同。

這篇會先 demo frontend-a 透過暫時將 api-a 的 Service 設定為 NodePort 使其對外暴露，驗證瀏覽器端的設定與 CORS。

前端：configuration.json

在這個 Demo 中，frontend-a 的頁面透過 kubectl port-forward 提供於 http://127.0.0.1:18081，api-a 的 NodePort 對應到 http://127.0.0.1:8080。

Client 在瀏覽 frontend-a 時會先下載 /runtime/configuration.json，再由瀏覽器呼叫 API：

{
  "apiBaseUrl": "http://127.0.0.1:8080"
}

configuration.json 由 frontend-a-config ConfigMap 掛載到 frontend-a Pod 的 Nginx 網站目錄。

這次 Demo 的 frontend-a 會讀取設定後送出 GET /api/a/hello，組成 http://127.0.0.1:8080/api/a/hello。

後端：Pod 之間持續用 Service DNS

api-b 呼叫 api-a 的既有設定仍是 API_A_BASE_URL=http://api-a；api-gateway 的下游設定仍指向 http://api-a 與 http://api-b。

這些 request 從同一個 namespace 的 Pod 發出，所以 Service DNS 可以解析到對應的 ClusterIP。

跨 namespace 時可使用 Service FQDN，並依叢集實際 DNS 設定確認 suffix，例如：api-c.｛namespace}.sec.cluster.local

目前瀏覽器到 API A 的路徑是 frontend-a 頁面 → api-a-test NodePort Service → api-a Pod。

api-a-test 與供 Pod 內呼叫的 api-a ClusterIP 是兩個各自選到api-a Pod 的 Service。

CORS

http://127.0.0.1:18081 與 http://127.0.0.1:8080 的埠不同，因此是兩個 origin。

API 即使能被 curl 呼叫，瀏覽器仍會檢查跨 origin response 的 CORS header。

API 程式必須再套用此 CORS 規則：

var corsAllowedOrigin = Environment.GetEnvironmentVariable("CORS_ALLOWED_ORIGIN");
if (!string.IsNullOrWhiteSpace(corsAllowedOrigin))
{
    builder.Services.AddCors(options => options.AddPolicy("frontend-a-direct", policy =>
        policy.WithOrigins(corsAllowedOrigin).WithMethods("GET").AllowAnyHeader()));
}

var app = builder.Build();
if (!string.IsNullOrWhiteSpace(corsAllowedOrigin))
    app.UseCors("frontend-a-direct");

實際驗證順序

在 apply 相關 YAML 後，保持以下 port-forward 視窗開啟（Windows 環境，故使用 Powershell），再用瀏覽器開啟 http://127.0.0.1:18081：

kubectl --context k3d-ironman -n team-a port-forward --address 127.0.0.1 service/frontend-a 18081:80

畫面應顯示來自 api-a 的 JSON，並從瀏覽器 F12 Console 工具的 Network 依序檢查 /runtime/configuration.json 的 apiBaseUrl、/api/a/hello 的實際 Request URL 與 Response，以及 Access-Control-Allow-Origin 是否等於前端 origin。

若呼叫失敗，則依序看頁面讀到的 JSON 欄位、瀏覽器實際發出的 URL、NodePort 是否可達、CORS response、api-a Pod 的 log 來確認問題點。

api-b → api-a 及 api-gateway → api-a/api-b 則建議可以透過 kubectl exec 進入到 Pod 內的 Container，再透過 curl 去手動發出 request 來驗證。

而後續的文章會改用 Ingress，將 / 送到 portal-web、/api/... 送到 api-gateway，再由 api-gateway 轉送到各個後端 API。

再讓前端站台也改成串接 Gateway，並移除這篇暫時設定的 NodePort，這時頁面與 API 由同一 origin 提供，也就不會遇到本篇直連測試的跨 origin 情境。

參考資料

• Kubernetes：ConfigMaps
• Kubernetes：DNS for Services and Pods
• Kubernetes：Secrets
• Kubernetes：kubectl port-forward
• Microsoft：ASP.NET Core CORS
• MDN：CORS