驗證許可控制器
本文是一系列文章的一部分。 從概 觀開始。
許可控制者很少會造成問題，但請務必確保其適當的功能。 本文討論許可控制器在無法正常運作時如何影響其他元件。 它也會描述可用來驗證許可控制器效能的命令。
許可控制器
許可控制器是一段程式代碼，會在對象持續性之前攔截對 Kubernetes API 伺服器的要求，但在要求經過驗證和授權之後。
許可控制器可以 驗證、 變動或兩者的組合。 變更 控制器可以在允許要求之前修改相關物件。 驗證 控制器完全可確保要求符合特定預先定義的準則。
許可控制者的主要功能之一是規範物件建立、刪除和修改的要求。 此外，許可控制器可以限制自定義動詞，例如透過 API 伺服器 Proxy 要求與 Pod 的連線。 不過，許可控制器無法封鎖讀取物件的要求，包括、 watch或 list等get作業。
某些元件可能會影響許可控制器，例如 變動和驗證 Webhook。 當您在 Kubernetes 叢集中納入變動和驗證 Webhook 時，請務必確保高可用性。 狀況不良的節點不應該封鎖 API 伺服器要求。 監視許可控制管線非常重要，因此不會封鎖對 API 伺服器的要求。 狀況不良的許可控制器可能會影響變動和驗證 Webhook。 您應該監視的 Webhook 型許可控制器包括：
Azure Kubernetes Service （AKS） 叢集的 Azure 原則 附加元件，可擴充 Gatekeeper。 網關守衛是開放原則代理程序的許可控制站 Webhook。
Kyverno，其會以 Kubernetes 叢集中的動態許可控制器身分執行。 Kyverno 會從 Kubernetes API 伺服器接收驗證和變動許可 Webhook HTTP 回呼，並套用比對原則以傳回強制執行許可原則或拒絕要求的結果。 如需疑難解答參考數據（例如 APIServer 失敗的 Webhook 呼叫），請參閱 Kyverno 疑難解答檔。
或者，無法正常運作的許可控制器可能會影響各種元件，例如 服務網格。 服務網格，例如 Istio 和 Linkerd，使用許可控制器將 Pod 內的側車容器插入自動化，以及其他功能。 請務必評估並確認許可控制器正常運作，以確保服務網格的順暢作業。
檢查 AKS 叢集 Azure 原則 附加元件的狀態
如果您為 AKS 安裝 Azure 原則 附加元件，您可以使用下列 kubectl 命令來驗證叢集中 Azure 原則 許可控制器的安裝和功能：
# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system
# Sample output
...
NAME READY STATUS RESTARTS AGE
gatekeeper-audit-65844778cb-rkflg 1/1 Running 0 163m
gatekeeper-controller-78797d4687-4pf6w 1/1 Running 0 163m
gatekeeper-controller-78797d4687-splzh 1/1 Running 0 163m
...
執行上一個命令，以確認閘道守衛系統命名空間中 Azure 原則 代理程式 Pod 的可用性。 如果輸出不是您預期的輸出，它可能會指出許可控制器、API 服務或自定義資源定義 （CRD） 的問題。
# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources
# Sample output
...
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
...
上一個命令可協助您確認所有 API 資源都正常運作。 請確定輸出包含預期的資源，而不會有任何錯誤或遺漏元件。 kubectl get pod使用和 kubectl api-resources 命令來檢查 AKS Azure 原則 附加元件的狀態，並驗證 Kubernetes 叢集中許可控制器的功能。 定期監視許可控制器，以確保它們正常運作，讓您可以維護叢集的整體健康情況和穩定性。
使用下列 kubectl get 命令來確認原則指派已套用至您的叢集：
kubectl get constrainttemplates
注意
原則指派最多可能需要 20 分鐘的時間，才能與每個叢集同步 。
您的輸出應該會類似下列範例：
NAME AGE
k8sazureallowedcapabilities 23m
k8sazureallowedusersgroups 23m
k8sazureblockhostnamespace 23m
k8sazurecontainerallowedimages 23m
k8sazurecontainerallowedports 23m
k8sazurecontainerlimits 23m
k8sazurecontainernoprivilege 23m
k8sazurecontainernoprivilegeescalation 23m
k8sazureenforceapparmor 23m
k8sazurehostfilesystem 23m
k8sazurehostnetworkingports 23m
k8sazurereadonlyrootfilesystem 23m
k8sazureserviceallowedports 23m
如需詳細資訊，請參閱以下資源：
驗證 Webhook
若要確保驗證和變動 Webhook 在 Kubernetes 叢集中如預期般運作，請遵循下列步驟。
執行下列命令以列出叢集中的驗證 Webhook：
kubectl get ValidatingWebhookConfiguration -o wide您的輸出應該會類似下列範例：
NAME WEBHOOKS AGE aks-node-validating-webhook 1 249d azure-policy-validating-webhook-configuration 1 249d gatekeeper-validating-webhook-configuration 1 249d檢閱輸出以確認驗證 Webhook 是否存在，且其設定如預期般。 輸出包含每個驗證 Webhook 的名稱、Webhook 的數目，以及每個 Webhook 的存留期。
執行下列命令以列出叢集中的變動 Webhook：
kubectl get MutatingWebhookConfiguration -o wide您的輸出應該會類似下列範例：
NAME WEBHOOKS AGE aks-node-mutating-webhook 1 249d azure-policy-mutating-webhook-configuration 1 249d gatekeeper-mutating-webhook-configuration 1 249d檢查輸出，以確保已正確列出變動 Webhook，並視需要設定。 輸出包含每個變動 Webhook 的名稱、Webhook 的數目，以及每個 Webhook 的存留期。
執行下列命令以擷取特定許可控制器的特定詳細資料：
kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml將 取代
<mutating-webhook-name>為您想要擷取詳細數據的變動 Webhook 名稱。 此命令的輸出會顯示指定變動 Webhook 組態的 YAML 表示法。
執行本節中的命令，並檢閱輸出，以便確認 Kubernetes 叢集中的驗證和變動 Webhook 已如預期般存在並設定。 此驗證對於確保正常運作至關重要。 也請務必確保 Webhook 遵守原則，以驗證和修改叢集中的資源。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Paolo Salvatori |首席客戶工程師
其他投稿人：
- 弗朗西斯·西米·納扎雷斯 |資深技術專家
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。