文件

• 1: 詞彙表
• 2: Kubernetes 文件
• 2.1: 可用的文件版本
• 3: 容器執行階段
• 4: 最佳實務
• 4.1: 大型叢集的考量事項
• 4.2: 跨區域執行
• 5: 教學
• 5.1: Hello Minikube
• 5.2: 配置
• 5.2.1: 使用 ConfigMap 設定 Redis

1 - 詞彙表

2 - Kubernetes 文件

2.1 - 可用的文件版本

本網站包含 Kubernetes 現行版本與前 4 個版本的說明文件。

Kubernetes 各版本文件的提供情況，與該版本是否仍受支援是兩回事。 請參閱支援週期了解哪些版本的 Kubernetes 受官方支援，以及它的期限。

3 - 容器執行階段

您需要在叢集中的每個節點安裝 容器執行階段， 以便 Pod 能在其中執行。本頁概述了相關的內容，並說明設定節點的相關工作。

Kubernetes 1.35 要求您使用符合 Container Runtime Interface (CRI) 的執行階段。

如需更多資訊，請參閱 CRI 版本支援。

本頁概述了如何將數種常見的容器執行階段與 Kubernetes 搭配使用。

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

安裝與設定前置作業

網路設定

預設情況下，Linux 核心不允許在介面之間路由 IPv4 封包。 大多數 Kubernetes 叢集網路實作都會修改此設定（如果需要），但有些實作可能會預期管理員代為執行此步驟。 （有些實作也可能預期管理員設定其他 sysctl 參數、載入核心模組等；請針對您所使用的特定網路實作，參閱其說明文件。）

啟用 IPv4 封包轉發

若要手動啟用 IPv4 封包轉發：

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

透過以下指令驗證 net.ipv4.ip_forward 是否已設定為 1：

sysctl net.ipv4.ip_forward

cgroup 驅動程式

在 Linux 系統上，控制群組 是用於限制分配給程序的資源。

kubelet 與底層的容器執行階段都需要與控制群組互動， 以強制執行 Pod 與容器的資源管理，並設定如 CPU、記憶體等資源的請求與限制。 為了與控制群組互動，kubelet 和容器執行階段需要使用 cgroup 驅動程式。 最重要的是，kubelet 和容器執行階段必須使用相同的 cgroup 驅動程式，且設定必須一致。

目前有兩種可用的 cgroup 驅動程式：

• cgroupfs
• systemd

cgroupfs 驅動程式

cgroupfs 驅動程式是 kubelet 預設的 cgroup 驅動程式。 當使用 cgroupfs 驅動程式時，kubelet 和容器執行階段會直接與 cgroup 檔案系統互動以設定 cgroup。

當 systemd 是系統的 init 系統時， 不建議使用 cgroupfs 驅動程式，因為 systemd 預期系統上只有單一個 cgroup 管理器。 此外，如果您使用 cgroup v2，請使用 systemd cgroup 驅動程式而非 cgroupfs。

systemd cgroup 驅動程式

當 Linux 發行版選擇 systemd 作為 init 系統時， init 程序會產生並使用一個根控制群組（cgroup），並扮演 cgroup 管理器的角色。

systemd 與 cgroup 具有緊密的整合，並會為每個 systemd 單元分配一個 cgroup。 因此，如果您將 systemd 作為 init 系統並搭配 cgroupfs 驅動程式使用，系統中將會出現兩個不同的 cgroup 管理器。

兩個 cgroup 管理器會導致系統對可用資源與已用資源產生兩種不同的解讀。 在某些情況下，如果節點被設定為在 kubelet 和容器執行階段使用 cgroupfs，而其他程序則使用 systemd； 當資源面臨壓力時，系統將會變得不穩定。

緩解這種不穩定性的方法是，當 systemd 被選為 init 系統時，kubelet 和容器執行階段也應該使用 systemd 作為 cgroup 驅動程式。

若要將 cgroup 驅動程式設定為 systemd，請編輯 KubeletConfiguration 中的 cgroupDriver 選項，並將其設定為 systemd。例如：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

如果您將 kubelet 的 cgroup 驅動程式設定為 systemd，您也必須將容器執行階段的 cgroup 驅動程式設定為 systemd。相關說明請參閱您的容器執行階段文件。例如：

• containerd
• CRI-O

在 Kubernetes 1.35 中，若啟用 KubeletCgroupDriverFromCRI 功能開關， 並且容器執行階段支援 RuntimeConfig CRI RPC，kubelet 將自動從執行階段偵測合適的 cgroup 驅動程式， 並忽略 kubelet 設定中的 cgroupDriver 設定。

