集成

• 1: 与 AWS 的集成
• 1.1: AWS 认证
• 2: 与 Azure 的集成
• 2.1: 对 Azure 进行身份验证
• 2.1.1: 向 Azure 进行身份验证
• 2.1.2: 如何使用工作负载身份联合
• 2.1.3: 操作指南：生成新的 Microsoft Entra ID 应用程序和服务主体
• 2.1.4: 如何：使用托管标识
• 2.2: Azure API Management 的 Dapr 集成策略
• 2.3: Dapr extension for Azure Functions runtime
• 2.4: 适用于 Azure Kubernetes Service (AKS) 的 Dapr 扩展
• 3: Diagrid 集成
• 3.1: Conductor: Enterprise Dapr for Kubernetes
• 4: 如何：使用 KEDA 自动扩缩 Dapr 应用
• 5: 如何：在 GitHub Actions 工作流中使用 Dapr CLI
• 6: 操作指南：使用 Dapr Kubernetes Operator
• 7: 如何：与 Kratix 集成
• 8: 操作指南：与 Argo CD 集成

1 - 与 AWS 的集成

1.1 - AWS 认证

利用 AWS 服务的 Dapr 组件（例如 DynamoDB、SQS、S3）通过 AWS SDK 使用标准化的配置属性。了解更多关于 AWS SDK 如何处理凭据的信息。

您可以使用 AWS SDK 的默认提供程序链或下面列出的预定义 AWS 认证配置文件之一来配置认证。通过测试和检查 Dapr 运行时日志来确认正确初始化，从而验证您的组件配置。

术语

• ARN (Amazon Resource Name，Amazon 资源名称): 用于指定 AWS 资源的唯一标识符。格式：arn:partition:service:region:account-id:resource。示例：arn:aws:iam::123456789012:role/example-role。
• IAM (Identity and Access Management，身份和访问管理): 用于安全管理 AWS 资源访问的 AWS 服务。

认证配置文件

访问密钥 ID 和秘密访问密钥

使用静态访问密钥和秘密密钥凭据，可以通过组件元数据字段或通过默认 AWS 配置实现。

承担 IAM 角色

此配置文件允许 Dapr 承担特定的 IAM 角色。通常在 Dapr 边车运行在 EKS 上或附加到 IAM 策略的节点/ Pod 上时使用。目前由 Kafka 和 PostgreSQL 组件支持。

来自环境变量的凭据

使用环境变量进行认证。这对于边车注入器不配置环境变量的自托管模式下的 Dapr 特别有用。

此认证配置文件不需要元数据字段。

IAM Roles Anywhere

IAM Roles Anywhere 将基于 IAM 角色的认证扩展到外部工作负载。它通过使用加密签名证书消除了对长期凭据的需求，该证书使用 Dapr PKI 建立在信任关系中。Dapr SPIFFE 身份 X.509 证书用于向 AWS 服务进行认证，Dapr 在会话生命周期的一半时处理凭据轮换。

要配置此认证配置文件：

1. 在信任 AWS 账户中使用 Dapr 证书包作为 External certificate bundle 创建信任锚点。
2. 创建一个具有必要资源权限策略以及 Roles Anywhere AWS 服务的信任实体的 IAM 角色。在此处，您可以指定允许的 SPIFFE 身份。
3. 在 Roles Anywhere 服务下创建一个 IAM 配置文件，链接 IAM 角色。

附加字段

某些 AWS 组件包含其他可选字段：

此外，支持 AWS 认证配置文件的非原生 AWS 组件（如 Kafka 和 PostgreSQL）具有用于触发 AWS 认证逻辑的元数据字段。请务必查看特定组件文档。

在组件清单文件中显式指定凭据的替代方案

在生产场景中，建议使用以下解决方案：

• Kiam
• Kube2iam

如果在 AWS EKS 上运行，您可以将 IAM 角色链接到 Kubernetes 服务账户，您的 Pod 可以使用该角色。

所有这些解决方案都解决了相同的问题：它们允许 Dapr 运行时进程（或边车）动态检索凭据，因此不需要显式凭据。这提供了几个好处，例如自动密钥轮换，以及避免管理机密。

Kiam 和 Kube2IAM 都通过拦截对实例元数据服务的调用来工作。

使用 AWS EKS Pod Identity 设置 Dapr

EKS Pod 身份提供了为您的应用程序管理凭据的能力，类似于 Amazon EC2 实例配置文件为 Amazon EC2 实例提供凭据的方式。您可以将 IAM 角色与 Kubernetes 服务账户关联，并配置您的 Pod 使用该服务账户，而不是创建和分发 AWS 凭据到容器或使用 Amazon EC2 实例的角色。

