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
It is possible to configure the token cache to cache failures. We
allow 1 MB of headers per request, meaning a malicious actor could
cause the cache to use a large amount of memory by filling it with
large invalid tokens. This change hashes the token before using it
as a key. Measures have been taken to prevent precomputation
attacks. SHA 256 is used as the hash to prevent collisions.
Signed-off-by: Monis Khan <mkhan@redhat.com>
Kubernetes-commit: 9a547bca8e6e15273bfafd3496aa6524fd7d35bd
Service account authorization checks are done frequently and were
observed to perform 7% of allocations on a system running e2e tests.
The allocation comes from when we walk the authorization rules to
find matching service accounts.
Optimize the check for service account names to avoid allocating.
Kubernetes-commit: 4c87a14e6b1809359fcb6566d883a169ff0db259
The `certificate_expiration_seconds` histogram measures the remaining
time of client certificates used to authenticate to the API server. It
records the lifetime of received client request certificates in buckets
of 6h, 12h, ..., 1y.
In environments with automated certificate rotation it is not uncommen
to have issued certificates expire in less than the above mentioned
minimum bucket of 6h. In such environments the above histogram is
useless given that every request will be recorded in the first bucket.
This patch increases the histogram resolution by adding a 30m, 1h and 2h
bucket. Prometheus histogram buckets are cummulative, e.g. the 12h
bucket is counting _all_ records with an expiration date lower or equal
to 12h including _all_ requests of the 6h bucket. Thereby this patch
does not break existing monitoring setups. This histogram is exposed
once per API server, thereby the 3 additional time series do not cause a
cardinality issue.
Kubernetes-commit: f90bbc3d6bfba992831eb216161990eae1098ae5
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
Kubernetes-commit: 954996e231074dc7429f7be1256a579bedd8344c
The striped cache used by the token cache is slightly more sophisticated
however the simple cache provides about the same exact behavior. I used
the striped cache rather than the simple cache because:
* It has been used without issue as the primary token cache.
* It preforms better under load.
* It is already exposed in the public API of the token cache package.
Kubernetes-commit: 0ec4d6d396f237ccb3ae0e96922a90600befb83d
Suppress common name verify warning log and roll up into returned error
remove glog test dependency
Kubernetes-commit: bb3124c48a4d276ed280175e5825ea9db022d699
When incoming requests to the API server are authenticated by a
certificate, the expiration of the certificate can affect the validity
of the authentication. With auto rotation of certificates, which is
starting with kubelet certificates, the goal is to use shorter lifetimes
and let the kubelet renew the certificate as desired. Monitoring
certificates which are approaching expiration and not renewing would be
an early warning sign that nodes are about to stop participating in the
cluster.
Kubernetes-commit: 49a19c6011e05363a8baf8e99c917d11a9496568