Kubernetes 核心架構解析：從容器編排到儲存管理的完整實務指南

– 13 分鐘閱讀

容器技術的基礎架構

當台灣的企業開始擁抱雲端原生架構時，容器技術成為數位轉型的核心基石。然而在深入 Kubernetes 的複雜世界之前，理解容器的本質至關重要。容器並非單一的技術元件，而是由多個精密協作的機制所組成的完整生態系統。從開發者在本機建置應用程式，到在生產環境的數百台伺服器上執行，容器確保了應用程式行為的一致性。這種一致性來自於容器的兩個核心組成部分：容器映像檔與作業系統層級的隔離機制。

容器映像檔扮演著應用程式執行環境的完整封裝。當開發者建置容器映像檔時，不僅包含了應用程式的執行檔與程式碼，更涵蓋了所有依賴的函式庫、系統工具、執行時環境變數與配置檔案。這種完整封裝的特性讓開發者能夠在本機環境建置映像檔，推送到容器註冊表後，確信這個映像檔在任何支援容器執行時的環境中都能以相同的方式運作。無論是在開發者的筆記型電腦、測試伺服器，還是雲端平台的生產叢集，容器映像檔都能提供一致的執行環境。這種可攜性徹底改變了傳統的應用程式部署流程，消除了「在我的機器上可以執行」的經典問題。

當容器映像檔被啟動執行時，作業系統層級的隔離機制開始發揮作用。Linux 核心提供了多種命名空間（Namespace）技術，為每個執行中的容器建立獨立的執行環境。網路命名空間讓每個容器擁有獨立的網路堆疊，包含獨立的 IP 位址、路由表與網路介面。程序命名空間確保每個容器內的程序 ID 空間獨立，容器 A 中的程序編號 1 與容器 B 中的程序編號 1 是完全不同的程序。檔案系統命名空間類似於 chroot 機制，讓每個容器看到的根目錄都是獨立的，無法存取其他容器的檔案系統。使用者命名空間則提供了權限隔離，容器內的 root 使用者並不等同於主機系統的 root 權限。

除了命名空間提供的邏輯隔離，控制群組（cgroups）機制提供了資源使用的實體隔離。透過 cgroups，系統管理員可以限制每個容器能夠使用的 CPU 時間、記憶體容量、磁碟 I/O 頻寬與網路頻寬。這種資源限制確保了單一容器無法耗盡整個主機的資源，影響其他容器的正常運作。在多租戶環境中，cgroups 更是實現公平資源分配的關鍵機制。結合 SELinux 或 AppArmor 等強制存取控制系統，容器能夠在受限的安全沙箱中執行，即使應用程式存在漏洞，攻擊者也難以突破容器邊界影響主機系統或其他容器。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 14
skinparam minClassWidth 100

package "容器技術架構" {
    component "容器映像檔層" {
        [應用程式二進位] as app_binary
        [依賴函式庫] as libraries
        [系統工具] as system_tools
        [配置檔案] as config_files
    }
    
    component "作業系統隔離層" {
        [網路命名空間\n獨立 IP] as net_ns
        [程序命名空間\n獨立 PID] as pid_ns
        [檔案系統命名空間\n獨立根目錄] as fs_ns
        [使用者命名空間\n權限隔離] as user_ns
    }
    
    component "資源控制層" {
        [CPU 限制\ncgroups] as cpu_cgroup
        [記憶體限制\ncgroups] as mem_cgroup
        [磁碟 I/O 限制] as io_cgroup
        [網路頻寬限制] as net_cgroup
    }
    
    component "安全加固層" {
        [SELinux\n強制存取控制] as selinux
        [AppArmor\n應用程式防護] as apparmor
        [Seccomp\n系統呼叫過濾] as seccomp
    }
}

app_binary --> net_ns: 執行於
libraries --> pid_ns: 執行於
system_tools --> fs_ns: 執行於
config_files --> user_ns: 執行於

net_ns --> cpu_cgroup: 受限於
pid_ns --> mem_cgroup: 受限於
fs_ns --> io_cgroup: 受限於
user_ns --> net_cgroup: 受限於

cpu_cgroup --> selinux: 強化於
mem_cgroup --> apparmor: 強化於
io_cgroup --> seccomp: 強化於

note right of app_binary
  完整封裝執行環境
  確保跨平台一致性
end note

