Azure Kubernetes Service 的核心 Kubernetes 概念
應用程式開發會繼續進入以容器為基礎的方法，增加協調和管理資源的需求。 Kubernetes 是領先的平台，可提供容錯應用程式工作負載的可靠排程。 Azure Kubernetes Service (AKS) 是受控 Kubernetes 供應項目，可進一步簡化容器型應用程式的部署和管理。
本文將介紹核心概念：
Kubernetes 基礎結構元件：
- 控制平面
- 節點
- 節點集區
工作負載資源：
- Pod
- deployments (英文)
- 集合
使用「命名空間」來將資源分組。
什麼是 Kubernetes？
Kubernetes 是一個快速發展中的平台，可管理容器型應用程式及其相關聯的網路和儲存體元件。 Kubernetes 重視應用程式工作負載，而不是基礎結構元件。 Kubernetes 提供宣告式部署方法，並以一組完善的 API 管理作業，作為此部署方法的後盾。
您可以使用 Kubernetes 建置及執行現代化、可攜式微服務型應用程式，以協調和管理應用程式元件的可用性。 隨著小組採用以微服務為基礎的應用程式而獲得進展，Kubernetes 對於無狀態與具狀態的應用程式均提供支援。
Kubernetes 屬於開放式平台，可讓您使用慣用的程式設計語言、作業系統、程式庫或訊息匯流排來建置您的應用程式。 現有的持續整合與持續傳遞 (CI/CD) 工具可與 Kubernetes 整合，以排程及部署發行。
AKS 提供受控 Kubernetes 服務，以減少部署和核心管理工作的複雜性，例如升級協調。 Azure 平台會管理 AKS 控制平面，您只需支付用於執行應用程式的 AKS 節點費用。
Kubernetes 叢集架構
Kubernetes 叢集分成兩個元件：
- 控制平面: 提供核心 Kubernetes 服務和應用程式工作負載的協調流程。
- 節點：會執行您的應用程式工作負載。
控制平面
建立 AKS 叢集時，會自動建立和設定控制平面。 此控制平面會免費以受控 Azure 資源的形式提供，使用者無需加以管理。 您只需支付連結至 AKS 叢集的節點費用。 控制平面以及資源只位於您建立叢集的區域。
控制平面包含下列核心 Kubernetes 元件：
| 元件 | 描述 |
|---|---|
| kube-apiserver | API 伺服器是公開基礎 Kubernetes API 的方式。 此元件提供管理工具的互動，例如 kubectl 或 Kubernetes 儀表板。 |
| etcd | 擁有高可用性的 etcd 是 Kubernetes 中的金鑰值存放區，用以維護 Kubernetes 叢集和設定的狀態。 |
| kube-scheduler | 您建立或調整應用程式時，排程器會判斷哪些節點可執行工作負載，並加以啟動。 |
| kube-controller-manager | 控制器管理員會監看數個較小型的控制器，這類控制器會執行複寫 Pod 和處理節點作業之類的動作。 |
AKS 提供具有專用 API 伺服器、排程器等項目的單一租用戶控制平面。您會定義節點的數目和大小，而 Azure 平台會設定控制平面與節點之間的安全通訊。 與控制平面之間的互動可透過 Kubernetes API 進行，例如 kubectl 或 Kubernetes 儀表板。
雖然您不需要使用這個受控控制平面來設定元件 (例如高可用性 etcd 存放區)，但您無法直接存取控制平面。 Kubernetes 控制平面和節點升級是透過 Azure CLI 或 Azure 入口網站進行協調。 若要對可能的問題進行疑難排解，您可以透過 Azure 監視器記錄來檢閱控制平面記錄。
若要設定或直接存取控制平面，請使用叢集 API 提供者 Azure 部署自我管理 Kubernetes 叢集。
如需相關聯的最佳做法，請參閱 AKS 中叢集安全性和升級的最佳做法。
如需 AKS 成本管理資訊，請參閱 AKS 成本基本概念 (部分機器翻譯) 和 AKS 定價。
節點和節點集區
若要執行應用程式和支援的服務，您必須要有 Kubernetes 節點。 AKS 叢集中有至少一個節點，而此類節點是可執行 Kubernetes 節點元件和容器執行階段的 Azure 虛擬機器 (VM)。
| 元件 | 描述 |
|---|---|
kubelet |
Kubernetes 代理程式負責處理來自控制平面的協調流程要求，以及處理排程和執行要求的容器。 |
| kube-proxy | 處理每個節點上的虛擬網路。 Proxy 會路由傳送網路流量，並管理適用於服務與 Pod 的 IP 位址。 |
| 容器執行階段 | 可讓容器化應用程式執行其他資源 (例如，虛擬網路或儲存體) 並與其互動。 針對 Linux 節點集區使用 Kubernetes 1.19 版以上版本的 AKS 叢集會使用 containerd 作為其容器執行時間。 從 Windows節點集區的 Kubernetes 1.20 版開始，containerd 可用於容器執行時間的預覽版，但 Docker 仍為預設容器執行時間。 針對節點集區使用舊版 Kubernetes 的 AKS 叢集會使用 Docker 作為其容器執行時間。 |
節點的 Azure VM 大小會定義 CPU、記憶體、大小及可用的儲存體類型 (例如，高效能 SSD 或一般 HDD)。 規劃您的應用程式是否需要大量 CPU 和記憶體或高效能儲存體的節點大小。 在 AKS 叢集中擴大節點數目，以符合需求。 如需有關擴縮的詳細資訊，請參閱在 AKS 中擴縮應用程式的選項 (部分機器翻譯)。
在 AKS 中，叢集節點的 VM 映像是以 Ubuntu Linux、Azure Linux 或 Windows Server 2019 為基礎。 您建立 AKS 叢集或擴增節點數目時，Azure 平台即會自動建立並設定所要求的 VM 數目。 代理程式節點會以標準 VM 計費，因此會自動套用任何 VM 大小折扣 (包括 Azure 保留)。
對於受控磁碟，系統會根據選取的 VM SKU 和 vCPU 計數來指派預設磁碟大小和效能。 如需詳細資訊，請參閱預設 OS 磁碟大小調整。
如果您需要 Kubernetes 節點容器執行時間和作業系統上的進階設定和控制，您可以使用叢集 API 提供者 Azure 來部署自我管理叢集。
資源保留
AKS 會使用節點資源來協助節點作為叢集的一部分運作。 此使用量可能會讓節點的總資源與 AKS 中可配置的資源不一致。 設定使用者部署 Pod 的要求和限制時，請記住這項資訊。
若要尋找節點的可配置資源，請執行：
kubectl describe node [NODE_NAME]
為了維持節點的效能與功能，AKS 會在每個節點上保留資源： 節點在資源中成長較大時，資源保留會因為管理使用者部署 Pod 的需求較高而成長。
注意
使用 Container Insights (OMS) 之類的 AKS 附加元件會耗用額外的節點資源。
保留兩種類型的資源：
CPU
保留的 CPU 取決於節點類型和叢集設定，這可能會因為執行其他功能而造成較少可配置的 CPU。
| 主機上的 CPU 核心 | 1 | 2 | 4 | 8 | 16 | 32 | 64 |
|---|---|---|---|---|---|---|---|
| Kube 保留 (millicores) | 60 | 100 | 140 | 180 | 260 | 420 | 740 |
記憶體
AKS 所使用的記憶體包含兩個值的總和。
重要
AKS 1.29 預覽版將於 2024 年 1 月推出，其中包含對記憶體保留的特定變更。 下一節將詳述這些變更。
AKS 1.29 和更新版本
kubelet精靈預設具有 memory.available<100Mi 收回規則。 這確保節點隨時至少一律有 100Mi 可配置。 當主機低於該可用記憶體閾值時，kubelet會觸發其中一個執行中 Pod 的終止，並釋放主機電腦上的記憶體。記憶體保留率的設定會以下列項目的較小值為依據：「20MB * 節點上支援的最大 Pod 數 + 50MB」或「系統記憶體資源總數的 25%」。
範例：
- 如果 VM 提供 8GB 的記憶體，且節點最多支援 30 個 Pod，則 AKS 會針對 kube-reserved 保留「20MB * 30 個最大 Pod 數 + 50MB = 650MB」。
Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable. - 如果 VM 提供 4GB 的記憶體，且節點最多支援 70 個 Pod，則 AKS 會針對 kube-reserved 保留「25% * 4GB = 1000MB」，因為這小於「20MB * 70 個最大 Pod 數 + 50MB = 1450MB」。
如需詳細資訊，請參閱在 AKS 叢集中設定每個節點的最大 Pod 數。
- 如果 VM 提供 8GB 的記憶體，且節點最多支援 30 個 Pod，則 AKS 會針對 kube-reserved 保留「20MB * 30 個最大 Pod 數 + 50MB = 650MB」。
1.29 之前的 AKS 版本
kubelet精靈會安裝在所有 Kubernetes 代理程式節點上，以管理容器建立和終止。 根據預設，kubelet精靈在 AKS 上具有 memory.available<750Mi 收回規則，可確保節點隨時都必須至少一律有 750Mi 可配置。 主機低於該可用的記憶體閾值時，kubelet會觸發而終止其中一個執行中的 Pod，並在主機電腦上釋放記憶體。kubelet 精靈可正常運作的記憶體保留迴歸速率 (kube 保留)。
- 前 4GB 記憶體的 25%
- 後續 4GB 記憶體 (最多 8GB) 的 20%
- 後續 8GB 記憶體 (最多 16GB) 的 10%
- 後續 112GB 記憶體 (最多 128GB) 的 6%
- 任何 128GB 以上記憶體的 2%
注意
AKS 會在不屬於已計算記憶體的 Windows 節點中，為系統程序額外保留 2GB。
記憶體和 CPU 配置規則是設計來執行下列動作：
- 讓代理程式節點保持狀況良好，包括對叢集健全狀態至關重要的一些裝載系統 Pod。
- 導致節點報告的可配置記憶體和 CPU 少於其不屬於 Kubernetes 叢集一部分時所報告的可配置記憶體和 CPU。
以上保留的資源無法變更。
例如，如果節點提供 7 GB，這會報告 34% 的記憶體，但不包括 750Mi 硬式收回閾值。
0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved
除了 Kubernetes 本身的保留，基礎節點作業系統也會保留大量 CPU 和記憶體資源來維護作業系統功能。
如需相關聯的最佳做法，請參閱 AKS 中基本排程器功能的最佳做法。
節點集區
注意
Azure Linux 節點集區現已正式發行 (GA)。 若要了解優點和部署步驟，請參閱適用於 AKS 的 Azure Linux 容器主機簡介 (部分機器翻譯)。
相同設定的節點會一起分組到節點集區中。 Kubernetes 叢集包含至少一個節點集區。 初始數目的節點和大小會在建立 AKS 叢集時 (其會建立預設節點集區) 定義。 AKS 中這個預設節點集區包含用來執行代理程式節點的基礎 VM。
注意
若要確保叢集能夠可靠地運作，您應該在預設節點集區中執行至少兩 (2) 個節點。
您可以對預設節點集區調整或升級 AKS 叢集。 您可以選擇調整或升級特定節點集區。 進行升級作業時，執行中的容器會排程於節點集區中的其他節點上，直到所有節點皆成功升級。
如需如何在 AKS 中使用多個節點集區的詳細資訊，請參閱在 AKS 中建立叢集的多個節點集區 (部分機器翻譯)。
節點選取器
在具有多個節點集區的 AKS 叢集中，您可能需要告訴 Kubernetes 排程器要將節點集區用於指定的資源。 例如，輸入控制器不應該在 Windows 伺服器節點上執行。
節點選取器可讓您定義各種參數，例如節點作業系統，以控制應該排程 Pod 的位置。
下列基本範例會使用節點選取器 "kubernetes.io/os": linux 在 Linux 節點上排程 NGINX 執行個體：
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
nodeSelector:
"kubernetes.io/os": linux
如需如何控制 Pod 排程位置的詳細資訊，請參閱 AKS 中進階排程器功能的最佳做法。
節點資源群組
當您建立 AKS 叢集時，必須指定要在其中建立叢集資源的資源群組。 除了此資源群組之外，AKS 資源提供者也會建立和管理稱為節點資源群組的個別資源群組。 「節點資源群組」包含下列基礎結構資源：
- 節點集區中每個節點的虛擬機器擴展集和 VM
- 叢集的虛擬網路
- 叢集的儲存體
預設會為節點資源群組指派類似 MC_myResourceGroup_myAKSCluster_eastus 的名稱。 在叢集建立期間，您也可以指定要指派給節點資源群組的名稱。 當您刪除 AKS 叢集時，AKS 資源提供者就會自動刪除節點資源群組。
節點資源群組有下列限制：
- 您無法為節點資源群組指定現有的資源群組。
- 您無法為節點資源群組指定不同的訂用帳戶。
- 您無法在建立叢集之後，變更節點資源群組名稱。
- 您無法在節點資源群組內指定受控資源的名稱。
- 您無法在節點資源群組內修改或刪除 Azure 建立的受控資源標記。
如果您在節點資源群組中修改或刪除 Azure 建立的標記和其他資源屬性，可能就會得到非預期的結果，例如，擴縮和升級錯誤。 當 AKS 在節點資源群組中管理基礎結構的生命週期時，任何變更都會使您的叢集成為不支援的狀態 (部分機器翻譯)。
客戶想要修改資源的常見案例是透過標記。 AKS 可讓您建立和修改傳播至節點資源群組中資源的標記，而您可以在建立或更新叢集時新增那些標記。 例如，您可以建立或修改自訂標記，以指派業務單位或成本中心。 您也可以在受控資源群組上建立具有範圍的 Azure 原則，來達成此一目標。
在 AKS 叢集中的節點資源群組底下，修改資源上任何 Azure 建立的標記是不支援的動作，其會中斷服務層級目標 (SLO)。 如需詳細資訊，請參閱 AKS 是否提供服務等級協定？
若要降低節點資源群組中的變更影響叢集的機會，您可以啟用節點資源群組鎖定，將拒絕指派套用至 AKS 資源。 如需詳細資訊，請參閱 AKS 中的叢集設定 (部分機器翻譯)。
警告
如果您並未啟用節點資源群組鎖定，就可以直接修改節點資源群組中的任何資源。 直接修改節點資源群組中的資源，會導致叢集變得不穩定或沒有回應。
Pod
Kubernetes 會使用 Pod 來執行您應用程式的執行個體。 Pod 代表單一的應用程式執行個體。
Pod 通常與容器間有 1：1 的對應。 在進階情節中，Pod 可能包含多個容器。 多容器 Pod 的排程可於相同節點上同時安排，並允許容器共用相關資源。
建立 Pod 時，您能定義資源要求，以要求特定數量的 CPU 或記憶體資源。 Kubernetes 排程器會嘗試將 Pod 排程在具有可用資源的節點上執行，以符合要求。 您也可以指定資源上限，以防止 Pod 在基礎節點上耗用太多計算資源。 最佳做法是為所有 Pod 加上資源限制，以協助 Kubernetes 排程器識別必要且可供使用的資源。
如需詳細資訊，請參閱 Kubernetes Pod (英文) 和 Kubernetes Pod 生命週期 (英文)。
Pod 是邏輯資源，但容器是應用程式工作負載執行所在之處。 Pod 通常是暫時的可處置資源。 個別排程的 Pod 會錯過 Kubernetes 提供的一些高可用性和備援功能。 實際上，Pod 會由 Kubernetes「控制器」部署及管理，例如「部署控制器」。
部署和 YAML 資訊清單
「部署」代表由 Kubernetes 部署控制器管理的相同 Pod。 部署會定義要建立的 Pod「複本」數目。 Kubernetes 排程器則會確保若 Pod 或節點發生問題，仍然會在狀況良好的節點上排程其他 Pod。
您可以更新部署以變更 Pod 的設定、使用的容器映像，或連結的儲存體。 部署控制器：
- 清空並終止指定的複本數目。
- 從新的部署定義建立複本。
- 繼續此流程，直到部署中的所有複本都已更新為止。
AKS 中大多數的無狀態應用程式都應該使用部署模型，而不是排程個別的 Pod。 Kubernetes 可以監視部署健康情況和狀態，以確保會在叢集中執行所需的複本數目。 如果個別排程 Pod，Pod 在發生問題時並不會重新啟動，且在其目前節點發生問題時也不會重新排程於狀況良好的節點上。
如果您的應用程式需要最少的可用執行個體數目，您不會想要中斷管理決策與更新流程。 您可以使用「Pod 中斷預算」，定義在更新或節點升級期間可在部署中停止多少個複本。 例如，如果您的部署中有「五 (5)」個複本，您可以將 Pod 中斷定義為「4 (四)」，以僅允許每次刪除或重新排程一個複本。 與 Pod 資源限制相同，最佳做法是為需要有最少量複本持續存在的應用程式定義 Pod 中斷預算。
部署通常可透過 kubectl create 或 kubectl apply 來建立和管理。 藉由以 YAML 格式定義資訊清單檔來建立部署。
下列範例會建立 NGINX Web 伺服器的基本部署。 此部署會指定要建立「三 (3)」個複本，並要求開啟容器上的連接埠 80。 此外也會定義 CPU 和記憶體的資源要求和限制。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
ports:
- containerPort: 80
resources:
requests:
cpu: 250m
memory: 64Mi
limits:
cpu: 500m
memory: 256Mi
YAML 資訊清單檔中的部署規格明細如下：
| 規格 | 描述 |
|---|---|
.apiVersion |
指定建立資源時要使用的 API 群組和 API 資源。 |
.kind |
指定您想要建立的資源型別。 |
.metadata.name |
指定部署的名稱。 此檔案會從 Docker Hub 執行 nginx 映像。 |
.spec.replicas |
指定要建立的 Pod 數目。 此檔案將建立三個重複的 Pod。 |
.spec.selector |
指定哪些 Pod 會受到此部署的影響。 |
.spec.selector.matchLabels |
包含 {key, value} 組的對應，可讓部署尋找和管理建立的 Pod。 |
.spec.selector.matchLabels.app |
必須符合 .spec.template.metadata.labels。 |
.spec.template.labels |
指定附加至 物件的 {key, value}} 組。 |
.spec.template.app |
必須符合 .spec.selector.matchLabels。 |
.spec.spec.containers |
指定屬於 Pod 的容器清單。 |
.spec.spec.containers.name |
指定指定為 DNS 標籤的容器名稱。 |
.spec.spec.containers.image |
指定容器映像名稱。 |
.spec.spec.containers.ports |
指定要從容器公開的連接埠清單。 |
.spec.spec.containers.ports.containerPort |
指定要在 Pod 的 IP 位址上公開的連接埠數目。 |
.spec.spec.resources |
指定容器所需的計算資源。 |
.spec.spec.resources.requests |
指定所需的計算資源數量下限。 |
.spec.spec.resources.requests.cpu |
指定所需的 CPU 數量下限。 |
.spec.spec.resources.requests.memory |
指定所需的最小記憶體數量。 |
.spec.spec.resources.limits |
指定允許的計算資源數量上限。 kubelet 會強制執行此限制。 |
.spec.spec.resources.limits.cpu |
指定允許的最大 CPU 數量。 kubelet 會強制執行此限制。 |
.spec.spec.resources.limits.memory |
指定允許的記憶體數量上限。 kubelet 會強制執行此限制。 |
您可以在 YAML 資訊清單中納入負載平衡器之類的服務，以建立更複雜的應用程式。
如需詳細資訊，請參閱 Kubernetes 部署。
使用 Helm 管理套件
Helm 通常用來管理 Kubernetes 中的應用程式。 您可以建置和使用現有的公用 Helm 圖表，其中包含封裝版的應用程式程式碼，以及用來部署資源的 Kubernetes YAML 資訊清單。 您可以將 Helm 圖表儲存在本機，或儲存在遠端存放庫中，例如 Azure Container RegistryHelm 圖表存放庫。
若要使用 Helm，請在電腦上安裝 Helm 用戶端，或使用 Azure Cloud Shell 中的 Helm 用戶端。 搜尋或建立 Helm 圖表，然後將其安裝至 Kubernetes 叢集。 如需詳細資訊，請參閱在 AKS 中使用 Helm 安裝現有的應用程式。
StatefulSet 和 Daemonset
使用 Kubernetes 排程器，部署控制器會在任何有可用資源的可用節點上執行複本。 雖然此方法對無狀態應用程式而言可能就已足夠，但部署控制器不適合需要下列項目的應用程式：
- 持續性命名慣例或儲存體。
- 要存在於叢集內每個選取節點上的複本。
不過，兩項 Kubernetes 資源可讓您管理以下類型的應用程式：
- StatefulSet 跨個別 Pod 生命週期來維護應用程式的狀態。
- DaemonSet 在 Kubernetes 早期啟動程序時確定每個節點都有執行中的執行個體。
StatefulSet
新式應用程式開發通常的目標是無狀態應用程式。 針對具狀態應用程式，例如包含資料庫元件的具狀態應用程式，您可以使用 StatefulSet。 如同部署，StatefulSet 會建立和管理至少一個相同的 Pod。 StatefulSet 中的複本會依照正常、循序的方法進行部署、調整、升級和終止。 透過 StatefulSet，命名慣例、網路名稱和儲存體在複本重新排程後仍可持續保存。
使用 kind: StatefulSet 以 YAML 格式定義應用程式。 從其中，StatefulSet 控制器會處理所需複本的部署和管理。 資料會寫入至 Azure 受控磁碟或 Azure 檔案所提供的永續性儲存體。 透過 StatefulSet，即使在 StatefulSet 刪除後，基礎的永續性儲存體仍將保存。
如需詳細資訊，請參閱 Kubernetes StatefulSet (英文)。
StatefulSet 中的複本可在 AKS 叢集中任何可用的節點上排程及執行。 若要確定每個節點都至少要執行您集合中的一個 Pod，您可以改用 DaemonSet。
DaemonSet
針對特定的記錄收集或監視，您可能需要在所有節點或一組選取的節點上執行 Pod。 您可以使用 DaemonSet 部署至一或多個相同的 Pod。 DaemonSet 控制器可確保每個指定的節點都會執行 Pod 的執行個體。
DaemonSet 控制器可及早在叢集啟動程序執行時，在預設 Kubernetes 排程器啟動之前將 Pod 排程於節點上。 這項功能可確保 DaemonSet 中的 Pod 會在部署或 StatefulSet 中的傳統 Pod 排程之前啟動。
和 StatefulSet 相同，DaemonSet 也可使用 kind: DaemonSet 定義為 YAML 定義的一部分。
如需詳細資訊，請參閱 Kubernetes DaemonSet (英文)。
注意
如果使用虛擬節點附加元件，則 DaemonSets 將不會在虛擬節點上建立 Pod。
命名空間
Kubernetes 資源 (例如 Pod 和部署) 會以邏輯方式分組為「命名空間」，以分割 AKS 叢集，並建立、檢視或管理對資源的存取。 例如，您可以建立命名空間以區隔商務群組。 使用者只能與其指派的命名空間內包含的資源互動。
您在建立 AKS 叢集時，可以使用下列命名空間：
| Namespace | 描述 |
|---|---|
| 預設值 | 當未提供 Pod 和部署時，預設會建立 Pod 和部署的位置。 在較小的環境中，您可以直接將應用程式部署到預設命名空間中，而無須建立額外的邏輯分隔。 當您與 Kubernetes API 互動時 (例如 kubectl get pods)，若未指定命名空間，將會使用預設值。 |
| kube-system | 核心資源存在的位置，例如 DNS 和 Proxy 之類的網路功能，或 Kubernetes 儀表板。 您通常不會將自己的應用程式部署到此命名空間中。 |
| kube-public | 通常不會使用，但可用於要在整個叢集中顯示，並且可供任何使用者檢視的資源。 |
如需詳細資訊，請參閱 Kubernetes 命名空間 (英文)。
下一步
本文說明了部分核心 Kubernetes 元件，及其套用至 AKS 叢集的方式。 如需有關 Kubernetes 及 AKS 核心概念的詳細資訊，請參閱下列文章：
- AKS 存取和身分識別 (部分機器翻譯)
- AKS 安全性 (部分機器翻譯)
- AKS 虛擬網路 (部分機器翻譯)
- AKS 儲存體 (部分機器翻譯)
- AKS 調整 (部分機器翻譯)