(已弃用)在容器服务中为 Kubernetes 群集设置 Azure AD 服务主体

提示

有关使用 Azure Kubernetes 服务的本文的更新版本,请参阅使用 Azure Kubernetes 服务 (AKS) 的服务主体

警告

Azure 容器服务 (ACS) 正在被弃用。 将不会向 ACS 添加任何新特性或新功能。 所有 API、门户体验、CLI 命令和文档均已标记为“已弃用”。

2017 年,我们推出了 Azure Kubernetes 服务 (AKS),以简化 Kubernetes 的管理、部署和操作。 如果使用 Kubernetes 业务流程协调程序,请于 2020 年 1 月 31 日之前迁移到 AKS。 若要开始,请参阅迁移到 Azure Kubernetes 服务

有关详细信息,请参阅 Azure.com 上的 Azure 容器服务弃用声明

在 Azure 容器服务中,Kubernetes 群集需要 Azure Active Directory 服务主体才能与 Azure API 交互。 需要服务主体才能动态管理相关资源,例如用户定义路由第 4 层 Azure 负载均衡器

本文介绍用于为 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>"

输出如下所示(此处以密文形式显示):

创建服务主体

突出显示的是 客户端 ID (appId) ,以及用作群集部署服务主体参数的 客户端机密password () 。

在创建 Kubernetes 群集时指定服务主体

创建 Kubernetes 群集时,提供现有服务主体的“客户端 ID”(也称为 appId,即应用程序 ID)和“客户端机密”(password) 作为参数。 请确保服务主体满足本文开头的要求。

可以在使用 Azure 命令行接口 (CLI)Azure 门户等方法部署 Kubernetes 群集时指定这些参数。

提示

指定“客户端 ID”时,请确保使用服务主体的 appId 而不是 ObjectId

以下示例说明了一种通过 Azure CLI 传递参数的方法。 此示例使用 Kubernetes 快速启动模板

  1. 从 GitHub 下载模板参数文件 azuredeploy.parameters.json

  2. 若要指定服务主体,请在文件中输入 servicePrincipalClientIdservicePrincipalClientSecret 的值。 (还需要为和sshRSAPublicKey提供自己的值dnsNamePrefix。后者是用于访问 cluster.) 保存文件的 SSH 公钥。

    传递服务主体参数

  3. 运行以下命令,使用 --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 会自动创建一个适用于容器服务的服务主体。 该操作以透明方式在部署过程中进行。

以下命令创建 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 容器服务的服务主体。

  • Kubernetes 的服务主体是群集配置的一部分。 但是,请勿使用标识来部署群集。

  • 每个服务主体都与一个 Azure AD 应用程序相关联。 Kubernetes 群集的服务主体可以与任何有效的 Azure AD 应用程序名称(例如 https://www.contoso.org/example )相关联。 应用程序的 URL 不一定是实际的终结点。

  • 指定服务主体的“客户端 ID”时,可以使用 appId 的值(如本文所示)或相应的服务主体 name(例如,https://www.contoso.org/example)。

  • 在 Kubernetes 群集的主 VM 和代理 VM 中,服务主体凭据存储在 /etc/kubernetes/azure.json 文件中。

  • 使用 az acs create 命令自动生成服务主体时,会将服务主体凭据写入用于运行命令的计算机上的 ~/.azure/acsServicePrincipal.json 文件中。

  • 使用 az acs create 命令自动生成服务主体时,服务主体也可以使用在同一订阅中创建的 Azure 容器注册表进行身份验证。

  • 服务主体凭据可能会过期,导致群集节点进入“NotReady”状态。 请参阅凭据过期部分,了解缓解信息。

凭据过期

除非在创建服务主体时使用 --years 参数指定了自定义时效期,否则凭据的有效期为自创建之时起 1 年。 凭据过期后,群集节点可能进入“NotReady”状态。

若要查看服务主体的过期日期,请使用 --debug 参数执行 az ad app show 命令,然后在输出底部附近查找 passwordCredentialsendDate 值:

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 进行更新,然后重启节点。

后续步骤