9.3. 配置节点池
更新 KafkaNodePool
自定义资源的 spec
属性来配置节点池部署。
节点池指的是 Kafka 集群中不同的 Kafka 节点组。每个池都有自己的唯一的配置,其中包括副本、角色和存储分配数量的强制设置。
另外,您还可以为以下属性指定值:
-
指定内存和 cpu 请求和限值
的资源
-
模板
为 Pod 和其他 OpenShift 资源指定自定义配置 -
jvmOptions
,用于指定堆大小、运行时和其他选项的自定义 JVM 配置
Kafka
资源代表 Kafka 集群中所有节点的配置。KafkaNodePool
资源仅代表节点池中的节点的配置。如果没有在 KafkaNodePool
中指定配置属性,它将继承自 Kafka
资源。如果在两个资源中设置,则 KafkaNodePool
资源中指定的配置具有优先权。例如,如果节点池和 Kafka 配置都包含 jvmOptions
,则使用节点池配置中指定的值。当在 KafkaNodePool.spec.jvmOptions
中设置了 -Xmx: 1024m
,在 Kafka.spec.kafka.jvmOptions
中设置了 -Xms: 512m
,节点会使用其节点池配置中的值。
Kafka
和 KafkaNodePool
模式的属性不会被合并。为了说明,如果 KafkaNodePool.spec.template
只包含 podSet.metadata.labels
,并且 Kafka.spec.kafka.template
包含 podSet.metadata.annotations
和 pod.metadata.labels
,则 Kafka 配置中的模板值会被忽略,因为节点池配置中有一个模板值。
要深入了解节点池配置选项,请参阅 Apache Kafka 自定义资源 API 参考。
使用 KRaft 模式的集群中节点池的配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: kraft-dual-role 1 labels: strimzi.io/cluster: my-cluster 2 spec: replicas: 3 3 roles: 4 - controller - broker storage: 5 type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false resources: 6 requests: memory: 64Gi cpu: "8" limits: memory: 64Gi cpu: "12"
Kafka
资源的配置必须适合 KRaft 模式。目前,KRaft 模式有很多限制。
使用 ZooKeeper 在集群中节点池的配置示例
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
name: pool-a
labels:
strimzi.io/cluster: my-cluster
spec:
replicas: 3
roles:
- broker 1
storage:
type: jbod
volumes:
- id: 0
type: persistent-claim
size: 100Gi
deleteClaim: false
resources:
requests:
memory: 64Gi
cpu: "8"
limits:
memory: 64Gi
cpu: "12"
- 1
- 节点池中的节点的角色,只有使用带有 ZooKeeper 的 Kafka 时,才可以
代理
。
9.3.1. 为节点池分配 ID 以进行扩展操作
此流程描述了如何在节点池中执行扩展操作时,Cluster Operator 对高级节点 ID 处理使用注解。您可以按顺序使用下一个 ID 来指定要使用的节点 ID,而不是 Cluster Operator。以这种方式管理节点 ID 可提供更多控制。
要添加一系列 ID,您可以为 KafkaNodePool
资源分配以下注解:
-
strimzi.io/next-node-ids
来添加用于新代理的 ID 范围 -
strimzi.io/remove-node-ids
来添加一系列 ID 以删除现有代理
您可以指定单个节点 ID、ID 范围或两者的组合。例如,您可以指定以下 ID 范围: [0, 1, 2, 10-20, 30]
来扩展 Kafka 节点池。通过这种格式,您可以指定单个节点 ID (0
、1
、2
、30
)以及一系列 ID (10-20
)。
在典型的场景中,您可以指定一个 ID 范围来向上扩展和单一节点 ID,以便在缩减时删除特定节点。
在此过程中,我们将扩展注解添加到节点池中,如下所示:
-
为
pool-a
分配一系列 ID 进行扩展 -
为
pool-b
分配一系列 ID 用于缩减
在扩展操作过程中,使用 ID,如下所示:
- 扩展获取新节点范围内的最低可用 ID。
- 缩减会删除范围中具有最高可用 ID 的节点。
如果在节点池中分配的节点 ID 序列中有差距,则要添加的下一个节点会被分配一个填充空白的 ID。
每次扩展操作后,不需要更新注解。任何未使用的 ID 仍对下一个扩展事件有效。
Cluster Operator 允许您以升序或降序指定 ID 范围,以便您可以按照节点扩展的顺序定义它们。例如,在扩展时,您可以指定一个范围,如 [1000-1999]
,并且新节点分配下一个最低 ID: 1000
、1001
、1002
、1003
等。相反,当缩减时,您可以指定一个范围,如 [1999-1000]
,确保具有下一个最高 ID 的节点被删除 :1003
, 1002
, 1001
, 1000
等。
如果没有使用注解指定 ID 范围,Cluster Operator 遵循其在扩展操作期间处理 ID 的默认行为。节点 ID 以 0 (零)开始,并在 Kafka 集群中按顺序运行。下一个最低 ID 分配给新节点。在集群中填充节点 ID 的差距。这意味着它们可能无法在节点池中按顺序运行。扩展的默认行为是在集群中添加下一个最低可用节点 ID;在缩减时,它会删除具有最高可用节点 ID 的节点。如果分配的 ID 范围被误格式化,则扩展范围没有 ID,或者缩减范围不适用于任何正在使用的节点,则应用默认方法。
先决条件
- 必须部署 Cluster Operator。
-
(可选)使用
reserved.broker-max.id
配置属性来扩展节点池中节点 ID 的允许范围。
默认情况下,Apache Kafka 将节点 ID 限制为范围从 0 到 999。要使用大于 999 的节点 ID 值,请将 reserved.broker-max.id
配置属性添加到 Kafka
自定义资源中,并指定所需的最大节点 ID 值。
在本例中,最大节点 ID 设置为 10000。然后,节点 ID 可以分配给该值。
最大节点 ID 数量配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: config: reserved.broker.max.id: 10000 # ...
流程
使用 ID 为节点池添加在扩展或缩减时要使用的 ID,如下例所示。
用于向上扩展的 ID 会被分配给节点
池池
:为扩展分配 ID
oc annotate kafkanodepool pool-a strimzi.io/next-node-ids="[0,1,2,10-20,30]"
将节点添加到
池
时使用此范围内的最低可用 ID。用于缩减的 ID 分配给节点池
pool-b
:为缩减分配 ID
oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids="[60-50,9,8,7]"
缩减
pool-b
时会删除此范围内的最高可用 ID。注意如果要删除特定节点,您可以为缩减注解分配一个单一节点 ID:
oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids="[3]"
。现在,您可以扩展节点池。
如需更多信息,请参阅以下:
在协调时,如果注解被错误格式化,则会提供一个警告。
执行扩展操作后,如果需要,可以删除注解。
删除扩展注解
oc annotate kafkanodepool pool-a strimzi.io/next-node-ids-
删除缩减注解
oc annotate kafkanodepool pool-b strimzi.io/remove-node-ids-
9.3.2. 将节点从节点池移动时对机架的影响
如果在 Kafka 集群中启用了机架感知,副本可以分散到不同的机架、数据中心或可用区中。当将节点从节点池中移动时,请考虑对集群拓扑的影响,特别是对机架感知的影响。从节点池中删除特定的 pod,特别是没有顺序,可能会破坏集群拓扑,或者导致在机架间分布不平衡。imbalance 可能会影响节点本身和集群中的分区副本的分布。跨机架的节点和分区均匀分布可能会影响 Kafka 集群的性能和弹性。
规划以战略方式删除节点,以保持跨机架所需的平衡和弹性。使用 strimzi.io/remove-node-ids
注解来谨慎移动具有特定 ID 的节点。确保将分区副本分散到机架之间,并且客户端若要从最接近的副本使用的配置不会中断。
使用 Cruise Control 和带有 RackAwareGoal
的 KafkaRebalance
资源,以确保副本在不同机架之间保持分布。
9.3.3. 将节点添加到节点池中
这个步骤描述了如何扩展节点池来添加新节点。目前,只有包含作为专用代理运行的节点的代理节点池才可以扩展。
在此过程中,我们从三个节点池( 池
)开始:
节点池中的 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0
节点 ID 在创建时附加到节点的名称中。我们添加节点 my-cluster-pool-a-3
,节点 ID 为 3
。
在此过程中,保存分区副本的节点 ID 会改变。考虑引用节点 ID 的任何依赖项。
先决条件
- 必须部署 Cluster Operator。
- Cruise Control 使用 Kafka 部署。
(可选)要扩展操作 ,您可以指定要在操作中使用的节点 ID。
如果您为操作分配了一系列节点 ID,正在添加的节点 ID 由给定的节点序列决定。如果您分配了单一节点 ID,则使用指定 ID 添加节点。否则,会使用集群中的最低可用节点 ID。
流程
在节点池中创建新节点。
例如,节点池
pool-a
有三个副本。我们通过增加副本数量来添加节点:oc scale kafkanodepool pool-a --replicas=4
检查部署的状态,并等待节点池中的 pod 创建并就绪(
1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示节点池中的四个 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0 my-cluster-pool-a-3 1/1 Running 0
在增加节点池中的节点数后重新分配分区。
在扩展节点池后,使用 Cruise Control
add-brokers
模式将分区副本从现有代理移到新添加的代理中。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: add-brokers brokers: [3]
我们正在将分区重新分配给节点
my-cluster-pool-a-3
。根据集群中的主题和分区数量,重新分配可能需要一些时间。
9.3.4. 从节点池中删除节点
这个步骤描述了如何缩减节点池来删除节点。目前,只有包含作为专用代理运行的节点的代理节点池才可以缩减。
在此过程中,我们从四个节点池( 池
)开始:
节点池中的 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0 my-cluster-pool-a-3 1/1 Running 0
节点 ID 在创建时附加到节点的名称中。我们删除节点 my-cluster-pool-a-3
,节点 ID 为 3
。
在此过程中,保存分区副本的节点 ID 会改变。考虑引用节点 ID 的任何依赖项。
先决条件
- 必须部署 Cluster Operator。
- Cruise Control 使用 Kafka 部署。
(可选)为了缩减操作 ,您可以指定要在操作中使用的节点 ID。
如果您为操作分配了一系列节点 ID,则要删除的节点的 ID 由给定的节点序列决定。如果您分配了单一节点 ID,则将删除具有指定 ID 的节点。否则,节点池中具有最高可用 ID 的节点会被删除。
流程
在减少节点池中的节点数前重新分配分区。
在缩减节点池前,请使用 Cruise Control
remove-brokers
模式,将分区副本从要删除的代理中移出。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: remove-brokers brokers: [3]
我们从节点
my-cluster-pool-a-3
重新分配分区。根据集群中的主题和分区数量,重新分配可能需要一些时间。在重新分配过程完成后,删除的节点没有实时分区,从而减少节点池中的 Kafka 节点数量。
例如,节点池
pool-a
有四个副本。我们通过减少副本数来删除节点:oc scale kafkanodepool pool-a --replicas=3
输出显示节点池中的三个 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-b-kafka-0 1/1 Running 0 my-cluster-pool-b-kafka-1 1/1 Running 0 my-cluster-pool-b-kafka-2 1/1 Running 0
9.3.5. 在节点池之间移动节点
这个步骤描述了如何在不停机的情况下在源和目标 Kafka 节点池之间移动节点。您可以在目标节点池中创建新节点并重新分配分区,以便从源节点池中的旧节点移动数据。当新节点上的副本同步时,您可以删除旧节点。
在此过程中,我们从两个节点池开始:
-
具有三个副本的池
是目标节点池 -
带有四个副本的
pool-b
是源节点池
我们扩展 pool-a
,并重新分配分区并缩减 pool-b
,这会导致以下内容:
-
pool-a
带有四个副本 -
带有三个副本的
pool-b
在此过程中,保存分区副本的节点 ID 会改变。考虑引用节点 ID 的任何依赖项。
先决条件
- 必须部署 Cluster Operator。
- Cruise Control 使用 Kafka 部署。
(可选)要扩展和缩减操作 ,您可以指定要使用的节点 ID 范围。
如果您为操作分配了节点 ID,正在添加或删除的节点 ID 由给定的节点序列决定。否则,在添加节点时会使用集群中可用的最低节点 ID;并删除节点池中可用 ID 的节点。
流程
在目标节点池中创建新节点。
例如,节点池
pool-a
有三个副本。我们通过增加副本数量来添加节点:oc scale kafkanodepool pool-a --replicas=4
检查部署的状态,并等待节点池中的 pod 创建并就绪(
1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示源和目标节点池中的四个 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-4 1/1 Running 0 my-cluster-pool-a-7 1/1 Running 0 my-cluster-pool-b-2 1/1 Running 0 my-cluster-pool-b-3 1/1 Running 0 my-cluster-pool-b-5 1/1 Running 0 my-cluster-pool-b-6 1/1 Running 0
节点 ID 在创建时附加到节点的名称中。我们添加节点
my-cluster-pool-a-7
,节点 ID 为7
。将分区从旧节点重新分配给新节点。
在缩减源节点池前,请使用 Cruise Control
remove-brokers
模式,将分区副本从要删除的代理中移出。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: remove-brokers brokers: [6]
我们从节点
my-cluster-pool-b-6
重新分配分区。根据集群中的主题和分区数量,重新分配可能需要一些时间。重新分配过程完成后,减少源节点池中的 Kafka 节点数量。
例如,节点池
pool-b
具有四个副本。我们通过减少副本数来删除节点:oc scale kafkanodepool pool-b --replicas=3
池中具有最高 ID
(
6)的节点会被删除。输出显示源节点池中的三个 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-b-kafka-2 1/1 Running 0 my-cluster-pool-b-kafka-3 1/1 Running 0 my-cluster-pool-b-kafka-5 1/1 Running 0
9.3.6. 更改节点池角色
节点池可用于以 KRaft 模式(使用 Kafka Raft 元数据)操作的 Kafka 集群,或使用 ZooKeeper 进行元数据管理。如果使用 KRaft 模式,您可以为节点池中的所有节点指定角色,以作为代理、控制器或两者运行。如果使用 ZooKeeper,则节点必须设置为代理。
在某些情况下,您可能想要更改分配给节点池的角色。例如,您可能有一个节点池,其中包含执行双代理和控制器角色的节点,然后决定将角色拆分在两个节点池之间。在这种情况下,您可以使用作为代理的节点创建新节点池,然后将分区从 dual-role 节点重新分配给新代理。然后,您可以将旧节点池切换到仅限控制器的角色。
您还可以通过从带有 controller-only 和 broker-only 角色的节点池移到包含执行双代理和控制器角色的节点池,来执行反向操作。在这种情况下,您可以将 broker
角色添加到现有的 controller-only 节点池中,将仅代理节点中的分区重新分配给 dual-role 节点,然后删除仅代理节点池。
在节点池配置中删除 代理
角色时,请记住 Kafka 不会自动重新分配分区。在删除代理角色前,请确保更改为 controller-only 角色的节点没有任何分配的分区。如果分配了分区,则阻止更改。在删除代理角色前,节点上的副本不能保留。在更改角色前重新分配分区的最佳方法是在 remove-brokers
模式中应用 Cruise Control 优化建议。如需更多信息,请参阅 第 19.6 节 “生成优化建议”。
9.3.7. 过渡到单独的代理和控制器角色
此流程描述了如何过渡到使用带有独立角色的节点池。如果您的 Kafka 集群使用带有控制器和代理角色的节点池,您可以过渡到使用具有独立角色的两个节点池。要做到这一点,请重新平衡集群,将分区副本移到具有仅代理角色的节点池中,然后将旧节点池切换到仅限控制器的角色。
在此过程中,我们从节点池 pool-a
开始,它具有 controller
和 broker
角色:
dual-role 节点池
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-a labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - controller - broker storage: type: jbod volumes: - id: 0 type: persistent-claim size: 20Gi deleteClaim: false # ...
节点池有三个节点:
节点池中的 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0
每个节点都执行代理和控制器的组合角色。我们创建一个名为 pool-b
的第二个节点池,它有三个节点仅充当代理。
在此过程中,保存分区副本的节点 ID 会改变。考虑引用节点 ID 的任何依赖项。
流程
使用
代理
角色创建节点池。节点池配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-b labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - broker storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false # ...
新节点池也有三个节点。如果您已经有一个仅限代理的节点池,您可以跳过这一步。
-
应用新的
KafkaNodePool
资源以创建代理。 检查部署的状态,并等待节点池中的 pod 创建并就绪(
1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示在两个节点池中运行的 pod
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0 my-cluster-pool-b-3 1/1 Running 0 my-cluster-pool-b-4 1/1 Running 0 my-cluster-pool-b-5 1/1 Running 0
节点 ID 在创建时附加到节点的名称中。
使用 Cruise Control
remove-brokers
模式,将 dual-role 节点的分区副本重新分配给新添加的代理。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: remove-brokers brokers: [0, 1, 2]
根据集群中的主题和分区数量,重新分配可能需要一些时间。
注意如果更改为仅控制器角色的节点具有任何分配的分区,则阻止更改。
Kafka
资源的status.conditions
提供了防止更改的事件详情。从最初具有组合角色的节点池中删除
代理
角色。双角色节点切换到控制器
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-a labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - controller storage: type: jbod volumes: - id: 0 type: persistent-claim size: 20Gi deleteClaim: false # ...
- 应用配置更改,以便节点池切换到仅限控制器的角色。
9.3.8. 过渡到双角色节点
此流程描述了如何从带有仅代理和仅控制器角色的独立节点池过渡到使用双角色节点池。如果您的 Kafka 集群使用带有专用控制器和代理节点的节点池,您可以使用带这两个角色的单一节点池过渡到。要做到这一点,将 broker
角色添加到仅 controller-only 节点池中,重新平衡集群,将分区副本移到 dual-role 节点池中,然后删除旧的仅代理节点池。
在此过程中,我们从两个节点池 pool-a
开始,它只有 controller
角色和 pool-b
,它们只有 broker
角色:
单个角色节点池
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-a labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - controller storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false # ... --- apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-b labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - broker storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false # ...
Kafka 集群有六个节点:
节点池中的 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0 my-cluster-pool-b-3 1/1 Running 0 my-cluster-pool-b-4 1/1 Running 0 my-cluster-pool-b-5 1/1 Running 0
pool-a
节点执行控制器的角色。pool-b
节点执行代理角色。
在此过程中,保存分区副本的节点 ID 会改变。考虑引用节点 ID 的任何依赖项。
流程
编辑节点池
pool-a
并为其添加broker
角色。节点池配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-a labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - controller - broker storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false # ...
检查状态并等待节点池中的 pod 重启并就绪(
1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示在两个节点池中运行的 pod
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0 my-cluster-pool-b-3 1/1 Running 0 my-cluster-pool-b-4 1/1 Running 0 my-cluster-pool-b-5 1/1 Running 0
节点 ID 在创建时附加到节点的名称中。
使用 Cruise Control
remove-brokers
模式,将分区副本从 broker-only 节点重新分配给 dual-role 节点。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: remove-brokers brokers: [3, 4, 5]
根据集群中的主题和分区数量,重新分配可能需要一些时间。
删除具有旧仅限代理节点的
pool-b
节点池。oc delete kafkanodepool pool-b -n <my_cluster_operator_namespace>
9.3.9. 使用节点池管理存储
Apache Kafka 的存储管理通常非常简单,设置时需要很少更改,但在某些情况下您可能需要修改存储配置。节点池简化了这个过程,因为您可以设置指定新存储要求的独立节点池。
在此过程中,我们为一个包含三个节点的、名为 pool-a
的节点池创建和管理存储。我们演示了如何更改定义其使用的持久性存储类型的存储类 (volumes.class
)。您可以使用相同的步骤来更改存储大小 (volume.size
)。
我们强烈建议您使用块存储。Apache Kafka 的流只测试用于块存储。
先决条件
- 必须部署 Cluster Operator。
- Cruise Control 使用 Kafka 部署。
- 对于使用持久性卷声明进行动态卷分配的存储,存储类在与您需要的存储解决方案对应的 OpenShift 集群中定义并可用。
流程
使用自己的存储设置创建节点池。
例如,节点池
pool-a
使用带有持久性卷的 JBOD 存储:apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-a labels: strimzi.io/cluster: my-cluster spec: replicas: 3 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 500Gi class: gp2-ebs # ...
pool-a
中的节点配置为使用 Amazon EBS (Elastic Block Store) GP2 卷。-
为
pool-a
应用节点池配置。 检查部署的状态,并等待
pool-a
中的 pod 创建并就绪(1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示节点池中的三个 Kafka 节点
NAME READY STATUS RESTARTS my-cluster-pool-a-0 1/1 Running 0 my-cluster-pool-a-1 1/1 Running 0 my-cluster-pool-a-2 1/1 Running 0
要迁移到新存储类,请使用所需存储配置创建新节点池:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-b labels: strimzi.io/cluster: my-cluster spec: roles: - broker replicas: 3 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 1Ti class: gp3-ebs # ...
pool-b
中的节点配置为使用 Amazon EBS (Elastic Block Store) GP3 卷。-
为
pool-b
应用节点池配置。 -
检查部署的状态,并等待
pool-b
中的 pod 创建并就绪。 将分区从
pool-a
重新分配给pool-b
。迁移到新的存储配置时,请使用 Cruise Control
remove-brokers
模式,将分区副本从要删除的代理移出。使用 Cruise Control 重新分配分区副本
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaRebalance metadata: # ... spec: mode: remove-brokers brokers: [0, 1, 2]
我们是从
池-a
重新分配分区。根据集群中的主题和分区数量,重新分配可能需要一些时间。重新分配过程完成后,删除旧节点池:
oc delete kafkanodepool pool-a
9.3.10. 使用节点池管理存储关联性
如果存储资源(如本地持久性卷)受到特定 worker 节点或可用区的限制,配置存储关联性有助于将 pod 调度到正确的节点。
节点池允许您独立配置关联性。在此过程中,我们为两个可用区创建和管理存储关联性: zone-1
和 zone-2
。
您可以为单独的可用区配置节点池,但使用相同的存储类。我们定义了一个 all-zones
持久性存储类,代表每个区域中可用的存储资源。
我们还使用 .spec.template.pod
属性来配置节点关联性,并在 zone-1
和 zone-2
worker 节点上调度 Kafka pod。
存储类和关联性在代表每个可用区中的节点池中指定:
-
pool-zone-1
-
pool-zone-2
.
先决条件
- 必须部署 Cluster Operator。
- 如果您不熟悉关联性概念,请参阅 Kubernetes 节点和 pod 关联性文档。
流程
定义用于每个可用区的存储类:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: all-zones provisioner: kubernetes.io/my-storage parameters: type: ssd volumeBindingMode: WaitForFirstConsumer
创建代表两个可用区的节点池,指定每个区的
all-zones
存储类和关联性:zone-1 的节点池配置
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-zone-1 labels: strimzi.io/cluster: my-cluster spec: replicas: 3 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 500Gi class: all-zones template: pod: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - zone-1 # ...
zone-2 的节点池配置
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: pool-zone-2 labels: strimzi.io/cluster: my-cluster spec: replicas: 4 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 500Gi class: all-zones template: pod: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - zone-2 # ...
- 应用节点池配置。
检查部署的状态,并等待节点池中的 pod 创建并就绪(
1/1
)。oc get pods -n <my_cluster_operator_namespace>
输出显示
pool-zone-1
和 4 Kafka 节点中的 3 个 Kafka 节点(pool-zone-2)
NAME READY STATUS RESTARTS my-cluster-pool-zone-1-kafka-0 1/1 Running 0 my-cluster-pool-zone-1-kafka-1 1/1 Running 0 my-cluster-pool-zone-1-kafka-2 1/1 Running 0 my-cluster-pool-zone-2-kafka-3 1/1 Running 0 my-cluster-pool-zone-2-kafka-4 1/1 Running 0 my-cluster-pool-zone-2-kafka-5 1/1 Running 0 my-cluster-pool-zone-2-kafka-6 1/1 Running 0
9.3.11. 将现有 Kafka 集群迁移到使用 Kafka 节点池
这个步骤描述了如何迁移现有 Kafka 集群以使用 Kafka 节点池。更新 Kafka 集群后,您可以使用节点池来管理每个池中的节点配置。
目前,KafkaNodePool
资源中的副本和存储配置还必须存在于 Kafka
资源中。使用节点池时会忽略配置。
流程
创建新的
KafkaNodePool
资源。-
将资源命名为
kafka
。 -
将
strimzi.io/cluster
标签指向现有的Kafka
资源。 - 设置副本数和存储配置以匹配您当前的 Kafka 集群。
-
将角色设置为
代理
。
迁移 Kafka 集群的节点池配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaNodePool metadata: name: kafka labels: strimzi.io/cluster: my-cluster spec: replicas: 3 roles: - broker storage: type: jbod volumes: - id: 0 type: persistent-claim size: 100Gi deleteClaim: false
警告要保留集群数据及其节点和资源名称,节点池名称必须是
kafka
,并且strimzi.io/cluster
标签必须与 Kafka 资源名称匹配。否则,节点和资源会使用新名称创建,包括节点使用的持久性卷存储。因此,您之前的数据可能不可用。-
将资源命名为
应用
KafkaNodePool
资源:oc apply -f <node_pool_configuration_file>
通过应用此资源,您可以将 Kafka 切换到使用节点池。
没有更改或滚动更新和资源与之前的资源相同。
使用
strimzi.io/node-pools: enabled
注解启用对Kafka
资源中的节点池的支持。使用 ZooKeeper 在集群中节点池的配置示例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster annotations: strimzi.io/node-pools: enabled spec: kafka: # ... zookeeper: # ...
应用
Kafka
资源:oc apply -f <kafka_configuration_file>
没有更改或滚动更新。这些资源与之前的资源相同。
-
从
Kafka
自定义资源中删除复制的属性。当使用KafkaNodePool
资源时,您可以删除复制到KafkaNodePool
资源的属性,如.spec.kafka.replicas
和.spec.kafka.storage
属性。
翻转迁移
要恢复到只使用 Kafka 自定义资源管理 Kafka
节点:
-
如果您有多个节点池,将其合并到名为
kafka
的单个KafkaNodePool
中,节点 ID 从 0 到 N (其中 N 是副本数)。 -
确保 Kafka 资源中的
.spec.kafka
配置与Kafka
NodePool -
使用
strimzi.io/node-pools: disabled
注解禁用Kafka
资源中节点池的支持。 -
删除名为
kafka
的 Kafka 节点池。