Revert v1.17 release changes on v1.16 branch (#18123)
This reverts commits:1131f8603e.cf5b8b200c.75de70a431.dff2f7b960.cf925bb688.ffd1363c0e.87a2cafb20.ffe259d6f2.
This commit is contained in:
Tim Bannister
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
5733771d62
commit
065ccd94be
@@ -64,18 +64,17 @@ is to drain the Node from its workloads, remove it from the cluster and re-join
|
||||
## Docker
|
||||
|
||||
On each of your machines, install Docker.
|
||||
Version 19.03.4 is recommended, but 1.13.1, 17.03, 17.06, 17.09, 18.06 and 18.09 are known to work as well.
|
||||
Version 18.06.2 is recommended, but 1.11, 1.12, 1.13, 17.03 and 18.09 are known to work as well.
|
||||
Keep track of the latest verified Docker version in the Kubernetes release notes.
|
||||
|
||||
Use the following commands to install Docker on your system:
|
||||
|
||||
{{< tabs name="tab-cri-docker-installation" >}}
|
||||
{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
|
||||
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
|
||||
# Install Docker CE
|
||||
## Set up the repository:
|
||||
### Install packages to allow apt to use a repository over HTTPS
|
||||
apt-get update && apt-get install \
|
||||
apt-transport-https ca-certificates curl software-properties-common
|
||||
apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
|
||||
|
||||
### Add Docker’s official GPG key
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
|
||||
@@ -87,10 +86,7 @@ add-apt-repository \
|
||||
stable"
|
||||
|
||||
## Install Docker CE.
|
||||
apt-get update && apt-get install \
|
||||
containerd.io=1.2.10-3 \
|
||||
docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
|
||||
docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
|
||||
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
|
||||
|
||||
# Setup daemon.
|
||||
cat > /etc/docker/daemon.json <<EOF
|
||||
@@ -118,14 +114,12 @@ systemctl restart docker
|
||||
yum install yum-utils device-mapper-persistent-data lvm2
|
||||
|
||||
### Add Docker repository.
|
||||
yum-config-manager --add-repo \
|
||||
yum-config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/centos/docker-ce.repo
|
||||
|
||||
## Install Docker CE.
|
||||
yum update && yum install \
|
||||
containerd.io-1.2.10 \
|
||||
docker-ce-19.03.4 \
|
||||
docker-ce-cli-19.03.4
|
||||
yum update && yum install docker-ce-18.06.2.ce
|
||||
|
||||
## Create /etc/docker directory.
|
||||
mkdir /etc/docker
|
||||
|
||||
+6
-101
@@ -123,120 +123,25 @@ Users today need to use some combination of taints and node selectors in order t
|
||||
|
||||
Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels:
|
||||
|
||||
* kubernetes.io/os = [windows|linux]
|
||||
* kubernetes.io/arch = [amd64|arm64|...]
|
||||
* beta.kubernetes.io/os = [windows|linux]
|
||||
* beta.kubernetes.io/arch = [amd64|arm64|...]
|
||||
|
||||
If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
|
||||
If a Pod specification does not specify a nodeSelector like `"beta.kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector.
|
||||
|
||||
However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only.
|
||||
|
||||
For example: `--register-with-taints='os=windows:NoSchedule'`
|
||||
For example: `--register-with-taints='os=Win1809:NoSchedule'`
|
||||
|
||||
By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
kubernetes.io/os: windows
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
"beta.kubernetes.io/os": windows
|
||||
tolerations:
|
||||
- key: "os"
|
||||
operator: "Equal"
|
||||
value: "windows"
|
||||
value: "Win1809"
|
||||
effect: "NoSchedule"
|
||||
```
|
||||
|
||||
### Handling multiple Windows versions in the same cluster
|
||||
|
||||
The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
|
||||
Server versions in the same cluster, then you should set additional node labels and nodeSelectors.
|
||||
|
||||
Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes.
|
||||
|
||||
This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version.
|
||||
|
||||
| Product Name | Build Number(s) |
|
||||
|--------------------------------------|------------------------|
|
||||
| Windows Server 2019 | 10.0.17763 |
|
||||
| Windows Server version 1809 | 10.0.17763 |
|
||||
| Windows Server version 1903 | 10.0.18362 |
|
||||
|
||||
|
||||
### Simplifying with RuntimeClass
|
||||
|
||||
[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations.
|
||||
|
||||
|
||||
1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version.
|
||||
|
||||
```yaml
|
||||
apiVersion: node.k8s.io/v1beta1
|
||||
kind: RuntimeClass
|
||||
metadata:
|
||||
name: windows-2019
|
||||
handler: 'docker'
|
||||
scheduling:
|
||||
nodeSelector:
|
||||
kubernetes.io/os: 'windows'
|
||||
kubernetes.io/arch: 'amd64'
|
||||
node.kubernetes.io/windows-build: '10.0.17763'
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: os
|
||||
operator: Equal
|
||||
value: "windows"
|
||||
```
|
||||
|
||||
1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator
|
||||
1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: iis-2019
|
||||
labels:
|
||||
app: iis-2019
|
||||
spec:
|
||||
replicas: 1
|
||||
template:
|
||||
metadata:
|
||||
name: iis-2019
|
||||
labels:
|
||||
app: iis-2019
|
||||
spec:
|
||||
runtimeClassName: windows-2019
|
||||
containers:
|
||||
- name: iis
|
||||
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
|
||||
resources:
|
||||
limits:
|
||||
cpu: 1
|
||||
memory: 800Mi
|
||||
requests:
|
||||
cpu: .1
|
||||
memory: 300Mi
|
||||
ports:
|
||||
- containerPort: 80
|
||||
selector:
|
||||
matchLabels:
|
||||
app: iis-2019
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: iis
|
||||
spec:
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 80
|
||||
selector:
|
||||
app: iis-2019
|
||||
```
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
|
||||
|
||||
Reference in New Issue
Block a user