Also rename utilnet.ChooseBindAddress() to ResolveBindAddress(), to
better describe its functionality.
Kubernetes-commit: afa0b808f873b515c9d58a9ead788972ea7d2533
stopAllDelegates will signal other functions to stop updating, instead of acquiring a Mutex and never unlock it
Signed-off-by: Ziheng Liu <zxl381@psu.edu>
Kubernetes-commit: b1c9ae5499b49b5630768050d92bc8ac3553d830
b.N is adjusted by pkg/testing using an internal heuristic:
> The benchmark function must run the target code b.N times. During
> benchmark execution, b.N is adjusted until the benchmark function
> lasts long enough to be timed reliably.
Using b.N to seed other parameters makes the benchmark behavior
difficult to reason about. Before this change, thread count in the
CachedTokenAuthenticator benchmark is always 5000, and batch size is
almost always 1 when I run this locally. SimpleCache and StripedCache
benchmarks had similarly strange scaling.
After modifying CachedTokenAuthenticator to only adjust iterations based
on b.N, the batch chan was an point of contention and I wasn't able to
see any significant CPU consumption. This was fixed by using
ParallelBench to do the batching, rather than using a chan.
Kubernetes-commit: 43d34882c9b3612d933b97b6e470fd8d36fe492b
And maybe the webhook authorizer cache.
This cache has two primary advantages over the LRU cache used currently:
- Cache hits don't acquire an exclusive lock.
- More importantly, performance doesn't fallover when the access pattern
scans a key space larger than an arbitrary size (e.g. the LRU
capacity).
The downside of using an expiring cache here is that it doesn't have a
maximum size so it's suspectible to DoS when the input is user
controlled. This is not the case for successful authentications, and
successful authentications have a natural expiry so it might be a good
fit here.
It has some a few differences compared to:
3d7318f29d/staging/src/k8s.io/client-go/tools/cache/expiration_cache.go
- Expiration is not entirely lazy so keys that are never accessed again
are still released from the cache.
- It does not acquire an exclusive lock on cache hits.
- It supports per entry ttls specified on Set.
The expiring cache (without striping) does somewhere in between the
simple cache and striped cache in the very contrived contention test
where every iteration acquires a write lock:
```
$ benchstat simple.log expiring.log
name old time/op new time/op delta
Cache-12 2.74µs ± 2% 2.02µs ± 3% -26.37% (p=0.000 n=9+9)
name old alloc/op new alloc/op delta
Cache-12 182B ± 0% 107B ± 4% -41.21% (p=0.000 n=8+9)
name old allocs/op new allocs/op delta
Cache-12 5.00 ± 0% 2.00 ± 0% -60.00% (p=0.000 n=10+10)
$ benchstat striped.log expiring.log
name old time/op new time/op delta
Cache-12 1.58µs ± 5% 2.02µs ± 3% +27.34% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
Cache-12 288B ± 0% 107B ± 4% -62.85% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
Cache-12 9.00 ± 0% 2.00 ± 0% -77.78% (p=0.000 n=10+10)
$ benchstat simple.log striped.log expiring.log
name \ time/op simple.log striped.log expiring.log
Cache-12 2.74µs ± 2% 1.58µs ± 5% 2.02µs ± 3%
name \ alloc/op simple.log striped.log expiring.log
Cache-12 182B ± 0% 288B ± 0% 107B ± 4%
name \ allocs/op simple.log striped.log expiring.log
Cache-12 5.00 ± 0% 9.00 ± 0% 2.00 ± 0%
```
I also naively replacemed the LRU cache with the expiring cache in the
more realisitc CachedTokenAuthenticator benchmarks:
https://gist.github.com/mikedanese/41192b6eb62106c0758a4f4885bdad53
For token counts that fit in the LRU, expiring cache does better because
it does not require acquiring an exclusive lock for cache hits.
For token counts that exceed the size of the LRU, the LRU has a massive
performance drop off. The LRU cache is around 5x slower (with lookups
taking 1 milisecond and throttled to max 40 lookups in flight).
```
$ benchstat before.log after.log
name old time/op new time/op delta
CachedTokenAuthenticator/tokens=100_threads=256-12 3.60µs ±22% 1.08µs ± 4% -69.91% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=500_threads=256-12 3.94µs ±19% 1.20µs ± 3% -69.57% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=2500_threads=256-12 3.07µs ± 6% 1.17µs ± 1% -61.87% (p=0.000 n=9+10)
CachedTokenAuthenticator/tokens=12500_threads=256-12 3.16µs ±17% 1.38µs ± 1% -56.23% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=62500_threads=256-12 15.0µs ± 1% 2.9µs ± 3% -80.71% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
CachedTokenAuthenticator/tokens=100_threads=256-12 337B ± 1% 300B ± 0% -11.06% (p=0.000 n=10+8)
CachedTokenAuthenticator/tokens=500_threads=256-12 307B ± 1% 304B ± 0% -0.96% (p=0.000 n=9+10)
CachedTokenAuthenticator/tokens=2500_threads=256-12 337B ± 1% 304B ± 0% -9.79% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=12500_threads=256-12 343B ± 1% 276B ± 0% -19.58% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=62500_threads=256-12 493B ± 0% 334B ± 0% -32.12% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
CachedTokenAuthenticator/tokens=100_threads=256-12 13.0 ± 0% 11.0 ± 0% -15.38% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=500_threads=256-12 12.0 ± 0% 11.0 ± 0% -8.33% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=2500_threads=256-12 13.0 ± 0% 11.0 ± 0% -15.38% (p=0.000 n=10+10)
CachedTokenAuthenticator/tokens=12500_threads=256-12 13.0 ± 0% 10.0 ± 0% -23.08% (p=0.000 n=9+10)
CachedTokenAuthenticator/tokens=62500_threads=256-12 17.0 ± 0% 12.0 ± 0% -29.41% (p=0.000 n=10+10)
```
Benchmarked with changes in #84423
Bugs: #83259#83375
Kubernetes-commit: 9167711fd18511ffc9c90ee306c462be9fc7999b
Reload SNI certificate cert and key file from disk every minute and notify
the dynamic certificate controller when they change, allowing serving
tls config to be updated.
Kubernetes-commit: d9adf535f35051be1d79d1309c72762939593d7c
Reload certificate cert and key file from disk every minute and notify
the dynamic certificate controller when they change, allowing serving
tls config to be updated.
Kubernetes-commit: 3f5fbfbfac281f40c11de2f57d58cc332affc37b
Clients should be able to identify when a namespace is being terminated and
take special action such as backing off or giving up. Add a helper for
getting the cause of an error and then add a special cause to the forbidden
error that namespace lifecycle admission returns. We can't change the forbidden
reason without potentially breaking older clients and so cause is the
appropriate tool.
Add `StatusCause` and `HasStatusCause` to the errors package to make checking
for causes simpler. Add `NamespaceTerminatingCause` to the v1 API as a constant.
Kubernetes-commit: a62c5b282fda7c0832d329cde45e5e0a836924e8
Joe Betz