要查看有关如何使用 AWS EKS Pod Identity 从 EKS 授权 Pod 访问 AWS Secrets Manager 的综合示例，请遵循此存储库中的示例。

在 AWS EC2 上以独立模式运行时使用实例配置文件

如果以独立模式直接在 AWS EC2 实例上运行 Dapr，您可以使用实例配置文件。

1. 配置 IAM 角色。
2. 将其附加到 ec2 实例的实例配置文件。

然后，Dapr 在不需要在 Dapr 组件清单中指定凭据的情况下向 AWS 进行认证。

在独立模式下本地运行 dapr 时向 AWS 进行认证

• Linux/MacOS
• Windows

FOO=bar daprd --app-id myapp

AWS_PROFILE=myprofile dapr run...

AWS_PROFILE=myprofile daprd...

如果使用基于 AWS SSO 的配置文件，则向 AWS 进行认证

如果您使用 AWS SSO 向 AWS 进行认证，适用于 Go 的 AWS SDK（v1 和 v2）为 AWS SSO 凭据提供程序提供原生支持。这意味着您可以直接使用 AWS SSO 配置文件，而无需其他实用程序。

有关适用于 Go 的 AWS SDK 中 AWS SSO 支持的更多信息，请参阅 AWS 博客文章。

后续步骤

相关链接

• 有关更多信息，请参阅 AWS SDK（Dapr 使用的）如何处理凭据。
• EKS Pod Identity 文档
• AWS SDK 凭据配置
• 设置 Elastic Kubernetes Service (EKS) 集群

2 - 与 Azure 的集成

2.1 - 对 Azure 进行身份验证

2.1.1 - 向 Azure 进行身份验证

关于使用 Microsoft Entra ID 进行身份验证

Microsoft Entra ID 是 Azure 的标识和访问管理 (IAM) 解决方案，用于对用户和服务进行身份验证和授权。它构建在 OAuth 2.0 等开放标准之上，允许服务（应用程序）获取访问令牌以向 Azure 服务发出请求，包括 Azure Storage、Azure Service Bus、Azure Key Vault、Azure Cosmos DB、Azure Database for Postgres、Azure SQL 等。

身份验证选项

应用程序可以通过多种方法使用 Microsoft Entra ID 进行身份验证并获取访问令牌以向 Azure 服务发出请求：

• 工作负载标识联合 - 配置 Microsoft Entra ID 租户以信任外部标识提供者的推荐方式。这包括来自 Kubernetes 或 AKS 集群的服务账户。了解有关工作负载标识联合的更多信息。
• 系统分配和用户分配的托管标识 - 不如工作负载标识联合精细，但保留了部分优势。了解有关系统分配和用户分配的托管标识的更多信息。
• [客户端 ID 和密钥]({{ < ref howto-aad.md >}}) - 不推荐，因为它要求您在应用程序级别维护和关联凭据。
• Pod 标识 - 已弃用的方法，用于对在 Kubernetes Pod 上运行的应用程序进行身份验证，在 Pod 级别进行。不应再使用此方法。

如果您刚刚开始，建议使用工作负载标识联合。

托管标识和工作负载标识联合

使用托管标识 (MI)，您的应用程序可以使用 Microsoft Entra ID 进行身份验证并获取访问令牌以向 Azure 服务发出请求。当您的应用程序在支持的 Azure 服务（例如 Azure VM、Azure Container Apps、Azure Web Apps 等）上运行时，可以在基础设施级别为您的应用程序分配标识。您还可以设置 Microsoft Entra ID 以使用联合标识凭据直接将联合信任委托给您的 Dapr 应用程序标识。这允许您配置对 Microsoft 资源的访问权限，即使不在 Microsoft 基础设施上运行也是如此。要了解如何配置 Dapr 以使用联合标识，请参阅使用联合标识凭据进行身份验证部分。 这是通过系统分配或用户分配的托管标识或工作负载标识联合完成的。

使用托管标识后，您的代码不必处理凭据，这可以：

• 消除安全管理凭据的挑战
• 允许开发团队和运营团队之间更好地分离关注点
• 减少有权访问凭据的人数
• 简化操作方面——尤其是在使用多个环境时

虽然某些 Dapr Azure 组件提供替代身份验证方法，例如基于"共享密钥"或"访问令牌"的系统，但只要有可能，您应该始终尝试使用 Microsoft Entra ID 对 Dapr 组件进行身份验证。这提供了许多好处，包括：

