Day 15 的 api-a 可以在叢集內被其他 Pod 呼叫，但我們在電腦上開 API Client，還不能直接使用 api-a.team-a.svc.cluster.local。必須要再要做一個暫時的測試入口，所以可以透過將把Service 設成 NodePort 來達到這個目的

apiVersion: v1
kind: Service
metadata:
  name: api-a-test
  namespace: team-a
spec:
  type: NodePort
  selector:
    app: api-a
  ports:
    - name: http
      port: 80
      targetPort: http
      nodePort: 30080

這樣的配置可以讓叢集外部的 Client 端透過 NodeIP:30080 做為 request URL，後續 K8s 會再轉到 api-a Pod。

30080 必須為叢集允許的 NodePort 範圍，且沒有被其他 Service 使用。

而因為本次示範的環境是 k3d，k3d 會多了一層 Kubernetes Node 在 Docker container 裡。

先前建立的 ironman cluster 已把主機 8080 映射到 NodePort 30080。

把 Service YAML 存成 api-a-nodeport.yaml 後，套用並測試：

kubectl apply -f api-a-nodeport.yaml
kubectl -n team-a get service api-a-test
curl http://localhost:8080/health

。若本機連不到，先確認 host 映射、Service 與 EndpointSlice，再看 Pod 是否監聽 8080。

前端 nginx 也可以代理 /api 到後端，讓瀏覽器走同一來源。這會讓 nginx 路徑成為 API 入口的一部分，因此要一起考慮前端服務的可用性。

這裡的 NodePort 則讓 API Client 暫時繞過前端，方便測試。

若瀏覽器頁面與 NodePort API 分屬不同 origin，還會碰到 CORS。

NodePort 能通，只代表網路可以連線並且是通了，但瀏覽器是否允許頁面讀取回應，還要再確認後端 CORS 回應與瀏覽器規則等等的相關設定，接下來會持續說明這塊內容。

不過還是要提醒一下，NodePort 通常還是用來短暫測試的，不會長時間作為接收 request / 對外揭露叢集內的服務的路徑。

參考資料

• Kubernetes：Service type NodePort
• k3d：Exposing Services
• MDN：Cross-Origin Resource Sharing