* Forensic Container Checkpointing as described in KEP 2008 moves from
Alpha to Beta. This is corresponding code change.
* Adapt e2e test to handle
'(rpc error: code = Unimplemented desc = unknown method CheckpointContainer'
and
'(rpc error: code = Unimplemented desc = method CheckpointContainer not implemented)'
and
'(rpc error: code = Unknown desc = checkpoint/restore support not available)'
One error message is if the CRI implementation does
not implement the CRI RPC (too old) and the second is
if the CRI implementation does explicitly not support the feature.
The third error message can be seen if the container engine
explicitly disabled the checkpoint/restore support,
* As described in the corresponding KEP 2008 explicitly test for
disabled functionality.
* Extended test to look for the checkpoint kubelet metric.
* Extended test to look for the CRI error metric.
* Add separate sub-resource permission to control permissions on
the checkpoint kubelet API endpoint
Signed-off-by: Adrian Reber <areber@redhat.com>
Container runtimes like CRI-O and containerd reuse the code by copying
it from Kubernetes. To have a single source of truth for the streaming
server we now move the already isolated implementation to the
k8s.io/kubelet staging repository. This way runtimes can re-use the code
without copying the parts.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
This patch makes the CRI `v1` API the new project-wide default version.
To allow backwards compatibility, a fallback to `v1alpha2` has been added
as well. This fallback can either used by automatically determined by
the kubelet.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
CRI runtimes do not supply cpu nano core usage as it is not part of CRI
stats. However, there are upstream components that still rely on such
stats to function. The previous fix was faulty because the multiple
callers could compete and update the stats, causing
inconsistent/incoherent metrics. This change, instead, creates a
separate call for updating the usage, and rely on eviction manager,
which runs periodically, to trigger the updates. The caveat is that if
eviction manager is completley turned off, no one would compute the
usage.
This allows kubelets to stop the necessary work when the context has
been canceled (e.g., connection closed), and not leaking a goroutine
and inotify watcher waiting indefinitely.