然而，較舊版本的容器執行階段（具體來說，containerd 1.y 及更低版本）不支援 RuntimeConfig CRI RPC，因此可能無法正確回應此查詢，導致 kubelet 退而使用自身 --cgroup-driver 參數的值。

在 Kubernetes 1.36 中，此退回機制將被移除，這意味著較舊版本的 containerd 在較新的 kubelet 上將無法運作。

在 kubeadm 管理的叢集中遷移至 systemd 驅動程式

如果您希望在現有由 kubeadm 管理的叢集中遷移至 systemd cgroup 驅動程式，請遵循設定 cgroup 驅動程式的說明。

CRI 版本支援

您的容器執行階段必須至少支援 v1alpha2 的容器執行階段介面。

Kubernetes 自 v1.26 起 僅支援 v1 版本的 CRI API。較早版本預設使用 v1 版本，但如果容器執行階段不支援 v1 API，kubelet 將退而使用（已棄用）v1alpha2 API。

容器執行階段

containerd

本節概述將 containerd 作為 CRI 執行階段所需的步驟。

若要在您的系統上安裝 containerd，請遵循 getting started with containerd 中的說明。 當您建立好有效的 config.toml 設定檔後，請回到此步驟。

• Linux
• Windows

在 Linux 上，containerd 的預設 CRI socket 為 /run/containerd/containerd.sock。 在 Windows 上，預設的 CRI 端點為 npipe://./pipe/containerd-containerd。

設定 systemd cgroup 驅動程式

若要在 /etc/containerd/config.toml 中搭配 runc 使用 systemd cgroup 驅動程式，請根據您的 Containerd 版本設定以下配置：

Containerd 1.x 版本：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