note right of net_ns
  多重命名空間隔離
  防止容器間干擾
end note

note right of cpu_cgroup
  資源使用限制
  公平分配機制
end note

@enduml

上方架構圖清楚呈現了容器技術的多層次防護機制。從最上層的容器映像檔封裝，到作業系統命名空間的邏輯隔離，再到 cgroups 的資源控制，最後到安全加固層的防護措施，每一層都為容器提供了不同面向的隔離與保護。這種深度防禦的架構設計讓容器能夠在共享主機資源的同時，維持高度的隔離性與安全性。

Kubernetes 容器編排的核心機制

當企業的容器化應用從少數幾個容器擴展到成百上千個容器時，手動管理這些容器變得不切實際。Kubernetes 作為容器編排平台，將一組提供運算資源的伺服器轉化為統一的容器執行環境。開發者不再需要關心應用程式執行在哪台伺服器上，只需要透過 Kubernetes API 宣告期望的狀態，系統會自動將容器排程到適當的節點執行。這種宣告式的管理方式是 Kubernetes 設計哲學的核心。

Kubernetes API 採用 RESTful 設計，所有的操作都透過 HTTP 與 JSON 格式進行。當開發者透過 kubectl 命令列工具或是自動化腳本提交部署需求時，實際上是向 API Server 發送 HTTP 請求。API Server 接收請求後，將資源定義儲存到 etcd 分散式鍵值儲存系統中。控制器管理器持續監控 etcd 中的資源狀態，當發現實際狀態與期望狀態不符時，會採取相應的協調動作。排程器則負責為新建立的 Pod 選擇適合的節點，考量因素包含節點的可用資源、親和性規則、污點與容忍度等複雜的約束條件。

Pod 是 Kubernetes 中最小的可部署單元，也是排程的原子單位。一個 Pod 可以包含一個或多個緊密耦合的容器，這些容器共享網路命名空間與儲存卷。共享網路命名空間意味著 Pod 內的所有容器共用相同的 IP 位址，可以透過 localhost 互相通訊。這種設計讓主容器與輔助容器的組合變得非常自然，例如一個 Web 應用程式容器搭配一個日誌收集的 sidecar 容器，或是一個應用程式容器搭配一個反向代理容器。雖然可以將多個容器打包成單一容器映像檔，但將它們分離成不同的容器映像檔能夠提供更好的重用性與維護性，不同的團隊可以獨立開發與更新各自負責的容器映像檔。

# Pod 基礎配置範例
# 展示單一 Pod 中包含主應用程式容器與輔助容器的設計

apiVersion: v1
kind: Pod
metadata:
  # Pod 名稱，在命名空間內必須唯一
  name: web-app-pod
  
  # 命名空間，用於資源隔離
  namespace: production
  
  # 標籤，用於選擇器匹配與資源組織
  labels:
    app: web-application
    tier: frontend
    version: v1.2.0
spec:
  # 容器定義列表
  # Pod 可以包含多個容器，這些容器共享網路與儲存
  containers:
  # 主應用程式容器
  - name: web-server
    # 容器映像檔位址
    # 建議使用明確的版本標籤而非 latest
    image: myregistry.azurecr.io/web-app:1.2.0
    
    # 容器連接埠定義
    # 雖然 Pod 內的容器可以互相通訊，但仍建議明確宣告連接埠
    ports:
    - containerPort: 8080
      name: http
      protocol: TCP
    
    # 環境變數配置
    # 可以從 ConfigMap、Secret 或直接定義取得
    env:
    - name: APP_ENV
      value: "production"
    - name: LOG_LEVEL
      value: "info"
    
    # 資源請求與限制
    # requests: 排程時保證的最低資源
    # limits: 容器能使用的最大資源
    resources:
      requests:
        # CPU 以 millicores 為單位，250m = 0.25 核心
        cpu: "250m"
        # 記憶體以 bytes 為單位，支援 Ki、Mi、Gi 等單位
        memory: "512Mi"
      limits:
        cpu: "500m"
        memory: "1Gi"
    
    # 健康檢查探針
    # livenessProbe: 檢測容器是否存活，失敗會重啟容器
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      # 容器啟動後等待 30 秒才開始檢查
      initialDelaySeconds: 30
      # 每 10 秒檢查一次
      periodSeconds: 10
      # 連續失敗 3 次才認定為失敗
      failureThreshold: 3
    
    # readinessProbe: 檢測容器是否準備好接收流量
    # 失敗會從 Service 的端點列表中移除
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
  
  # 輔助容器（Sidecar）
  # 負責收集主容器的日誌並轉發到集中式日誌系統
  - name: log-collector
    image: fluent/fluentd:v1.14
    
    # 掛載主容器的日誌目錄
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
      # 唯讀掛載，避免誤修改日誌
      readOnly: true
    
    # 輔助容器的資源通常較小
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  
  # Volume 定義
  # Pod 內的容器可以共享這些 Volume
  volumes:
  # emptyDir: Pod 生命週期內的臨時儲存
  # Pod 刪除時資料也會清除
  - name: logs
    emptyDir: {}
  
  # 重啟策略
  # Always: 總是重啟（預設）
  # OnFailure: 只在失敗時重啟
  # Never: 從不重啟
  restartPolicy: Always
  
  # DNS 策略
  # ClusterFirst: 使用叢集 DNS（預設）
  dnsPolicy: ClusterFirst

