關於 Azure Kubernetes Service 的常見問題 (AKS)

本文說明關於 Azure Kubernetes Service (AKS) 的常見問題。

哪些 Azure 區域目前提供 AKS?

如需可用區域的完整清單,請參閱 AKS 區域和可用性

我可以跨區域分散 AKS 叢集嗎?

否。 AKS 叢集是區域資源,無法跨越區域。 如需如何建立包含多個區域的架構的指引,請參閱 商務持續性和災害復原 的最佳做法。

我可以將 AKS 叢集分散到可用性區域嗎?

是。 您可以在支援 AKS 的區域中,跨一或多個可用性區域部署 AKS 叢集。

我可以限制可存取 Kubernetes API 伺服器的人員嗎?

是。 有兩個選項可用來限制對 API 伺服器的存取:

我可以在單一叢集中有不同的 VM 大小嗎?

是,您可以藉由建立 多個節點集區,在 AKS 叢集中使用不同的虛擬機大小。

安全性更新是否套用至 AKS 代理程序節點?

AKS 修補每周有「廠商修正」的 CVE。 沒有修正的 CVE 正在等候「廠商修正」,才能補救。 AKS 映像會在30天內自動更新。 建議您定期套用更新的節點映像,以確保已套用最新的已修補映像和 OS 修補程式和目前版本。 您可以使用下列其中一種方法來執行這項操作:

AKS 中容器映像的大小限制為何?

AKS 不會設定容器映像大小的限制。 不過,請務必瞭解映射越大,記憶體需求就越高。 較大的大小可能會超過資源限制或背景工作節點的整體可用記憶體。 根據預設,AKS 叢集的 VM 大小Standard_DS2_v2記憶體會設定為 7 GiB。

當容器映像太大時,如同 TB (TBs) 範圍一樣,kubelet 可能無法從容器登錄提取到節點,因為磁碟空間不足。

Windows Server 節點

針對 Windows Server 節點,Windows Update 不會自動執行並套用最新的更新。 在 Windows Update 發行週期和您自己的驗證程式周圍定期排程,您應該在 AKS 叢集中的叢集和 Windows Server 節點集區上執行升級。 此升級流程會建立執行最新 Windows Server 映像和修補檔的節點,然後移除舊版節點。 如需此程式的詳細資訊,請參閱 升級 AKS 中的節點集區。

我是否應該注意以 AKS 為目標的安全性威脅?

Microsoft 提供您可以採取的其他動作指引,透過適用於容器的 Microsoft Defender 等服務保護您的工作負載。 下列安全性威脅與您應該注意的 AKS 和 Kubernetes 相關:

受控控制平面如何與節點通訊?

AKS 會使用安全通道通訊,讓 api-server 和個別節點 Kubelets 即使在個別的虛擬網路上通訊也一併通訊。 通道會透過 mTLS 加密來保護。 AKS 所使用的目前主要通道是 Konnectivity,先前稱為 apiserver-network-proxy。 確認所有網路規則都 遵循 Azure 所需的網路規則和 FQDN

我的 Pod 可以使用 API 伺服器 FQDN 而不是叢集 IP 嗎?

是,您可以將批註 kubernetes.azure.com/set-kube-service-host-fqdn 新增至 Pod,將變數設定 KUBERNETES_SERVICE_HOST 為 API 伺服器的功能變數名稱,而不是叢集內服務 IP。 如果您的叢集輸出是透過第7層防火牆完成,例如搭配應用程式規則使用 Azure 防火牆時,這非常有用。

為何使用 AKS 建立兩個資源群組?

AKS 是以許多 Azure 基礎結構資源為基礎,包括 虛擬機器擴展集、虛擬網路和受控磁碟。 這些整合可讓您在 AKS 提供的受控 Kubernetes 環境中套用 Azure 平台的許多核心功能。 例如,大部分的 Azure 虛擬機類型可以直接與 AKS 搭配使用,而 Azure 保留可用來自動接收這些資源的折扣。

