Now that projected service account tokens do not require the secret
to be created, exclude the wait condition on the token and simply
wait for the service account.
The change from service account secrets to projected tokens and
the new dependency on kube-root-ca.crt to start pods with those
projected tokens means that e2e tests can start before
kube-root-ca.crt is created in a namespace. Wait for the default
service account AND the kube-root-ca.crt configmap in normal
e2e tests.
watchCacheInterval serves as an abstraction over a source
of watchCacheEvents. It maintains a window of events over
an underlying source and these events can be served using
the exposed Next() API. The main intent for doing things
this way is to introduce an upper bound of memory usage
for starting a watch and reduce the maximum possible time
interval for which the lock would be held while events are
copied over.
The source of events for the interval is typically either
the watchCache circular buffer, if events being retrieved
need to be for resource versions > 0 or the underlying
implementation of Store, if resource version = 0.
Furthermore, an interval can be either valid or invalid at
any given point of time. The notion of validity makes sense
only in cases where the window of events in the underlying
source can change over time - i.e. for watchCache circular
buffer. When the circular buffer is full and an event needs
to be popped off, watchCache::startIndex is incremented. In
this case, an interval tracking that popped event is valid
only if it has already been copied to its internal buffer.
However, for efficiency we perform that lazily and we mark
an interval as invalid iff we need to copy events from the
watchCache and we end up needing events that have already
been popped off. This translates to the following condition:
watchCacheInterval::startIndex >= watchCache::startIndex.
When this condition becomes false, the interval is no longer
valid and should not be used to retrieve and serve elements
from the underlying source.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Goal of this commit is to add some missing features when the
Kubernetes API is accessed through a SOCKS5 proxy. That's for
example the case when port-forwarding is used (`kubectl port-forward`)
or when exec'ing inside a container (`kubectl exec`), with this
commit it'll now be possible to use both.
Signed-off-by: Romain Aviolat <romain.aviolat@kudelskisecurity.com>
Signed-off-by: Romain Jufer <romain.jufer@kudelskisecurity.com>