ReplicaSet 負責維護指定數量的 Pod 副本。當開發者宣告需要執行三個 Web 伺服器副本時，ReplicaSet 控制器會持續監控實際執行的 Pod 數量。若某個 Pod 因為節點故障而消失，ReplicaSet 會立即建立新的 Pod 補足數量。若某個節點恢復導致 Pod 數量超過期望值，ReplicaSet 會刪除多餘的 Pod。這種自動修復機制大幅提升了應用程式的可靠性。值得注意的是，在 Kubernetes 的早期版本中曾有一個名為 ReplicationController 的類似物件，但由於功能限制已被 ReplicaSet 取代。雖然基於向後相容性 ReplicationController 仍然存在於 API 中，但所有新的部署都應該使用 ReplicaSet 或更高層次的 Deployment 物件。

# ReplicaSet 配置範例
# 確保指定數量的 Pod 副本持續執行

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  # ReplicaSet 名稱
  name: web-app-replicaset
  namespace: production
  
  # ReplicaSet 的標籤
  # 與 Pod 標籤分開管理
  labels:
    app: web-application
    managed-by: replicaset
spec:
  # 期望的副本數量
  # ReplicaSet 控制器會確保始終維持這個數量的 Pod
  replicas: 3
  
  # 選擇器定義
  # 決定 ReplicaSet 管理哪些 Pod
  selector:
    matchLabels:
      # 必須與下方 template.metadata.labels 匹配
      app: web-application
      tier: frontend
  
  # Pod 模板定義
  # 當 ReplicaSet 需要建立新 Pod 時使用此模板
  template:
    metadata:
      # Pod 的標籤
      # 必須包含與 selector.matchLabels 相符的標籤
      labels:
        app: web-application
        tier: frontend
        version: v1.2.0
    spec:
      # Pod 規格與上面的單一 Pod 範例相同
      containers:
      - name: web-server
        image: myregistry.azurecr.io/web-app:1.2.0
        ports:
        - containerPort: 8080
        
        # 資源配置
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        
        # 健康檢查
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
      
      # Pod 反親和性設定（選用）
      # 盡可能將 Pod 分散到不同節點
      # 提升可用性
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-application
              topologyKey: kubernetes.io/hostname

# ReplicaSet 的運作機制：
# 1. 控制器持續監控符合 selector 的 Pod 數量
# 2. 若實際數量少於 replicas，建立新 Pod
# 3. 若實際數量多於 replicas，刪除多餘 Pod
# 4. 若 Pod 失敗，自動重建達到期望數量
# 5. 支援水平擴縮容，修改 replicas 值即可

# 注意事項：
# - ReplicaSet 通常不直接使用，而是透過 Deployment 管理
# - Deployment 提供滾動更新、版本回滾等進階功能
# - 修改 template 不會自動更新現有 Pod
# - 需要刪除舊 Pod 或使用 Deployment 觸發滾動更新

Service 負載平衡與服務發現

當多個 Pod 副本同時執行時，如何讓外部流量均勻分配到這些副本成為關鍵問題。Kubernetes 的 Service 物件提供了穩定的網路端點與負載平衡機制。每個 Service 被建立時會獲得三個重要屬性：一個虛擬 IP 位址、在叢集 DNS 中的記錄，以及負載平衡規則。這個虛擬 IP 位址並不對應於任何實體網路介面，而是被程式設計到叢集的網路平面中。當封包被發送到這個虛擬 IP 時，kube-proxy 元件會根據負載平衡演算法將流量轉發到後端的 Pod。

