適用於 Azure Kubernetes Service 的核心 Kubernetes 概念 （AKS）

本文說明 Azure Kubernetes Service （AKS）的核心概念，這是受控 Kubernetes 服務，可用來在 Azure 上大規模部署及操作容器化應用程式。 它可協助您瞭解 Kubernetes 的基礎結構元件，並深入瞭解 Kubernetes 在 AKS 中的運作方式。

什麼是 Kubernetes？

Kubernetes 是一個快速發展中的平台，可管理容器型應用程式及其相關聯的網路和儲存體元件。 Kubernetes 著重於應用程式工作負載，而不是基礎結構元件。 Kubernetes 提供宣告式部署方法，並以一組完善的 API 管理作業，作為此部署方法的後盾。

您可以使用 Kubernetes 建置及執行現代化、可攜式微服務型應用程式，以協調和管理應用程式元件的可用性。 Kubernetes 同時支援無狀態和具狀態應用程式。

Kubernetes 屬於開放式平台，可讓您使用慣用的程式設計語言、作業系統、程式庫或訊息匯流排來建置您的應用程式。 現有的持續整合與持續傳遞 (CI/CD) 工具可與 Kubernetes 整合，以排程及部署發行。

AKS 提供受控 Kubernetes 服務，可降低部署和核心管理工作的複雜性。 Azure 平台會管理 AKS 控制平面，您只需支付用於執行應用程式的 AKS 節點費用。

Kubernetes 叢集架構

Kubernetes 叢集分成兩個元件：

• 控制平面提供核心 Kubernetes 服務和應用程式工作負載的協調流程，且
• 執行應用程式工作負載的節點。

控制平面

當您建立 AKS 叢集時，Azure 平臺會自動建立並設定其相關聯的控制平面。 此單一租使用者控制平面免費提供，因為受控 Azure 資源是從使用者擷取而來。 您只需支付連結至 AKS 叢集的節點費用。 控制平面以及資源只位於您建立叢集的區域。

控制平面包含下列核心 Kubernetes 元件：

元件	描述
kube-apiserver	API 伺服器會公開基礎 Kubernetes API，並提供管理工具的互動，例如 kubectl 或 Kubernetes 儀錶板。
etcd	etcd 是 Kubernetes 內的高可用性索引鍵/值存放區，可協助維護 Kubernetes 叢集和設定的狀態。
kube-scheduler	當您建立或調整應用程式時，排程器會決定哪些節點可以執行工作負載，並啟動已識別的節點。
kube-controller-manager	控制器管理員會監督一些較小的控制器，這些控制器會執行複寫 Pod 和處理節點作業等動作。

請記住，您無法直接存取控制平面。 Kubernetes 控制平面和節點升級是透過 Azure CLI 或 Azure 入口網站進行協調。 若要針對可能的問題進行疑難解答，您可以使用 Azure 監視器來檢閱控制平面記錄。

節點

若要執行應用程式和支援的服務，您必須要有 Kubernetes 節點。 每個 AKS 叢集至少有一個節點、執行 Kubernetes 節點元件和容器運行時間的 Azure 虛擬機（VM）。

節點包含下列核心 Kubernetes 元件：

元件	描述
kubelet	Kubernetes 代理程式負責處理來自控制平面的協調流程要求，以及處理排程和執行要求的容器。
kube-proxy	Proxy 會處理每個節點上的虛擬網路、路由網路流量，以及管理服務和 Pod 的 IP 尋址。
容器執行階段	容器運行時間可讓容器化應用程式執行並與其他資源互動，例如虛擬網路或記憶體。 如需詳細資訊，請參閱 容器運行時間組態。

節點的 Azure VM 大小會定義 CPU、記憶體、大小和可用的記憶體類型，例如高效能 SSD 或一般 HDD。 規劃應用程式可能需要大量 CPU 和記憶體或高效能記憶體的節點大小。 在 AKS 叢集中擴大節點數目，以符合需求。 如需有關擴縮的詳細資訊，請參閱在 AKS 中擴縮應用程式的選項 (部分機器翻譯)。

