Azure Kubernetes Service (AKS) 的常見問題集

發行項
03/18/2024

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

哪些 Azure 區域目前提供 AKS？

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

我可以跨區域散佈 AKS 叢集嗎？

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

我可以在可用性區域之間散佈 AKS 叢集嗎？

是。您可以在支援 AKS 叢集的區域中，將某個 AKS 叢集部署到一或多個可用性區域。

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

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

如果您想要維護 API 伺服器的公用端點，但限制只能存取一組信任的 IP 範圍，請使用 API 伺服器授權的 IP 範圍。
如果您想要將 API 伺服器限制為「僅」可從虛擬網路中存取，請使用私人叢集。

單一叢集中是否可以有不同的 VM 大小？

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

安全性更新是否會套用至 AKS 代理程式節點？

AKS 修補程式會每週有「廠商修正」的 CVE。沒有修正程式的 CVE 正在等候「廠商修正」，才能補救。 AKS 映像會在 30 天內自動更新。建議您定期套用更新的節點映像，以確保套用最新的修補映像和 OS 修補程式。您可以使用下列其中一種方法進行：

手動、透過 Azure 入口網站，或透過 Azure CLI。
藉由升級 AKS 叢集。叢集會自動升級 cordon 和 drain 節點，然後使用最新的 Ubuntu 映像和新的修補程式版本或 Kubernetes 次要版本來讓新節點上線。如需詳細資訊，請參閱升級 AKS 叢集。
透過使用節點映像升級。

AKS 中容器影像的大小限制為何？

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

當容器影像過大時，如同在 TB (TB) 範圍中，kubelet 可能無法將其從容器登錄提取到節點，因為磁碟空間不足。

Windows Server 節點

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

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

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

新的 Kubeflow 大規模行銷活動 (2021 年 6 月 8 日)

受控控制平面如何與我的節點通訊？

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 部署皆會跨越兩個資源群組：

您會建立第一個資源群組。此群組僅包含 Kubernetes 服務資源。 AKS 資源提供者會在部署期間自動建立第二個資源群組。第二個資源群組的範例是 MC_myResourceGroup_myAKSCluster_eastus。如需如何指定這第二個資源群組名稱的相關資訊，請參閱下一節。
第二個資源群組 (稱為「節點資源群組」) 包含所有與該叢集相關聯的基礎結構資源。這些資源包括 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 屬性來定義資源群組名稱。

AKS 資源提供者會自動建立第二個資源群組。
只有在建立叢集時，才能指定自訂資源群組名稱。

當使用節點資源群組時，您無法進行以下動作：

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

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

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

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

注意

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

AKS 支援哪些 Kubernetes 許可控制器？是否可以新增或移除許可控制器？

AKS 支援下列許可控制器：

NamespaceLifecycle
LimitRanger
ServiceAccount
DefaultIngressClass
DefaultStorageClass
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 系統和內部 AKS 命名空間嗎？

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

如果您有在 kube 系統上部署某些項目 (不建議) 以支援自訂許可 Webhook 的關鍵使用案例，則您可以新增下列標籤或註釋，讓許可強制器能夠加以忽略。

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

Azure Key Vault 是否會與 AKS 整合？

密碼存放區驅動程式的 Azure Key Vault 供應商會提供將 Azure Key Vault 原生整合至 AKS。

我是否可以在 AKS 上執行 Windows Server 容器？

是，Windows Server 容器可在 AKS 上取得。若要在 AKS 中執行 Windows Server 容器，請建立執行 Windows Server 的節點集區作為客體 OS。 Windows Server 容器只能使用 Windows Server 2019。若要開始使用，請參閱建立具有 Windows Server 節點集區的 AKS 叢集。

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

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

AKS 以具有運行時間 SLA 功能的標準定價層提供 SLA 保證。

免費定價層沒有相關聯的服務等級合約，但服務等級目標為 99.5%。在升級、狀況不良的下層節點、平台維護，或應用程式壓倒具要求的 API 伺服器等狀況下，可能會觀察到暫時性連線問題。針對任務關鍵性與生產工作負載，或如果您的工作負載不容許 API 伺服器重新啟動，建議您使用標準層，其中包括運行時間 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。若要盡量減少中斷，請設定維護時段。如需自動升級通道的詳細資訊，請參閱自動升級。

如果我的 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 和機制。例如，使用 DaemonSet 來安裝必要元件。

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

否，所有資料都會儲存在叢集的區域中。

是否需要以根目錄身分執行 AKS 映像？

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

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 透明模式與橋接器模式？

從 v1.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 路由設定看起來像是位於橋接器模式中的範例。不論節點有多少 Pod，只會有兩個路由。第一個路由指出：azure0 上排除本機的所有流量，都會透過 ip 為「src 10.240.0.4」的介面移至子網路的預設閘道 (這是節點主要 IP)；第二個路由則指出針對要決定的核心，以「10.20.x.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 路由規則將進行路由傳送。

Transparent mode topology

下列範例顯示透明模式的 IP 路由設定。每個 Pod 的介面都會取得靜態路由連結，讓具有 dest IP 作為 Pod 的流量會直接傳送至 Pod 的主機端 veth 配對介面。

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

透明模式的優點

將 conntrack DNS 平行競爭條件的風險降低，並避免發生 5 秒 DNS 延遲問題，且不需要設定節點本機 DNS (您仍可能基於效能理由，繼續使用節點本機 DNS)。
由於「Just In Time」橋接器設定的關係，消除現在導入的初始 5 秒 DNS 延遲 CNI 橋接器模式。
橋接器模式的其中一個邊角案例，是 Azure CNI 無法持續更新使用者新增至 VNET 或 NIC 的自訂 DNS 伺服器清單。此情節會導致 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 單位，其會偵測節點問題，並使用 Events 和 NodeConditions 將其報告給叢集的 API 伺服器。
ig：eBPF 支援的開放原始碼架構，用於偵錯和觀察 Linux 和 Kubernetes 系統。其提供一組專為收集相關資訊而設計的工具 (或小工具)，讓使用者能識別效能問題、當機或其他異常的原因。值得注意的是，其獨立於 Kubernetes，因此使用者也能將其用於偵錯控制平面的問題。

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

基礎結構精靈問題：NTP 服務關閉
硬體問題：CPU、記憶體或磁碟損壞
核心問題：核心鎖死、檔案系統損毀
容器運行時間問題：沒有回應的運行時間精靈

擴充功能不需要對記載的 AKS 輸出需求以外的任何 URL、IP 位址或連接埠的額外輸出存取。其不需要在 Azure 中授與任何特殊權限。其使用 kubeconfig 連線到 API 伺服器，以傳送所收集的監控資料。