若要啟用此架構,每個 AKS 部署都會跨越兩個資源群組:

  1. 您會建立第一個資源群組。 此群組只包含 Kubernetes 服務資源。 AKS 資源提供者會在部署期間自動建立第二個資源群組。 第二個資源群組的範例是 MC_myResourceGroup_myAKSCluster_eastus。 如需如何指定第二個資源群組名稱的資訊,請參閱下一節。

  2. 第二個 資源群組稱為節點資源群組,包含與叢集相關聯的所有基礎結構資源。 這些資源包括 Kubernetes 節點 VM、虛擬網路和記憶體。 根據預設,節點資源群組的名稱類似 MC_myResourceGroup_myAKSCluster_eastus。 每當刪除叢集時,AKS 會自動刪除節點資源群組。 您應該只將此叢集用於共用叢集生命週期的資源。

    注意

    修改 AKS 叢集中節點資源群組下的任何資源是不支援的動作,而且會導致叢集作業失敗。 您可以封鎖使用者修改 AKS 叢集所管理的資源,以防止對節點資源群組進行變更。

我可以為 AKS 節點資源群組提供我自己的名稱嗎?

是。 根據預設,AKS 會將節點資源群組 命名為MC_resourcegroupname_clustername_location,但您也可以提供您自己的名稱。

若要指定您自己的資源組名,請安裝 aks-preview Azure CLI 擴充功能 0.3.2 版或更新版本。 當您使用 az aks create 命令建立 AKS 叢集時,請使用 --node-resource-group 參數並指定資源群組的名稱。 如果您使用 Azure Resource Manager 範本來部署 AKS 叢集,您可以使用 nodeResourceGroup 屬性來定義資源組名

  • Azure 資源提供者會自動建立次要資源群組。
  • 您只能在建立叢集時指定自訂資源組名。

當您使用節點資源群組時,請記住,您無法:

  • 指定節點資源群組的現有資源群組。
  • 為節點資源群組指定不同的訂用帳戶。
  • 在建立叢集之後變更節點資源組名。
  • 指定節點資源群組內受控資源的名稱。
  • 修改或刪除節點資源群組內受控資源的 Azure 建立標籤。 請參閱下一節中的其他資訊。

我可以修改節點資源群組中 AKS 資源的標記和其他屬性嗎?

如果您在節點資源群組中修改或刪除 Azure 建立的標籤和其他資源屬性,可能會發生非預期的調整和升級錯誤。 AKS 可讓您建立和修改使用者所建立的自定義標籤,而且您可以在建立節點集區時新增這些標籤。 例如,您可能想要建立或修改自定義標籤,以指派業務單位或成本中心。 另一個選項是在受控資源群組上建立具有範圍的 Azure 原則。

針對其各自的 Azure 服務建立 Azure 建立標籤,應該一律允許。 針對 AKS,有 aks-managedk8s-azure 標籤。 修改 AKS 叢集中節點資源群組下資源上任何 Azure 建立的標籤 是不支援的動作,這會中斷服務層級目標 (SLO)。 如需詳細資訊,請參閱 AKS 是否提供服務等級協定?

注意

過去,標記名稱「擁有者」已保留給AKS,以管理負載平衡器前端IP上指派的公用IP。 現在,服務會遵循使用 aks-managed 前置詞。 針對舊版資源,請勿使用 Azure 原則來套用「擁有者」標籤名稱。 否則,AKS 叢集部署和更新作業上的所有資源都會中斷。 這不適用於新建立的資源。

AKS 支援哪些 Kubernetes 許可控制器? 可以新增或移除許可控制器嗎?

AKS 支援下列 許可控制器

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultIngressClass
  • Default 儲存體 Class
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

目前,您無法修改 AKS 中的許可控制器清單。

我可以在 AKS 上使用許可控制器 Webhook 嗎?

是,您可以在 AKS 上使用許可控制器 Webhook。 建議您排除使用控制平面標籤標示 的內部 AKS 命名空間。 例如:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS 防火牆 API 伺服器輸出,因此您的許可控制器 Webhook 必須可從叢集記憶體取。

