Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
@@ -21,6 +21,7 @@ This page lists some of the available add-ons and links to their respective inst
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
|
||||
* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
|
||||
|
||||
@@ -120,7 +120,7 @@ your Pod spec.
|
||||
|
||||
For example, consider the following Pod spec:
|
||||
|
||||
{{<codenew file="pods/pod-with-node-affinity.yaml">}}
|
||||
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
|
||||
|
||||
In this example, the following rules apply:
|
||||
|
||||
@@ -167,7 +167,7 @@ scheduling decision for the Pod.
|
||||
|
||||
For example, consider the following Pod spec:
|
||||
|
||||
{{<codenew file="pods/pod-with-affinity-anti-affinity.yaml">}}
|
||||
{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
|
||||
|
||||
If there are two possible nodes that match the
|
||||
`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
|
||||
|
||||
@@ -478,7 +478,7 @@ in the Pod manifest, and represent parameters to the container runtime.
|
||||
|
||||
Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
|
||||
as well as other related parameters outside the Security Context. As of July 2021,
|
||||
[Pod Security Policies](/docs/concepts/profile/pod-security-profile/) are deprecated in favor of the
|
||||
[Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
|
||||
built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/).
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
@@ -323,17 +323,6 @@ If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and
|
||||
the kubelet, it is allowed for Kubernetes to have at most 32 search domains and
|
||||
a list of search domains of up to 2048 characters.
|
||||
|
||||
### Feature availability
|
||||
|
||||
The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
|
||||
|
||||
| k8s version | Feature support |
|
||||
| :---------: |:-----------:|
|
||||
| 1.14 | Stable |
|
||||
| 1.10 | Beta (on by default)|
|
||||
| 1.9 | Alpha |
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
||||
@@ -45,42 +45,7 @@ See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "vers
|
||||
|
||||
An example NetworkPolicy might look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: test-network-policy
|
||||
namespace: default
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
role: db
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
ingress:
|
||||
- from:
|
||||
- ipBlock:
|
||||
cidr: 172.17.0.0/16
|
||||
except:
|
||||
- 172.17.1.0/24
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
project: myproject
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
role: frontend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 6379
|
||||
egress:
|
||||
- to:
|
||||
- ipBlock:
|
||||
cidr: 10.0.0.0/24
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 5978
|
||||
```
|
||||
{{< codenew file="service/networking/networkpolicy.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
|
||||
|
||||
@@ -185,7 +185,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
|
||||
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
|
||||
command is interrupted, it can be restarted.
|
||||
|
||||
When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
|
||||
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you need to do the steps explicitly (scale replicas to
|
||||
0, wait for pod deletions, then delete the ReplicationController).
|
||||
|
||||
### Deleting only a ReplicationController
|
||||
@@ -194,7 +194,7 @@ You can delete a ReplicationController without affecting any of its pods.
|
||||
|
||||
Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
|
||||
|
||||
When using the REST API or Go client library, you can delete the ReplicationController object.
|
||||
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you can delete the ReplicationController object.
|
||||
|
||||
Once the original is deleted, you can create a new ReplicationController to replace it. As long
|
||||
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
|
||||
|
||||
@@ -87,3 +87,17 @@ To close a pull request, leave a `/close` comment on the PR.
|
||||
The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
## PR Wrangler shadow program
|
||||
|
||||
In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process.
|
||||
|
||||
### Become a shadow
|
||||
|
||||
- If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up.
|
||||
|
||||
- Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week.
|
||||
|
||||
- Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
|
||||
|
||||
- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io).
|
||||
@@ -31,7 +31,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
||||
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
|
||||
_RoleBinding_ and _ClusterRoleBinding_. You can
|
||||
[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
|
||||
or amend them, using tools such as `kubectl,` just like any other Kubernetes object.
|
||||
or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
|
||||
|
||||
{{< caution >}}
|
||||
These objects, by design, impose access restrictions. If you are making changes
|
||||
|
||||
@@ -19,4 +19,9 @@ You can request eviction either by directly calling the Eviction API
|
||||
using a client of the kube-apiserver, like the `kubectl drain` command.
|
||||
When an `Eviction` object is created, the API server terminates the Pod.
|
||||
|
||||
API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
|
||||
and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
|
||||
|
||||
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction).
|
||||
|
||||
* See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.
|
||||
|
||||
@@ -15,6 +15,76 @@ This document serves both as a reference to the values and as a coordination poi
|
||||
|
||||
## Labels, annotations and taints used on API objects
|
||||
|
||||
### app.kubernetes.io/component
|
||||
|
||||
Example: `app.kubernetes.io/component=database`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The component within the architecture.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/created-by
|
||||
|
||||
Example: `app.kubernetes.io/created-by=controller-manager`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The controller/user who created this resource.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/instance
|
||||
|
||||
Example: `app.kubernetes.io/instance=mysql-abcxzy`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
A unique name identifying the instance of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/managed-by
|
||||
|
||||
Example: `app.kubernetes.io/managed-by=helm`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The tool being used to manage the operation of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/name
|
||||
|
||||
Example: `app.kubernetes.io/name=mysql`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of the application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/part-of
|
||||
|
||||
Example: `app.kubernetes.io/part-of=wordpress`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of a higher level application this one is part of.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/version
|
||||
|
||||
Example: `app.kubernetes.io/version="5.7.21"`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The current version of the application (e.g., a semantic version, revision hash, etc.).
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### kubernetes.io/arch
|
||||
|
||||
Example: `kubernetes.io/arch=amd64`
|
||||
|
||||
@@ -2,27 +2,27 @@
|
||||
reviewers:
|
||||
- vincepri
|
||||
- bart0sh
|
||||
title: Container runtimes
|
||||
title: Container Runtimes
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
You need to install a
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
into each node in the cluster so that Pods can run there. This page outlines
|
||||
what is involved and describes related tasks for setting up nodes.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
|
||||
conforms with the
|
||||
conforms with the
|
||||
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
|
||||
|
||||
See [CRI version support](#cri-versions) for more information.
|
||||
|
||||
This page lists details for using several common container runtimes with
|
||||
Kubernetes, on Linux:
|
||||
This page provides an outline of how to use several common container runtimes with
|
||||
Kubernetes.
|
||||
|
||||
- [containerd](#containerd)
|
||||
- [CRI-O](#cri-o)
|
||||
@@ -30,12 +30,27 @@ Kubernetes, on Linux:
|
||||
- [Mirantis Container Runtime](#mcr)
|
||||
|
||||
{{< note >}}
|
||||
For other operating systems, look for documentation specific to your platform.
|
||||
Kubernetes releases before v1.24 included a direct integration with Docker Engine,
|
||||
using a component named _dockershim_. That special direct integration is no longer
|
||||
part of Kubernetes (this removal was
|
||||
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
as part of the v1.20 release).
|
||||
You can read
|
||||
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to understand how this removal might
|
||||
affect you. To learn about migrating from using dockershim, see
|
||||
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
|
||||
|
||||
If you are running a version of Kubernetes other than v{{< skew currentVersion >}},
|
||||
check the documentation for that version.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Cgroup drivers
|
||||
|
||||
Control groups are used to constrain resources that are allocated to processes.
|
||||
On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}}
|
||||
are used to constrain resources that are allocated to processes.
|
||||
|
||||
When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
|
||||
system for a Linux distribution, the init process generates and consumes a root control group
|
||||
@@ -64,7 +79,7 @@ If you have automation that makes it feasible, replace the node with another usi
|
||||
configuration, or reinstall it using automation.
|
||||
{{< /caution >}}
|
||||
|
||||
## Cgroup v2
|
||||
### Cgroup version 2 {#cgroup-v2}
|
||||
|
||||
Cgroup v2 is the next version of the cgroup Linux API. Differently than cgroup v1, there is a single
|
||||
hierarchy instead of a different one for each controller.
|
||||
@@ -102,8 +117,8 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
|
||||
|
||||
### Migrating to the `systemd` driver in kubeadm managed clusters
|
||||
|
||||
Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
|
||||
if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
|
||||
If you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters,
|
||||
follow [configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
|
||||
|
||||
## CRI version support {#cri-versions}
|
||||
|
||||
@@ -120,95 +135,51 @@ using the (deprecated) v1alpha2 API instead.
|
||||
|
||||
### containerd
|
||||
|
||||
This section contains the necessary steps to use containerd as CRI runtime.
|
||||
This section outlines the necessary steps to use containerd as CRI runtime.
|
||||
|
||||
Use the following commands to install Containerd on your system:
|
||||
|
||||
Install and configure prerequisites:
|
||||
1. Install and configure prerequisites:
|
||||
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Setup required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
Install containerd:
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
1. Install the `containerd.io` package from the official Docker repositories.
|
||||
Instructions for setting up the Docker repository for your respective Linux distribution and
|
||||
installing the `containerd.io` package can be found at
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
|
||||
2. Configure containerd:
|
||||
(these instructions apply to Linux nodes only)
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Setup required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
3. Restart containerd:
|
||||
1. Install containerd:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`),
|
||||
and then run the following commands:
|
||||
|
||||
1. Download containerd:
|
||||
Visit
|
||||
[Getting started with containerd](https://containerd.io/docs/getting-started/#starting-containerd)
|
||||
and follow the instructions there, up to the point where you have a valid
|
||||
configuration file (on Linux: `/etc/containerd/config.toml`).
|
||||
|
||||
If you are running Windows, you might want to exclude containerd from Windows Defender Scans
|
||||
```powershell
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
2. Extract and configure:
|
||||
|
||||
```powershell
|
||||
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
|
||||
cd $Env:ProgramFiles\containerd\
|
||||
.\containerd.exe config default | Out-File config.toml -Encoding ascii
|
||||
|
||||
# Review the configuration. Depending on setup you may want to adjust:
|
||||
# - the sandbox_image (Kubernetes pause image)
|
||||
# - cni bin_dir and conf_dir locations
|
||||
Get-Content config.toml
|
||||
|
||||
# (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
|
||||
# If excluding containerd from Windows Defender scans, consider how else
|
||||
# you will make sure that the executable is genuine.
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
|
||||
```
|
||||
|
||||
3. Start containerd:
|
||||
For containerd, the CRI socket is `/run/containerd/containerd.sock` by default.
|
||||
|
||||
```powershell
|
||||
.\containerd.exe --register-service
|
||||
Start-Service containerd
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### Using the `systemd` cgroup driver {#containerd-systemd}
|
||||
#### Configuring the `systemd` cgroup driver {#containerd-systemd}
|
||||
|
||||
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
|
||||
|
||||
@@ -219,7 +190,7 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`,
|
||||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
If you apply this change make sure to restart containerd again:
|
||||
If you apply this change, make sure to restart containerd:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
@@ -232,176 +203,14 @@ When using kubeadm, manually configure the
|
||||
|
||||
This section contains the necessary steps to install CRI-O as a container runtime.
|
||||
|
||||
Use the following commands to install CRI-O on your system:
|
||||
|
||||
{{< note >}}
|
||||
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
|
||||
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
|
||||
{{< /note >}}
|
||||
|
||||
Install and configure prerequisites:
|
||||
|
||||
```shell
|
||||
# Create the .conf file to load the modules at bootup
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Set up required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
{{% tab name="Debian" %}}
|
||||
|
||||
To install CRI-O on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate value from the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Debian Unstable | `Debian_Unstable` |
|
||||
| Debian Testing | `Debian_Testing` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
||||
To install on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate field in the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Ubuntu 20.04 | `xUbuntu_20.04` |
|
||||
| Ubuntu 19.10 | `xUbuntu_19.10` |
|
||||
| Ubuntu 19.04 | `xUbuntu_19.04` |
|
||||
| Ubuntu 18.04 | `xUbuntu_18.04` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="CentOS" %}}
|
||||
|
||||
To install on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate field in the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Centos 8 | `CentOS_8` |
|
||||
| Centos 8 Stream | `CentOS_8_Stream` |
|
||||
| Centos 7 | `CentOS_7` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
sudo yum install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="openSUSE Tumbleweed" %}}
|
||||
|
||||
```shell
|
||||
sudo zypper install cri-o
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora" %}}
|
||||
|
||||
Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, `VERSION=1.20`.
|
||||
|
||||
You can find available versions with:
|
||||
```shell
|
||||
sudo dnf module list cri-o
|
||||
```
|
||||
CRI-O does not support pinning to specific releases on Fedora.
|
||||
|
||||
Then run
|
||||
```shell
|
||||
sudo dnf module enable cri-o:$VERSION
|
||||
sudo dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Start CRI-O:
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable crio --now
|
||||
```
|
||||
|
||||
Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
|
||||
for more information.
|
||||
|
||||
To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/cri-o/blob/main/install.md#readme).
|
||||
|
||||
#### cgroup driver
|
||||
|
||||
CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
|
||||
cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
|
||||
configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
|
||||
CRI-O uses the systemd cgroup driver per default, which is likely to work fine
|
||||
for you. To switch to the `cgroupfs` cgroup driver, either edit
|
||||
`/etc/crio/crio.conf` or place a drop-in configuration in
|
||||
`/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
|
||||
|
||||
```toml
|
||||
[crio.runtime]
|
||||
@@ -409,28 +218,28 @@ conmon_cgroup = "pod"
|
||||
cgroup_manager = "cgroupfs"
|
||||
```
|
||||
|
||||
Please also note the changed `conmon_cgroup`, which has to be set to the value
|
||||
You should also note the changed `conmon_cgroup`, which has to be set to the value
|
||||
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
|
||||
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
|
||||
in sync.
|
||||
|
||||
For CRI-O, the CRI socket is `/var/run/crio/crio.sock` by default.
|
||||
|
||||
### Docker Engine {#docker}
|
||||
|
||||
Docker Engine is the container runtime that started it all. Formerly known just as Docker,
|
||||
this container runtime is available in various forms.
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
|
||||
for installing this runtime.
|
||||
{{< note >}}
|
||||
These instructions assume that you are using the
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) adapter to integrate
|
||||
Docker Engine with Kubernetes.
|
||||
{{< /note >}}
|
||||
|
||||
Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
|
||||
and context, see the [Dockershim deprecation FAQ](/dockershim).
|
||||
1. On each of your nodes, install Docker for your Linux distribution as per
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
|
||||
You can also find third-party adapters that let you use Docker Engine with Kubernetes
|
||||
through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
|
||||
(CRI).
|
||||
2. Install [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), following
|
||||
the instructions in that source code repository.
|
||||
|
||||
The following CRI adaptors are designed to work with Docker Engine:
|
||||
|
||||
- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
|
||||
For `cri-dockerd`, the CRI socket is `/run/cri-dockerd.sock` by default.
|
||||
|
||||
### Mirantis Container Runtime {#mcr}
|
||||
|
||||
@@ -439,3 +248,14 @@ available container runtime that was formerly known as Docker Enterprise Edition
|
||||
|
||||
You can use Mirantis Container Runtime with Kubernetes using the open source
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
|
||||
|
||||
To learn more about how to install Mirantis Container Runtime,
|
||||
visit [MCR Deployment Guide](https://docs.mirantis.com/mcr/20.10/install.html).
|
||||
|
||||
Check the systemd unit named `cri-docker.socket` to find out the path to the CRI
|
||||
socket.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
As well as a container runtime, your cluster will need a working
|
||||
[network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
|
||||
|
||||
+3
-2
@@ -70,9 +70,10 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
|
||||
|
||||
## Instructions
|
||||
|
||||
### Installing kubeadm on your hosts
|
||||
### Preparing the hosts
|
||||
|
||||
See ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
Install a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}} and kubeadm on all the hosts.
|
||||
For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
|
||||
{{< note >}}
|
||||
If you have already installed kubeadm, run `apt-get update &&
|
||||
|
||||
@@ -14,7 +14,7 @@ card:
|
||||
This page shows how to install the `kubeadm` toolbox.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
@@ -69,10 +69,10 @@ For more details please see the [Network Plugin Requirements](/docs/concepts/ext
|
||||
## Check required ports
|
||||
These
|
||||
[required ports](/docs/reference/ports-and-protocols/)
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use telnet to check if a port is open. For example:
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
|
||||
|
||||
```shell
|
||||
telnet 127.0.0.1 6443
|
||||
nc 127.0.0.1 6443
|
||||
```
|
||||
|
||||
The pod network plugin you use (see below) may also require certain ports to be
|
||||
|
||||
@@ -8,6 +8,8 @@ weight: 80
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
The lifecycle of the kubeadm CLI tool is decoupled from the
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
|
||||
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
|
||||
|
||||
@@ -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