mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-29 08:05:34 +00:00
Denise
GitHub
+74
-62
@@ -3,7 +3,12 @@ title: Configuring Custom Clusters for Windows (Experimental)
|
||||
weight: 2240
|
||||
---
|
||||
|
||||
_Available as of v2.1.0_
|
||||
>**Notes:**
|
||||
>
|
||||
>- Windows are new and improved for Rancher v2.3!
|
||||
>- Still using v2.1.x or v2.2.x? As of v2.1.10 and v2.2.3, the previous Windows feature has been removed. See the windows documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/docs-for-2.1-and-2.2/).
|
||||
|
||||
_Available as of v2.3.0-alpha1_
|
||||
|
||||
>**Important:**
|
||||
>
|
||||
@@ -11,106 +16,109 @@ _Available as of v2.1.0_
|
||||
|
||||
When provisioning a [custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/) using Rancher, you can use a mix of Linux and Windows hosts as your cluster nodes.
|
||||
|
||||
This guide walks you through create of a custom cluster that includes 3 nodes: a Linux node, which serves as a Kubernetes control plane node; another Linux node, which serves as a Kubernetes worker used to support Ingress for the cluster; and a Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.
|
||||
This guide walks you through the creation of a custom cluster that includes three nodes.
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
|
||||
>- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
|
||||
>- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
|
||||
* A Linux node, which serves as a Kubernetes control plane node.
|
||||
* Another Linux node, which serves as a Kubernetes worker used to support Rancher Cluster agent, Metrics server, DNS and Ingress for the cluster.
|
||||
* A Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.
|
||||
|
||||
## Pre-Prerequisites
|
||||
|
||||
For a summary of Kubernetes features supported in Windows, see [Using Windows Server Containers in Kubernetes](https://kubernetes.io/docs/getting-started-guides/windows/#supported-features).
|
||||
|
||||
### Node Requirements
|
||||
|
||||
In order to add Windows worker nodes, the node must be running Windows Server 2019 (i.e. core version 1809 or above). Any earlier versions (e.g. core version 1803 and earlier) do not properly support Kubernetes.
|
||||
|
||||
Windows overlay networking requires that [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix is installed. Most cloud-hosted VMs already have this hotfix.
|
||||
|
||||
### Container Requirements
|
||||
|
||||
Windows requires that containers must be built on the same Windows server version that they are being deployed on. Therefore, containers must be built on Windows Server 2019 in order to be used with the node requirements of running Windows Server 2019. If you have existing containers built for Windows Server 1803 or earlier, they must be re-built to use Windows Server 2019.
|
||||
|
||||
## Objectives for Creating Cluster with Windows Support
|
||||
|
||||
When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below.
|
||||
To set up a custom cluster with support for Windows nodes and containers, you will need to complete the series of tasks listed below.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Provision Hosts](#1-provision-hosts)
|
||||
- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
|
||||
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
|
||||
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
|
||||
- [5. Adding Windows Workers](#5-adding-windows-workers)
|
||||
- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
|
||||
- [2. Create the Custom Cluster](#2-create-the-custom-cluster)
|
||||
- [3. Add Linux Master Node](#3-add-linux-master-node)
|
||||
- [4. Add Linux Worker Node](#4-add-linux-worker-node)
|
||||
- [5. Add Windows Workers](#5-add-windows-workers)
|
||||
- [6. Cloud-host VM Routes Configuration for Host Gateway Mode (Optional)](#6-cloud-hosted-vm-routes-configuration-for-host-gateway-mode)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
## 1. Provision Hosts
|
||||
|
||||
To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/)—two Linux, one Windows. Your hosts can be:
|
||||
To begin provisioning a custom cluster with Windows support, prepare your hosts. Provision three nodes according to our [installation requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/) - two Linux, one Windows. Your hosts can be:
|
||||
|
||||
- Cloud-hosted VMs
|
||||
- VMs from virtualization clusters
|
||||
- Bare-metal servers
|
||||
|
||||
The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
|
||||
The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we’re installing all three roles on this node. The second node is also a Linux worker, which is responsible for running a DNS server, Ingress controller, Metrics server and Rancher Cluster agent. Finally, the third node is the Windows worker, which will run your Windows applications.
|
||||
|
||||
Node | Operating System | Future Cluster Role(s)
|
||||
--------|------------------|------
|
||||
Node 1 | Linux (Ubuntu Server 16.04 recommended) | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
|
||||
Node 3 | Windows (*Windows Server 1803 required*) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 1 | Linux (Ubuntu Server 18.04 recommended) | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 2 | Linux (Ubuntu Server 18.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 3 | Windows (Windows Server 2019 required) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- If you are using AWS, you should choose *Microsoft Windows Server 2019 Base with Containers* as the Amazon Machine Image (AMI).
|
||||
>- If you are using GCE, you should choose *Windows Server 2019 Datacenter for Containers* as the OS image.
|
||||
|
||||
### Requirements
|
||||
|
||||
- You can view node requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
|
||||
- All nodes in a virtualization cluster or a bare metal cluster must be connected using a layer 2 network.
|
||||
- To support [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), your cluster must include at least one Linux node dedicated to the worker role.
|
||||
- Although we recommend the three node architecture listed in the table above, you can add additional Linux and Windows workers to scale up your cluster for redundancy.
|
||||
- You can view the general requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
|
||||
- For **Host Gateway (L2bridge)** networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them.
|
||||
- For **VXLAN (Overlay)** networking, you must confirm that the Windows Server 2019 has the [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix installed. Most cloud-hosted VMs already have this hotfix.
|
||||
- Your cluster must include at least one Linux worker node to run Rancher Cluster agent, DNS, Metrics server and Ingress related containers.
|
||||
- Although we recommend the three node architecture listed in the table above, you can always add additional Linux and Windows workers to scale up your cluster for redundancy.
|
||||
|
||||
## 2. Create the Custom Cluster
|
||||
|
||||
To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed below.
|
||||
|
||||
|
||||
## 2. Cloud-hosted VM Networking Configuration
|
||||
1. Select `v1.14 or above` version for **Kubernetes Version**.
|
||||
|
||||
>**Note:** This step only applies to nodes hosted on cloud-hosted virtual machines. If you're using virtualization clusters or bare-metal servers, skip ahead to [Create the Custom Cluster](#3-create-the-custom-cluster).
|
||||
1. Select **Flannel** as **Network Provider**.
|
||||
|
||||
If you're hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.
|
||||
1. Select **Enable** for **Windows Support**.
|
||||
|
||||
1. Choose the **Flannel Backend**. There are two options [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) and [**VXLAN (Overlay)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). Default is **VXLAN (Overlay)** mode.
|
||||
|
||||
If your nodes are hosted by a **Cloud Provider** and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
|
||||
|
||||
Finally, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
|
||||
|
||||
>**Important:** If you are using *Host Gateway (L2bridge)* mode and hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.
|
||||
|
||||
Service | Directions to disable private IP address checks
|
||||
--------|------------------------------------------------
|
||||
Amazon EC2 | [Disabling Source/Destination Checks](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
|
||||
Google GCE | [Enabling IP Forwarding for Instances](https://cloud.google.com/vpc/docs/using-routes#canipforward)
|
||||
Azure VM | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)
|
||||
Azure VM | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)
|
||||
|
||||
## 3. Create the Custom Cluster
|
||||
## 3. Add Linux Master Node
|
||||
|
||||
To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed in the subheadings below.
|
||||
|
||||
|
||||
### Enable the Windows Support Option
|
||||
|
||||
While choosing **Cluster Options**, set **Windows Support (Experimental)** to **Enabled**.
|
||||
|
||||
|
||||
|
||||
After you select this option, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
|
||||
|
||||
### Networking Option
|
||||
|
||||
When choosing a network provider for a cluster that supports Windows, the only option available is Flannel, as [host-gw](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) is needed for IP routing.
|
||||
|
||||
|
||||
|
||||
If your nodes are hosted by a cloud provider and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
|
||||
|
||||
### Node Configuration
|
||||
|
||||
The first node in your cluster should be a Linux host that fills the Control Plane role. This role must be fulfilled before you can add Windows hosts to your cluster. At minimum, the node must have this role enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).
|
||||
The first node in your cluster should be a Linux host that fills both *Control Plane* and *etcd* role. Both of these two roles must be fulfilled before you can add Windows hosts to your cluster. At a minimum, the node must have 2 roles enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).
|
||||
|
||||
Option | Setting
|
||||
-------|--------
|
||||
Node Operating System | Linux
|
||||
Node Roles | etcd <br/> Control Plane <br/> Worker
|
||||
|
||||
|
||||
Node Roles | etcd <br/> Control Plane <br/> Worker (optional)
|
||||
|
||||
When you're done with these configurations, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 8]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-8).
|
||||
|
||||
## 4. Add Linux Worker Node
|
||||
|
||||
|
||||
## 4. Add Linux Host for Ingress Support
|
||||
|
||||
After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support Ingress for your cluster.
|
||||
After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support *Rancher cluster agent*, *Metrics server*, *DNS* and *Ingress* for your cluster.
|
||||
|
||||
1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
|
||||
|
||||
@@ -128,9 +136,11 @@ After the initial provisioning of your custom cluster, your cluster only has a s
|
||||
|
||||
1. From **Rancher**, click **Save**.
|
||||
|
||||
**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
|
||||
**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher.
|
||||
|
||||
## 5. Adding Windows Workers
|
||||
|
||||
|
||||
## 5. Add Windows Workers
|
||||
|
||||
You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
|
||||
|
||||
@@ -150,11 +160,13 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
|
||||
|
||||
1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
|
||||
|
||||
**Result:** The worker role is installed on your Windows host, and the node registers with Rancher.
|
||||
**Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher.
|
||||
|
||||
## 6. Cloud-hosted VM Routes Configuration
|
||||
|
||||
In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
|
||||
|
||||
## 6. Cloud-hosted VM Routes Configuration for Host Gateway Mode
|
||||
|
||||
If you are using the [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) backend of Flannel, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
|
||||
|
||||
- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
|
||||
|
||||
@@ -171,7 +183,7 @@ Then follow the instructions for each cloud provider to configure routing rules
|
||||
Service | Instructions
|
||||
--------|-------------
|
||||
Google GCE | For GCE, add a static route for each node: [Adding a Static Route](https://cloud.google.com/vpc/docs/using-routes#addingroute).
|
||||
Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).
|
||||
Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).
|
||||
|
||||
|
||||
` `
|
||||
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: v2.1.x and v2.2.x Windows Documentation (Experimental)
|
||||
weight: 9100
|
||||
---
|
||||
|
||||
>**Note:** This section describes the Windows feature as implemented in Rancher v2.1.x and v2.2.x. If you are using Rancher v2.3 or later, where Windows have been significantly improved, please refer to the new documentation for [v2.3 or later]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
|
||||
_Available from v2.1.0 to v2.1.9 and v2.2.0 to v2.2.2_
|
||||
|
||||
>**Important:**
|
||||
>
|
||||
>Support for Windows nodes is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using Windows nodes in a production environment.
|
||||
|
||||
When provisioning a [custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/) using Rancher, you can use a mix of Linux and Windows hosts as your cluster nodes.
|
||||
|
||||
This guide walks you through create of a custom cluster that includes 3 nodes: a Linux node, which serves as a Kubernetes control plane node; another Linux node, which serves as a Kubernetes worker used to support Ingress for the cluster; and a Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
|
||||
>- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
|
||||
>- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
|
||||
|
||||
|
||||
|
||||
## Objectives for Creating Cluster with Windows Support
|
||||
|
||||
When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Provision Hosts](#1-provision-hosts)
|
||||
- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
|
||||
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
|
||||
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
|
||||
- [5. Adding Windows Workers](#5-adding-windows-workers)
|
||||
- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
## 1. Provision Hosts
|
||||
|
||||
To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/)—two Linux, one Windows. Your hosts can be:
|
||||
|
||||
- Cloud-hosted VMs
|
||||
- VMs from virtualization clusters
|
||||
- Bare-metal servers
|
||||
|
||||
The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
|
||||
|
||||
Node | Operating System | Future Cluster Role(s)
|
||||
--------|------------------|------
|
||||
Node 1 | Linux (Ubuntu Server 16.04 recommended) | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
Node 2 | Linux (Ubuntu Server 16.04 recommended) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
|
||||
Node 3 | Windows (*Windows Server 1803 required*) | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
|
||||
|
||||
### Requirements
|
||||
|
||||
- You can view node requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
|
||||
- All nodes in a virtualization cluster or a bare metal cluster must be connected using a layer 2 network.
|
||||
- To support [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), your cluster must include at least one Linux node dedicated to the worker role.
|
||||
- Although we recommend the three node architecture listed in the table above, you can add additional Linux and Windows workers to scale up your cluster for redundancy.
|
||||
|
||||
|
||||
## 2. Cloud-hosted VM Networking Configuration
|
||||
|
||||
>**Note:** This step only applies to nodes hosted on cloud-hosted virtual machines. If you're using virtualization clusters or bare-metal servers, skip ahead to [Create the Custom Cluster](#3-create-the-custom-cluster).
|
||||
|
||||
If you're hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.
|
||||
|
||||
Service | Directions to disable private IP address checks
|
||||
--------|------------------------------------------------
|
||||
Amazon EC2 | [Disabling Source/Destination Checks](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
|
||||
Google GCE | [Enabling IP Forwarding for Instances](https://cloud.google.com/vpc/docs/using-routes#canipforward)
|
||||
Azure VM | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)
|
||||
|
||||
## 3. Create the Custom Cluster
|
||||
|
||||
To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed in the subheadings below.
|
||||
|
||||
|
||||
### Enable the Windows Support Option
|
||||
|
||||
While choosing **Cluster Options**, set **Windows Support (Experimental)** to **Enabled**.
|
||||
|
||||
After you select this option, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
|
||||
|
||||
### Networking Option
|
||||
|
||||
When choosing a network provider for a cluster that supports Windows, the only option available is Flannel, as [host-gw](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) is needed for IP routing.
|
||||
|
||||
If your nodes are hosted by a cloud provider and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
|
||||
|
||||
### Node Configuration
|
||||
|
||||
The first node in your cluster should be a Linux host that fills the Control Plane role. This role must be fulfilled before you can add Windows hosts to your cluster. At minimum, the node must have this role enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).
|
||||
|
||||
Option | Setting
|
||||
-------|--------
|
||||
Node Operating System | Linux
|
||||
Node Roles | etcd <br/> Control Plane <br/> Worker
|
||||
|
||||
|
||||
|
||||
When you're done with these configurations, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 8]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-8).
|
||||
|
||||
|
||||
|
||||
## 4. Add Linux Host for Ingress Support
|
||||
|
||||
After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support Ingress for your cluster.
|
||||
|
||||
1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
|
||||
|
||||
1. From the main menu, select **Nodes**.
|
||||
|
||||
1. Click **Edit Cluster**.
|
||||
|
||||
1. Scroll down to **Node Operating System**. Choose **Linux**.
|
||||
|
||||
1. Select the **Worker** role.
|
||||
|
||||
1. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
1. From **Rancher**, click **Save**.
|
||||
|
||||
**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
|
||||
|
||||
## 5. Adding Windows Workers
|
||||
|
||||
You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
|
||||
|
||||
1. From the main menu, select **Nodes**.
|
||||
|
||||
1. Click **Edit Cluster**.
|
||||
|
||||
1. Scroll down to **Node Operating System**. Choose **Windows**.
|
||||
|
||||
1. Select the **Worker** role.
|
||||
|
||||
1. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
|
||||
|
||||
1. From Rancher, click **Save**.
|
||||
|
||||
1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
|
||||
|
||||
**Result:** The worker role is installed on your Windows host, and the node registers with Rancher.
|
||||
|
||||
## 6. Cloud-hosted VM Routes Configuration
|
||||
|
||||
In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
|
||||
|
||||
- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
|
||||
|
||||
- When worker nodes are provisioned on GCE or Azure, they are not on the same layer 2 subnet. Nodes on GCE and Azure belong to a routable layer 3 network. Follow the instructions below to configure GCE and Azure so that the cloud network knows how to route the host subnets on each node.
|
||||
|
||||
To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
|
||||
|
||||
```bash
|
||||
kubectl get nodes -o custom-columns=nodeName:.metadata.name,nodeIP:status.addresses[0].address,routeDestination:.spec.podCIDR
|
||||
```
|
||||
|
||||
Then follow the instructions for each cloud provider to configure routing rules for each node:
|
||||
|
||||
Service | Instructions
|
||||
--------|-------------
|
||||
Google GCE | For GCE, add a static route for each node: [Adding a Static Route](https://cloud.google.com/vpc/docs/using-routes#addingroute).
|
||||
Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).
|
||||
|
||||
|
||||
` `
|
||||
@@ -74,6 +74,7 @@ These ports are typically opened on your Kubernetes nodes, regardless of what ty
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
|
||||
@@ -20,8 +20,8 @@ Rancher is tested on the following operating systems and their subsequent non-ma
|
||||
* Docker 17.03.x, 18.06.x, 18.09.x
|
||||
* RancherOS 1.5.1 (64-bit x86)
|
||||
* Docker 17.03.x, 18.06.x, 18.09.x
|
||||
* Windows Server version 1803 (64-bit x86)
|
||||
* Docker 17.06
|
||||
* Windows Server 2019 (64-bit x86)
|
||||
* Docker 18.09
|
||||
* _Experimental, see [Configuring Custom Clusters for Windows]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/)_
|
||||
|
||||
If you are using RancherOS, make sure you switch the Docker engine to a supported version using:<br>
|
||||
|
||||
@@ -21,8 +21,8 @@
|
||||
<td style="background-color: #3497DA; color:#ffffff;">git.rancher.io <sup>(2)</sup>:<br>35.160.43.145:32<br>35.167.242.46:32<br>52.33.59.17:32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="5">etcd Plane Nodes</td>
|
||||
<td rowspan="5" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td rowspan="6">etcd Plane Nodes</td>
|
||||
<td rowspan="6" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td style="background-color: #3497DA; color:#ffffff;">2379 TCP</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
@@ -45,6 +45,10 @@
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="background-color: #3497DA; color:#ffffff;">9099 TCP <sup>(4)</sup></td>
|
||||
<td></td>
|
||||
@@ -52,8 +56,8 @@
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="7">Control Plane Nodes</td>
|
||||
<td rowspan="7" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td rowspan="8">Control Plane Nodes</td>
|
||||
<td rowspan="8" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td style="background-color: #3497DA; color:#ffffff;">2379 TCP</td>
|
||||
<td></td>
|
||||
<td></td>
|
||||
@@ -76,6 +80,10 @@
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">10250 TCP</td>
|
||||
<td></td>
|
||||
@@ -93,8 +101,8 @@
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="4">Worker Plane Nodes</td>
|
||||
<td rowspan="4" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td rowspan="5">Worker Plane Nodes</td>
|
||||
<td rowspan="5" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
|
||||
<td></td>
|
||||
<td style="background-color: #3497DA; color:#ffffff;">6443 TCP</td>
|
||||
<td></td>
|
||||
@@ -105,6 +113,10 @@
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td></td>
|
||||
@@ -175,7 +187,7 @@
|
||||
<td></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="7">Notes:<br><br>1. Nodes running standalone server or Rancher HA deployment.<br>2. Required to fetch Rancher chart library.<br>3. Only without external load balancer.<br>4. Local traffic to the node itself (not across nodes).<br>5. Load balancer / proxy that handles tragging to the Rancher UI / API.<br>6. Only if SSL is not terminated at external load balancer.</td>
|
||||
<td colspan="7">Notes:<br><br>1. Nodes running standalone server or Rancher HA deployment.<br>2. Required to fetch Rancher chart library.<br>3. Only without external load balancer.<br>4. Local traffic to the node itself (not across nodes).<br>5. Load balancer / proxy that handles tragging to the Rancher UI / API.<br>6. Only if SSL is not terminated at external load balancer.<br>7. Only if using Overlay mode on Windows cluster.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -213,7 +213,29 @@
|
||||
<th>Port</th>
|
||||
<th align="left">Source</th>
|
||||
<th align="left">Description</th>
|
||||
</tr>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TCP</td>
|
||||
<td>22</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li><strong>Linux worker nodes only</strong></li>
|
||||
<li>Any network that you want to be able to remotely access this node from.</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Remote access over SSH</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TCP</td>
|
||||
<td>3389</td>
|
||||
<td>
|
||||
<ul>
|
||||
<li><strong>Windows worker nodes only</strong></li>
|
||||
<li>Any network that you want to be able to remotely access this node from.</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>Remote access over RDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TCP</td>
|
||||
<td>80</td>
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 83 KiB |
Reference in New Issue
Block a user