• 基于角色的访问控制
• 审核
• (可选) 使用证书进行身份验证

建议在 Azure Kubernetes Service 上运行的应用程序利用工作负载标识联合自动为各个 Pod 提供标识。

基于角色的访问控制

在对受支持的服务使用 Azure 基于角色的访问控制 (RBAC) 时，可以微调授予应用程序的权限。例如，您可以限制对数据子集的访问或使访问变为只读。

审核

使用 Microsoft Entra ID 可提供改进的访问审核体验。租户管理员可以查看审核日志以跟踪身份验证请求。

(可选) 使用证书进行身份验证

虽然 Microsoft Entra ID 允许您使用 MI，但您仍然可以选择使用证书进行身份验证。

对其他 Azure 环境的支持

默认情况下，Dapr 组件配置为与"公有云"中的 Azure 资源进行交互。如果您的应用程序部署到另一个云，例如 Azure China 或 Azure Government（“主权云”），可以通过将 azureEnvironment 元数据属性设置为支持的值之一，为支持的组件启用该功能：

• Azure 公有云（默认）: "AzurePublicCloud"
• Azure 中国: "AzureChinaCloud"
• Azure 政府: "AzureUSGovernmentCloud"

对主权云的支持是实验性的。

凭据元数据字段

要使用 Microsoft Entra ID 进行身份验证，您需要将以下凭据作为值添加到您的 Dapr 组件的元数据中。

元数据选项

根据您如何将凭据传递给 Dapr 服务，您有多个元数据选项。

• 使用客户端凭据
• 使用证书
• 使用托管标识 (MI)
• 在 AKS 上使用工作负载标识
• 使用 Azure CLI 凭据（仅限开发）

使用客户端凭据进行身份验证

在 Kubernetes 上运行时，您还可以对上述任何或所有值使用对 Kubernetes 机密的引用。

使用证书进行身份验证

在 Kubernetes 上运行时，您还可以对上述任何或所有值使用对 Kubernetes 机密的引用。

使用托管标识 (MI) 进行身份验证

使用托管标识，通常推荐使用 azureClientId 字段。使用系统分配的标识时，该字段是可选的，但在使用用户分配的标识时可能是必需的。

在 AKS 上使用工作负载标识进行身份验证

在 Azure Kubernetes Service (AKS) 上运行时，您可以使用工作负载标识对组件进行身份验证。请参阅 Azure AKS 文档中关于为 Kubernetes 资源启用工作负载标识的内容。

使用联合标识凭据进行身份验证

您可以使用 Microsoft Entra ID 中的联合标识凭据直接将联合信任委托给您的 Dapr 安装，无论其运行在何处。这允许您跨不同云一致地针对 Dapr 应用程序的 SPIFFE ID 轻松配置访问规则。

为了联合信任，您必须运行启用了 JWT 颁发和 OIDC 发现的 Dapr Sentry。可以使用以下 Dapr Sentry helm 值配置这些功能：

jwt:
  # 通过 Sentry 启用 JWT 令牌颁发
  enabled: true
  # JWT 令牌的颁发者值
  issuer: "<your-issuer-domain>"

oidc:
  enabled: true
  server:
    # OIDC HTTP 服务器的端口
    port: 9080
  tls:
    # 为 OIDC HTTP 服务器启用 TLS
    enabled: true
    # OIDC HTTP 服务器的 TLS 证书文件
    certFile: "<path-to-tls-cert.pem>"
    # OIDC HTTP 服务器的 TLS 证书文件
    keyFile: "<path-to-tls-key.pem>"

提供这些设置后，在提供的 OIDC HTTP 端口上的 Dapr Sentry 安装上会公开以下端点：

/.well-known/openid-configuration
/jwks.json

您还需要提供 Dapr 运行时配置以请求具有 Azure 受众 api://AzureADTokenExchange 的 JWT 令牌。 在独立模式下运行时，可以使用标志 --sentry-request-jwt-audiences=api://AzureADTokenExchange 提供。 在 Kubernetes 上运行时，可以通过使用注解 "dapr.io/sentry-request-jwt-audiences": "api://AzureADTokenExchange" 修饰应用程序 Kubernetes 清单来提供。 这可确保 Sentry 服务颁发具有正确受众的 JWT 令牌，这是 Microsoft Entra ID 验证令牌所必需的。

为了使 Microsoft Entra ID 能够访问 OIDC 端点，您必须在公共地址上公开它们。您必须确保提供这些端点的域与配置 Dapr Sentry 时提供的颁发者相同。

现在您可以在 Microsoft Entra ID 中创建联合凭据。

