文件

• 1: 詞彙表
• 2: Kubernetes 文件
• 2.1: 可用的文件版本
• 3: 最佳實務
• 3.1: 大型叢集的考量事項
• 3.2: 跨區域執行
• 4: 教學
• 4.1: Hello Minikube
• 4.2: 學習 Kubernetes 基礎
• 4.3: 配置
• 4.3.1: 使用 ConfigMap 設定 Redis

1 - 詞彙表

2 - Kubernetes 文件

2.1 - 可用的文件版本

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

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

3 - 最佳實務

3.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 可協助您隨著叢集規模的變化， 自動調整附加元件的資源配置。

3.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， 請參閱排程與驅逐。

4 - 教學

本節收錄了 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 安裝驅動程式並配置裝置

接下來

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

4.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

4.2 - 學習 Kubernetes 基礎

學習目標

本教學將帶您逐步了解 Kubernetes 叢集編排系統的基礎。 每個模組都包含 Kubernetes 主要功能和概念的背景介紹，以及可供您逐步操作的教學。

透過這些教學，您將學會：

• 在叢集上部署容器化應用程式。
• 擴展 Deployment。
• 將容器化應用程式更新至新的軟體版本。
• 為容器化應用程式除錯。

Kubernetes 能為您做什麼？

在現代 Web 服務中，使用者期望應用程式能夠全天候運作，而開發人員則期望每天能多次部署新版本。 容器化技術有助於封裝軟體以達成這些目標，讓應用程式能夠在不停機的情況下發佈與更新。 Kubernetes 可確保容器化應用程式依照您的需求在指定的位置與時機運行，並協助取得運作所需的資源與相關工具。 Kubernetes 是一個可用於正式環境的開源平台，結合了 Google 在容器編排方面累積的豐富經驗，以及來自社群的最佳實踐。

Kubernetes 基礎模組

1. 建立 Kubernetes 叢集

2. 部署應用程式

3. 探索應用程式

4. 公開應用程式

5. 擴展應用程式規模

6. 更新應用程式

接下來

• 請參閱學習環境頁面，以深入了解練習用叢集，以及如何自行建立叢集。
• 教學：使用 Minikube 建立叢集

4.3.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 更新設定的範例。