Altinity / Altinity/clickhouse-operator
When operator pod crashes or it is restarted it restarts the chi pods
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.6k
- Forks
- 574
- Avg merge
- 8d 6h
- Merged PRs (30d)
- 6
Description
I have done some testing following a issue we had in our k8s cluster and observed the following:
- running 1 replica of operator pod : if this pod crashes for any reason or it gets restarted it restarts the chi pods
- running 2 replica of operator pod: the same situation as with one replica, when pod crashes or it is restarted it restarts the chi pods.
Normal behaviour for operators would be that the pods do a reconciliation among them and one run as primary and another as secondary . when primary restarts or crashes the secondary should take over and not restart the managed resources. The same with running only one pod, it should know that nothing changed in the pod/sts state and not restart pods.
Running latest operator and CH versions on 1.33 k8s.
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
Reproduce the behavior by restarting or crashing the operator pod while managing a ClickHouse cluster on Kubernetes, first comparing the one-replica and two-replica cases described here. Trace the operator's reconciliation and managed-pod lifecycle behavior; done means an operator restart leaves unchanged ClickHouse pods running without unnecessary restarts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100