Dapr 服务概述

• 1: Dapr sidecar (daprd) 概述
• 2: Dapr Operator 控制平面服务概述
• 3: Dapr Placement 控制平面服务概述
• 4: Dapr Scheduler 控制平面服务概述
• 5: Dapr Sentry 控制平面服务概述
• 6: Dapr Sidecar Injector 控制平面服务概述

1 - Dapr sidecar (daprd) 概述

Dapr 采用 sidecar 模式，这意味着 Dapr API 运行在一个独立的进程中，即 Dapr sidecar，并与您的应用程序一起运行。Dapr sidecar 进程命名为 daprd，并根据托管环境以不同的方式启动。

Dapr sidecar 提供以下功能：

• 应用程序业务逻辑使用的 构建块 API
• 用于发现功能和设置属性的 元数据 API
• 用于检查健康状态和 sidecar 准备及存活状态的 健康 API

当应用程序在其配置的端口上可访问时，Dapr sidecar 即达到准备状态。在应用程序启动或初始化期间，应用程序暂时无法访问 Dapr 组件。

应用程序通过本地 http 或 gRPC 端点调用 sidecar API。

使用 dapr run 的自托管

在 自托管模式 下安装 Dapr 时，daprd 二进制文件会被下载并放置在用户主目录下（Linux/macOS 为 $HOME/.dapr/bin，Windows 为 %USERPROFILE%\.dapr\bin\）。

在自托管模式下，使用 Dapr CLI 的 run 命令 会启动 daprd 可执行文件，并运行您提供的应用程序可执行文件。这是在本地进行开发和测试等场景中运行 Dapr sidecar 的推荐方式。

您可以在 Dapr run 命令参考 中找到 CLI 提供的用于配置 sidecar 的各种参数。

在 Kubernetes 中使用 dapr-sidecar-injector

在 Kubernetes 上，Dapr 控制平面包括 dapr-sidecar-injector 服务，它监视带有 dapr.io/enabled 注释的新 pod，并在 pod 内注入一个包含 daprd 进程的容器。在这种情况下，可以通过注释传递 sidecar 参数，如 此表 中的 Kubernetes 注释 列所述。

直接运行 sidecar

在大多数情况下，您不需要显式运行 daprd，因为 sidecar 要么由 CLI（自托管模式）启动，要么由 dapr-sidecar-injector 服务（Kubernetes）启动。对于高级用例（如调试、脚本化部署等），可以直接启动 daprd 进程。

要获取所有可用参数的详细列表，请运行 daprd --help 或查看 此表，该表概述了 daprd 参数与 CLI 参数和 Kubernetes 注释的关系。

示例

1. 通过指定其唯一 ID 启动与应用程序一起的 sidecar。

   注意： --app-id 是必填字段，且不能包含点。

   daprd --app-id myapp
   

2. 指定您的应用程序正在监听的端口

   daprd --app-id myapp --app-port 5000
   

3. 如果您使用了多个自定义资源并希望指定资源定义文件的位置，请使用 --resources-path 参数：

   daprd --app-id myapp --resources-path <PATH-TO-RESOURCES-FILES>
   

4. 如果您已将组件和其他资源（例如，弹性策略、订阅或配置）组织到单独的文件夹或共享文件夹中，您可以指定多个资源路径：

   daprd --app-id myapp --resources-path <PATH-1-TO-RESOURCES-FILES> --resources-path <PATH-2-TO-RESOURCES-FILES>
   

5. 在运行应用程序时启用 Prometheus 指标收集

   daprd --app-id myapp --enable-metrics
   

6. 仅监听 IPv4 和 IPv6 回环

   daprd --app-id myapp --dapr-listen-addresses '127.0.0.1,[::1]'
   

2 - Dapr Operator 控制平面服务概述

在 Kubernetes 模式下运行 Dapr 时，一个运行 Dapr Operator 服务的 pod 负责管理 Dapr 组件的更新，并为 Dapr 提供 Kubernetes 服务端点。

运行 Operator 服务

Operator 服务是 dapr init -k 部署过程的一部分，或者可以通过 Dapr Helm charts 部署。有关在 Kubernetes 上运行 Dapr 的更多信息，请访问 Kubernetes 托管页面。

其他配置选项

Operator 服务提供了一些额外的配置选项。

注入器监控功能

Operator 服务包含一个 注入器监控功能，它会定期检查 Kubernetes 集群中所有运行的 pod，确保那些标记了 dapr.io/enabled=true 的 pod 中正确注入了 Dapr sidecar。这个功能主要用于解决 注入器服务未能成功将 sidecar（daprd 容器）注入 pod 的问题。

注入器监控功能在以下情况下可能会很有帮助：

• 从完全停止的 Kubernetes 集群中恢复。当集群完全停止后再启动时（包括在集群完全故障的情况下），pod 会以随机顺序重启。如果您的应用程序在 Dapr 控制平面（特别是注入器服务）准备好之前重启，Dapr sidecar 可能不会注入到您的应用程序的 pod 中，导致应用程序行为异常。