在 AKS 中，叢集節點的 VM 映像是以 Ubuntu Linux、Azure Linux 或 Windows Server 2022 為基礎。 您建立 AKS 叢集或擴增節點數目時，Azure 平台即會自動建立並設定所要求的 VM 數目。 代理程序節點會以標準 VM 計費，因此會自動套用任何 VM 大小折扣，包括 Azure 保留。

針對受控磁碟，預設磁碟大小和效能會根據選取的 VM SKU 和 vCPU 計數來指派。 如需詳細資訊，請參閱預設 OS 磁碟大小調整。

OS 設定

AKS 支援 Ubuntu 22.04 和 Azure Linux 2.0 作為 Kubernetes 1.25 和更新版本的叢集節點作業系統 (OS)。 您也可以在 Kubernetes 1.24 版和以下版本的節點集區建立時指定 Ubuntu 18.04。

AKS 支援 Windows Server 2022 作為 Kubernetes 1.25 和更新版本叢集中 Windows 節點集區的預設 OS。 您也可以在 Kubernetes 1.32 版和以下版本的節點集區建立時指定 Windows Server 2019。 在 Kubernetes 1.32 版終止生命週期後，Windows Server 2019 即將淘汰，未來版本不支援。 如需關於這項淘汰的詳細資訊，請參閱 AKS 版本資訊。

容器執行階段設定

容器執行階段是在節點上執行容器和管理容器映像的軟體。 運行時間可協助抽象化 sys 呼叫或 OS 特定功能，以在 Linux 或 Windows 上執行容器。 針對 Linux 節點集區，containerd 用於 Kubernetes 1.19 版和更高版本。 針對 Windows Server 2019 和 2022 節點集區，containerd 已正式推出，而且是 Kubernetes 1.23 和更高版本中唯一的執行階段選項。 自 2023 年 5 月起，Docker 已淘汰，不再支援。 如需關於這項淘汰的詳細資訊，請參閱 AKS 版本資訊。

Containerd 是遵循 OCI (開放式容器方案) 的核心容器執行階段，可提供執行容器和管理節點上映像的最低必要功能集。 使用containerd以節點和節點集區為基礎的 kubelet 會直接 containerd 與使用 CRI （容器運行時間介面） 外掛程式進行交談，相較於 Docker CRI 實作，移除數據流中額外的躍點。 因此，您會看到較佳的 Pod 啟動延遲，以及較少的資源 (CPU 和記憶體) 使用量。

Containerd 適用於 AKS 中 Kubernetes 的每個 GA 版本、從 v1.19 開始的每個 Kubernetes 版本，並支援所有 Kubernetes 和 AKS 功能。

containerd 限制/差異

• 針對 containerd，我們建議使用 crictl 作為 Docker CLI 的替代專案，以 針對 Kubernetes 節點上的 Pod、容器和容器映像進行疑難解答。 如需 的詳細資訊，請參閱一般使用方式和用戶端組態選項。crictl

  • Containerd 不提供 Docker CLI 的完整功能。 僅提供給疑難排解。
  • crictl 提供更適合 Kubernetes 的容器檢視，其中包含 Pod 等概念。

• Containerd 使用標準化 cri 記錄格式設定記錄。 您的記錄解決方案需要支持記錄格式，例如適用於容器的 cri Azure 監視器。

• 您無法再存取 Docker 引擎， /var/run/docker.sock或使用 Docker-in-Docker （DinD）。

  • 如果您目前從 Docker 引擎擷取應用程式記錄或監視數據，請改用 Container Insights 。 AKS 不支援在可能導致不穩定的代理程式節點上執行任何頻外命令。
  • 我們不建議您建置映射，或直接使用 Docker 引擎。 例如，Kubernetes 不會完全掌握這些耗用的資源，而且這些方式會產生這裡和這裡描述的問題。

