このコンテンツは選択した言語では利用できません。

Chapter 15. Guaranteeing availability with anti-affinity


Kubernetes includes anti-affinity capabilities that protect workloads from single points of failure.

15.1. Anti-affinity strategies

Each Data Grid node in a cluster runs in a pod that runs on an OpenShift node in a cluster. Each Red Hat OpenShift node runs on a physical host system. Anti-affinity works by distributing Data Grid nodes across OpenShift nodes, ensuring that your Data Grid clusters remain available even if hardware failures occur.

Data Grid Operator offers two anti-affinity strategies:

kubernetes.io/hostname
Data Grid replica pods are scheduled on different OpenShift nodes.
topology.kubernetes.io/zone
Data Grid replica pods are scheduled across multiple zones.

Fault tolerance

Anti-affinity strategies guarantee cluster availability in different ways.

Note

The equations in the following section apply only if the number of OpenShift nodes or zones is greater than the number of Data Grid nodes.

Scheduling pods on different OpenShift nodes

Provides tolerance of x node failures for the following types of cache:

  • Replicated: x = spec.replicas - 1
  • Distributed: x = num_owners - 1

Scheduling pods across multiple zones

Provides tolerance of x zone failures when x zones exist for the following types of cache:

  • Replicated: x = spec.replicas - 1
  • Distributed: x = num_owners - 1
Note
spec.replicas
Defines the number of pods in each Data Grid cluster.
num_owners
Is the cache configuration attribute that defines the number of replicas for each entry in the cache.

15.2. Configuring anti-affinity

Specify where OpenShift schedules pods for your Data Grid clusters to ensure availability.

Procedure

  1. Add the spec.scheduling.affinity block to your Infinispan CR.
  2. Configure anti-affinity strategies as necessary.
  3. Apply your Infinispan CR.

15.2.1. Anti-affinity strategy configurations

Configure anti-affinity strategies in your Infinispan CR to control where OpenShift schedules Data Grid replica pods.

Expand
Topology keysDescription

topologyKey: "topology.kubernetes.io/zone"

Schedules Data Grid replica pods across multiple zones.

topologyKey: "kubernetes.io/hostname"

Schedules Data Grid replica pods on different OpenShift nodes.

Schedule pods on different OpenShift nodes

The following is the anti-affinity strategy that Data Grid Operator uses if you do not configure the spec.scheduling.affinity field in your Infinispan CR:

spec:
  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: infinispan-pod
                clusterName: <cluster_name>
                infinispan_cr: <cluster_name>
            topologyKey: "kubernetes.io/hostname"
Requiring different nodes

In the following example, OpenShift does not schedule Data Grid pods if different nodes are not available:

spec:
  scheduling:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: infinispan-pod
              clusterName: <cluster_name>
              infinispan_cr: <cluster_name>
          topologyKey: "topology.kubernetes.io/hostname"
Note

To ensure that you can schedule Data Grid replica pods on different OpenShift nodes, the number of OpenShift nodes available must be greater than the value of spec.replicas.

Schedule pods across multiple OpenShift zones

The following example prefers multiple zones when scheduling pods but schedules Data Grid replica pods on different OpenShift nodes if it is not possible to schedule across zones:

spec:
  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: infinispan-pod
                clusterName: <cluster_name>
                infinispan_cr: <cluster_name>
            topologyKey: "topology.kubernetes.io/zone"
        - weight: 90
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: infinispan-pod
                clusterName: <cluster_name>
                infinispan_cr: <cluster_name>
            topologyKey: "kubernetes.io/hostname"
Requiring multiple zones

The following example uses the zone strategy only when scheduling Data Grid replica pods:

spec:
  scheduling:
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: infinispan-pod
              clusterName: <cluster_name>
              infinispan_cr: <cluster_name>
          topologyKey: "topology.kubernetes.io/zone"
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る