shared controller informers#23575
Conversation
|
GCE e2e build/test passed for commit 97be6688850149e4b09f0976b5715be9acbabeac. |
|
GCE e2e build/test passed for commit afed8824c9e93d739a1769b35b23f1e81de4dd25. |
|
@deads2k - sorry for late response - I'm in US now and have a calendar full of meetings. |
There was a problem hiding this comment.
maybe you floss really well the next morning ;-)
|
@deads2k - sorry for a huge delay in reviewing this; I'm back from US now; looking into it now. |
There was a problem hiding this comment.
If we want to proceed with this PR, we should avoid this code duplication. But I guess this is just POC now, so never mind :)
There was a problem hiding this comment.
If we want to proceed with this PR, we should avoid this code duplication. But I guess this is just POC now, so never mind :)
My plan would be to switch over a couple controllers, prove that they work, then start phasing in the new approach and removing the old paths. Probably once we have a standard way of tracking the shared informers for a given resource.
|
@deads2k - I added few comments to it. After some deeper thinking about it, my biggest concern is that we may want to unregister/register a handler function when the informer is already running - see this comment: WDYT? |
|
@lavalamp @kubernetes/sig-api-machinery - FYI |
Looking at the thread, I think we closed it off with me implementing an infinite slice feeding an unbuffered channel on a go func and that would satisfy the primary case of register/unregister. If you agree, I'll work on fixing this up tomorrow, switching over the two sample controllers I saw and building unit tests to finish up the concept. |
|
@deads2k - I would like this to be fixed in the future, but I'm fine with what you implemented short term. So yeah - your plan SGTM. Please let me know when it will be ready for review. |
|
/cc @rrati |
There was a problem hiding this comment.
nit: s/coordinatino/coordination/
|
@deads2k - thanks a lot for working on it @derekwaynecarr - should we wait for comments from you? |
|
Comments addressed and squashed. |
|
LGTM - thanks! |
|
I will wait for @derekwaynecarr for comments and if no comments for a day, I will apply lgtm label (or feel free to reassign it to me, if you know that Derek is fine with that). |
|
GCE e2e build/test passed for commit f0c33d6. |
|
@wojtek-t yeah, he'll be fine with it. |
|
LGTM - thanks! |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
GCE e2e build/test passed for commit f0c33d6. |
|
Automatic merge from submit-queue |
|
|
||
| // run the shared informers | ||
| for _, informer := range informers { | ||
| go informer.Run(wait.NeverStop) |
There was a problem hiding this comment.
@deads2k I'm creating a new controller so I was looking into using a shared informer. Some questions:
- Are shared informers ready for wider use, or are they still a work in progress?
- All shared informers (including the
podInformer) are started here (Run(...)is called) in thecontrollermanager, but I see that the individual controllers also start the pod informer passed into them manually (internalPodInformer.Run(...)), won't this result in thepodInformer'sRun(...)getting called twice?
There was a problem hiding this comment.
@saad-ali the internalPodInformer field of the controllers is only set when calling the New_Resource_ControllerFromClient() functions. All of the Run() functions have a check to see if the internalPodInformer != nil before trying to start it.
Said another way, tests use New_Resource_ControllerFromClient() so that the Run() will start the informer. The regular New_Resource_Controller() function, don't set internalPodInformer, and the shared informer is started here.
Also, FYI I have PR #24841 open for converting some of the remaining controllers to using the shared pod informer.
There was a problem hiding this comment.
@sjenning that makes perfect sense. Thanks for the clarification.
There was a problem hiding this comment.
Are shared informers ready for wider use, or are they still a work in progress?
They are ready for wider use. The initial transitions of controllers to a shared pod informer went very smoothly, so I don't expect any structural problems. Remember not to mess with the object in the cache, its shared.
There was a problem hiding this comment.
We should have called the informer method that your register on
"AddMeAsLongAsIPromiseNotToMutateTheSharedCache"
On Thu, Apr 28, 2016 at 8:54 AM, David Eads notifications@github.com
wrote:
In cmd/kube-controller-manager/app/controllermanager.go
#23575 (comment)
:@@ -410,6 +418,11 @@ func StartControllers(s *options.CMServer, kubeClient *client.Client, kubeconfig
).Run()
time.Sleep(wait.Jitter(s.ControllerStartInterval.Duration, ControllerStartJitter))
- // run the shared informers
- for _, informer := range informers {
go informer.Run(wait.NeverStop)Are shared informers ready for wider use, or are they still a work in
progress?They are ready for wider use. The initial transitions of controllers to a
shared pod informer went very smoothly, so I don't expect any structural
problems. Remember not to mess with the object in the cache, its shared.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/23575/files/f0c33d65b6fea84d791059d96c93a15e4b3de4ec#r61421456
There was a problem hiding this comment.
They are ready for wider use. The initial transitions of controllers to a shared pod informer went very smoothly, so I don't expect any structural problems. Remember not to mess with the object in the cache, its shared.
Sounds good, thanks!
Related to #14978
This demonstrates how controllers which use an
Informer, would be able to share the same watch and store. A similar "setup and run" approach could be done for anIndexInformerto share that cache. I found adding listeners here to be easier than intercepting at the watch interface (problems with resourceVersion) or the reflector (same plumbing, but you have to fan out to multiple stores).We could also use the cache we build here to back several of the admission plugins that currently run their own lookup caches today.
If there's interest, I can finish out the
SharedInformerand switch the low hanging fruit over.@kubernetes/rh-cluster-infra @smarterclayton @liggitt @wojtek-t