cat > creds.json <<EOF
{ 
  "name": "DaprAppIDSpiffe",
  "issuer": "https://<your-issuer-domain>",
  "subject": spiffe://public/ns/<dapr-app-id-namespace>/<dapr-app-id>",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Credential for Dapr App ID"
}
EOF

export APP_ID=$(az ad app create --display-name my-dapr-app --enable-access-token-issuance --enable-id-token-issuance | jq .id)
az ad sp create --id $APP_ID
az ad app federated-credential create --id $APP_ID --parameters ./creds.json

现在您已经有了 Microsoft Entra ID 应用程序注册的联合凭据，可以为其服务主体分配所需的角色。

下面是分配"Storage Blob Data Owner"角色的示例。

az role assignment create --assignee-object-id $APP_ID --assignee-principal-type ServicePrincipal --role "Storage Blob Data Owner" --scope "/subscriptions/$SUBSCRIPTION/resourceGroups/$GROUP/providers/Microsoft.Storage/storageAccounts/$ACCOUNT_NAME"

要配置 Dapr 组件以使用联合凭据访问 Azure 资源，首先需要获取您的 clientId 和 tenantId：

CLIENT_ID=$(az ad app show --id $APP_ID --query appId --output tsv)
TENANT_ID=$(az account show --query tenantId --output tsv)

然后您可以创建 Azure Dapr 组件并只需提供这些值：

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azureblob
spec:
  type: state.azure.blobstorage
  version: v2
  initTimeout: 10s # 增加初始化超时以允许 Azure 有足够的时间执行令牌交换
  metadata:
  - name: clientId
    value: $CLIENT_ID
  - name: tenantId
    value:  $TENANT_ID
  - name: accountName
    value: $ACCOUNT_NAME
  - name: containerName
    value: $CONTAINER_NAME

Dapr 运行时使用这些详细信息通过 Microsoft Entra ID 进行身份验证，使用 Dapr Sentry 颁发的 JWT 令牌交换访问令牌以访问 Azure 资源。

使用 Azure CLI 凭据进行身份验证（仅限开发）

重要提示： 此身份验证方法仅建议用于开发。

此身份验证方法在本地计算机上开发时可能很有用。您需要：

• 已安装 Azure CLI
• 已成功使用 az login 命令进行身份验证

当 Dapr 在有 Azure CLI 凭据可用的主机上运行时，如果没有配置其他身份验证方法，组件可以使用这些凭据自动进行身份验证。

使用此身份验证方法不需要设置任何元数据选项。

在 Dapr 组件中的使用示例

在此示例中，您将设置一个使用 Microsoft Entra ID 进行身份验证的 Azure Key Vault 机密存储组件。

• 自托管
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureClientSecret
    value : "[your_client_secret]"

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
  namespace: default
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: "[your_keyvault_name]"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId
    value: "[your_client_id]"
  - name: azureCertificateFile
    value : "[pfx_certificate_file_fully_qualified_local_path]"

后续步骤

参考

• Microsoft Entra ID 应用凭据: Azure CLI 参考
• Azure 托管服务标识 (MSI) 概述
• 机密构建块
• 操作方法: 检索机密
• 操作方法: 在 Dapr 组件中引用机密
• 机密 API 参考

2.1.2 - 如何使用工作负载身份联合

本指南将帮助你配置 Kubernetes 集群，以在 Azure 上运行 Dapr 并使用工作负载身份联合。

它是什么？

工作负载身份联合 是一种让应用程序向 Azure 进行身份验证的方式，无需在发布过程中存储或管理凭据。

通过使用工作负载身份联合，任何在 Kubernetes 和 AKS 上运行并面向 Azure 的 Dapr 组件都可以透明地进行身份验证，无需额外配置。

指南

我们将演示如何针对 AKS 集群配置 Azure Key Vault 资源。你可以根据需要调整本指南，将其应用于不同的 Dapr Azure 组件。

在本操作指南中，我们将使用此 Dapr AKS secrets 示例应用。

前提条件

• 已启用工作负载身份的 AKS 集群
• Microsoft Entra ID 租户

1 - 启用工作负载身份联合

按照 在 AKS 集群上启用工作负载身份联合的 Azure 文档 进行操作。

该操作指南将引导你配置 Azure Entra ID 租户以信任来自 AKS 集群颁发者的身份。它还会指导你设置一个 Kubernetes 服务账户，该账户与你创建的 Azure 托管标识相关联。

完成后，返回此处继续执行步骤 2。

2 - 向 Azure Key Vault 添加密钥