• 建置映射時，除非您在 AKS 叢集內建置映射，否則您可以繼續使用目前的 Docker 建置工作流程。 在此情況下，請考慮切換為使用 ACR 工作建置映像的建議方法，或使用 docker buildx 之類更安全的叢集內選項。

資源保留

AKS 會使用節點資源來協助節點作為叢集的一部分運作。 此使用量可能會讓節點的總資源與 AKS 中可配置的資源不一致。 設定使用者部署 Pod 的要求和限制時，請記住這項資訊。

若要尋找節點的allocatable資源，您可以使用 kubectl describe node 命令：

kubectl describe node [NODE_NAME]

為了維護節點效能和功能，AKS 會在每個節點上保留兩種類型的資源，即 CPU 和記憶體。 節點在資源中成長較大時，資源保留會因為管理使用者部署 Pod 的需求較高而成長。 請記住，無法變更資源保留。

CPU

保留的CPU取決於節點類型和叢集組態，這可能會因為執行額外的功能而造成較少的可配置CPU。 下表顯示 millicores 中的 CPU 保留：

主機上的 CPU 核心	1	2	4	8	16	32	64
Kube 保留 (millicores)	60	100	140	180	260	420	740

記憶體

AKS 中的保留記憶體包含兩個值的總和：

AKS 1.29 和更新版本

1. kubelet 精靈預設具有 memory.available<100Mi 收回規則。 此規則可確保節點隨時至少有 100Mi allocatable。 當主機低於該可用記憶體閾值時，kubelet 會觸發其中一個執行中 Pod 的終止，並釋放主機電腦上的記憶體。

2. 記憶體保留率的設定會以下列項目的較小值為依據：「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 數。

1.29 之前的 AKS 版本

1. kubelet 精靈 預設具有 memory.available<750Mi 收回規則。 此規則可確保節點隨時至少有 750Mi 可設定。 當主機低於該可用的記憶體閾值時，會 kubelet 觸發其中一個執行中的 Pod 終止，並在主電腦上釋放記憶體。
2. kubelet 精靈可正常運作的記憶體保留迴歸速率 (kube 保留)。
   • 前 4GB 記憶體的 25%
   • 後續 4GB 記憶體 (最多 8GB) 的 20%
   • 後續 8GB 記憶體 (最多 16GB) 的 10%
   • 後續 112GB 記憶體 (最多 128GB) 的 6%
   • 2% 的記憶體超過 128 GB

記憶體和 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 中基本排程器功能的最佳做法。

節點集區

相同設定的節點會一起分組到節點集區中。 每個 Kubernetes 叢集至少包含一個節點集區。 當您建立 AKS 叢集時，您可以定義初始節點數目和大小，以建立 預設節點集區。 AKS 中這個預設節點集區包含用來執行代理程式節點的基礎 VM。

您可以對預設節點集區調整或升級 AKS 叢集。 您可以選擇調整或升級特定節點集區。 進行升級作業時，執行中的容器會排程於節點集區中的其他節點上，直到所有節點皆成功升級。

如需詳細資訊，請參閱 建立節點集 區和 管理節點集區。

預設 OS 磁碟大小調整

當您建立新的叢集或將新的節點集區新增至現有的叢集時，vCPU 依預設會決定 OS 磁碟大小。 vCPU 數目是以 VM SKU 為基礎。 下表列出每個 VM SKU 的預設 OS 磁碟大小：

