Node Reference Information
This section contains the following reference topics about nodes:
You can also read node reference details from elsewhere in the
Kubernetes documentation, including:
1 - Kubelet Checkpoint API
FEATURE STATE: Kubernetes v1.25 [alpha]
Checkpointing a container is the functionality to create a stateful copy of a
running container. Once you have a stateful copy of a container, you could
move it to a different computer for debugging or similar purposes.
If you move the checkpointed container data to a computer that's able to restore
it, that restored container continues to run at exactly the same
point it was checkpointed. You can also inspect the saved data, provided that you
have suitable tools for doing so.
Creating a checkpoint of a container might have security implications. Typically
a checkpoint contains all memory pages of all processes in the checkpointed
container. This means that everything that used to be in memory is now available
on the local disk. This includes all private data and possibly keys used for
encryption. The underlying CRI implementations (the container runtime on that node)
should create the checkpoint archive to be only accessible by the root
user. It
is still important to remember if the checkpoint archive is transferred to another
system all memory pages will be readable by the owner of the checkpoint archive.
Operations
post
checkpoint the specified container
Tell the kubelet to checkpoint a specific container from the specified Pod.
Consult the Kubelet authentication/authorization reference
for more information about how access to the kubelet checkpoint interface is
controlled.
The kubelet will request a checkpoint from the underlying
CRI implementation. In the checkpoint
request the kubelet will specify the name of the checkpoint archive as
checkpoint-<podFullName>-<containerName>-<timestamp>.tar
and also request to
store the checkpoint archive in the checkpoints
directory below its root
directory (as defined by --root-dir
). This defaults to
/var/lib/kubelet/checkpoints
.
The checkpoint archive is in tar format, and could be listed using an implementation of
tar
. The contents of the
archive depend on the underlying CRI implementation (the container runtime on that node).
HTTP Request
POST /checkpoint/{namespace}/{pod}/{container}
Parameters
namespace (in path): string, required
Namespacepod (in path): string, required
Podcontainer (in path): string, required
Containertimeout (in query): integer
Timeout in seconds to wait until the checkpoint creation is finished.
If zero or no timeout is specfied the default CRI timeout value will be used. Checkpoint
creation time depends directly on the used memory of the container.
The more memory a container uses the more time is required to create
the corresponding checkpoint.
Response
200: OK
401: Unauthorized
404: Not Found (if the ContainerCheckpoint
feature gate is disabled)
404: Not Found (if the specified namespace
, pod
or container
cannot be found)
500: Internal Server Error (if the CRI implementation encounter an error during checkpointing (see error message for further details))
500: Internal Server Error (if the CRI implementation does not implement the checkpoint CRI API (see error message for further details))
2 - Kubelet Device Manager API Versions
This page provides details of version compatibility between the Kubernetes
device plugin API,
and different versions of Kubernetes itself.
Compatibility matrix
| v1alpha1 | v1beta1 |
---|
Kubernetes 1.21 | - | ✓ |
Kubernetes 1.22 | - | ✓ |
Kubernetes 1.23 | - | ✓ |
Kubernetes 1.24 | - | ✓ |
Kubernetes 1.25 | - | ✓ |
Kubernetes 1.26 | - | ✓ |
Key:
✓
Exactly the same features / API objects in both device plugin API and
the Kubernetes version.+
The device plugin API has features or API objects that may not be present in the
Kubernetes cluster, either because the device plugin API has added additional new API
calls, or that the server has removed an old API call. However, everything they have in
common (most other APIs) will work. Note that alpha APIs may vanish or
change significantly between one minor release and the next.-
The Kubernetes cluster has features the device plugin API can't use,
either because server has added additional API calls, or that device plugin API has
removed an old API call. However, everything they share in common (most APIs) will work.
3 - Articles on dockershim Removal and on Using CRI-compatible Runtimes
This is a list of articles and other pages that are either
about the Kubernetes' deprecation and removal of dockershim,
or about using CRI-compatible container runtimes,
in connection with that removal.
Kubernetes project
You can provide feedback via the GitHub issue Dockershim removal feedback & issues. (k/kubernetes/#106917)
External sources