(已被取代) 在 Container Service 中設定 Kubernetes 叢集的 Azure AD 服務主體
提示
如需本文中使用 Azure Kubernetes Service 的更新版本,請參閱服務主體與 Azure Kubernetes Service (AKS)。
警告
Azure Container Service (ACS) 即將淘汰。 ACS 不會再新增任何新的特性或功能。 所有 API、入口網站體驗、CLI 命令和文件均會標示為已淘汰。
自 2017 年引進 Azure Kubernetes Service (AKS) 起,即將其用於簡化 Kubernetes 的管理、部署及作業。 若您使用 Kubernetes 協調器,請於 2020 年 1 月 31 日前遷移至 AKS。 若要開始使用,請參閱遷移至 Azure Kubernetes Service。
如需詳細資訊,請參閱 Azure.com 上的 Azure Container Service 淘汰通知。
在 Azure Container Service 中,Kubernetes 叢集需要 Azure Active Directory 服務主體,才能與 Azure API 進行互動。 需要服務主體,才能以動態方式管理資源,例如使用者定義的路由及第 4 層 Azure Load Balancer。
本文說明為 Kubernetes 叢集設定服務主體的各種選項。 例如,如果您已安裝並設定 Azure CLI,您可以執行 az acs create
命令,在同一時間建立 Kubernetes 叢集與服務主體。
服務主體的需求
您可以使用符合下列需求的現有 Azure AD 服務主體,或建立一個新的服務主體。
範圍:資源群組
角色:參與者
用戶端密碼:必須是密碼。 目前,您無法使用針對憑證驗證設定的服務主體。
重要
若要建立服務主體,您必須有足夠權限向 Azure AD 租用戶註冊應用程式,並將應用程式指派給您訂用帳戶中的角色。 若要查看您是否有必要的權限,請在入口網站中檢查。
選項 1:在 Azure AD 中建立服務主體
如果您想要在部署 Kubernetes 叢集之前建立 Azure AD 服務主體,Azure 會提供數種方法。
下列範例命令示範如何使用 Azure CLI 執行這項作業。 或者,您也可以使用 Azure PowerShell、入口網站或其他方法來建立服務主體。
az login
az account set --subscription "mySubscriptionID"
az group create --name "myResourceGroup" --location "westus"
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>"
輸出如下所示 (以下顯示擬定的輸出):
反白顯示的是 用戶端識別碼 (appId
) ,而 用戶端密碼 (password
) 您用來作為叢集部署的服務主體參數。
在建立 Kubernetes 叢集時指定服務主體
當您建立 Kubernetes 叢集時,提供現有服務主體的用戶端識別碼 (也稱為appId
,適用於應用程式識別碼) 和用戶端密碼 (password
) 做為參數。 確定服務主體符合本文開頭所述的需求。
使用 Azure 命令列介面 (CLI)、Azure 入口網站或其他方法部署 Kubernetes 叢集時,您可以指定這些參數。
提示
指定用戶端識別碼時,務必使用服務主體的 appId
,而非 ObjectId
。
下列範例顯示使用 Azure CLI 傳遞參數的其中一種方式。 此範例使用 Kubernetes 快速入門範本。
從 GitHub 下載範本參數檔案
azuredeploy.parameters.json
。若要指定服務主體,在檔案中輸入
servicePrincipalClientId
和servicePrincipalClientSecret
的值。 (您也需要為 和sshRSAPublicKey
提供自己的值dnsNamePrefix
。後者是用來存取 cluster.) 儲存檔案的 SSH 公開金鑰。執行下列命令,並使用
--parameters
來設定 azuredeploy.parameters.json 檔案的路徑。 此命令會在美國西部區域中名為myResourceGroup
的資源群組中部署叢集。az login az account set --subscription "mySubscriptionID" az group create --name "myResourceGroup" --location "westus" az group deployment create -g "myResourceGroup" --template-uri "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-acs-kubernetes/azuredeploy.json" --parameters @azuredeploy.parameters.json
選項 2︰在使用 az acs create
建立叢集時產生服務主體
如果您執行 az acs create
命令來建立 Kubernetes 叢集,您可以選擇自動產生服務主體。
至於其他 Kubernetes 叢集建立選項,您可以在執行 az acs create
時指定現有服務主體的參數。 不過,當您省略這些參數時,Azure CLI 會自動建立一個參數以搭配 Container Service 使用。 這會在部署期間以透明方式發生。
下列命令會建立 Kubernetes 叢集並產生 SSH 金鑰和服務主體認證︰
az acs create -n myClusterName -d myDNSPrefix -g myResourceGroup --generate-ssh-keys --orchestrator-type kubernetes
重要
如果您的帳戶沒有 Azure AD 和訂用帳戶權限可建立服務主體,則命令會產生類似 Insufficient privileges to complete the operation.
的錯誤。
其他考量
如果您沒有在訂用帳戶中建立服務主體的權限,您可能需要要求 Azure AD 或訂用帳戶管理員指派所需的權限,或要求他們提供服務主體以搭配 Azure Container Service 使用。
Kubernetes 的服務主體是叢集組態的一部分。 不過,請勿使用身分識別來部署叢集。
每個服務主體都會與 Azure AD 應用程式相關聯。 Kubernetes 叢集的服務主體可與任何有效的 Azure AD 應用程式名稱相關聯 (例如:
https://www.contoso.org/example
)。 應用程式的 URL 不一定是實際端點。指定服務主體的 [用戶端識別碼] 時,您可以使用
appId
的值 (如本文所示) 或對應的服務主體name
(例如,https://www.contoso.org/example
)。在 Kubernetes 叢集中的主要和代理程式 VM 上,服務主體認證會儲存在
/etc/kubernetes/azure.json
檔案中。當您使用
az acs create
命令自動產生服務主體時,服務主體認證會寫入用來執行命令之電腦上的~/.azure/acsServicePrincipal.json
檔案。當您使用
az acs create
命令自動產生服務主體時,服務主體也可以向在訂用帳戶中建立的 Azure Container Registry 進行驗證。服務主體認證可能會過期,導致您的叢集節點進入 NotReady 狀態。 請參閱認證到期一節,以取得風險降低資訊。
認證到期
除非您在建立服務主體時以 --years
參數指定自訂的有效範圍,否則其認證的有效期為自建立起 1 年內。 當認證到期時,您的叢集節點可能會進入 NotReady 狀態。
若要檢查服務主體的到期日,請執行 az ad app show 命令並搭配 --debug
參數,然後在輸出底部附近尋找 passwordCredentials
的 endDate
值:
az ad app show --id <appId> --debug
輸出 (此處顯示已截斷的內容):
...
"passwordCredentials":[{"customKeyIdentifier":null,"endDate":"2018-11-20T23:29:49.316176Z"
...
如果您的服務主體認證到期,請使用 az ad sp reset-credentials 命令更新認證:
az ad sp reset-credentials --name <appId>
輸出:
{
"appId": "4fd193b0-e6c6-408c-a21a-803441ad2851",
"name": "4fd193b0-e6c6-408c-a21a-803441ad2851",
"password": "404203c3-0000-0000-0000-d1d2956f3606",
"tenant": "72f988bf-0000-0000-0000b-2d7cd011db47"
}
然後,使用所有叢集節點上的新認證更新 /etc/kubernetes/azure.json
,並重新啟動節點。
後續步驟
若要針對 Kubernetes 的服務主體進行疑難排解,請參閱 ACS 引擎文件。