許可控制器 Webhook 會影響 kube-system 和內部 AKS 命名空間嗎?

為了保護系統的穩定性,並防止自定義許可控制器影響 kube-system 中的內部服務,命名空間 AKS 具有 許可強制執行程式,這會自動排除 kube-system 和 AKS 內部命名空間。 此服務可確保自定義許可控制器不會影響在 kube-system 中執行的服務。

如果您有在 kube-system 上部署某些專案的重要使用案例,以支援您的自定義許可 Webhook,您可以新增下列卷標或批註,讓許可強制執行程式忽略它。

標籤: "admissions.enforcer/disabled": "true" 或註釋: "admissions.enforcer/disabled": true

Azure 金鑰保存庫 是否與 AKS 整合?

Azure 金鑰保存庫 Secrets Store CSI Driver 的提供者提供 Azure 金鑰保存庫 與 AKS 的原生整合。

我可以在 AKS 上執行 Windows Server 容器嗎?

是,AKS 上提供 Windows Server 容器。 若要在 AKS 中執行 Windows Server 容器,您可以建立以客體 OS 身分執行 Windows Server 的節點集區。 Windows Server 容器只能使用 Windows Server 2019。 若要開始使用,請參閱 使用 Windows Server 節點集區建立 AKS 叢集。

節點集區的 Windows Server 支援包含 Kubernetes 專案中上游 Windows Server 的一些限制。 如需這些限制的詳細資訊,請參閱 AKS 限制中的 Windows Server 容器。

AKS 是否提供服務等級協定?

AKS 會使用運行時間 SLA 功能,在標準定價層中提供 SLA 保證。

免費定價層沒有相關聯的服務等級協定,但服務等級目標為99.5%。 如果有升級、狀況不良的底層節點、平臺維護、應用程式讓 API 伺服器不堪重負的要求等等,就會觀察到暫時性連線問題。針對任務關鍵性與生產工作負載,或如果您的工作負載無法容許 API Server 重新啟動,建議您使用標準層,其中包括運行時間 SLA。

我可以將 Azure 保留折扣套用至我的 AKS 代理程序節點嗎?

AKS 代理程式節點會以標準 Azure 虛擬機計費。 如果您針對您在 AKS 中所使用的 VM 大小購買 Azure 保留 ,則會自動套用這些折扣。

我可以在 Azure 租用戶之間移動/移轉叢集嗎?

目前不支援在租用戶之間移動 AKS 叢集。

我可以在訂用帳戶之間移動/移轉叢集嗎?

目前不支援在訂用帳戶之間移動叢集。

我可以將 AKS 叢集從目前的 Azure 訂用帳戶移至另一個訂用帳戶嗎?

不支援在 Azure 訂用帳戶之間移動 AKS 叢集及其相關聯的資源。

我可以將 AKS 叢集或 AKS 基礎結構資源移至其他資源群組或重新命名嗎?

不支援移動或重新命名 AKS 叢集及其相關聯的資源。

為什麼我的叢集刪除需要這麼久的時間?

大部分的叢集都會在使用者要求時刪除。 在某些情況下,特別是您攜帶自己的資源群組或執行跨 RG 工作的情況下,刪除可能需要更多時間,甚至失敗。 如果您有刪除的問題,請仔細檢查您沒有 RG 的鎖定、RG 以外的任何資源與 RG 解除關聯等等。

為什麼我的叢集建立/更新需要這麼久的時間?

如果您在建立和更新叢集作業時遇到問題,請確定您沒有任何指派的原則或服務限制,可能會封鎖您的 AKS 叢集管理 VM、負載平衡器、卷標等資源。

是否可以在刪除叢集之後還原叢集?

否,您無法在刪除叢集之後還原叢集。 當您刪除叢集時,也會刪除節點資源群組及其所有資源。 第二個資源群組的範例是 MC_myResourceGroup_myAKSCluster_eastus