Service 的 DNS 名稱遵循固定的命名規則，在同一命名空間內的 Pod 可以直接使用服務名稱存取，例如存取名為 frontend 的 Service 只需要使用 frontend 作為主機名稱。跨命名空間存取則需要使用完整的 DNS 名稱，格式為服務名稱.命名空間.svc.cluster.local。這種基於 DNS 的服務發現機制讓微服務之間的通訊變得簡單可靠。當後端 Pod 因為擴縮容或故障重建而變化時，Service 會自動更新其端點列表，確保流量只導向健康的 Pod。客戶端無需感知後端的變化，始終透過固定的 Service 名稱或 IP 存取服務。

# Service 配置範例
# 提供穩定的網路端點與負載平衡

apiVersion: v1
kind: Service
metadata:
  # Service 名稱
  # 將成為 DNS 記錄的一部分
  name: web-service
  namespace: production
  
  # Service 的標籤
  labels:
    app: web-application
spec:
  # Service 類型
  # ClusterIP: 叢集內部存取（預設）
  # NodePort: 透過節點的固定埠號對外暴露
  # LoadBalancer: 使用雲端供應商的負載平衡器
  # ExternalName: 建立 DNS CNAME 記錄
  type: ClusterIP
  
  # 選擇器定義
  # Service 會將流量導向符合這些標籤的 Pod
  selector:
    app: web-application
    tier: frontend
  
  # 連接埠配置
  # Service 可以暴露多個連接埠
  ports:
  # HTTP 連接埠
  - name: http
    # Service 監聽的連接埠
    port: 80
    # 目標 Pod 的連接埠
    targetPort: 8080
    # 協定類型
    protocol: TCP
  
  # HTTPS 連接埠（選用）
  - name: https
    port: 443
    targetPort: 8443
    protocol: TCP
  
  # 會話親和性（選用）
  # None: 無會話保持，純輪詢（預設）
  # ClientIP: 基於客戶端 IP 的會話保持
  sessionAffinity: None
  
  # ClusterIP 設定（選用）
  # 可以手動指定 IP，或留空讓系統自動分配
  # clusterIP: 10.96.100.50

---
# NodePort Service 範例
# 將服務暴露在每個節點的固定埠號上

apiVersion: v1
kind: Service
metadata:
  name: web-service-nodeport
  namespace: production
spec:
  type: NodePort
  selector:
    app: web-application
    tier: frontend
  ports:
  - name: http
    # Service 的埠號（叢集內部存取）
    port: 80
    # Pod 的埠號
    targetPort: 8080
    # 節點上的埠號（30000-32767）
    # 可以手動指定或讓系統自動分配
    nodePort: 30080
    protocol: TCP

# Service 的運作流程：
# 1. Service 建立時獲得虛擬 IP (ClusterIP)
# 2. DNS 記錄被新增到叢集 DNS
#    - 同命名空間存取: web-service
#    - 跨命名空間存取: web-service.production.svc.cluster.local
# 3. kube-proxy 在每個節點設定 iptables/IPVS 規則
# 4. 流量發送到 ClusterIP:port 時被攔截
# 5. 根據負載平衡演算法轉發到後端 Pod
# 6. 只有通過 readinessProbe 的 Pod 會接收流量

# 負載平衡演算法：
# - 預設使用隨機選擇或輪詢
# - 啟用 sessionAffinity 時基於客戶端 IP 雜湊
# - 可透過 externalTrafficPolicy 控制來源 IP 保留

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 14
skinparam minClassWidth 100

package "Kubernetes 服務架構" {
    component "客戶端層" {
        [外部用戶端] as external_client
        [叢集內 Pod] as internal_client
    }
    
    component "Service 層" {
        [Service\nClusterIP: 10.96.100.50] as service
        [DNS 記錄\nweb-service.production] as dns
        [kube-proxy\n負載平衡規則] as kube_proxy
    }
    
    component "Pod 副本層" {
        [Pod 1\n192.168.1.10:8080\nReady] as pod1
        [Pod 2\n192.168.1.11:8080\nReady] as pod2
        [Pod 3\n192.168.1.12:8080\nNotReady] as pod3
    }
    
    component "健康檢查" {
        [Readiness Probe] as readiness
    }
}

