The original design was to honour strong consistency
semantics for when the RV is unset, i.e. serve the
watch by doing a quorum read.
However, the implementation did not match the intent,
in that, the Cacher did not distinguish between set
and unset RV. This commit rectifies that behaviour by
serving the watch from the underlying storage if the
RV is unset.
This commit subsequently also adds a test for the same.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Kubernetes-commit: 610b67031c79c6c38964631d27dd59df357c6d2e
This commit allows injecting errors for the
Watch() method of the dummy storage impl.
As a consequence of this, a race is introduced
between when the injected error is written and
read whenever a Watch() is invoked using the
dummy storage. This commit adds locking in order
to mitigate this.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Kubernetes-commit: 2593671337ad449f51b9dcc0b63aa190dd07ab68
* Make policy decision object public
Signed-off-by: Max Smythe <smythe@google.com>
* Separate version conversion from validation
Signed-off-by: Max Smythe <smythe@google.com>
* Address review comments
Signed-off-by: Max Smythe <smythe@google.com>
* Fix variable name
Signed-off-by: Max Smythe <smythe@google.com>
---------
Signed-off-by: Max Smythe <smythe@google.com>
Kubernetes-commit: 0ed74145fb00626ce0e900812a54ca3de5406f2e
The --contention-profiling flag enables block profiling by calling
SetBlockProfileRate(). It, however does not call SetMutexProfileFraction
which enables mutex profiling.
Mutex profiling gives us information about lock contention whereas
block profiling on the other hand gives us information on gorotuines
being blocked on sync primitives.
Updating the docs to "block profiling" in order to make it more accurate.
Eventhough a block profile may reflect contention points on locks to some
extent, it also talks about other sources where goroutines may be blocked.
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
Kubernetes-commit: f236ab24dfcb84906a1d453877a79bd4a94f897d
reduces memory and cpu when things like configmap are used as a param
cannot be shared due to limitatoins of sharedinformerfactory
Kubernetes-commit: b969dfec9fd33f8bfff47e54f2995a4865839ea6
Each of these scripts is basically identical, and all were too brittle.
Now they should be more resilient and easier to manage. The script
still needs to be updated if we add new ones, which I do not love.
More cleanup to follow.
Kubernetes-commit: e0ecccff3f5148cc167117ac73233b4edc1640d8
The condition methods will eventually all take a context. Since we
have been provided one, alter the accepted condition type and
change the four references in tree.
Collers of ExponentialBackoffWithContext should use a condition
aware function (ConditionWithContextFunc). If the context can be
ignored the helper ConditionFunc.WithContext can be used to convert
an existing function to the new type.
Kubernetes-commit: 34bfdc3635cb621d94eebde5d8f4b9c0b933c68e
ContextForChannel uses a goroutine to transform a channel close to
a context cancel. However, this exposes a synchronization issue if
we want to unify the underlying implementation between contextless
and with context - a ConditionFunc that closes the channel today
expects the behavior that no subsequent conditions will be invoked
(we have a test in wait_test.go TestUntilReturnsImmediately that
verifies this expectation). We can't unify the implementation
without ensuring this property holds.
To do that this commit changes from the goroutine propagation to
implementing context.Context and using stopCh as the Done(). We
then implement Err() by returning context.Canceled and stub the
other methods. Since our context cannot be explicitly cancelled
by users, we cease to return the cancelFn and callers that need
that behavior must wrap the context as normal.
This should be invisible to clients - they would already observe
the same behavior from the context, and the existing error
behavior of Poll* is preserved (which ignores ctx.Err()).
As a side effect, one less goroutine is created making it more
efficient.
Kubernetes-commit: 95051a63b323081daf8a3fe55a252eb79f0053aa
Remove dependencies on internal fieldmanager for admission things. This
is preparing for moving fieldmanager out, but the admission part will
stay here, so it can't depend directly on internal.
Kubernetes-commit: d13b405307262b2b9c0795af3a22d0a5725ef6a0
Add a "lazy" type to track when an update is needed. It uses a nested
locking technique to avoid extra evaluation calls.
Kubernetes-commit: 5a1091d88d95bd1dd5c27f2c72cee4ecb4219dda
This change in a no-op refactor of the encryption at rest code that
primarily changes the wiring to consistently use context for
lifecycle management (instead of a mixture of context and stop
channels).
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 70b414b0e5cbe9706e5a4fc0d7299ec6b169d642
This significantly reduces the surface area of the fieldmanager package
by hiding all the private "managers" objects, as well as the interface
that was made specifically for these. There is no reason to configure
these.
Kubernetes-commit: adfc65ec23292ebd95d96727654acd8e8e0452a5
This is mostly because the path, even for built-in, can change from test
to test, so it's easier to make the whole thing configurable anyway.
Kubernetes-commit: 1617b06c039cb66f05e59b79f9a9963d5614ce31
The fact that we're building the OpenAPI using the proto.Models is an
implementation detail that we shouldn't have to expose. Since we're
going to change the way this is transformed, let's first hide it behind
the common NewTypeConverter so that the next change is transparent.
This will also enable other clean-ups like hiding the gvkParser which
shouldn't be exposed and prevent some refactoring.
Kubernetes-commit: a7ab6b86db83e31ff599e4d21a065f6845fb93dd
This introduces `singularNameProvider`. This provider will be used
by core types to have their singular names are defined in discovery
endpoint. Thanks to that, core resources singular name always have
higher precedence than CRDs shortcuts or singular names.
Kubernetes-commit: 0990ba1cc92449bbbd9b25a4391f1da834f8c5fd
* Add tracker types and tests
* Modify ResourceEventHandler interface's OnAdd member
* Add additional ResourceEventHandlerDetailedFuncs struct
* Fix SharedInformer to let users track HasSynced for their handlers
* Fix in-tree controllers which weren't computing HasSynced correctly
* Deprecate the cache.Pop function
Kubernetes-commit: 8100efc7b3122ad119ee8fa4bbbedef3b90f2e0d
Serving profiling information can leak information or expose the
apiserver to possible DoS attacks. Serving on a UDS is more secure
though slightly less convenient. One can't use `go tool pprof` directly
against the socket since it's not supported, but can either run a proxy
to copy from the socket over to http, or use `curl --unix-socket` to
download the profile and then use `go tool pprof`.
Kubernetes-commit: 667599b0ddfad8ba760d3bbfe006aae0d8f7dec6
Since this is used both in real-code and in test-code, let's put it
somewhere it can be re-used.
Kubernetes-commit: 9c447177e85dadaba0f12fa95c5d8ee6c4e54602
some subresources were not properly included in the array due to pointers becoming stale over a resize
Kubernetes-commit: d74b6b2cfa9bd2bc322750db9c42fb575e947982
so that aggregated-apiservers can also take advantage. discovered by e2e tests with feature enabled
Kubernetes-commit: c9b34884004079ed3f184b475f7408984f9226f4
Also make some design changes exposed in testing and review.
Do not remove the ambiguous old metric
`apiserver_flowcontrol_request_concurrency_limit` because reviewers
though it is too early. This creates a problem, that metric can not
keep both of its old meanings. I chose the configured concurrency
limit.
Testing has revealed a design flaw, which concerns the initialization
of the seat demand state tracking. The current design in the KEP is
as follows.
> Adjustment is also done on configuration change … For a newly
> introduced priority level, we set HighSeatDemand, AvgSeatDemand, and
> SmoothSeatDemand to NominalCL-LendableSD/2 and StDevSeatDemand to
> zero.
But this does not work out well at server startup. As part of its
construction, the APF controller does a configuration change with zero
objects read, to initialize its request-handling state. As always,
the two mandatory priority levels are implicitly added whenever they
are not read. So this initial reconfig has one non-exempt priority
level, the mandatory one called catch-all --- and it gets its
SmoothSeatDemand initialized to the whole server concurrency limit.
From there it decays slowly, as per the regular design. So for a
fairly long time, it appears to have a high demand and competes
strongly with the other priority levels. Its Target is higher than
all the others, once they start to show up. It properly gets a low
NominalCL once other levels show up, which actually makes it compete
harder for borrowing: it has an exceptionally high Target and a rather
low NominalCL.
I have considered the following fix. The idea is that the designed
initialization is not appropriate before all the default objects are
read. So the fix is to have a mode bit in the controller. In the
initial state, those seat demand tracking variables are set to zero.
Once the config-producing controller detects that all the default
objects are pre-existing, it flips the mode bit. In the later mode,
the seat demand tracking variables are initialized as originally
designed.
However, that still gives preferential treatment to the default
PriorityLevelConfiguration objects, over any that may be added later.
So I have made a universal and simpler fix: always initialize those
seat demand tracking variables to zero. Even if a lot of load shows
up quickly, remember that adjustments are frequent (every 10 sec) and
the very next one will fully respond to that load.
Also: revise logging logic, to log at numerically lower V level when
there is a change.
Also: bug fix in float64close.
Also, separate imports in some file
Co-authored-by: Han Kang <hankang@google.com>
Kubernetes-commit: feb42277884bc7cfbd6f0bb1d875cc63b1b6caac
This change enables hot reload of encryption config file when api server
flag --encryption-provider-config-automatic-reload is set to true. This
allows the user to change the encryption config file without restarting
kube-apiserver. The change is detected by polling the file and is done
by using fsnotify watcher. When file is updated it's process to generate
new set of transformers and close the old ones.
Signed-off-by: Nilekh Chaudhari <1626598+nilekhc@users.noreply.github.com>
Kubernetes-commit: 761b7822fca569d475f782b135ef433e5b014147
Add new kube-apiserver SLI metric better reflecting that the metric is
an SLI and not an SLO and deprecate the existing
apiserver_request_slo_duration_seconds in 1.27. Although the metric is
still in alpha, we prefer deprecating it for one release since it is a
critical metric used for SLOs and to make sure that users that are using
it have time to make the transition.
Going forward we prefer going with SLI specific metrics, we will use
_sli_ instead of _slo_ so for consistency purposes.
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Kubernetes-commit: 1493da92d9513e383f8382c7e80316a3fa6c94fa
Co-authored-by: Alexander Zielenski <zielenski@google.com>
Co-authored-by: Joe Betz <jpbetz@google.com>
Kubernetes-commit: e7d83a1fb7b3e4f6a75ed73bc6e410946e12ad9f
This change adds a flag --encryption-provider-config-automatic-reload
which will be used to drive automatic reloading of the encryption
config at runtime. While this flag is set to true, or when KMS v2
plugins are used without KMS v1 plugins, the /healthz endpoints
associated with said plugins are collapsed into a single endpoint at
/healthz/kms-providers - in this state, it is not possible to
configure exclusions for specific KMS providers while including the
remaining ones - ex: using /readyz?exclude=kms-provider-1 to exclude
a particular KMS is not possible. This single healthz check handles
checking all configured KMS providers. When reloading is enabled
but no KMS providers are configured, it is a no-op.
k8s.io/apiserver does not support dynamic addition and removal of
healthz checks at runtime. Reloading will instead have a single
static healthz check and swap the underlying implementation at
runtime when a config change occurs.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: 22e540bc48d9bf698c4f381ccb56ed57dea0dae2
Abu Kashem
Rita Zhang
A. Lombarte
Madhav Jivrajani
Jiahui Feng
Li Bo
Andrew Sy Kim
Paco Xu
ZhangYu
Han Kang
Hippie Hacker
mantuliu
Anish Ramasekar
baomingwang
SataQiu
Dipankar Das
Max Smythe
Alexander Zielenski
Nilekh Chaudhari
Richa Banker
Joseph Anttila Hall
Kevin Delgado
Tim Hockin
Monis Khan
Patrick Ohly
Clayton Coleman
Antoine Pelisse
lengrongfu
Krzysztof Ostrowski
Daniel Smith
root
Jordan Liggitt
Jefftree
kkkkun
Arda Güçlü
Wojciech Tyczyński
qingwave
Dario Tranchitella
Tim Allclair
David Ashpole
Cici Huang
Kermit Alexander II
Mike Spreitzer
Joe Betz
sanwishe
Damien Grisonnet
Paweł Banaszewski