VM SKU Cores (vCPU)	預設 OS 磁碟層	佈建的 IOPS	佈建的輸送量 (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

節點選取器

在具有多個節點集區的 AKS 叢集中，您可能需要告訴 Kubernetes 排程器要用於指定資源的節點集區。 例如，輸入控制器不應該在 Windows 伺服器節點上執行。 您可以使用節點選取器來定義各種參數，例如節點OS，以控制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

如需詳細資訊，請參閱 AKS 中進階排程器功能的最佳做法。

節點資源群組

當您建立 AKS 叢集時，您會指定要在中建立叢集資源的 Azure 資源群組。 除了此資源群組之外，AKS 資源提供者也會建立和管理稱為 節點資源群組的個別資源群組。 「節點資源群組」包含下列基礎結構資源：

• 節點集區中每個節點的虛擬機器擴展集和 VM
• 叢集的虛擬網路
• 叢集的儲存體

節點資源群組預設會以下列格式指派名稱： MC_resourceGroupName_clusterName_location。 在叢集建立期間，您可以指定指派給節點資源群組的名稱。 使用 Azure Resource Manager 樣本時，您可以使用 屬性來定義名稱 nodeResourceGroup 。 使用 Azure CLI 時，您可以使用 --node-resource-group 參數搭配 az aks create 命令，如下列範例所示：

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

當您刪除 AKS 叢集時，AKS 資源提供者就會自動刪除節點資源群組。

節點資源群組有下列限制：

• 您無法為節點資源群組指定現有的資源群組。
• 您無法為節點資源群組指定不同的訂用帳戶。
• 您無法在建立叢集之後，變更節點資源群組名稱。
• 您無法在節點資源群組內指定受控資源的名稱。
• 您無法在節點資源群組內修改或刪除 Azure 建立的受控資源標記。

在 AKS 叢集中的節點資源群組底下，修改資源上任何 Azure 建立的標記是不支援的動作，其會中斷服務層級目標 (SLO)。 如果您在節點資源群組中修改或刪除 Azure 建立的標籤或其他資源屬性，您可能會收到非預期的結果，例如調整和升級錯誤。 AKS 會管理節點資源群組中的基礎結構生命週期，因此進行任何變更會將您的叢集移至 不支援的狀態。 如需詳細資訊，請參閱 AKS 是否提供服務等級協定？

AKS 可讓您建立和修改傳播至節點資源群組中資源的標記，而且您可以在建立或更新叢集時新增這些標籤。 例如，您可能想要建立或修改自定義標籤來指派業務單位或成本中心。 您也可以在受控資源群組上建立具有範圍的 Azure 原則。

若要減少影響叢集之節點資源群組變更的機會，您可以啟用 節點資源群組鎖定 ，將拒絕指派套用至 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 提供的一些高可用性和備援功能。 相反地，Kubernetes 控制器，例如部署控制器、部署和管理 Pod。

部署和 YAML 資訊清單

「部署」代表由 Kubernetes 部署控制器管理的相同 Pod。 部署會定義要建立的 Pod「複本」數目。 如果 Pod 或節點遇到問題，Kubernetes 排程器可確保在狀況良好的節點上排程額外的 Pod。 您可以更新部署來變更 Pod、容器映像或連結記憶體的組態。

部署控制站會管理部署生命週期，並執行下列動作：

• 清空並終止指定的複本數目。
• 從新的部署定義建立複本。
• 繼續此流程，直到部署中的所有複本都已更新為止。

AKS 中大多數的無狀態應用程式都應該使用部署模型，而不是排程個別的 Pod。 Kubernetes 可以監視部署健康情況和狀態，以確保會在叢集中執行所需的複本數目。 個別排程時，如果 Pod 遇到問題，就不會重新啟動 Pod，如果目前的節點遇到問題，就不會在狀況良好的節點上重新排程。

如果您的應用程式需要最少的可用執行個體數目，您不會想要中斷管理決策與更新流程。 您可以使用「Pod 中斷預算」，定義在更新或節點升級期間可在部署中停止多少個複本。 例如，如果您的部署中有五個複本，您可以定義 4 個的 Pod 中斷，一次只能刪除或重新排程一個複本。 如同 Pod 資源限制，我們建議的最佳做法是針對需要一律存在最少複本數目的應用程式定義 Pod 中斷預算。

部署通常可透過 kubectl create 或 kubectl apply 來建立和管理。 您可以藉由以 YAML 格式定義指令清單檔案來建立部署。 下列範例顯示 NGINX Web 伺服器的基本部署指令清單檔：

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	指定部署的名稱。 此範例 YAML 檔案會 從 Docker Hub 執行 nginx 映射。
.spec.replicas	指定要建立的 Pod 數目。 此範例 YAML 檔案會建立三個重複的 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 資源可讓您管理這些類型的應用程式： StatefulSets 和 DaemonSets。

StatefulSet 跨個別 Pod 生命週期來維護應用程式的狀態。 DaemonSet 可確保 Kubernetes 啟動程式程式早期在每個節點上執行中的實例。

StatefulSet

新式應用程式開發通常的目標是無狀態應用程式。 針對具狀態應用程式，例如包含資料庫元件的具狀態應用程式，您可以使用 StatefulSet。 如同部署，StatefulSet 會建立和管理至少一個相同的 Pod。 StatefulSet 中的複本遵循部署、調整、升級和終止作業的正常、循序方法。 透過 StatefulSet，命名慣例、網路名稱和儲存體在複本重新排程後仍可持續保存。

您可以使用 ，以 kind: StatefulSetYAML 格式定義應用程式。 從其中，StatefulSet 控制器會處理所需複本的部署和管理。 數據寫入永續性記憶體，由 Azure 受控磁碟 或 Azure 檔案儲存體 提供。 透過 StatefulSet，即使在 StatefulSet 刪除後，基礎的永續性儲存體仍將保存。

如需詳細資訊，請參閱 Kubernetes StatefulSet (英文)。

DaemonSet

針對特定記錄收集或監視，您可能需要在所有節點上或選取的節點集上執行 Pod。 您可以使用 DaemonSet 部署至一或多個相同的 Pod。 DaemonSet 控制器可確保每個指定的節點都會執行 Pod 的執行個體。

DaemonSet 控制器可以在叢集開機程式初期排程節點上的 Pod，然後再啟動預設 Kubernetes 排程器。 這項功能可確保在部署或 StatefulSet 中的傳統 Pod 排程之前，處於 DaemonSet 狀態的 Pod。

如同 StatefulSets，您可以使用 將 DaemonSet 定義為 YAML 定義的 kind: DaemonSet一部分。

如需詳細資訊，請參閱 Kubernetes DaemonSet (英文)。

命名空間

Kubernetes 資源，例如 Pod 和部署，會以邏輯方式分組為 命名空間 ，以分割 AKS 叢集並建立、檢視或管理資源的存取權。 例如，您可以建立命名空間以區隔商務群組。 使用者只能與其指派的命名空間內包含的資源互動。

當您建立 AKS 叢集時，可以使用下列命名空間：

Namespace	描述
預設值	當未提供 Pod 和部署時，預設會建立 Pod 和部署的位置。 在較小的環境中，您可以直接將應用程式部署到預設命名空間中，而無須建立額外的邏輯分隔。 當您與 Kubernetes API 互動時 (例如 kubectl get pods)，若未指定命名空間，將會使用預設值。
kube-system	核心資源存在的位置，例如 DNS 和 Proxy 之類的網路功能，或 Kubernetes 儀表板。 您通常不會將自己的應用程式部署到此命名空間中。
kube-public	通常未使用，您可以將它用於整個叢集上可見的資源，而且可由任何用戶檢視。

如需詳細資訊，請參閱 Kubernetes 命名空間 (英文)。

下一步

如需有關 Kubernetes 及 AKS 核心概念的詳細資訊，請參閱下列文章：

• AKS 存取和身分識別 (部分機器翻譯)
• AKS 安全性 (部分機器翻譯)
• AKS 虛擬網路 (部分機器翻譯)
• AKS 儲存體 (部分機器翻譯)
• AKS 調整 (部分機器翻譯)