如果您想要保留任何資源,請先將其移至另一個資源群組,再刪除叢集。 如果您想要防止意外刪除,您可以使用節點資源群組鎖定鎖定裝載叢集資源的 AKS 受控資源群組。

什麼是平台支援,以及它包含什麼?

平台支援是不支援的「N-3」版本叢集的支持計劃。 平台支援僅包含 Azure 基礎結構支援。 平台支援不包含與下列項目相關的任何專案:

  • Kubernetes 功能和元件
  • 叢集或節點集區建立
  • Hotfix
  • 錯誤修正
  • 安全性修補程式
  • 已淘汰的元件

如需限制的詳細資訊,請參閱 平臺支持原則

AKS 依賴 Kubernetes 的版本和修補程式,這是僅支援三個次要版本的滑動視窗的開放原始碼專案。 AKS 只能保證 在上游服務這些版本時的完整支援 。 由於上游不再產生修補程式,AKS 可能會讓這些版本未修補或派生。 由於這項限制,平臺支援不支援依賴 kubernetes 上游的任何專案。

AKS 是否會自動升級不支援的叢集?

AKS 會起始不支援叢集的自動升級。 當 n-3 版本的叢集(其中 n 是最新支援的 AKS GA 次要版本)即將降至 n-4 時,AKS 會自動將叢集升級為 n-2,以保留在 AKS 支持 原則中。 默認會啟用自動將平台支援的叢集升級至支援的版本。

例如,kubernetes v1.25 會在 v1.29 GA 版本期間升級至 v1.26。 若要將中斷降至最低,請設定 維護期間。 如需自動升級通道的詳細資訊,請參閱 自動升級

如果我有狀態為 'NodeLost' 或 'Unknown' 的 Pod/部署,我仍然可以升級叢集嗎?

您可以,但我們不建議這麼做。 當叢集的狀態為已知且狀況良好時,您應該執行更新。

如果我有一或多個節點處於狀況不良狀態或關閉的叢集,我可以執行升級嗎?

否,在升級之前,刪除/移除處於失敗狀態或叢集中的任何節點。

我執行了叢集刪除,但看到錯誤 [Errno 11001] getaddrinfo failed

最常見的情況是,如果您有一或多個仍在與叢集相關聯的網路安全組 (NSG) 時,就會發生此錯誤。 請移除它們,然後再次嘗試刪除。

我執行了升級,但現在我的 Pod 處於損毀迴圈中,整備探查會失敗?

確認您的服務主體尚未過期。 請參閱: AKS 服務主體AKS 更新認證

我的叢集運作正常,但突然無法布建 LoadBalancers、掛接 PVC 等等?

確認您的服務主體尚未過期。 請參閱: AKS 服務主體AKS 更新認證

我可以將 AKS 叢集調整為零嗎?

您可以完全 停止執行中的 AKS 叢集,以節省個別的計算成本。 此外,您也可以選擇將 所有或特定 User 節點集 區調整為 0,只維護必要的叢集設定。

您無法將系統節點集區直接調整為零。

我可以使用虛擬機擴展集 API 手動調整嗎?

否,不支援使用虛擬機擴展集 API 進行調整作業。 使用 AKS API (az aks scale)。

我可以使用 虛擬機器擴展集 手動調整為零節點嗎?

否,不支援使用虛擬機擴展集 API 進行調整作業。 您可以使用 AKS API 調整為零非系統節點集區,或 改為停止叢集

我可以停止或取消配置所有 VM 嗎?

雖然 AKS 具有可承受這類設定並從中復原的復原機制,但這不是支持的設定。 請改為停止叢集

我可以使用自定義 VM 擴充功能嗎?

否,AKS 是受控服務,不支援對 IaaS 資源的操作。 若要安裝自定義元件,請使用 Kubernetes API 和機制。 例如,使用 DaemonSets 安裝必要的元件。

AKS 是否將任何客戶資料儲存在叢集區域之外?

否,所有數據都會儲存在叢集的區域。

需要 AKS 映射才能以根目錄身分執行嗎?

