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
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 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
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
This change updates the API server code to load the encryption
config once at start up instead of multiple times. Previously the
code would set up the storage transformers and the etcd healthz
checks in separate parse steps. This is problematic for KMS v2 key
ID based staleness checks which need to be able to assert that the
API server has a single view into the KMS plugin's current key ID.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: f507bc255382b2e2095351053bc17e74f7100d35
This is a Config specialized for a GroupResource.
It will support generating new resource-specific metrics.
Kubernetes-commit: 85bcd243aa3c8769a5904a1aea44ce704f5e7174
Noted that group must be omitted for resources of apiVersion v1 (the
legacy core API) and included for others.
Fixes#65393
Kubernetes-commit: fc20359fed5e3d0e89a60653b9b0d638d4d757d8
This change renames the '--experimental-encryption-provider-config'
flag to '--encryption-provider-config'. The old flag is accepted but
generates a warning.
In 1.14, we will drop support for '--experimental-encryption-provider-config'
entirely.
Co-authored-by: Stanislav Laznicka <slaznick@redhat.com>
Kubernetes-commit: 21c1bb883081b13244002271bccc9cf119d4db4f
This commit adds an option for controlling request of compaction to
etcd3 from apiserver. There is a situation that apiserver cannot fully
own its etcd cluster (e.g. sharing it with canal). In such a case,
apiserver should have limited access in terms of etcd's auth
functionality so it don't have a priviledge to issue compaction
requests. It means that the compaction requests should be issued by
other component and apiserver's compaction requests are needless.
For such use cases, this commit adds a new flag
`storagebackend.Config.CompactionInterval`. If the flag is non 0,
apiserver issues the compaction requests like current behaviour (the
default is 5 minutes). If it is 0, apiserver doesn't issue the
requests. It can be configured with a newly added option of apiserver
`--etcd-compaction-interval`.
Kubernetes-commit: 87d4d3e92be6b93517f189082b0451cee6957ee5
Currently setting watch cache size for a given resource does not disable
the watch cache. This commit adds a new `default-watch-cache-size` flag
to map to the existing field, and refactors how watch cache sizes are
calculated to bring all of the code into one place. It also adds debug
logging to startup to allow us to verify watch cache enablement in
production.
Kubernetes-commit: fc2d201e155296f311ae0a9278b00dcae2d68708
Add a feature gate in the apiserver to control whether paging can be
used. Add controls to the storage factory that allow it to be disabled
per resource. Use a JSON encoded continuation token that can be
versioned. Create a 410 error if the continuation token is expired.
Adds GetContinue() to ListMeta.
Kubernetes-commit: 8952a0cb722b77459cf2701632a30f5b264f5aba