配置 - D2iQ Docs

默认 DC/OS Apache Kafka 安装为试行服务提供合理的默认设置，但可能不足以支持生产使用。根据部署的上下文，您可能需要不同的配置。

使用自定义配置安装

以下是如何自定义安装 Apache Kafka 实例的一些例子。

在每个例子中，您将使用自定义配置创建一个新的 Apache Kafka 实例，如下所示：

$ dcos package install kafka --options=sample-kafka.json

建议： 将自定义配置存储在源控件中。

安装多个实例

默认情况下，Apache Kafka 服务安装名称为 kafka 的服务。您可以使用如下自定义服务配置来指定不同的名称：

{
  "service": {
    "name": "kafka-other"
  }
}

当上述 JSON 配置通过 --options 自变量被传递到 package install kafka 命令时，新服务将使用 JSON 配置中指定的名称：

$ dcos package install kafka --options=kafka-other.json

可以通过自定义每个实例的名称将多个 Apache Kafka 实例安装到 DC/OS 群集中。例如，您可能有一个名为 kafka-staging 和另一个名为 kafka-prod的 Apache Kafka 实例，每个都具有各自的自定义配置。

为实例指定自定义名称后，可以使用 dcos kafka CLI 命令或直接通过 HTTP 接触实例，如下所述以下。

注意： 初次安装后，服务名称不能更改。更改服务名称需要根据新名称安装服务的新实例，然后根据需要复制任何数据到新实例。

安装到文件夹中

在 DC/OS 1.10 及更高版本中，可以通过指定斜线分隔的服务名称将服务安装到文件夹中。例如：

{
  "service": {
    "name": "/foldered/path/to/kafka"
  }
}

以上示例将在路径 foldered => path => to => kafka 中安装服务。然后可以使用 dcos kafka CLI 命令或直接通过 HTTP 接触服务，如下所述以下。

注意：初次安装后，服务文件夹位置不能更改。更改服务位置需要针对新位置安装服务的新实例，然后根据需要复制任何数据到新实例。

寻址已命名实例

使用自定义名称或在文件夹下安装服务之后，可以使用 --name 自变量从所有 dcos kafka CLI 命令访问该服务。默认情况下，--name 值默认为包名称，或 kafka。

例如，如果您有一个名为 kafka-dev的实例，以下命令将针对它调用 pod list 命令：

$ dcos kafka --name=kafka-dev pod list

相同的查询将通过 HTTP 执行，如下所示：

$ curl -H "Authorization:token=$auth_token" <dcos_url>/service/kafka-dev/v1/pod

同样，如果您在文件夹中有一个类似 /foldered/path/to/kafka的实例，以下命令将针对它调用 pod list 命令：

$ dcos kafka --name=/foldered/path/to/kafka pod list

类似地，可以直接通过 HTTP 查询，如下所示：

$ curl -H "Authorization:token=$auth_token" <dcos_url>/service/foldered/path/to/kafka-dev/v1/pod

您可以添加 -v （详细）自变量到任何 dcos kafka 命令以查看正在进行的潜在 HTTP 查询。这是查看 CLI 在何处获取信息的有用工具。在实践中，dcos kafka 命令是由 DC/OS Apache Kafka 服务本身提供的 HTTP 接口的瘦包装器。

与 DC/OS 访问控制集成

在 Enterprise DC/OS 中，可以使用 DC/OS 访问控制来限制对服务的访问。要让非超级用户完全访问服务，向其授予以下权限列表：

dcos:adminrouter:service:marathon full
dcos:service:marathon:marathon:<service-name> full
dcos:adminrouter:ops:mesos full
dcos:adminrouter:ops:slave full

其中 <service-name> 是您的完整服务名称，包括文件夹（如果安装在文件夹中）。

服务设置

布局约束

布局约束允许您自定义 DC/OS 群集中部署服务的位置。布局约束使用 Marathon 运营商语法。例如，[["hostname", "UNIQUE"]] 确保每个代理最多部署一个 Pod。

通用任务是指定要对其进行部署的白名单系统列表。为此，请使用以下语法用于布局约束：

[["hostname", "LIKE", "10.0.0.159|10.0.1.202|10.0.3.3"]]

注意: 请务必在这种情境中包括超额容量，以便如果白名单系统中的一个系统性能下降，还有足够的容量修复您的服务。

更新布局约束

群集更改，因此布局约束也随之变化。但是，已经运行的服务 Pod 将不会受到布局约束变化的影响。这是因为更改布局约束可能会使得当前运行的 pod 的当前布局失效，而且 Pod 不会自动被重新布置，因为这样做是破坏性的操作。我们建议使用以下程序更新 Pod 的布局约束：

