client-go/examples/workqueue
Patrick Ohly 5d289bc44c client-go/tools/cache: add APIs with context parameter
The context is used for cancellation and to support contextual logging.

In most cases, alternative *WithContext APIs get added, except for
NewIntegerResourceVersionMutationCache where code searches indicate that the
API is not used downstream.

An API break around SharedInformer couldn't be avoided because the
alternative (keeping the interface unchanged and adding a second one with
the new method) would have been worse. controller-runtime needs to be updated
because it implements that interface in a test package. Downstream consumers of
controller-runtime will work unless they use those test package.

Converting Kubernetes to use the other new alternatives will follow. In the
meantime, usage of the new alternatives cannot be enforced via logcheck
yet (see https://github.com/kubernetes/kubernetes/issues/126379 for the
process).

Passing context through and checking it for cancellation is tricky for event
handlers. A better approach is to map the context cancellation to the normal
removal of an event handler via a helper goroutine. Thanks to the new
HandleErrorWithLogr and HandleCrashWithLogr, remembering the logger is
sufficient for handling problems at runtime.

Kubernetes-commit: 4638ba971661497b147906b8977ae206c9dd6e44
2024-07-26 15:26:00 +02:00
..
main.go client-go/tools/cache: add APIs with context parameter 2024-07-26 15:26:00 +02:00
README.md Remove non-existent log option 2021-03-06 16:23:06 +09:00

Workqueue Example

This example demonstrates how to write a controller which follows the states of watched resources.

It demonstrates how to:

  • combine the workqueue with a cache to a full controller
  • synchronize the controller on startup

The example is based on https://git.k8s.io/community/contributors/devel/sig-api-machinery/controllers.md.

Running

# if outside of the cluster
go run *.go -kubeconfig=/my/config