還沒講到 Namespace 所以跳過 Demo 的 Service：ExternalName

先複習一下：

ExternalName

Kubernetes Service 的類型之一。
用於 Service 導向指定的 DNS name，而非指定的 pod。
相當於將外部服務當作 Cluster 內部服務來使用，即便外部服務的 IP 變更，也只需要修改 ExternalName Service 的配置，而不需要更動使用該服務的 Pod。

相同的概念也可以應用在Cluster內部

內部？外部？

在同一個 Cluster 內部的 Pod 為什麼會有這種需求？
用 ClusterIP Service 不行嗎？
不行。
出於安全和隔離機制，ClusterIP Service 只有在同一個 Namespace 中的服務可見。

所以才會用到 ExternalName。

開始之前

需要先知道 Kubernetes 中的跨 Namespace Service 怎麼呼叫

<service-name>.<namespace>.svc.cluster.local

• cluster.local：kubernetes default domain
• svc：service

Demo

1. 準備兩個不同的 Namespace：demo-01、demo-02
   （只建立一個 + default 也可以）

   kubectl create namespace <namespace-name>
   

   

2. 在第一個 Namespace（demo-01）中建立一個 Pod，並建置 Service

   • create pod
     
   • create service
     
   • 確認建置結果

     # -n : --namespace 簡寫
     kubectl get pods,svc -n demo-01
     

     

3. 在第二個 Namespace （demo-02）中建立 ExternalName Service

     apiVersion: v1 
     kind: Service 
     metadata: 
       name: nginx-external 
       namespace: demo-02
    spec: 
      type: ExternalName 
      externalName: nginx-service.demo-01.svc.cluster.local
   

   

4. 在第二個 Namespace （demo-02）建立一個Pod，並使用 ExternalName 設定的 name 呼叫

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pod
     namespace: demo-02
   spec:
     containers:
       - name: busybox
         image: busybox
         command: ['sh', '-c', 'while true; do wget -qO- nginx-external; sleep 5; done']
   

   
   （busybox：＊註1，相關指令：＊註2）
   確認建置結果：
   

5. 查詢 Log 確認呼叫是否成功

   kubectl logs -f <pod-name> -n <namespace-name>
   # 範例
   kubectl logs -f test-pod -n demo-02
   

   
   從 Log 內容可看出從 Namespace： demo-02 透過 ExternalName 設定的名稱有成功呼叫到不同 Namespace （demo-01）的服務。

這個方式有什麼優缺點？

• 優點
  • 簡單：設置相對簡單，只需要創建一個 ExternalName 類型的 Service，且不需要自行設定 DNS 或 Porxy
  • 抽象：為 client 端提供了一層抽象，使得實際服務的位置對客戶端透明。
  • 靈活：若目的端出現變動需要調整，可以輕鬆地將服務重定向而不需要更改 client 端設定。
• 缺點
  • ExternalName Service 本身不提供 Load Balance 功能
  • ExternalName Service 不會對後端服務進行 health check
  • 僅支援 DNS 解析：只能重定向到一個特定的 DNS 名稱，不能指向 IP 位置
  • 潛在的性能開銷：每次訪問都需要額外的 DNS 查詢
  • 安全性考慮：可能會暴露內部服務結構，需要謹慎管理權限
  • 偵錯困難：因為是在 DNS 層進行重定向，可能增加問題排查的難度

ExternalName Service 是一個簡單易用的解決方案，不需要 Load Balance 或細部流量管理的時候適用。

那如果我要 Load Balance 或做流量控制呢？

要管理 Kubernetes 的內部流量，除了 ExternalName Service 外，還有不少方式可供選擇：

沒辦法在表格內換行只好直接上圖

小結

在 Kubernetes 中可以使用 ExternalName Service 實踐跨 Namespace 呼叫服務，方法雖簡單但也有其缺點。在設定 Kubernetes 的服務訪問注意時，除了是否便利，還要權衡安全性和複雜度，需根據當下的使用場景、安全要求和基礎設施配置選擇適當的解決方案。

＊註1
BusyBox 是一個非常輕量且實用的工具，又稱為"嵌入式 Linux 的瑞士軍刀"。
它是一個單一的可執行文件，包含了許多常見的 Unix 工具的精簡版本。
不但體積小（通常只有幾百 KB 到幾 MB），還包含了超過 300 個常用的 Linux 命令。
包含但不限於：

• 文件操作：ls, cp, mv, rm
• 文本處理：cat, grep, sed, awk
• 系統工具：ps, top, kill
• 網絡工具：ping, wget, netstat
• Shell：ash
  常用於 Container 的偵錯和測試。

＊註2

image: busybox
command: ['sh', '-c', 'while true; do wget -qO- nginx-external; sleep 5; done']

使用 wget 命令，透過 ExternalName Service 設定的名稱：nginx-external發送 HTTP 請求到 Namespace：demo-01 的 nginx 服務。
-qO- 實際上是兩個不同的參數組合在一起：

• -q
  • 代表 "quiet"（安靜模式）
  • 它會簡化 wget 的輸出，不顯示進度條、錯誤信息等其他資訊

2. -O-：
   • 這個指令由 -O 和 - 兩部分組成
   • -O：指定輸出文件。
   • -：作為 -O 的參數，表示將下載的內容輸出到標準輸出（stdout）。
   • 即為：不將下載的內容保存到文件，而是直接輸出到終端
     組合起來，整段 command 的意思是：

• 使用 wget 下載 nginx-external 的內容 (且省略其他資訊，只輸出下載內容)
• 不存檔，將內容直接輸出到終端
• 等待 5 秒
• 無限循環這個過程