Containerd 2.x 版本：

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
  ...
  [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
    SystemdCgroup = true

如果您使用 cgroup v2，則建議使用 systemd cgroup 驅動程式。

如果您套用了此變更，請務必重新啟動 containerd：

sudo systemctl restart containerd

使用 kubeadm 時，請手動設定 kubelet 的 cgroup 驅動程式。

在 Kubernetes v1.28 中，您可以將自動偵測 cgroup 驅動程式啟用為 alpha 功能。如需更多細節，請參閱 systemd cgroup 驅動程式。

覆寫沙盒（pause）映像檔

在您的 containerd 設定中，您可以透過設定以下內容來覆寫沙盒映像檔：

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.10"

更新設定檔後，您可能還需要重新啟動 containerd：systemctl restart containerd。

CRI-O

本節包含將 CRI-O 安裝為容器執行階段所需的步驟。

若要安裝 CRI-O，請遵循 CRI-O 安裝說明。

cgroup 驅動程式

CRI-O 預設使用 systemd cgroup 驅動程式，這通常可以正常運作。若要切換為 cgroupfs cgroup 驅動程式，您可以編輯 /etc/crio/crio.conf 或是在 /etc/crio/crio.conf.d/02-cgroup-manager.conf 放置一個補充設定檔，例如：

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

您也應注意已變更的 conmon_cgroup。當 CRI-O 與 cgroupfs 搭配使用時，conmon_cgroup 必須被設定為 pod。一般來說，必須保持 kubelet（通常透過 kubeadm 設定）和 CRI-O 的 cgroup 驅動程式設定同步。

在 Kubernetes v1.28 中，您可以將自動偵測 cgroup 驅動程式啟用為 alpha 功能。如需更多細節，請參閱 systemd cgroup 驅動程式。

對於 CRI-O，預設的 CRI socket 是 /var/run/crio/crio.sock。

覆寫沙盒（pause）映像檔

在您的 CRI-O 設定中，您可以設定以下配置值：

[crio.image]
pause_image="registry.k8s.io/pause:3.10"

此設定選項支援即時重新載入以套用變更：執行 systemctl reload crio，或向 crio 程序發送 SIGHUP 訊號。

Docker Engine

1. 在您的每個節點上，根據安裝 Docker Engine 的說明，為您的 Linux 發行版安裝 Docker。

2. 安裝 cri-dockerd，請遵循文件安裝章節中的說明。

對於 cri-dockerd，預設的 CRI socket 是 /run/cri-dockerd.sock。

Mirantis 容器執行階段

Mirantis 容器執行階段 (MCR) 是一種商用的容器執行階段，其前身為 Docker Enterprise Edition。

您可以透過 MCR 內建的開源 cri-dockerd 組件，將 Mirantis 容器執行階段搭配 Kubernetes 使用。

要進一步了解如何安裝 Mirantis 容器執行階段，請訪問 MCR 部署指南。

檢查名為 cri-docker.socket 的 systemd 單元，以找出 CRI socket 的路徑。

覆寫沙盒（pause）映像檔

cri-dockerd 轉接器接受一個命令列參數，用於指定要使用哪個容器映像檔作為 Pod 的基礎設施容器（"pause 映像檔"）。 要使用的命令列參數為 --pod-infra-container-image。

接下來

除了容器執行階段外，您的叢集還需要一個可用的網路外掛程式。

4 - 最佳實務

4.1 - 大型叢集的考量事項

叢集是由一組執行 Kubernetes 代理程式的節點 （實體機器或虛擬機器）所組成，並由控制平面進行管理。 Kubernetes v1.35 支援最多 5,000 個節點的叢集。 更具體來說，Kubernetes 的設計可支援符合以下所有準則的配置：

• 每個節點不超過 110 個 Pod
• 不超過 5,000 個節點
• Pod 總數不超過 150,000
• 容器總數不超過 300,000

您可以透過新增或移除節點來調整叢集規模。具體作法取決於叢集的部署方式。

雲端供應商資源配額

為了避免碰到雲端供應商的配額問題，在建立多個節點的叢集時，建議考量：

• 申請提高雲端資源的配額，例如：
  • 運算執行個體
  • CPU
  • 儲存卷
  • 使用中的 IP 位址
  • 封包過濾規則
  • 負載平衡器的數量
  • 子網路
  • 日誌串流
• 控制叢集的擴展流程，分批啟動新節點，並在各批之間加入間隔， 因為部分雲端供應商會限制新執行個體的建立速率。

控制平面組件

對於大型叢集，您需要一個具備足夠運算及其他資源的控制平面。

通常您會在每個故障區執行一到兩個控制平面執行個體，並優先對這些執行個體進行垂直擴展； 直到垂直擴展達到邊際效益遞減的臨界點後，再進行水平擴展。

您應該在每個故障區執行至少一個執行個體來提供容錯能力。 Kubernetes 節點不會自動將流量導向位於相同故障區的控制平面端點；然而， 您的雲端供應商可能有其獨有的機制來做到這一點。

例如，使用託管的負載平衡器時， 您可以設定此負載平衡器將源於故障區 A 的 kubelet 與 Pod 流量僅導向同樣位於故障區 A 的控制平面主機。 如果故障區 A 內的單一控制平面主機或端點離線，這意味著 A 區節點的所有控制平面流量現在都將改為跨區傳輸。 在每個區域中執行多個控制平面主機可以降低發生這種情況的可能性。

etcd 儲存

為了提升大型叢集的效能，您可以將 Event 物件儲存於一個獨立且專屬的 etcd 執行個體中。

您可以使用自訂工具，在建立叢集時：

• 啟動並設定額外的 etcd 執行個體
• 設定 API 伺服器將 Event 儲存在該執行個體中

請參閱針對 Kubernetes 維運 etcd 叢集 與使用 kubeadm 架設高可用性 etcd 叢集， 以了解為大型叢集設定與管理 etcd 的詳細資訊。

附加元件資源

Kubernetes 資源限制有助於將記憶體洩漏， 以及 Pod 與容器對其他組件的影響降至最低。 這些資源限制同樣適用於附加元件的資源， 也適用於應用程式工作負載。

例如，您可以為日誌組件設定 CPU 與記憶體限制：

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

附加元件的預設限制，通常是基於在小型或中型 Kubernetes 叢集上執行各個附加元件的經驗所蒐集的資料。 當在大型叢集上執行時，某些資源的使用量可能會超過預設限制。若在部署大型叢集時未調整這些數值， 附加元件可能會因為不斷觸及記憶體限制而反覆被終止；或者，附加元件雖能維持執行， 但會受 CPU 時間切片限制影響而效能低落。

為了避免遇到叢集附加元件的資源問題，在建立包含多個節點的叢集時，建議考量以下事項：

• 部分附加元件採垂直擴展 — 整個叢集或每個故障區僅執行一個附加元件副本。 對於此類附加元件，當您擴展叢集規模時，請增加其資源請求與限制。
• 許多附加元件採水平擴展 — 透過增加 Pod 數量來提升容量；但在超大型叢集中，您可能仍需稍微提高 CPU 或記憶體限制。 Vertical Pod Autoscaler 可以以recommender 模式執行，以提供資源請求與限制的建議值。
• 部分附加元件以每個節點一個副本的方式執行，並由 DaemonSet 進行控制： 例如節點級別的日誌聚合器。與水平擴展的附加元件類似，您可能也需要稍微調高 CPU 或記憶體限制。

優先處理叢集關鍵組件

為了確保叢集的必要組件（例如 CoreDNS、metrics-server 與其他關鍵附加元件）優先於其他工作負載進行排程，且不會被較低優先權的 Pod 搶佔， 請使用系統的 PriorityClass 來設定這些組件的優先順序， 例如 system-cluster-critical 或 system-node-critical。

接下來

• VerticalPodAutoscaler 是一個您可以部署到叢集中的自訂資源，用來協助您管理 Pod 的資源請求與限制。 請參閱 Vertical Pod Autoscaler 以了解更多資訊， 並學習如何使用它來調整叢集組件的規模，包括叢集關鍵的附加元件。

• 請參閱節點自動擴展

• addon resizer 可協助您隨著叢集規模的變化， 自動調整附加元件的資源配置。

4.2 - 跨區域執行

本頁面說明如何跨多個區域執行 Kubernetes。

背景

Kubernetes 的設計使單一叢集能夠跨多個故障區（Failure Zone）執行； 這些故障區通常隸屬於一個稱為**「地區」（Region）的邏輯分組。主要的雲端供應商將地區定義為一組故障區，亦稱為可用區（Availability Zone）**， 並提供一致的功能：在同一個地區內，各故障區提供相同的 API 與服務。

典型的雲端架構旨在將單一故障區故障對其他故障區服務的影響降至最低。

控制平面行為

所有控制平面組件都支援以可互換資源池的方式執行， 並為各個組件建立多個副本

當您部署叢集控制平面時，需將控制平面組件的副本分散部署於多個故障區。 若高可用性是重要考量，應選擇至少三個故障區，並為各個控制平面組件（API 伺服器、排程器、etcd、叢集控制器管理器）建立多個副本，分散部署於這些故障區中。 若有使用雲端控制器管理器，也應將它複製到您所選擇的所有故障區中。

節點行為

Kubernetes 會自動將工作負載資源 （例如 Deployment 或 StatefulSet） 的 Pod 分散部署於叢集中的不同節點。這種分散部署有助於降低故障造成的影響。

當節點啟動時，每個節點上的 kubelet 會自動在 Kubernetes API 中代表此特定節點的 Node 物件加上標籤。 這些標籤可以包含區域資訊。

如果您的叢集跨越多個故障區或地區，您可以結合使用節點標籤與 Pod 拓撲散佈限制， 來控制 Pod 在叢集中的各個故障域（地區、故障區，甚至特定節點）之間的分佈方式。 這些提示可讓排程器將 Pod 排程到更有利於可用性的位置， 從而降低相關故障影響整個工作負載的風險。

例如，您可以設定一項限制：確保在可行的情況下，一個 StatefulSet 的 3 個副本分別執行於不同的故障區 您可以透過宣告式的方式來定義此限制，不需要為每個工作負載明確指定使用哪些可用區。

跨區域分散節點

Kubernetes 核心本身不會為您建立節點；您需要自行建立， 或使用像是 Cluster API 的工具來代為管理節點。

透過使用 Cluster API 等工具，您可以定義一組機器，將其分散在多個故障域中作為叢集的工作節點執行， 並定義規則，在發生整個區域的服務中斷時自動修復叢集。

手動為 Pod 指定區域

您可以套用節點選擇器限制到您建立的 Pod， 以及 Deployment、StatefulSet 或 Job 等工作負載資源中的 Pod 模板。

區域的儲存存取

當建立持久卷時，Kubernetes 會自動為連結至特定故障區的 PersistentVolume 加上區域標籤。 接著排程器會透過 NoVolumeZoneConflict 預選規則， 確保使用該 PersistentVolume 的 Pod 只會被排程到與該卷相同的故障區。

請注意到區域標籤的新增方式可能取決於您使用的雲端供應商與儲存佈建器。 請務必參考適用於您環境的特定文件，確保配置正確。

您可以為 PersistentVolumeClaims 指定一個StorageClass， 用來指定該類別中的儲存空間可以使用的故障域（區域）。 要了解配置能夠感知到故障域或區域的 StorageClass，請參閱允許的拓撲。

網路

Kubernetes 本身並不包含故障區感知的網路功能。 您可以使用網路外掛來配置叢集網路， 而選用的網路解決方案可能包含與特定故障區相關的設定。例如，如果您的雲端供應商支援 type=LoadBalancer 的 Service， 負載平衡器可能只會將流量傳送至與處理此連線的負載平衡器位於相同區域的 Pod。請查看您的雲端供應商文件以瞭解詳情。

對於自訂或本地端部署，類似的考量同樣適用。 Service 與 Ingress 的行為，包含對不同故障區的處理方式， 會根據您叢集的實際部署方式而有所不同。

故障復原

當您架設叢集時，還需要考慮：若某個地區內的所有故障區同時離線，您的架構是否能恢復服務，以及應如何恢復。 例如，是否仰賴某個故障區中至少有一個節點能夠執行 Pod？ 請確保任何叢集關鍵的修復工作，都不依賴叢集中至少有一個健康節點。例如：如果所有節點皆處於不健康狀態， 您可能需要執行一個帶有特殊 容許 的修復 Job， 使修復能順利完成，並讓至少一個節點恢復運作。

Kubernetes 並未提供此問題的解法；但在規劃時仍需納入考量。

接下來

若想了解排程器如何在叢集中依照設定的限制來排程 Pod， 請參閱排程與驅逐。

5 - 教學

本節收錄了 Kubernetes 的教學。 教學示範了如何完成一個比單一任務更大的目標。 通常一個教學會有幾個小節，每個小節都有一系列的步驟。 在閱讀每個教學之前，建議您將詞彙表頁面加入書籤，以便日後參考。

基礎

• Kubernetes 基礎是一個深入的互動式教學，幫助您了解 Kubernetes 系統並實際嘗試一些基本的 Kubernetes 功能。
• Kubernetes 簡介（edX）
• Hello Minikube

設定

• 使用 ConfigMap 設定 Redis

撰寫 Pod

• 採用 Sidecar 容器

無狀態應用程式

• 對外公開 IP 位址以存取叢集中的應用程式
• 範例：使用 Redis 部署 PHP 留言板應用程式

有狀態應用程式

• StatefulSet 基礎
• 範例：使用持久卷部署 WordPress 與 MySQL
• 範例：使用 StatefulSet 部署 Cassandra
• 執行 ZooKeeper（CP 分散式系統）

服務

• 使用 Service 連接應用程式
• 使用來源 IP

安全性

• 在叢集層級套用 Pod 安全標準
• 在命名空間層級套用 Pod 安全標準
• 使用 AppArmor 限制容器對資源的存取
• Seccomp

叢集管理

• 在 Kubernetes 節點上設定 Swap 記憶體
• 以獨立模式執行 Kubelet
• 使用 DRA 安裝驅動程式並配置裝置

接下來

如果您想撰寫教學，請參閱 內容頁面類型 以取得有關教學頁面類型的資訊。

5.1 - Hello Minikube

本教學示範如何使用 minikube 在 Kubernetes 上執行一個範例應用程式。 教學提供了一個使用 NGINX 回應所有請求的容器映像檔。

學習目標

• 將範例應用程式部署到 minikube。
• 執行應用程式。
• 查看應用程式日誌。

開始之前

本教學假設您已完成 minikube 的設定。 請參閱 minikube start 中的步驟 1 以取得安裝說明。

您還需要安裝 kubectl。 請參閱安裝工具以取得安裝說明。

建立 minikube 叢集

minikube start

確認 minikube 叢集狀態

確認 minikube 叢集的狀態，以確保所有元件都處於執行狀態。

minikube status

上述指令的輸出應顯示所有元件為 Running 或 Configured，如以下範例輸出所示：

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

開啟 Dashboard

開啟 Kubernetes Dashboard，您可以透過以下兩種方式進行：

• 啟動瀏覽器
• 複製貼上 URL

# Start a new terminal, and leave this running.
# 開啟新終端機，讓此指令持續執行。
minikube dashboard

# Start a new terminal, and leave this running.
# 開啟新終端機，讓此指令持續執行。
minikube dashboard --url

kubectl delete service hello-node
kubectl delete deployment hello-node

minikube stop

# Optional
minikube delete

5.2.1 - 使用 ConfigMap 設定 Redis

本頁提供了一個實際範例，說明如何使用 ConfigMap 設定 Redis，並延伸自設定 Pod 以使用 ConfigMap 任務。

學習目標

• 建立一個包含 Redis 設定值的 ConfigMap
• 建立一個掛載並使用該 ConfigMap 的 Redis Pod
• 驗證設定是否正確套用。

開始之前

您需要有一個 Kubernetes 叢集，且必須設定 kubectl 命令列工具使其能與叢集通訊。 建議在至少有兩個未擔任控制平面主機之節點的叢集上執行本教學。 如果您還沒有叢集，可以使用 Minikube 建立一個， 或使用以下其中一個 Kubernetes 練習環境：

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

若要確認版本，請輸入 kubectl version.

• 本頁範例需要 kubectl 1.14 或以上版本。
• 瞭解設定 Pod 以使用 ConfigMap。

實際範例：使用 ConfigMap 設定 Redis

請按照以下步驟，使用 ConfigMap 中的資料設定 Redis 快取。

首先，建立一個設定區塊為空的 ConfigMap：

cat <<EOF >./example-redis-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: ""
EOF

套用上述建立的 ConfigMap，以及 Redis Pod 的設定檔：

kubectl apply -f example-redis-config.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

查看 Redis Pod 設定檔的內容，並注意以下事項：

• spec.volumes[1] 建立了一個名為 config 的卷
• spec.volumes[1].configMap.items[0] 下的 key 與 path，將 example-redis-config ConfigMap 中的 redis-config 鍵，以名為 redis.conf 的檔案形式呈現在 config 卷中
• spec.containers[0].volumeMounts[1] 接著將 config 卷掛載至 /redis-master

結果會將 example-redis-config ConfigMap 中 data.redis-config 的資料，以 /redis-master/redis.conf 的形式於 Pod 內呈現。

pods/config/redis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis:8.0.2
    command:
      - redis-server
      - "/redis-master/redis.conf"
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf

查看已建立的物件：

kubectl get pod/redis configmap/example-redis-config

您應該會看到以下輸出：

NAME        READY   STATUS    RESTARTS   AGE
pod/redis   1/1     Running   0          8s

NAME                             DATA   AGE
configmap/example-redis-config   1      14s

回想一下，我們先前將 example-redis-config ConfigMap 中的 redis-config 鍵留白：

kubectl describe configmap/example-redis-config

您應該會看到空的 redis-config 鍵：

Name:         example-redis-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
redis-config:

使用 kubectl exec 進入 Pod，並執行 redis-cli 工具以確認目前的設定：

kubectl exec -it pod/redis -- redis-cli

確認 maxmemory：

127.0.0.1:6379> CONFIG GET maxmemory

應顯示預設值 0：

1) "maxmemory"
2) "0"

