Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Add example to pod placement #413

Merged
merged 10 commits into from
Nov 14, 2023
33 changes: 33 additions & 0 deletions docs/modules/hbase/pages/usage-guide/operations/pod-placement.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,14 @@

You can configure Pod placement for HBase nodes as described in xref:concepts:operations/pod_placement.adoc[].

== Defaults

The default affinities created by the operator are:

1. Co-locate all the Hbase Pods (weight 20)
sbernauer marked this conversation as resolved.
Show resolved Hide resolved
2. Co-locate Hbase regionservers with the underlying HDFS datanodes (weight 50)
sbernauer marked this conversation as resolved.
Show resolved Hide resolved
3. Distribute all Pods within the same role (masters, region servers, rest servers) (weight 70)
sbernauer marked this conversation as resolved.
Show resolved Hide resolved

Default Pod placement constraints for master nodes:

[source,yaml]
Expand Down Expand Up @@ -94,3 +102,28 @@ affinity:
In the examples above `cluster-name` is the name of the HBase custom resource that owns this Pod. The `hdfs-cluster-name` is the name of the HDFS cluster that was configured in the `hdfsConfigMapName` property.

NOTE: It is important that the `hdfsConfigMapName` property contains the name the HDFS cluster. You could instead configure ConfigMaps of specific name or data roles, but for the purpose of pod placement, this will lead to faulty behavior.

== Use custom pod placement
xref:concepts:operations/pod_placement.adoc[] describes how you can configure pod placement in general.
lfrancke marked this conversation as resolved.
Show resolved Hide resolved
One example use-case for HBase would be to *require* the HBase masters to run on different Kubernetes nodes as follows:

[source,yaml]
----
spec:
masters:
config:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: hbase
app.kubernetes.io/instance: cluster-name # Replace with you HbaseCluster name!
app.kubernetes.io/component: master
topologyKey: kubernetes.io/hostname
roleGroups:
default:
replicas: 2
----

WARNING: Please note that the Pods will be stuck in `Pending`, when your Kubernetes cluster does not have any node without a masters already running on it and sufficient compute resources.