5.2. 使用主题 Operator

KafkaTopic 资源包含一个标签，用于定义它所属的 Kafka 集群名称（从 Kafka 资源的名称衍生）。

例如：

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaTopic
metadata:
  name: topic-name-1
  labels:
    strimzi.io/cluster: my-cluster

该标签供主题 Operator 用于标识 KafkaTopic 资源、创建一个新主题，以及后续处理该主题。

如果标签与 Kafka 集群不匹配，主题 Operator 无法识别 KafkaTopic，且不会创建该主题。

Topic Operator 必须解决的一个根本问题是没有单一数据源：KafkaTopic 资源和 Kafka 主题都可以独立于 Operator 修改。复杂的情况是，Topic Operator 可能无法实时观察每个末尾的更改（例如，操作器可能会停机）。

为解决这个问题，操作员会保留自己的专用副本，其中包含每个主题的信息。当 Kafka 集群或 OpenShift 中发生更改时，它会同时查看其他系统的状态及其私有副本，以确定需要更改的内容以保持一切同步。每当操作器启动时都会发生同样的事情，并在操作器运行时定期进行。

例如，假设主题 Operator 未在运行，并创建一个 KafkaTopic my-topic。当 Operator 启动时，它将缺少"my-topic"的私有副本，因此可以推断出 KafkaTopic 自上次运行以来已创建。操作器将创建与 my-topic 对应的主题，同时存储 my-topic 的元数据私有副本。

私有副本允许操作员应对在 Kafka 和 OpenShift 中主题配置都已更改的情况，只要这些更改不兼容（例如，更改同一主题配置键，但更改为不同的值）。如果出现不兼容的更改，Kafka 配置胜出，KafkaTopic 将更新来反映这一点。

私有副本保存在 Kafka 本身使用的同一 ZooKeeper 识别中。这缓解了可用性问题，因为如果 ZooKeeper 没有运行，则 Kafka 本身将无法运行，因此即使其无状态也少于 Operator 的可用性。

处理主题时，应保持一致。始终在 OpenShift 中直接对 KafkaTopic 资源或主题运行。对于给定主题，避免在这两种方法之间进行定期切换。

使用反映主题性质的主题名称，并记住以后无法更改名称。

如果在 Kafka 中创建主题，请使用有效的 OpenShift 资源名称，否则 Topic Operator 将需要使用符合 OpenShift 规则的名称创建对应的 KafkaTopic。

Kafka 和 OpenShift 分别为 Kafka 和 KafkaTopic.metadata.name 中的主题命名实施自己的验证规则。每个名称都无效。

使用 spec.topicName 属性，可以在 Kafka 中创建有效的主题，其名称对 OpenShift 中的 Kafka 主题无效。

spec.topicName 属性继承 Kafka 命名验证规则：

不得更改 spec.topicName。

例如：

apiVersion: {KafkaApiVersion}
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: topicName-1 1
  # ...

不能改为：

apiVersion: {KafkaApiVersion}
kind: KafkaTopic
metadata:
  name: topic-name-1
spec:
  topicName: name-2
  # ...