Altinity / Altinity/clickhouse-operator
Make affinity/antiaffinity topologyKey and required/preferred parameters configurable for podDistribution setting
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.6k
- Forks
- 574
- Avg merge
- 8d 6h
- Merged PRs (30d)
- 6
Description
Hello,
We would like to have replicas spread across availability zones. Currently, the podDistribution settings only work with the hostname topologyKey as far as I can tell:
https://github.com/Altinity/clickhouse-operator/blob/master/pkg/model/affinity.go#L504
https://github.com/Altinity/clickhouse-operator/blob/master/pkg/model/affinity.go#L529
https://github.com/Altinity/clickhouse-operator/blob/master/pkg/model/affinity.go#L561
The only way we have found to have pods spread across zones now is to use one pod template per zone which is repetitive and error-prone.
I also noticed that pod affinity is currently enforced using PreferredDuringSchedulingIgnoredDuringExecution and pod anti affinity using RequiredDuringSchedulingIgnoredDuringExecution. Can we also make this configurable?
2 additional optional settings like this could work:
podDistribution:
- type: ReplicaAntiAffinity
topologyKey: kubernetes.io/zone
affType: preferredDuringSchedulingIgnoredDuringExecution
Thanks
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in pkg/model/affinity.go at the referenced podDistribution handling and trace how its settings are represented and applied. Check the existing configuration and validation paths before defining the supported topologyKey and affinity-type values. Done means replica affinity and anti-affinity can target a configured topology and use the requested required or preferred mode.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100