在你创建的 Azure Key Vault 中，添加一个名为 dapr 的密钥，其值为 Hello Dapr!。

3 - 配置 Azure Key Vault dapr 组件

此时，你应该拥有一个名称类似于 workload-identity-sa0a1b2c 的 Kubernetes 服务账户。

将以下内容应用到你的 Kubernetes 集群，记得将 your-key-vault 替换为你的密钥保管库名称：

---
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: demo-secret-store # 请勿更改此名称，我们的应用将查找它。
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: your-key-vault # 替换

你会注意到，我们在组件定义中没有提供任何与身份验证相关的详细信息。这是有意为之，因为 Dapr 能够利用 Kubernetes 服务账户向 Azure 进行透明身份验证。

4 - 部署测试应用程序

前往 工作负载身份联合示例应用程序 并准备镜像的构建。

确保镜像已推送到你的 AKS 集群可见并有权拉取的注册表。

接下来，为我们的示例 AKS secrets 应用容器创建一个部署，同时包含一个 Dapr 边车。

记得将 dapr-wif-k8s-service-account 替换为你的服务账户名称，将 dapraksworkloadidentityfederation 替换为你的集群可以解析的镜像：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-dapr-wif-secrets
  labels:
    app: aks-dapr-wif-secrets
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-dapr-wif-secrets
  template:
    metadata:
      labels:
        app: aks-dapr-wif-secrets
        azure.workload.identity/use: "true" # 重要
      annotations:
        dapr.io/enabled: "true" # 启用 Dapr
        dapr.io/app-id: "aks-dapr-wif-secrets"
    spec:
      serviceAccountName: dapr-wif-k8s-service-account # 记得替换
      containers:
        - name: workload-id-demo
          image: dapraksworkloadidentityfederation # 记得替换
          imagePullPolicy: Always

应用程序启动并运行后，应该输出以下内容：

Fetched Secret: Hello dapr!

2.1.3 - 操作指南：生成新的 Microsoft Entra ID 应用程序和服务主体

前置条件

• Azure 订阅
• Azure CLI
• jq
• OpenSSL（默认包含在所有 Linux 和 macOS 系统以及 WSL 中）
• 确保您使用的是 bash 或 zsh shell

使用 Azure CLI 登录 Azure

在新的终端中，运行以下命令：

az login
az account set -s [your subscription id]

创建 Microsoft Entra ID 应用程序

使用以下命令创建 Microsoft Entra ID 应用程序：

# 应用程序 / 服务主体的友好名称
APP_NAME="dapr-application"

# 创建应用程序
APP_ID=$(az ad app create --display-name "${APP_NAME}"  | jq -r .appId)

选择您希望传递凭据的方式。

• Client secret
• PFX certificate

az ad app credential reset \
  --id "${APP_ID}" \
  --years 2

{
  "appId": "<your-app-id>",
  "password": "<your-password>",
  "tenant": "<your-azure-tenant>"
}

az ad app credential reset \
  --id "${APP_ID}" \
  --create-cert

{
  "appId": "<your-app-id>",
  "fileWithCertAndPrivateKey": "<file-path>",
  "password": null,
  "tenant": "<your-azure-tenant>"
}

创建服务主体

创建 Microsoft Entra ID 应用程序后，为该应用程序创建服务主体。使用此服务主体，您可以授予其对 Azure 资源的访问权限。

要创建服务主体，请运行以下命令：

SERVICE_PRINCIPAL_ID=$(az ad sp create \
  --id "${APP_ID}" \
  | jq -r .id)
echo "Service Principal ID: ${SERVICE_PRINCIPAL_ID}"

预期输出：

Service Principal ID: 1d0ccf05-5427-4b5e-8eb4-005ac5f9f163

上面返回的值是 服务主体 ID，它不同于 Microsoft Entra ID 应用程序 ID（客户端 ID）。服务主体 ID 在 Azure 租户内定义，用于授予应用程序对 Azure 资源的访问权限。

您将使用服务主体 ID 来授予应用程序访问 Azure 资源的权限。

同时，客户端 ID 由您的应用程序用于身份验证。您将在 Dapr 清单中使用客户端 ID 来配置与 Azure 服务的身份验证。

请记住，刚刚创建的服务主体默认情况下无权访问任何 Azure 资源。需要根据需要授予对每个资源的访问权限，如组件文档中所述。

后续步骤

2.1.4 - 如何：使用托管标识

使用托管标识时，身份验证会自动进行，因为你的应用程序运行在已启用系统托管标识或用户分配标识的 Azure 服务之上。