更新服务中的布局约束定义。
对每个受影响的 Pod，一次执行一个 pod replace。这将（破坏性地）移动 Pod 使其符合新的布局约束。

区

需要： DC/OS 1.11 Enterprise 或更高版本。

通过引用 @zone 键，布局约束可以应用于 DC/OS 区。例如，可以通过包括此约束在最少三个不同区中扩散 Pod：

[["@zone", "GROUP_BY", "3"]]

注意： 安装时不带有区约束的服务无法更新为有约束的服务，而安装时带有区约束的服务可能无法删除此约束。

虚拟网络

DC/OS Apache Kafka 支持在 DC/OS 的虚拟网络上进行部署（包括 dcos 覆盖网络），允许每个容器（任务）拥有自己的 IP 地址，而不使用代理机器上的端口资源。这可以通过在安装过程中传递以下配置来指定：

{
  "service": {
    "virtual_network_enabled": true
  }
}

注意： 服务在虚拟网络上部署后，就无法将其更新以使用主机网络。

区域

服务参数 region 可用于在一个替换区域中部署服务。默认情况下，服务部署在“本地”区域，这是运行 DC/OS 管理节点的区域。要在特定原因下安装服务，在其选项中包含：

{
  "service": {
    "region": "<region>"
  }
}

注意：服务不能在区域之间移动。

配置 ZooKeeper 连接

Apache Kafka 需要运行 ZooKeeper ensemble 来执行其自身的内部会计。默认情况下，DC/OS Apache Kafka 服务使用位于 master.mesos:2181/dcos-service- 的 DC/OS 集群中 Mesos 管理节点上提供的 ZooKeeper ensemble。在安装期间，您可以配置备用的 ZooKeeper，以便 Apache Kafka 进行使用。这可以让您增加 Apache Kafka 的容量并移除 DC/OS 系统 ZooKeeper ensemble 参与运行。

配置备用的 Zookeeper 实例：

创建名为 options.json 的文件以及以下内容。

注意： 如果您正在使用 DC/OS Apache ZooKeeper 服务，则使用由 dcos kafka-zookeeper endpoints clientport 命令提供的 DNS 地址，作为 kafka_zookeeper_uri 的值。

这是一个示例 options.json，指向名为 kafka-zookeeper 的 kafka-zookeeper 实例：

{
  "kafka": {
    "kafka_zookeeper_uri": "zookeeper-0-server.kafka-zookeeper.autoip.dcos.thisdcos.directory:1140,zookeeper-1-server.kafka-zookeeper.autoip.dcos.thisdcos.directory:1140,zookeeper-2-server.kafka-zookeeper.autoip.dcos.thisdcos.directory:1140"
  }
}

通过您创建的选项文件来安装 Apache Kafka 。

$ dcos package install kafka --options="options.json"

您也可以从 DC/OS CLI 更新已经运行的 Apache Kafka 的实例，以防您需要在其他地方迁移 ZooKeeper 数据。

注意： 执行此配置更改之前，您必须先将当前 ZooKeeper ensemble 中的数据复制到新的 ZooKeeper ensemble。在迁移过程中，新位置的数据必须与上一个位置相同。

$ dcos kafka --name=kafka update start --options=options.json

延长终止宽限期

执行请求的重新启动或更换运行中的 broker 时，Kafka 服务在终止进程之前将等待 30 秒钟（默认），让 broker 退出。此宽限期可通过 brokers.kill_grace_period 进行定制。在本示例中，我们将使用 DC/OS CLI 将宽限期延迟增加到 60 秒。此示例假设 Kafka 服务实例命名为 kafka。

在配置更新期间，每个 Kafka broker 任务已重启。在任务重新启动的关闭期间，之前 brokers.kill_grace_period 的配置值有效。关闭后，每个 broker 任务都会使用新的有效配置值启动。通过观察其日志来监控 Kafka broker 完全关闭所需的时间。

将 Broker 替换为 Grace

如果 broker 在替换前关闭，则必须尊重宽限期。尽管 broker 必须尊重宽限期（即使它将失去持久状态）这种方式并不理想，但是在 SDK 的未来版本中，这种行为将会得到改进。如果不是正常关闭，那么 broker 替换通常需要在启动时进行复杂且耗时的调解活动，因此，在大多数情况下，对终止宽限期的尊重仍具有价值。我们建议设置仅足以允许正常关闭的终止宽限期。监控 Kafka broker 日志中的 broker 完全关闭时间，从而使此值与流过 Kafka 服务的数据规模进行协调。

配置

配置 Kafka 和 ZooKeeper