Consider making cache.internal.CacheReader accessible for users

[nkvoll]

The documentation at https://book.kubebuilder.io/beyond_basics/using_client_go_informers.html shows how to wire in informers from the client-go package, but due to the behavior of the client provided to controllers (creates a watch when get/list is used), it means the story gets complicated

See below for an example where a custom informer is used, but having the ability to create a CacheReader would be very useful when it comes to actually using it.

	clientSet, err := kubernetes.NewForConfig(mgr.GetConfig())
	if err != nil {
		return err
	}

	informer := informersCoreV1.NewFilteredSecretInformer(
		clientSet,
		"default",
		10 * time.Hour,
		cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc},
		func(options *v1.ListOptions) {
			options.LabelSelector = labels.Set{"foo": "bar"}.String()
		},
	)

	if err := c.Watch(
		&source.Informer{
			Informer: informer,
		},
		&handler.EnqueueRequestForObject{},
	); err != nil {
		return err
	}

	if err := mgr.Add(manager.RunnableFunc(func(stopCh <-chan struct{}) error {
		informer.Run(stopCh)
		return nil
	})); err != nil {
		return err
	}

	// TODO: not sure how to actually go from the above Informer to a cache.Cache?
	//   e.g actually make it usable using the controller-runtime client.Reader interface.

In this scenario I cannot use the mgr.GetClient() to do any reads of Secrets because that would set up a watch (thus why bother with the custom informer?), so the fall back would be working with the old informer api's instead of the easier to use client.Reader interfaces, which would be possible if I could do secretsCache := NewCacheReader(informer.GetIndexer(), groupVersionKind)

Being able to explicitly ask for caching / non-caching behavior as discussed in #180 combined with first-class support of filtered watches (#244) might not fully solve this case, as there could be multiple different informers for the same GVK, but with different filters (overlapping or not), meaning the choice of informer/cache perhaps should be more explicit than first thought? (this is also mentioned at the bottom of #244). By letting users easily create their own CacheReaders it at least makes it possible to do this today without gating it on similar/getting built-in support for this in the main client(s) provided by controller-runtime to the custom controllers, though having to use more than one client to achieve this is unfortunate.

[DirectXMan12]

/kind feature
/priority important-longterm

[DirectXMan12]

#327 addresses this from the opposite direction

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.