要开始使用，你需要在各种 Azure 服务中启用托管标识作为服务选项/功能，这与 Dapr 无关。启用此功能会在底层为 Microsoft Entra ID（以前称为 Azure Active Directory ID）创建一个标识（或应用程序）。

然后，你的 Dapr 服务可以利用该标识与 Microsoft Entra ID 进行身份验证，这一过程是透明的，无需你指定任何凭据。

在本指南中，你将学习如何：

• 通过官方 Azure 文档向你的标识授予对正在使用的 Azure 服务的访问权限
• 在你的组件中设置系统托管标识或用户分配标识

大概就是这么多了。

向服务授予权限

为特定的 Azure 资源（由资源范围标识）设置所需的 Microsoft Entra ID 角色分配或自定义权限，以应用于你的系统托管标识或用户分配标识。

你可以将托管标识设置到新的或现有的 Azure 资源上。具体说明取决于所使用的服务。请查看以下官方文档以获取最合适的说明：

• Azure Kubernetes Service (AKS)
• Azure Container Apps (ACA)
• Azure App Service（包括 Azure Web Apps 和 Azure Functions）
• Azure Virtual Machines (VM)
• Azure Virtual Machines Scale Sets (VMSS)
• Azure Container Instance (ACI)

在将系统托管标识分配给你的 Azure 资源后，你将获得类似以下的凭据：

{
    "principalId": "<object-id>",
    "tenantId": "<tenant-id>",
    "type": "SystemAssigned",
    "userAssignedIdentities": null
}

从返回的值中，请注意 principalId 值，这是为你的标识创建的服务主体 ID。使用该值授予你的 Azure 资源组件访问该标识的权限。

在组件中设置标识

默认情况下，Dapr Azure 组件会查找其运行环境的系统托管标识并以此身份进行身份验证。通常，对于给定组件，除了服务名称、存储帐户名称以及 Azure 服务所需的任何其他属性（在文档中列出）之外，使用系统托管标识不需要其他必需属性。

对于用户分配标识，除了所使用服务所需的基本属性外，你还需要在组件中指定 azureClientId（用户分配标识 ID）。确保用户分配标识已附加到运行 Dapr 的 Azure 服务上，否则你将无法使用该标识。

以下示例演示如何在 Azure KeyVault secrets 组件中设置系统托管标识或用户分配标识。

• 系统托管
• 用户分配
• Kubernetes

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
  - name: vaultName
    value: mykeyvault
  - name: azureClientId
    value: someAzureIdentityClientIDHere

故障排除

如果你收到错误或托管标识未按预期工作，请检查以下项目是否为真：

• 系统托管标识或用户分配标识在目标资源上没有所需的权限。

• 用户分配标识未附加到正在加载组件的 Azure 服务（容器应用或 Pod）。这种情况特别可能发生在：

  • 你有一个未限定范围的组件（一个由环境中所有容器应用或 AKS 集群中所有部署加载的组件）。
  • 你只将用户分配标识附加到一个容器应用或 AKS 中的一个部署（使用 Azure Workload Identity）。

  在此场景中，由于标识未附加到 AKS 中的每个其他容器应用或部署，因此通过 azureClientId 引用用户分配标识的组件会失败。

最佳实践： 使用用户分配标识时，请务必将组件范围限定到特定应用！

后续步骤

2.2 - Azure API Management 的 Dapr 集成策略

Azure API Management 是为后端服务（包括使用 Dapr 构建的服务）创建一致且现代化的 API 网关的一种方式。你可以在自托管的 API Management 网关中启用 Dapr 支持，以允许它们：

• 将请求转发到 Dapr 服务
• 向 Dapr 发布订阅主题发送消息
• 触发 Dapr 输出绑定

试一试 Dapr 与 Azure API Management 集成示例。

2.3 - Dapr extension for Azure Functions runtime

Dapr 通过一个扩展与 Azure Functions runtime 集成，使函数能够与 Dapr 无缝交互。

• Azure Functions 提供事件驱动的编程模型。
• Dapr 提供云原生构建块。

该扩展将两者结合，用于无服务器和事件驱动应用。

2.4 - 适用于 Azure Kubernetes Service (AKS) 的 Dapr 扩展

在 AKS 上安装 Dapr 的推荐方法是使用 AKS Dapr 扩展。该扩展提供以下功能：

• 通过 Azure CLI 命令行参数支持所有原生 Dapr 配置功能
• 可选择启用 Dapr 运行时的自动次版本升级

使用 AKS 的 Dapr 扩展的前提条件：

