13.2.22. Rack スキーマ参照
KafkaClusterSpec、KafkaConnectS2ISpec、KafkaConnectSpec で使用
rackオプションは、ラックの認識を設定します。ラックは、アベイラビリティーゾーン、データセンター、またはデータセンターの実際のラックを表すことができます。rackの設定は、topologyKeyで行います。topologyKeyは、OpenShift ノード上のラベルを識別するもので、その値にはトポロジーの名前が含まれています。このようなラベルの例としては、topology.kubernetes.io/zone（古いOpenShiftバージョンではfailure-domain.beta.kubernetes.io/zone）があり、これにはOpenShiftノードが実行されているアベイラビリティゾーンの名前が含まれています。Kafka クラスターが実行するラックを認識するように設定し、パーティションレプリカを異なるラックに分散したり、最も近いレプリカからのメッセージの消費したりするなどの追加機能を有効にできます。
OpenShift ノードラベルの詳細は、「Well-Known Labels, Annotations and Taints」を参照してください。ノードがデプロイされたゾーンやラックを表すノードラベルについては、OpenShift 管理者に相談します。
13.2.22.1. ラック間でのパーティションレプリカの分散
ラックアウェアネスを設定すると、AMQ Streamsは各Kafkaブローカーのbroker.rack設定を行います。broker.rackの設定では、各ブローカにラックIDを割り当てます。broker.rackを設定すると、Kafkaブローカーはパーティションレプリカをできるだけ多くの異なるラックに分散して配置します。レプリカが複数のラックに分散されている場合、複数のレプリカが同時に失敗する可能性は、同じラックにある場合よりも低くなります。レプリカを分散すると回復性が向上し、可用性と信頼性にとっても重要です。Kafkaでラックアウェアネスを有効にするには、以下の例のように、Kafkaのカスタムリソースの.spec.kafkaセクションにrackオプションを追加します。
Kafkaのrack設定例
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
rack:
topologyKey: topology.kubernetes.io/zone
# ...
Pod が削除または再起動すると、ブローカーが実行されているラックは、変更されることがあります。その結果、異なるラックで実行しているレプリカが、同じラックを共有する可能性があります。RackAwareGoalでCruise ControlとKafkaRebalanceリソースを使用して、レプリカが異なるラックに分散していることを確認します。
Kafkaカスタムリソースでラックアウェアネスが有効になっている場合、AMQ Streamsは自動的にOpenShiftのpreferredDuringSchedulingIgnoredDuringExecutionアフィニティルールを追加して、Kafkaブローカーを異なるラックに分散させます。ただし、優先 ルールは、ブローカーが分散されることを保証しません。OpenShiftとKafkaの構成に応じて、affinityルールを追加したり、ZooKeeperとKafkaの両方にtopologySpreadConstraintsを設定したりして、できるだけ多くのラックにノードが適切に分散されるようにしてください。詳細は、「Pod スケジューリングの設定」 を参照してください。