external_client --> service: HTTP 請求
internal_client --> dns: DNS 查詢
dns --> service: 解析 IP

service --> kube_proxy: 流量轉發

kube_proxy --> pod1: 負載平衡
kube_proxy --> pod2: 負載平衡
kube_proxy -.-> pod3: 未就緒不轉發

readiness --> pod1: 檢查通過
readiness --> pod2: 檢查通過
readiness --> pod3: 檢查失敗

note right of service
  虛擬 IP 位址
  穩定的網路端點
  自動更新端點列表
end note

note right of kube_proxy
  iptables/IPVS 規則
  輪詢或會話保持
  只轉發到就緒 Pod
end note

note right of pod3
  未通過健康檢查
  暫時從服務移除
  待恢復後自動加入
end note

@enduml

上方架構圖展示了 Service 的完整流量路徑。外部或內部客戶端透過 Service 的虛擬 IP 或 DNS 名稱發送請求，kube-proxy 根據負載平衡規則將流量分配到後端的 Pod。健康檢查機制確保只有通過 Readiness Probe 的 Pod 才會接收流量，失敗的 Pod 會被暫時從服務端點中移除，待恢復後自動重新加入。

儲存管理的進化歷程

容器的無狀態特性簡化了擴縮容與故障恢復，但許多應用程式需要持久化儲存資料。Kubernetes 的儲存管理經歷了從簡單到複雜的演進過程。最初的 Volume 概念直接內建在 Pod 規格中，開發者需要在 Pod 定義裡明確指定使用何種類型的儲存，例如 NFS、iSCSI 或雲端供應商的塊儲存。這種緊密耦合的方式雖然簡單直接，但帶來了可攜性與可維護性的問題。當 Pod 定義包含特定雲端平台的儲存類型時，這個 Pod 定義就無法在其他平台上使用。

為了解決這個問題，Kubernetes 引入了 PersistentVolume 與 PersistentVolumeClaim 的概念，實現了儲存的供應與消費分離。PersistentVolume 代表叢集中的實際儲存資源，由叢集管理員預先配置或透過 StorageClass 動態配置。PersistentVolumeClaim 則代表使用者對儲存的需求聲明，開發者只需要指定需要多少儲存容量、需要何種存取模式，而無需關心底層使用的是哪種儲存技術。當 PersistentVolumeClaim 被建立時，Kubernetes 會自動尋找符合需求的 PersistentVolume 進行綁定，或透過 StorageClass 動態配置新的 PersistentVolume。

ConfigMap 與 Secret 則是特殊類型的儲存機制，專門用於管理配置資料與敏感資訊。ConfigMap 儲存非敏感的配置檔案，例如應用程式的配置參數、環境變數、命令列參數等。Secret 則用於儲存密碼、OAuth token、SSH 金鑰等敏感資料。雖然 Secret 的資料在 etcd 中預設只是 Base64 編碼而非加密，但 Kubernetes 提供了額外的安全機制，包含基於 RBAC 的存取控制、etcd 加密、與外部密鑰管理系統的整合等。透過將這些配置資料與應用程式程式碼分離，同一個容器映像檔可以在不同環境中使用不同的配置，實現了真正的環境無關性。

# PersistentVolume 與 PersistentVolumeClaim 範例
# 實現儲存的供應與消費分離

# PersistentVolume 定義
# 由叢集管理員建立，代表實際的儲存資源
apiVersion: v1
kind: PersistentVolume
metadata:
  # PV 名稱，叢集層級唯一
  name: nfs-pv-data
spec:
  # 儲存容量
  capacity:
    storage: 10Gi
  
  # 存取模式
  # ReadWriteOnce (RWO): 單節點讀寫
  # ReadOnlyMany (ROX): 多節點唯讀
  # ReadWriteMany (RWX): 多節點讀寫
  accessModes:
    - ReadWriteMany
  
  # 回收策略
  # Retain: 手動回收
  # Recycle: 基本清除（已棄用）
  # Delete: 自動刪除
  persistentVolumeReclaimPolicy: Retain
  
  # StorageClass 名稱
  # 用於動態配置時的分類
  storageClassName: nfs-storage
  
  # NFS 儲存配置
  nfs:
    # NFS 伺服器位址
    server: nfs.example.com
    # NFS 共享路徑
    path: /data/volumes/pv-data

