Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
@@ -16,8 +16,7 @@ weight: 30
|
||||
|
||||
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
|
||||
|
||||
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
---
|
||||
title: "Migrating from dockershim"
|
||||
weight: 10
|
||||
content_type: task
|
||||
content_type: task
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -22,3 +23,25 @@ section to know your options. Make sure to
|
||||
[report issues](https://github.com/kubernetes/kubernetes/issues) you encountered
|
||||
with the migration. So the issue can be fixed in a timely manner and your cluster would be
|
||||
ready for dockershim removal.
|
||||
|
||||
Your cluster might have more than one kind of node, although this is not a common
|
||||
configuration.
|
||||
|
||||
These tasks will help you to migrate:
|
||||
|
||||
* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
to understand your options for a container runtime.
|
||||
* There is a
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)
|
||||
to track discussion about the deprecation and removal of dockershim.
|
||||
* If you found a defect or other technical concern relating to migrating away from dockershim,
|
||||
you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose)
|
||||
to the Kubernetes project.
|
||||
|
||||
|
||||
+5
@@ -88,3 +88,8 @@ You can still pull images or build them using `docker build` command. But images
|
||||
built or pulled by Docker would not be visible to container runtime and
|
||||
Kubernetes. They needed to be pushed to some registry to allow them to be used
|
||||
by Kubernetes.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
|
||||
- Read the [dockershim deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article for more information.
|
||||
|
||||
+49
-3
@@ -32,16 +32,22 @@ kubectl get nodes -o wide
|
||||
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs
|
||||
the runtime and its version.
|
||||
|
||||
For Docker Engine, the output is similar to this:
|
||||
|
||||
```none
|
||||
# For dockershim
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.16.15 docker://19.3.1
|
||||
node-2 Ready v1.16.15 docker://19.3.1
|
||||
node-3 Ready v1.16.15 docker://19.3.1
|
||||
```
|
||||
If your runtime shows as Docker Engine, you still might not be affected by the
|
||||
removal of dockershim in Kubernetes 1.24. [Check the runtime
|
||||
endpoint](#which-endpoint) to see if you use dockershim. If you don't use
|
||||
dockershim, you aren't affected.
|
||||
|
||||
For containerd, the output is similar to this:
|
||||
|
||||
```none
|
||||
# For containerd
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.19.6 containerd://1.4.1
|
||||
node-2 Ready v1.19.6 containerd://1.4.1
|
||||
@@ -49,4 +55,44 @@ node-3 Ready v1.19.6 containerd://1.4.1
|
||||
```
|
||||
|
||||
Find out more information about container runtimes
|
||||
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page.
|
||||
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
page.
|
||||
|
||||
## Find out what container runtime endpoint you use {#which-endpoint}
|
||||
|
||||
The container runtime talks to the kubelet over a Unix socket using the [CRI
|
||||
protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
|
||||
framework. The kubelet acts as a client, and the runtime acts as the server.
|
||||
In some cases, you might find it useful to know which socket your nodes use. For
|
||||
example, with the removal of dockershim in Kubernetes 1.24 and later, you might
|
||||
want to know whether you use Docker Engine with dockershim.
|
||||
|
||||
{{<note>}}
|
||||
If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't
|
||||
affected by the dockershim removal.
|
||||
{{</note>}}
|
||||
|
||||
You can check which socket you use by checking the kubelet configuration on your
|
||||
nodes.
|
||||
|
||||
1. Read the starting commands for the kubelet process:
|
||||
|
||||
```
|
||||
tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
|
||||
```
|
||||
If you don't have `tr` or `pgrep`, check the command line for the kubelet
|
||||
process manually.
|
||||
|
||||
1. In the output, look for the `--container-runtime` flag and the
|
||||
`--container-runtime-endpoint` flag.
|
||||
|
||||
* If your nodes use Kubernetes v1.23 and earlier and these flags aren't
|
||||
present or if the `--container-runtime` flag is not `remote`,
|
||||
you use the dockershim socket with Docker Engine.
|
||||
* If the `--container-runtime-endpoint` flag is present, check the socket
|
||||
name to find out which runtime you use. For example,
|
||||
`unix:///run/containerd/containerd.sock` is the containerd endpoint.
|
||||
|
||||
If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
|
||||
or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
|
||||
CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
|
||||
+1
-1
@@ -233,7 +233,7 @@ in order to configure checks that rely on gRPC.
|
||||
|
||||
Here is an example manifest:
|
||||
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml">}}
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml" >}}
|
||||
|
||||
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
|
||||
on a non-default service, you must also specify the `service`.
|
||||
|
||||
@@ -107,7 +107,7 @@ kubectl delete pod qos-demo --namespace=qos-example
|
||||
A Pod is given a QoS class of Burstable if:
|
||||
|
||||
* The Pod does not meet the criteria for QoS class Guaranteed.
|
||||
* At least one Container in the Pod has a memory or CPU request.
|
||||
* At least one Container in the Pod has a memory or CPU request or limit.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
|
||||
and a memory request of 100 MiB.
|
||||
|
||||
@@ -194,7 +194,7 @@ both Linux and Windows kernels). The time window used to calculate CPU is shown
|
||||
in Metrics API.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures CPU resources, see
|
||||
[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
|
||||
[meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
|
||||
|
||||
### Memory
|
||||
|
||||
@@ -209,7 +209,7 @@ anonymous memory associated with the container in question. The working set metr
|
||||
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures memory resources, see
|
||||
[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
|
||||
[meaning of memory](/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory).
|
||||
|
||||
## Metrics Server
|
||||
|
||||
|
||||
@@ -11,6 +11,9 @@ min-kubernetes-server-version: 1.7
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
|
||||
Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
|
||||
|
||||
Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart.
|
||||
|
||||
Reference in New Issue
Block a user