下列影像具有「以根身分執行」的功能需求,而且必須針對任何原則提出例外狀況:

  • mcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprod
  • mcr.microsoft.com/oss/calico/node
  • mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

什麼是 Azure CNI 透明模式與網橋模式?

從 1.2.0 版開始,Azure CNI 會將單一租用 Linux CNI 部署的透明模式設定為預設值。 透明模式正在取代網橋模式。 在下列網橋模式和透明模式小節中,我們會進一步討論兩種模式之間的差異,以及 Azure CNI 中透明模式的優點和限制。

網橋模式

Azure CNI 網橋模式會以「及時」的方式建立名為 “azure0” 的 L2 網橋。 所有主機端Pod veth 配對接口都會連線到此網橋。 Pod-Pod 內部 VM 通訊和其餘流量會經過此網橋。 網橋是第 2 層虛擬設備,除非您將一或多個實際裝置系結至該裝置,否則它本身無法接收或傳輸任何專案。 基於這個理由,Linux VM 的 eth0 必須轉換成從屬至 “azure0” 網橋,這會在Linux VM 內建立複雜的網路拓撲。 作為徵兆,CNI 必須處理其他網路功能,例如 DNS 伺服器更新。

Bridge mode topology

下列範例顯示 Ip 路由設定在 Bridge 模式中的外觀。 不論節點有多少 Pod,只有兩個路由。 第一個路由表示流量(不包括 azure0 上的本機)會透過ip “src 10.240.0.4” 的介面,移至子網的默認網關,也就是節點主要IP。 第二個 Pod 空間表示 「10.20.x.x」 Pod 空間,讓核心決定。

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

透明模式

透明模式會採用簡單的方法來設定 Linux 網路。 在此模式中,Azure CNI 不會變更 Linux VM 中 eth0 介面的任何屬性。 這項變更Linux網路屬性的方法有助於減少叢集可能面臨網橋模式的複雜角落案例問題。 在透明模式中,Azure CNI 會建立並新增新增至主機網路的主機端 Pod veth 配對接口。 VM Pod 對 Pod 之間的通訊是透過 CNI 新增的 IP 路由。 基本上,Pod 對 Pod 通訊是透過第 3 層和 L3 路由規則路由 Pod 流量。

Transparent mode topology

下列範例顯示透明模式的IP路由設定。 每個 Pod 的介面都會取得靜態路由,因此當 Pod 直接傳送至 Pod 的主機端 veth 配對接口時,具有 dest IP 的流量。

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

透明模式的優點

  • 提供 DNS 平行競爭條件的風險 conntrack 降低,並避免發生 5 秒 DNS 延遲問題,而不需要設定節點本機 DNS(基於效能考慮,您仍然可以使用節點本機 DNS)。
  • 由於「Just-In-Time」網橋設定,因此目前引進了初始 5 秒 DNS 延遲 CNI 網橋模式。
  • 網橋模式的其中一個角落案例是,Azure CNI 無法持續更新自定義 DNS 伺服器,列出使用者新增至 VNET 或 NIC。 此案例會導致 CNI 只挑選 DNS 伺服器清單的第一個實例。 此問題會在透明模式中解決,因為 CNI 不會變更任何 eth0 屬性。 如需詳細資訊 ,請參閱這裡
  • 為 ARP 逾時時,為 UDP 洪水風暴提供更好的 UDP 流量和風險降低。在網橋模式中,當網橋在 VM Pod 對 Pod 通訊中不知道目的地 Pod 的 MAC 位址時,根據設計,它會造成封包到所有埠的風暴。 此問題會在透明模式中解決,因為路徑中沒有 L2 裝置。 如需詳細資訊 ,請參閱這裡
  • 相較於網橋模式,透明模式在內部 VM Pod 對 Pod 通訊中的輸送量和延遲方面執行得更好。

如何在磁碟區有大量檔案時避免許可權擁有權設定緩慢的問題?