• Azure 订阅
• 最新版本的 Azure CLI
• 现有的 AKS 集群
• Azure Kubernetes Service RBAC 管理员角色

3 - Diagrid 集成

3.1 - Conductor: Enterprise Dapr for Kubernetes

Diagrid Conductor 快速安全地连接到所有运行 Dapr 和 Daprized applications 的 Kubernetes 集群，提供卓越的运维、安全可靠性和洞察协作能力。

自动化 Dapr 管理

一键安装、升级和修补 Dapr，支持选择性应用更新和自动回滚，确保您始终保持最新状态。

Advisor：发现并自动化最佳实践

获取并应用生产环境最佳实践，通过持续检查防止配置错误，提升安全性、可靠性和性能。

资源使用报告和跟踪

通过研究历史资源使用行为，推荐应用资源优化方案，在 CPU 和内存方面实现显著的成本节约。

应用可视化

应用图通过提供服务和基础设施组件的动态概览，促进开发与运维之间的协作。

4 - 如何：使用 KEDA 自动扩缩 Dapr 应用

Dapr 采用构建块 API 方式，并提供众多发布订阅组件，这使得编写消息处理应用变得轻而易举。由于 Dapr 可以在多种环境中运行（例如虚拟机、物理机、云或边缘 Kubernetes），因此 Dapr 应用的自动扩缩由托管层管理。

对于 Kubernetes，Dapr 与 KEDA 集成，KEDA 是一个面向 Kubernetes 的事件驱动自动扩缩器。Dapr 的许多发布订阅组件与 KEDA 提供的扩缩器重叠，因此可以轻松配置 Dapr 在 Kubernetes 上的部署，基于背压使用 KEDA 进行自动扩缩。

在本指南中，你将配置一个可扩缩的 Dapr 应用，以及 Kafka topic 上的背压。但是，你可以将此方法应用于 Dapr 提供的_任意_ 发布订阅组件。

安装 KEDA

要安装 KEDA，请按照 KEDA 网站上的部署 KEDA 说明进行操作。

安装并部署 Kafka

如果你没有 Kafka 服务，可以使用 Helm 将其安装到 Kubernetes 集群中：

helm repo add confluentinc https://confluentinc.github.io/cp-helm-charts/
helm repo update
kubectl create ns kafka
helm install kafka confluentinc/cp-helm-charts -n kafka \
		--set cp-schema-registry.enabled=false \
		--set cp-kafka-rest.enabled=false \
		--set cp-kafka-connect.enabled=false

查看 Kafka 部署状态：

kubectl rollout status deployment.apps/kafka-cp-control-center -n kafka
kubectl rollout status deployment.apps/kafka-cp-ksql-server -n kafka
kubectl rollout status statefulset.apps/kafka-cp-kafka -n kafka
kubectl rollout status statefulset.apps/kafka-cp-zookeeper -n kafka

安装完成后，部署 Kafka 客户端并等待其就绪：

kubectl apply -n kafka -f deployment/kafka-client.yaml
kubectl wait -n kafka --for=condition=ready pod kafka-client --timeout=120s

创建 Kafka topic

创建本示例使用的 topic（demo-topic）：

kubectl -n kafka exec -it kafka-client -- kafka-topics \
		--zookeeper kafka-cp-zookeeper-headless:2181 \
		--topic demo-topic \
		--create \
		--partitions 10 \
		--replication-factor 3 \
		--if-not-exists

topic 的 partitions 数量与 KEDA 为你的部署创建的最大副本数相关。

部署 Dapr 发布订阅组件

为 Kubernetes 部署 Dapr Kafka 发布订阅组件。将以下 YAML 粘贴到名为 kafka-pubsub.yaml 的文件中：

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: autoscaling-pubsub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
    - name: brokers
      value: kafka-cp-kafka.kafka.svc.cluster.local:9092
    - name: authRequired
      value: "false"
    - name: consumerID
      value: autoscaling-subscriber

以上 YAML 定义了你的应用订阅的发布订阅组件，即你之前创建的 topic（demo-topic）。

如果你按照 Kafka Helm 安装说明 操作，可以保留 brokers 值不变。否则，请将此值更改为你的 Kafka brokers 连接字符串。

注意为 consumerID 设置的 autoscaling-subscriber 值。此值稍后用于确保 KEDA 和你的部署使用相同的 Kafka partition offset。

现在，将组件部署到集群：

kubectl apply -f kafka-pubsub.yaml

部署 KEDA Kafka 扩缩器

部署 KEDA 扩缩对象，它会：