• 解决 sidecar 注入器可能出现的随机故障，例如注入器服务中的瞬时故障。

如果监控功能发现某个 pod 缺少 sidecar，而它本应该有一个，它会删除该 pod。然后 Kubernetes 会重新创建该 pod，并再次调用 Dapr sidecar 注入器。

注入器监控功能默认是禁用的。

您可以通过向 operator 命令传递 --watch-interval 标志来启用它，该标志可以取以下值之一：

• --watch-interval=0：禁用注入器监控功能（如果省略该标志，则为默认值）。
• --watch-interval=<interval>：启用注入器监控功能，并在给定的间隔检查所有 pod；间隔的值是一个包含单位的字符串。例如：--watch-interval=10s（每 10 秒）或 --watch-interval=2m（每 2 分钟）。
• --watch-interval=once：注入器监控功能仅在 Operator 服务启动时运行一次。

如果您使用 Helm，可以使用 dapr_operator.watchInterval 选项配置注入器监控功能，该选项的值与命令行标志相同。

当 Operator 服务以 HA（高可用性）模式运行且有多个副本时，注入器监控功能是安全的。在这种情况下，Kubernetes 会自动选举一个“领导”实例，该实例是唯一运行注入器监控服务的实例。

然而，在 HA 模式下，如果您将注入器监控功能配置为“once”运行，则每次 Operator 服务的一个实例被选为领导时，监控功能都会启动。这意味着，如果 Operator 服务的领导崩溃并选出新的领导，这将再次触发注入器监控功能。

观看此视频以了解注入器监控功能的概述：

GET http://localhost:<healthzPort>/placement/state

 curl localhost:8080/placement/state

{
    "hostList": [{
            "name": "198.18.0.1:49347",
            "namespace": "ns1",
            "appId": "actor1",
            "actorTypes": ["testActorType1", "testActorType3"],
            "updatedAt": 1690274322325260000
        },
        {
            "name": "198.18.0.2:49347",
            "namespace": "ns2",
            "appId": "actor2",
            "actorTypes": ["testActorType2"],
            "updatedAt": 1690274322325260000
        },
        {
            "name": "198.18.0.3:49347",
            "namespace": "ns2",
            "appId": "actor2",
            "actorTypes": ["testActorType2"],
            "updatedAt": 1690274322325260000
        }
    ],
    "tableVersion": 1
}

4 - Dapr Scheduler 控制平面服务概述

Dapr Scheduler 服务概述

Dapr Scheduler 服务用于作业调度，可以在自托管模式或Kubernetes上运行。

下图展示了如何通过作业 API 从您的应用程序调用 Scheduler 服务。Scheduler 服务跟踪的所有作业都存储在嵌入式 Etcd 数据库中。

actor 提醒

在 Dapr v1.15 之前，actor 提醒是通过 Placement 服务运行的。现在，默认情况下，SchedulerReminders 功能标志被设置为 true，您创建的所有新 actor 提醒都通过 Scheduler 服务运行，以提高其可扩展性。

当您部署 Dapr v1.15 时，所有现有的 actor 提醒会从 Placement 服务迁移到 Scheduler 服务。这是针对每种 actor 类型的一次性迁移操作。您可以通过在 actor 类型的应用程序配置文件中将 SchedulerReminders 标志设置为 false 来阻止此迁移。

自托管模式

Scheduler 服务的 Docker 容器作为 dapr init 的一部分自动启动。如果您在精简初始化模式下运行，也可以手动作为进程运行。

Kubernetes 模式

Scheduler 服务作为 dapr init -k 的一部分或通过 Dapr Helm 图表部署。您可以在高可用性模式下运行 Scheduler。了解更多关于在 Kubernetes 服务中设置高可用性模式的信息。

有关在 Kubernetes 上运行 Dapr 的更多信息，请访问Kubernetes 托管页面。

相关链接

了解更多关于作业 API 的信息。

5 - Dapr Sentry 控制平面服务概述

Dapr Sentry 服务概述

Dapr Sentry 服务负责管理服务之间的 mTLS，并作为证书颁发机构。它生成 mTLS 证书并将其分发给所有正在运行的 sidecar。这样，sidecar 可以通过加密的 mTLS 流量进行通信。有关更多信息，请阅读 sidecar-to-sidecar 通信概述。

自托管模式

Sentry 服务的 Docker 容器不会作为 dapr init 的一部分自动启动。不过，您可以按照 mutual TLS 的设置说明手动启动。

如果您在 slim-init 模式 下运行，也可以手动以进程的方式启动。

Kubernetes 模式

Sentry 服务可以通过 dapr init -k 或使用 Dapr Helm Chart 部署。有关在 Kubernetes 上运行 Dapr 的更多信息，请访问 Kubernetes 托管页面。

进一步阅读

• 安全概述
• 自托管模式
• Kubernetes 模式