Is a SharedIndexInformer's Indexer's ThreadSafeStore ever emptied?

8/30/2018

I'm carefully making my way through the Go code in the tools/cache package for what seems like the hundredth time.

From close-reading the code, when you create a new SharedIndexInformer, the following things happen:

  1. SharedIndexInformer creates a new Indexer.
  2. The Indexer so created creates a new ThreadSafeStore internally for holding representations of Kubernetes resources.
  3. SharedIndexInformer.Run() creates a new DeltaFIFO with the new Indexer as its second parameter.
  4. The Indexer supplied to the new DeltaFIFO therefore functions as its KeyLister and its KeyGetter. (This is used to track "prior state" for deletions; i.e. if there's an object in it but the latest sync up with Kubernetes does not contain that object, then we know it has been deleted from the cluster.)
  5. The HandleDeltas function is the one that the underlying controller will call when Kubernetes resources are added, updated or deleted.
  6. The HandleDeltas function will call the Add, Update and Delete methods on the Indexer (and, by extension, on its underlying ThreadSafeStore).

Let's say I write a new controller using a SharedIndexInformer. Let's further say that it is watching for Pods. Let's finally say that there are 10 Pods in the cluster.

Does this mean that after the SharedIndexInformer's Run method has been called and some requisite amount of time has passed that there will be 10 JSON representations of Pods in the ThreadSafeStore, and, further, that none will be removed from this store until an actual deletion of one of the corresponding Pods occurs in Kubernetes?

-- Laird Nelson
kubernetes

1 Answer

9/1/2018

Correct, except for the JSON part.

The Store contains native Object structs, deserialized from protobuf messages.

-- Antoine Cotten
Source: StackOverflow