• 监控指定 Kafka topic 上的 lag
• 配置 Kubernetes Horizontal Pod Autoscaler (HPA) 以扩缩你的 Dapr 部署

将以下内容粘贴到名为 kafka_scaler.yaml 的文件中，并在所需位置配置你的 Dapr 部署：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: subscriber-scaler
spec:
  scaleTargetRef:
    name: <REPLACE-WITH-DAPR-DEPLOYMENT-NAME>
  pollingInterval: 15
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
  - type: kafka
    metadata:
      topic: demo-topic
      bootstrapServers: kafka-cp-kafka.kafka.svc.cluster.local:9092
      consumerGroup: autoscaling-subscriber
      lagThreshold: "5"

让我们回顾一下上述文件中的几个元数据值：

将 KEDA 扩缩器部署到 Kubernetes：

kubectl apply -f kafka_scaler.yaml

全部完成！

查看 KEDA 扩缩器工作

现在 ScaledObject KEDA 对象已配置，你的部署将根据 Kafka topic 的 lag 进行扩缩。了解有关为 Kafka topics 配置 KEDA 的更多信息。

按照 KEDA 扩缩器清单中的定义，你现在可以开始向 Kafka topic demo-topic 发布消息，并观察当 lag 阈值高于 5 时 pod 自动扩缩。使用 Dapr Publish CLI 命令向 Kafka Dapr 组件发布消息。

后续步骤

了解如何在 Azure Container Apps 中使用 KEDA 扩缩 Dapr 发布订阅或绑定应用

5 - 如何：在 GitHub Actions 工作流中使用 Dapr CLI

Dapr 可以通过 GitHub Marketplace 中的 Dapr tool installer 与 GitHub Actions 集成。该安装程序将 Dapr CLI 添加到你的工作流，使你能够在各个环境中部署、管理和升级 Dapr。

通过 Dapr 工具安装程序安装 Dapr CLI

将以下安装程序代码片段复制并粘贴到应用程序的 YAML 文件中：

- name: Dapr tool installer
  uses: dapr/setup-dapr@v1

dapr/setup-dapr action 会在 macOS、Linux 和 Windows 运行器上安装指定版本的 Dapr CLI。安装完成后，你可以运行任何 Dapr CLI 命令 来管理 Dapr 环境。

有关所有输入的详细信息，请参阅 action.yml 元数据文件。

示例

例如，对于使用 Azure Kubernetes Service (AKS) 的 Dapr 扩展 的应用程序，应用程序 YAML 将如下所示：

- name: Install Dapr
  uses: dapr/setup-dapr@v1
  with:
    version: '1.18.0'

- name: Initialize Dapr
  shell: bash
  run: |
    # Get the credentials to K8s to use with dapr init
    az aks get-credentials --resource-group ${{ env.RG_NAME }} --name "${{ steps.azure-deployment.outputs.aksName }}"

    # Initialize Dapr    
    # Group the Dapr init logs so these lines can be collapsed.
    echo "::group::Initialize Dapr"
    dapr init --kubernetes --wait --runtime-version ${{ env.DAPR_VERSION }}
    echo "::endgroup::"

    dapr status --kubernetes
  working-directory: ./demos/demo3

后续步骤

• 了解更多关于 GitHub Actions 的信息。

6 - 操作指南：使用 Dapr Kubernetes Operator

您可以使用 Dapr Kubernetes Operator 来管理 Dapr 控制平面。使用 operator 可以自动化管理 Kubernetes 模式下 Dapr 控制平面生命周期所需的任务。

7 - 如何：与 Kratix 集成

作为 Kratix Marketplace 的一部分，Dapr 可用于构建满足您需求的定制平台。

只需安装 Dapr Promise 即可开始使用，它会在所有匹配的集群上安装 Dapr。

8 - 操作指南：与 Argo CD 集成

Argo CD 是一个用于 Kubernetes 的声明式、GitOps 持续交付工具。它使您能够通过跟踪 Git 仓库中所需的应用程序状态并自动将其同步到集群来管理 Kubernetes 部署。

与 Dapr 集成

您可以使用 Argo CD 来管理 Dapr 控制平面组件和启用 Dapr 的应用程序的部署。通过采用 GitOps 方法，您可以确保 Dapr 的配置和应用程序在您的各个环境中以一致的方式部署、版本化和审计。Argo CD 可以轻松配置为部署存储在 Git 仓库中的 Helm charts、manifests 和 Dapr 组件。

示例代码

一个演示使用 Argo CD 部署 Dapr 的示例项目可在 https://github.com/dapr/samples/tree/master/dapr-argocd 获取。