同樣地，確認 maxmemory-policy：

127.0.0.1:6379> CONFIG GET maxmemory-policy

也應回傳其預設值 noeviction：

1) "maxmemory-policy"
2) "noeviction"

現在，讓我們在 example-redis-config ConfigMap 中新增一些設定值：

pods/config/example-redis-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: |
    maxmemory 2mb
    maxmemory-policy allkeys-lru    

套用更新後的 ConfigMap：

kubectl apply -f example-redis-config.yaml

確認 ConfigMap 已更新：

kubectl describe configmap/example-redis-config

您應該會看到剛才新增的設定值：

Name:         example-redis-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru

再次透過 kubectl exec 使用 redis-cli 確認 Redis Pod 是否已套用設定：

kubectl exec -it pod/redis -- redis-cli

確認 maxmemory：

127.0.0.1:6379> CONFIG GET maxmemory

它仍為在預設值 0：

1) "maxmemory"
2) "0"

同樣地，maxmemory-policy 仍維持 noeviction 的預設設定：

127.0.0.1:6379> CONFIG GET maxmemory-policy

回傳：

1) "maxmemory-policy"
2) "noeviction"

設定值沒有改變是因為 Pod 需要重新啟動才能取得相關 ConfigMap 更新後的值。讓我們刪除 Pod 並重新建立：

kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

最後再次確認設定值：

kubectl exec -it pod/redis -- redis-cli

確認 maxmemory：

127.0.0.1:6379> CONFIG GET maxmemory

現在應回傳更新後的值 2097152：

1) "maxmemory"
2) "2097152"

同樣地，maxmemory-policy 也已更新：

127.0.0.1:6379> CONFIG GET maxmemory-policy

現在已反映期望的值 allkeys-lru：

1) "maxmemory-policy"
2) "allkeys-lru"

刪除已建立的資源以清理環境：

kubectl delete pod/redis configmap/example-redis-config

接下來

• 深入瞭解 ConfigMap。
• 參考透過 ConfigMap 更新設定的範例。