pingcap / pingcap/tidb-operator
performance: configure a long resync period for informers to avoid generating high load on apiserver
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 540
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 18
Description
Feature Request
After the initial list, the informer will start the Watch API to receive updates. There is no need to configure a short resync period to resync objects.
We can configure a long resync period for informers, e.g. 12 hours ~ 24 hours (the default resync period used by kube-controller-manager).
Note that, our controllers need to sync our CRD objects every 30s. We can list and add all objects into the work queue every 30s, see an example in the Kubernetes PV controller.
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 by locating the informer configuration and the controller paths that enqueue CRD objects every 30 seconds. Compare the intended behavior with the Kubernetes PV controller example linked in the issue. Done means informers use a long resync period while controllers still synchronize CRD objects every 30 seconds without creating unnecessary apiserver load.
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
- Needs clarification
- Newbie friendliness
- 35/100