---
# PersistentVolumeClaim 定義
# 由開發者建立，聲明儲存需求

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  # PVC 名稱，命名空間層級
  name: app-data-claim
  namespace: production
spec:
  # 存取模式需求
  # 必須是 PV 支援的模式子集
  accessModes:
    - ReadWriteMany
  
  # 儲存容量需求
  resources:
    requests:
      # 請求 5Gi 儲存空間
      # 必須小於等於 PV 的容量
      storage: 5Gi
  
  # StorageClass 名稱
  # 留空表示使用預設 StorageClass
  # 設定為 "" 表示使用靜態配置
  storageClassName: nfs-storage
  
  # Volume 模式（選用）
  # Filesystem: 檔案系統模式（預設）
  # Block: 塊裝置模式
  volumeMode: Filesystem

---
# 使用 PVC 的 Pod 定義

apiVersion: v1
kind: Pod
metadata:
  name: app-with-storage
  namespace: production
spec:
  containers:
  - name: app-container
    image: myapp:1.0
    
    # 掛載 PVC
    volumeMounts:
    - name: data-volume
      # 容器內的掛載路徑
      mountPath: /data
      # 子路徑（選用）
      # 可以只掛載 PV 的特定子目錄
      # subPath: app-data
  
  # Volume 定義
  volumes:
  - name: data-volume
    # 使用 PVC
    persistentVolumeClaim:
      # PVC 名稱
      claimName: app-data-claim

# PV 與 PVC 的綁定流程：
# 1. 管理員建立 PV 或配置 StorageClass 動態配置
# 2. 開發者建立 PVC 聲明儲存需求
# 3. Kubernetes 尋找符合需求的 PV
#    - 容量足夠
#    - 存取模式符合
#    - StorageClass 匹配
# 4. 綁定 PVC 與 PV
# 5. Pod 透過 PVC 使用儲存
# 6. Pod 刪除後 PVC 仍存在
# 7. PVC 刪除後根據回收策略處理 PV

---
# ConfigMap 與 Secret 範例
# 管理配置與敏感資料

# ConfigMap 定義
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: production
data:
  # 簡單的鍵值對
  database.host: "mysql.example.com"
  database.port: "3306"
  
  # 完整的配置檔案
  app.properties: |
    server.port=8080
    server.context-path=/api
    logging.level.root=INFO
    logging.level.com.example=DEBUG

---
# Secret 定義
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: production
type: Opaque
data:
  # Secret 資料必須 Base64 編碼
  # 使用命令產生：echo -n 'password123' | base64
  database.password: cGFzc3dvcmQxMjM=
  api.key: YXBpa2V5MTIzNDU2Nzg=

---
# 使用 ConfigMap 與 Secret 的 Pod

apiVersion: v1
kind: Pod
metadata:
  name: app-with-config
  namespace: production
spec:
  containers:
  - name: app-container
    image: myapp:1.0
    
    # 從 ConfigMap 注入環境變數
    env:
    - name: DATABASE_HOST
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: database.host
    
    # 從 Secret 注入環境變數
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secrets
          key: database.password
    
    # 掛載 ConfigMap 為檔案
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
    
    # 掛載 Secret 為檔案
    - name: secret-volume
      mountPath: /etc/secrets
      readOnly: true
  
  volumes:
  # ConfigMap Volume
  - name: config-volume
    configMap:
      name: app-config
  
  # Secret Volume
  - name: secret-volume
    secret:
      secretName: app-secrets
      # 檔案權限設定
      defaultMode: 0400

透過 Kubernetes 的核心物件與儲存管理機制，台灣企業能夠建構彈性可靠的容器化應用平台。從容器的隔離機制到 Pod 的編排原理，從 ReplicaSet 的副本管理到 Service 的負載平衡，再到多樣化的儲存解決方案，Kubernetes 提供了完整的雲端原生基礎設施。無論是電商平台需要快速擴展處理促銷流量，金融系統需要高可用性與資料持久化，還是 SaaS 服務需要多租戶隔離，這些機制都能滿足不同場景的需求。掌握這些核心概念，將為團隊在雲端原生時代的應用開發與部署奠定堅實基礎。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。