傳統上,如果您的 Pod 是以非根使用者身分執行(您應該這麼做),您必須在 Pod 的安全性內容中指定 fsGroup ,讓磁碟區可由 Pod 讀取和寫入。 這裡將更詳細地說明這項需求。

設定 fsGroup 的副作用是,每次掛接磁碟區時,Kubernetes 都必須遞歸 chown() ,且 chmod() 磁碟區內的所有檔案和目錄(以下有一些例外狀況)。 即使磁碟區的群組擁有權已經符合所要求的 fsGroup,也會發生此案例。 對於大量小型檔案的較大磁碟區而言,成本可能很高,這可能會導致Pod啟動需要很長的時間。 此案例在 v1.20 之前是已知的問題,且因應措施是將 Pod 執行設定為根目錄:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Kubernetes 1.20 版已解決此問題。 如需詳細資訊,請參閱 Kubernetes 1.20:細微控制磁碟區許可權變更

我可以搭配 AKS 上的部署使用 FIPS 密碼編譯連結庫嗎?

Linux 型節點集區現在支援啟用 FIPS 的節點。 如需詳細資訊,請參閱 新增已啟用 FIPS 的節點集區

我可以使用 AKS 設定 NSG 嗎?

AKS 不會將網路安全組 (NSG) 套用至其子網,也不會修改與該子網相關聯的任何 NSG。 AKS 只會修改網路介面 NSG 設定。 如果您使用 CNI,也必須確定 NSG 中的安全性規則允許節點與 Pod CIDR 範圍之間的流量。 如果您使用 kubenet,您也必須確定 NSG 中的安全性規則允許節點與 Pod CIDR 之間的流量。 如需詳細資訊,請參閱 網路安全組

時間同步處理如何在 AKS 中運作?

AKS 節點會執行 「chrony」 服務,從 localhost 提取時間。 在 Pod 上執行的容器會從 AKS 節點取得時間。 從 Pod 的容器使用時間,在容器內啟動的應用程式。

AKS 附加元件如何更新?

任何修補程式,包括安全性修補程式,都會自動套用至 AKS 叢集。 比修補程式更大的任何專案,例如主要或次要版本變更(如果有已部署物件的中斷性變更),當您更新叢集時,如果有新的版本可用,就會更新。 您可以流覽 AKS 版本資訊,找到新版本何時可供使用。

我在 Linux 虛擬機器擴展集 實例上看到的 AKS Linux 延伸模組用途為何?

AKS Linux 擴充功能是 Azure VM 擴充功能,可在 Kubernetes 背景工作節點上安裝和設定監視工具。 擴充功能會安裝在所有新的和現有的Linux節點上。 它會設定下列監視工具:

  • 節點導出工具:從虛擬機收集硬體遙測,並使用計量端點加以使用。 然後,Prometheus 等監視工具就能夠取消這些計量。
  • 節點問題偵測器:旨在讓叢集管理堆棧中的上游層看到各種節點問題。 這是在每一個節點上執行的 systemd 單位,會偵測節點問題,並使用事件和 NodeConditions 將其報告給叢集的 API 伺服器。
  • ig:eBPF 支援的開放原始碼架構,用於偵錯和觀察Linux和 Kubernetes 系統。 它提供一組專為收集相關信息而設計的工具(或小工具),讓使用者能夠識別效能問題、當機或其他異常的原因。 值得注意的是,其與 Kubernetes 的獨立可讓使用者也將其用於偵錯控制平面問題。

這些工具有助於提供許多節點健康情況相關問題的可觀察性,例如:

  • 基礎結構精靈問題:NTP 服務關閉
  • 硬體問題:CPU、記憶體或磁碟不正確
  • 核心問題:核心死結、文件系統損毀
  • 容器運行時間問題:沒有回應的運行時間精靈

延伸模組不需要對記載 AKS 輸出需求以外的任何 URL、IP 位址或埠進行額外的輸出存取。 它不需要在 Azure 中授與任何特殊許可權。 它會使用 kubeconfig 連線到 API 伺服器,以傳送所收集的監視數據。