mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 13:08:11 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
@@ -0,0 +1,29 @@
|
||||
---
|
||||
headless: true
|
||||
---
|
||||
|
||||
|
||||
| Action | Rancher Launched Kubernetes Clusters | EKS, GKE and AKS Clusters<sup>1</sup> | Other Hosted Kubernetes Clusters | Non-EKS or GKE Registered Clusters |
|
||||
| --- | --- | ---| ---|----|
|
||||
| [Using kubectl and a kubeconfig file to Access a Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Managing Cluster Members]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/cluster-members/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Editing and Upgrading Clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/) | ✓ | ✓ | ✓ | ✓<sup>2</sup> |
|
||||
| [Managing Nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/nodes) | ✓ | ✓ | ✓ | ✓<sup>3</sup> |
|
||||
| [Managing Persistent Volumes and Storage Classes]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Managing Projects, Namespaces and Workloads]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/projects-and-namespaces/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Using App Catalogs]({{<baseurl>}}/rancher/v2.6/en/helm-charts/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| Configuring Tools ([Alerts, Notifiers, Monitoring]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/), [Logging]({{<baseurl>}}/rancher/v2.6/en/logging/), [Istio]({{<baseurl>}}/rancher/v2.6/en/istio/)) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Running Security Scans]({{<baseurl>}}/rancher/v2.6/en/security/security-scan/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Use existing configuration to create additional clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cloning-clusters/)| ✓ | ✓ | ✓ | |
|
||||
| [Ability to rotate certificates]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/certificate-rotation/) | ✓ | ✓ | | |
|
||||
| Ability to [backup]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/backing-up-etcd/) and [restore]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/restoring-etcd/) Rancher-launched clusters | ✓ | ✓ | | ✓<sup>4</sup> |
|
||||
| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cleaning-cluster-nodes/) | ✓ | | | |
|
||||
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/pod-security-policy/) | ✓ | ✓ | ||
|
||||
|
||||
1. Registered GKE and EKS clusters have the same options available as GKE and EKS clusters created from the Rancher UI. The difference is that when a registered cluster is deleted from the Rancher UI, it is not destroyed.
|
||||
|
||||
2. Cluster configuration options can't be edited for registered clusters, except for [K3s and RKE2 clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/)
|
||||
|
||||
3. For registered cluster nodes, the Rancher UI exposes the ability to cordon, drain, and edit the node.
|
||||
|
||||
4. For registered clusters using etcd as a control plane, snapshots must be taken manually outside of the Rancher UI to use for backup and recovery.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Setting up Kubernetes Clusters in Rancher
|
||||
description: Provisioning Kubernetes Clusters
|
||||
weight: 7
|
||||
---
|
||||
|
||||
Rancher simplifies the creation of clusters by allowing you to create them through the Rancher UI rather than more complex alternatives. Rancher provides multiple options for launching a cluster. Use the option that best fits your use case.
|
||||
|
||||
This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
|
||||
For a conceptual overview of how the Rancher server provisions clusters and what tools it uses to provision them, refer to the [architecture]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/) page.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type)
|
||||
- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider)
|
||||
- [Launching Kubernetes with Rancher](#launching-kubernetes-with-rancher)
|
||||
- [Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider](#launching-kubernetes-and-provisioning-nodes-in-an-infrastructure-provider)
|
||||
- [Launching Kubernetes on Existing Custom Nodes](#launching-kubernetes-on-existing-custom-nodes)
|
||||
- [Registering Existing Clusters](#registering-existing-clusters)
|
||||
- [Programmatically Creating Clusters](#programmatically-creating-clusters)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### Cluster Management Capabilities by Cluster Type
|
||||
|
||||
The following table summarizes the options and settings available for each cluster type:
|
||||
|
||||
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
|
||||
|
||||
# Setting up Clusters in a Hosted Kubernetes Provider
|
||||
|
||||
In this scenario, Rancher does not provision Kubernetes because it is installed by providers such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service.
|
||||
|
||||
If you use a Kubernetes provider such as Google GKE, Rancher integrates with its cloud APIs, allowing you to create and manage role-based access control for the hosted cluster from the Rancher UI.
|
||||
|
||||
For more information, refer to the section on [hosted Kubernetes clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters)
|
||||
|
||||
# Launching Kubernetes with Rancher
|
||||
|
||||
Rancher uses the [Rancher Kubernetes Engine (RKE)]({{<baseurl>}}/rke/latest/en/) as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer.
|
||||
|
||||
In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform.
|
||||
|
||||
These nodes can be dynamically provisioned through Rancher's UI, which calls [Docker Machine](https://docs.docker.com/machine/) to launch nodes on various cloud providers.
|
||||
|
||||
If you already have a node that you want to add to an RKE cluster, you can add it to the cluster by running a Rancher agent container on it.
|
||||
|
||||
For more information, refer to the section on [RKE clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
|
||||
|
||||
### Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider
|
||||
|
||||
Rancher can dynamically provision nodes in infrastructure providers such as Amazon EC2, DigitalOcean, Azure, or vSphere, then install Kubernetes on them.
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This template defines the parameters used to launch nodes in your cloud providers.
|
||||
|
||||
One benefit of using nodes hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically replace it, thus maintaining the expected cluster configuration.
|
||||
|
||||
The cloud providers available for creating a node template are decided based on the [node drivers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers) active in the Rancher UI.
|
||||
|
||||
For more information, refer to the section on [nodes hosted by an infrastructure provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/)
|
||||
|
||||
### Launching Kubernetes on Existing Custom Nodes
|
||||
|
||||
When setting up this type of cluster, Rancher installs Kubernetes on existing [custom nodes,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/) which creates a custom cluster.
|
||||
|
||||
You can bring any nodes you want to Rancher and use them to create a cluster.
|
||||
|
||||
These nodes include on-prem bare metal servers, cloud-hosted virtual machines, or on-prem virtual machines.
|
||||
|
||||
# Registering Existing Clusters
|
||||
|
||||
The cluster registration feature replaces the feature to import clusters.
|
||||
|
||||
Registering EKS clusters now provides additional benefits. For the most part, registered EKS clusters and EKS clusters created in Rancher are treated the same way in the Rancher UI, except for deletion.
|
||||
|
||||
When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
|
||||
|
||||
For more information, see [this page.](./registered-clusters)
|
||||
|
||||
# Programmatically Creating Clusters
|
||||
|
||||
The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
|
||||
|
||||
EKS, GKE, AKS clusters and RKE clusters can be created or imported with Terraform.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Creating an Aliyun ACK Cluster
|
||||
shortTitle: Alibaba Cloud Container Service for Kubernetes
|
||||
weight: 2120
|
||||
---
|
||||
|
||||
You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK). Rancher has already implemented and packaged the [cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/) for ACK, but by default, this cluster driver is `inactive`. In order to launch ACK clusters, you will need to [enable the ACK cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning ACK clusters.
|
||||
|
||||
# Prerequisites Outside of Rancher
|
||||
|
||||
>**Note**
|
||||
>Deploying to ACK will incur charges.
|
||||
|
||||
1. In Aliyun, activate the following services in their respective consoles.
|
||||
|
||||
- [Container Service](https://cs.console.aliyun.com)
|
||||
- [Resource Orchestration Service](https://ros.console.aliyun.com)
|
||||
- [RAM](https://ram.console.aliyun.com)
|
||||
|
||||
2. Make sure that the account you will be using to create the ACK cluster has the appropriate permissions. Referring to the official Alibaba Cloud documentation about [Role authorization](https://www.alibabacloud.com/help/doc-detail/86483.htm) and [Use the Container Service console as a RAM user](https://www.alibabacloud.com/help/doc-detail/86484.htm) for details.
|
||||
|
||||
3. In Alibaba Cloud, create an [access key](https://www.alibabacloud.com/help/doc-detail/53045.html).
|
||||
|
||||
4. In Alibaba Cloud, create an [SSH key pair](https://www.alibabacloud.com/help/doc-detail/51793.html). This key is used to access nodes in the Kubernetes cluster.
|
||||
|
||||
# Prerequisite in Rancher
|
||||
|
||||
You will need to enable the Alibaba ACK cluster driver:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Drivers**.
|
||||
1. In the **Cluster Drivers** tab, go to the **Alibaba ACK** cluster driver and click **⋮ > Activate**.
|
||||
|
||||
When the cluster driver is finished downloading, you will be able to create Alibaba ACK clusters in Rancher.
|
||||
|
||||
# Create an ACK Cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. From the **Clusters** page, click **Create**.
|
||||
1. Choose **Alibaba ACK**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Configure **Account Access** for the ACK cluster. Choose the geographical region in which to build your cluster, and input the access key that was created as part of the prerequisite steps.
|
||||
1. Click **Next: Configure Cluster**, then choose cluster type, the version of Kubernetes and the availability zone.
|
||||
1. If you choose **Kubernetes** as the cluster type, Click **Next: Configure Master Nodes**, then complete the **Master Nodes** form.
|
||||
1. Click **Next: Configure Worker Nodes**, then complete the **Worker Nodes** form.
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
+158
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: Creating an AKS Cluster
|
||||
shortTitle: Azure Kubernetes Service
|
||||
weight: 2115
|
||||
---
|
||||
|
||||
You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Service (AKS).
|
||||
|
||||
- [Prerequisites in Microsoft Azure](#prerequisites-in-microsoft-azure)
|
||||
- [Setting Up the Service Principal with the Azure Command Line Tool](#setting-up-the-service-principal-with-the-azure-command-line-tool)
|
||||
- [Setting Up the Service Principal from the Azure Portal](#setting-up-the-service-principal-from-the-azure-portal)
|
||||
- [1. Create the AKS Cloud Credentials](#1-create-the-aks-cloud-credentials)
|
||||
- [2. Create the AKS Cluster](#2-create-the-aks-cluster)
|
||||
- [Role-based Access Control](#role-based-access-control)
|
||||
- [AKS Cluster Configuration Reference](#aks-cluster-configuration-reference)
|
||||
- [Private Clusters](#private-clusters)
|
||||
- [Syncing](#syncing)
|
||||
- [Programmatically Creating AKS Clusters](#programmatically-creating-aks-clusters)
|
||||
|
||||
# Prerequisites in Microsoft Azure
|
||||
|
||||
>**Note**
|
||||
>Deploying to AKS will incur charges.
|
||||
|
||||
To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (AD) service principal. The service principal is needed to dynamically create and manage other Azure resources, and it provides credentials for your cluster to communicate with AKS. For more information about the service principal, refer to the [AKS documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal).
|
||||
|
||||
Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):
|
||||
|
||||
- Subscription ID
|
||||
- Client ID
|
||||
- Client secret
|
||||
|
||||
The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.
|
||||
|
||||
### Setting Up the Service Principal with the Azure Command Line Tool
|
||||
|
||||
You can create the service principal by running this command:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac --skip-assignment
|
||||
```
|
||||
|
||||
The result should show information about the new service principal:
|
||||
```
|
||||
{
|
||||
"appId": "xxxx--xxx",
|
||||
"displayName": "<SERVICE-PRINCIPAL-NAME>",
|
||||
"name": "http://<SERVICE-PRINCIPAL-NAME>",
|
||||
"password": "<SECRET>",
|
||||
"tenant": "<TENANT NAME>"
|
||||
}
|
||||
```
|
||||
|
||||
You also need to add roles to the service principal so that it has privileges for communication with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
Below is an example command for assigning the Contributor role to a service principal. Contributors can manage anything on AKS but cannot give access to others:
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee $appId \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
You can also create the service principal and give it Contributor privileges by combining the two commands into one. In this command, the scope needs to provide a full path to an Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
### Setting Up the Service Principal from the Azure Portal
|
||||
|
||||
You can also follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
|
||||
1. Go to the Microsoft Azure Portal [home page](https://portal.azure.com).
|
||||
|
||||
1. Click **Azure Active Directory**.
|
||||
1. Click **App registrations**.
|
||||
1. Click **New registration**.
|
||||
1. Enter a name. This will be the name of your service principal.
|
||||
1. Optional: Choose which accounts can use the service principal.
|
||||
1. Click **Register**.
|
||||
1. You should now see the name of your service principal under **Azure Active Directory > App registrations**.
|
||||
1. Click the name of your service principal. Take note of the application ID (also called app ID or client ID) so that you can use it when provisioning your AKS cluster. Then click **Certificates & secrets**.
|
||||
1. Click **New client secret**.
|
||||
1. Enter a short description, pick an expiration time, and click **Add**. Take note of the client secret so that you can use it when provisioning the AKS cluster.
|
||||
|
||||
**Result:** You have created a service principal and you should be able to see it listed in the **Azure Active Directory** section under **App registrations**. You still need to give the service principal access to AKS.
|
||||
|
||||
To give role-based access to your service principal,
|
||||
|
||||
1. Click **All Services** in the left navigation bar. Then click **Subscriptions**.
|
||||
1. Click the name of the subscription that you want to associate with your Kubernetes cluster. Take note of the subscription ID so that you can use it when provisioning your AKS cluster.
|
||||
1. Click **Access Control (IAM)**.
|
||||
1. In the **Add role assignment** section, click **Add**.
|
||||
1. In the **Role** field, select a role that will have access to AKS. For example, you can use the **Contributor** role, which has permission to manage everything except for giving access to other users.
|
||||
1. In the **Assign access to** field, select **Azure AD user, group, or service principal**.
|
||||
1. In the **Select** field, select the name of your service principal and click **Save**.
|
||||
|
||||
**Result:** Your service principal now has access to AKS.
|
||||
|
||||
# 1. Create the AKS Cloud Credentials
|
||||
|
||||
1. In the Rancher UI, click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **Azure**.
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/#cloud-credentials)
|
||||
1. Click **Create**.
|
||||
|
||||
# 2. Create the AKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. In the **Clusters** section, click **Create**.
|
||||
1. Click **Azure AKS**.
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference)
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
# Role-based Access Control
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
|
||||
# AKS Cluster Configuration Reference
|
||||
|
||||
For more information about how to configure AKS clusters from the Rancher UI, see the [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference)
|
||||
|
||||
# Private Clusters
|
||||
|
||||
Typically, AKS worker nodes do not get public IPs, regardless of whether the cluster is private. In a private cluster, the control plane does not have a public endpoint.
|
||||
|
||||
Rancher can connect to a private AKS cluster in one of two ways.
|
||||
|
||||
The first way to ensure that Rancher is running on the same [NAT](https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview) as the AKS nodes.
|
||||
|
||||
The second way is to run a command to register the cluster with Rancher. Once the cluster is provisioned, you can run the displayed command anywhere you can connect to the cluster’s Kubernetes API. This command is displayed in a pop-up when you provision an AKS cluster with a private API endpoint enabled.
|
||||
|
||||
> **Note:** Please be aware that when registering an existing AKS cluster, the cluster might take some time, possibly hours, to appear in the `Cluster To register` dropdown list. This outcome will be based on region.
|
||||
|
||||
For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster)
|
||||
|
||||
# Syncing
|
||||
|
||||
The AKS provisioner can synchronize the state of an AKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/syncing)
|
||||
|
||||
For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)
|
||||
|
||||
# Programmatically Creating AKS Clusters
|
||||
|
||||
The most common way to programmatically deploy AKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Creating a Huawei CCE Cluster
|
||||
shortTitle: Huawei Cloud Kubernetes Service
|
||||
weight: 2130
|
||||
---
|
||||
|
||||
You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine (CCE). Rancher has already implemented and packaged the [cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/) for CCE, but by default, this cluster driver is `inactive`. In order to launch CCE clusters, you will need to [enable the CCE cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning CCE clusters.
|
||||
|
||||
# Prerequisites in Huawei
|
||||
|
||||
>**Note**
|
||||
>Deploying to CCE will incur charges.
|
||||
|
||||
1. Find your project ID in Huawei CCE portal. See the CCE documentation on how to [manage your projects](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0066738518.html).
|
||||
|
||||
2. Create an [Access Key ID and Secret Access Key](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0079477318.html).
|
||||
|
||||
# Prerequisite in Rancher
|
||||
|
||||
You will need to enable the Huawei CCE cluster driver:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Drivers**.
|
||||
1. In the **Cluster Drivers** tab, go to the **Huawei CCE** cluster driver and click **⋮ > Activate**.
|
||||
|
||||
When the cluster driver is finished downloading, you will be able to create Huawei CCE clusters in Rancher.
|
||||
|
||||
# Limitations
|
||||
|
||||
Huawei CCE service doesn't support the ability to create clusters with public access through their API. You are required to run Rancher in the same VPC as the CCE clusters that you want to provision.
|
||||
|
||||
# Create the CCE Cluster
|
||||
|
||||
1. From the **Clusters** page, click **Create**.
|
||||
1. Click **Huawei CCE**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Enter **Project Id**, Access Key ID as **Access Key** and Secret Access Key **Secret Key**. Then Click **Next: Configure cluster**. Fill in the cluster configuration. For help filling out the form, refer to [Huawei CCE Configuration.](#huawei-cce-configuration)
|
||||
1. Fill the following node configuration of the cluster. For help filling out the form, refer to [Node Configuration.](#node-configuration)
|
||||
1. Click **Create** to create the CCE cluster.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
# Huawei CCE Configuration
|
||||
|
||||
|Settings|Description|
|
||||
|---|---|
|
||||
| Cluster Type | Which type or node you want to include into the cluster, `VirtualMachine` or `BareMetal`. |
|
||||
| Description | The description of the cluster. |
|
||||
| Master Version | The Kubernetes version. |
|
||||
| Management Scale Count | The max node count of the cluster. The options are 50, 200 and 1000. The larger of the scale count, the more the cost. |
|
||||
| High Availability | Enable master node high availability. The cluster with high availability enabled will have more cost. |
|
||||
| Container Network Mode | The network mode used in the cluster. `overlay_l2` and `vpc-router` is supported in `VirtualMachine` type and `underlay_ipvlan` is supported in `BareMetal` type |
|
||||
| Container Network CIDR | Network CIDR for the cluster. |
|
||||
| VPC Name | The VPC name which the cluster is going to deploy into. Rancher will create one if it is blank. |
|
||||
| Subnet Name | The Subnet name which the cluster is going to deploy into. Rancher will create one if it is blank. |
|
||||
| External Server | This option is reserved for the future we can enable CCE cluster public access via API. For now, it is always disabled. |
|
||||
| Cluster Label | The labels for the cluster. |
|
||||
| Highway Subnet | This option is only supported in `BareMetal` type. It requires you to select a VPC with high network speed for the bare metal machines. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
|
||||
# Node Configuration
|
||||
|
||||
|Settings|Description|
|
||||
|---|---|
|
||||
| Zone | The available zone at where the node(s) of the cluster is deployed. |
|
||||
| Billing Mode | The bill mode for the cluster node(s). In `VirtualMachine` type, only `Pay-per-use` is supported. in `BareMetal`, you can choose `Pay-per-use` or `Yearly/Monthly`. |
|
||||
| Validity Period | This option only shows in `Yearly/Monthly` bill mode. It means how long you want to pay for the cluster node(s). |
|
||||
| Auto Renew | This option only shows in `Yearly/Monthly` bill mode. It means that the cluster node(s) will renew the `Yearly/Monthly` payment automatically or not. |
|
||||
| Data Volume Type | Data volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
|
||||
| Data Volume Size | Data volume size for the cluster node(s) |
|
||||
| Root Volume Type | Root volume type for the cluster node(s). `SATA`, `SSD` or `SAS` for this option. |
|
||||
| Root Volume Size | Root volume size for the cluster node(s) |
|
||||
| Node Flavor | The node flavor of the cluster node(s). The flavor list in Rancher UI is fetched from Huawei Cloud. It includes all the supported node flavors. |
|
||||
| Node Count | The node count of the cluster |
|
||||
| Node Operating System | The operating system for the cluster node(s). Only `EulerOS 2.2` and `CentOS 7.4` are supported right now. |
|
||||
| SSH Key Name | The ssh key for the cluster node(s) |
|
||||
| EIP | The public IP options for the cluster node(s). `Disabled` means that the cluster node(s) are not going to bind a public IP. `Create EIP` means that the cluster node(s) will bind one or many newly created Eips after provisioned and more options will be shown in the UI to set the to-create EIP parameters. And `Select Existed EIP` means that the node(s) will bind to the EIPs you select. |
|
||||
| EIP Count | This option will only be shown when `Create EIP` is selected. It means how many EIPs you want to create for the node(s). |
|
||||
| EIP Type | This option will only be shown when `Create EIP` is selected. The options are `5_bgp` and `5_sbgp`. |
|
||||
| EIP Share Type | This option will only be shown when `Create EIP` is selected. The only option is `PER`. |
|
||||
| EIP Charge Mode | This option will only be shown when `Create EIP` is selected. The options are pay by `BandWidth` and pay by `Traffic`. |
|
||||
| EIP Bandwidth Size | This option will only be shown when `Create EIP` is selected. The BandWidth of the EIPs. |
|
||||
| Authentication Mode | It means enabling `RBAC` or also enabling `Authenticating Proxy`. If you select `Authenticating Proxy`, the certificate which is used for authenticating proxy will be also required. |
|
||||
| Node Label | The labels for the cluster node(s). Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) |
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
---
|
||||
title: Creating an EKS Cluster
|
||||
shortTitle: Amazon EKS
|
||||
weight: 2110
|
||||
---
|
||||
Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon EKS runs the Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Rancher provides an intuitive user interface for managing and deploying the Kubernetes clusters you run in Amazon EKS. With this guide, you will use Rancher to quickly and easily launch an Amazon EKS Kubernetes cluster in your AWS account. For more information on Amazon EKS, see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html).
|
||||
|
||||
- [Prerequisites in Amazon Web Services](#prerequisites-in-amazon-web-services)
|
||||
- [Amazon VPC](#amazon-vpc)
|
||||
- [IAM Policies](#iam-policies)
|
||||
- [Create the EKS Cluster](#create-the-eks-cluster)
|
||||
- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference)
|
||||
- [Architecture](#architecture)
|
||||
- [AWS Service Events](#aws-service-events)
|
||||
- [Security and Compliance](#security-and-compliance)
|
||||
- [Tutorial](#tutorial)
|
||||
- [Minimum EKS Permissions](#minimum-eks-permissions)
|
||||
- [Syncing](#syncing)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [Programmatically Creating EKS Clusters](#programmatically-creating-eks-clusters)
|
||||
# Prerequisites in Amazon Web Services
|
||||
|
||||
>**Note**
|
||||
>Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/).
|
||||
|
||||
To set up a cluster on EKS, you will need to set up an Amazon VPC (Virtual Private Cloud). You will also need to make sure that the account you will be using to create the EKS cluster has the appropriate [permissions.](#minimum-eks-permissions) For details, refer to the official guide on [Amazon EKS Prerequisites](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html#eks-prereqs).
|
||||
|
||||
### Amazon VPC
|
||||
|
||||
An Amazon VPC is required to launch the EKS cluster. The VPC enables you to launch AWS resources into a virtual network that you've defined. You can set one up yourself and provide it during cluster creation in Rancher. If you do not provide one during creation, Rancher will create one. For more information, refer to the [Tutorial: Creating a VPC with Public and Private Subnets for Your Amazon EKS Cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-public-private-vpc.html).
|
||||
|
||||
### IAM Policies
|
||||
|
||||
Rancher needs access to your AWS account in order to provision and administer your Kubernetes clusters in Amazon EKS. You'll need to create a user for Rancher in your AWS account and define what that user can access.
|
||||
|
||||
1. Create a user with programmatic access by following the steps [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html).
|
||||
|
||||
2. Next, create an IAM policy that defines what this user has access to in your AWS account. It's important to only grant this user minimal access within your account. The minimum permissions required for an EKS cluster are listed [here.](#minimum-eks-permissions) Follow the steps [here](https://docs.aws.amazon.com/eks/latest/userguide/EKS_IAM_user_policies.html) to create an IAM policy and attach it to your user.
|
||||
|
||||
3. Finally, follow the steps [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) to create an access key and secret key for this user.
|
||||
|
||||
> **Note:** It's important to regularly rotate your access and secret keys. See this [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#rotating_access_keys_console) for more information.
|
||||
|
||||
For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html).
|
||||
|
||||
|
||||
# Create the EKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Choose **Amazon EKS**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Fill out the rest of the form. For help, refer to the [configuration reference.](#eks-cluster-configuration-reference)
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
# EKS Cluster Configuration Reference
|
||||
|
||||
For the full list of EKS cluster configuration options, see [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference)
|
||||
|
||||
# Architecture
|
||||
|
||||
The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by EKS.
|
||||
|
||||
<figcaption>Managing Kubernetes Clusters through Rancher's Authentication Proxy</figcaption>
|
||||
|
||||
|
||||
|
||||
# AWS Service Events
|
||||
|
||||
To find information on any AWS Service events, please see [this page](https://status.aws.amazon.com/).
|
||||
|
||||
# Security and Compliance
|
||||
|
||||
By default only the IAM user or role that created a cluster has access to it. Attempting to access the cluster with any other user or role without additional configuration will lead to an error. In Rancher, this means using a credential that maps to a user or role that was not used to create the cluster will cause an unauthorized error. For example, an EKSCtl cluster will not register in Rancher unless the credentials used to register the cluster match the role or user used by EKSCtl. Additional users and roles can be authorized to access a cluster by being added to the aws-auth configmap in the kube-system namespace. For a more in-depth explanation and detailed instructions, please see this [documentation](https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/).
|
||||
|
||||
For more information on security and compliance with your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/shared-responsibilty.html).
|
||||
|
||||
# Tutorial
|
||||
|
||||
This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-rancher/) on the AWS Open Source Blog will walk you through how to set up an EKS cluster with Rancher, deploy a publicly accessible app to test the cluster, and deploy a sample project to track real-time geospatial data using a combination of other open-source software such as Grafana and InfluxDB.
|
||||
|
||||
# Minimum EKS Permissions
|
||||
|
||||
See [this page](./permissions) for the minimum set of permissions necessary to use all functionality of the EKS driver in Rancher.
|
||||
|
||||
# Syncing
|
||||
|
||||
The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/syncing/)
|
||||
|
||||
For information on configuring the refresh interval, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/#configuring-the-refresh-interval)
|
||||
|
||||
# Troubleshooting
|
||||
|
||||
If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing)
|
||||
|
||||
If an unauthorized error is returned while attempting to modify or register the cluster and the cluster was not created with the role or user that your credentials belong to, refer to [Security and Compliance.](#security-and-compliance)
|
||||
|
||||
For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html).
|
||||
|
||||
# Programmatically Creating EKS Clusters
|
||||
|
||||
The most common way to programmatically deploy EKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
|
||||
+223
@@ -0,0 +1,223 @@
|
||||
---
|
||||
title: Minimum EKS Permissions
|
||||
weight: 1
|
||||
---
|
||||
|
||||
Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration.
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | The service role provides Kubernetes the permissions it requires to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
Permissions required for Rancher to create service role on users behalf during the EKS cluster creation process.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "IAMPermisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:AddRoleToInstanceProfile",
|
||||
"iam:AttachRolePolicy",
|
||||
"iam:CreateInstanceProfile",
|
||||
"iam:CreateRole",
|
||||
"iam:CreateServiceLinkedRole",
|
||||
"iam:DeleteInstanceProfile",
|
||||
"iam:DeleteRole",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:GetRole",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
When an EKS cluster is created, Rancher will create a service role with the following trust policy:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
"Principal": {
|
||||
"Service": "eks.amazonaws.com"
|
||||
},
|
||||
"Effect": "Allow",
|
||||
"Sid": ""
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This role will also have two role policy attachments with the following policies ARNs:
|
||||
|
||||
```
|
||||
arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
Permissions required for Rancher to create VPC and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: Managing GKE Clusters
|
||||
shortTitle: Google Kubernetes Engine
|
||||
weight: 2105
|
||||
---
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster)
|
||||
- [Private Clusters](#private-clusters)
|
||||
- [Configuration Reference](#configuration-reference)
|
||||
- [Updating Kubernetes Version](#updating-kubernetes-version)
|
||||
- [Syncing](#syncing)
|
||||
- [Programmatically Creating GKE Clusters](#programmatically-creating-gke-clusters)
|
||||
|
||||
# Prerequisites
|
||||
|
||||
Some setup in Google Kubernetes Engine is required.
|
||||
|
||||
### Service Account Token
|
||||
|
||||
Create a service account using [Google Kubernetes Engine](https://console.cloud.google.com/projectselector/iam-admin/serviceaccounts). GKE uses this account to operate your cluster. Creating this account also generates a private key used for authentication.
|
||||
|
||||
The service account requires the following roles:
|
||||
|
||||
- **Compute Viewer:** `roles/compute.viewer`
|
||||
- **Project Viewer:** `roles/viewer`
|
||||
- **Kubernetes Engine Admin:** `roles/container.admin`
|
||||
- **Service Account User:** `roles/iam.serviceAccountUser`
|
||||
|
||||
[Google Documentation: Creating and Enabling Service Accounts](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
|
||||
|
||||
For help obtaining a private key for your service account, refer to the Google cloud documentation [here.](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#creating_service_account_keys) You will need to save the key in JSON format.
|
||||
|
||||
### Google Project ID
|
||||
|
||||
Your cluster will need to be part of a Google Project.
|
||||
|
||||
To create a new project, refer to the Google cloud documentation [here.](https://cloud.google.com/resource-manager/docs/creating-managing-projects#creating_a_project)
|
||||
|
||||
To get the project ID of an existing project, refer to the Google cloud documentation [here.](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects)
|
||||
|
||||
# Provisioning a GKE Cluster
|
||||
|
||||
>**Note**
|
||||
>Deploying to GKE will incur charges.
|
||||
|
||||
### 1. Create a Cloud Credential
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. In the left navigation bar, click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Enter a name for your Google cloud credentials.
|
||||
1. In the **Service Account** text box, paste your service account private key JSON, or upload the JSON file.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created credentials that Rancher will use to provision the new GKE cluster.
|
||||
|
||||
### 2. Create the GKE Cluster
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Google GKE**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Optional: Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Optional: Add Kubernetes [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to the cluster.
|
||||
1. Enter your Google project ID and your Google cloud credentials.
|
||||
1. Fill out the rest of the form. For help, refer to the [GKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference)
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have successfully deployed a GKE cluster.
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
# Private Clusters
|
||||
|
||||
Private GKE clusters are supported. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/)
|
||||
|
||||
# Configuration Reference
|
||||
|
||||
For details on configuring GKE clusters in Rancher, see [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference)
|
||||
# Updating Kubernetes Version
|
||||
|
||||
The Kubernetes version of a cluster can be upgraded to any version available in the region or zone fo the GKE cluster. Upgrading the master Kubernetes version does not automatically upgrade worker nodes. Nodes can be upgraded independently.
|
||||
|
||||
>**Note**
|
||||
>GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to 1.19+, basic authentication must be disabled in the Google Cloud. Otherwise, an error will appear in Rancher when an upgrade to 1.19+ is attempted. You can follow the [Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#disabling_authentication_with_a_static_password). After this, the Kubernetes version can be updated to 1.19+ via Rancher.
|
||||
|
||||
# Syncing
|
||||
|
||||
The GKE provisioner can synchronize the state of a GKE cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/syncing)
|
||||
|
||||
For information on configuring the refresh interval, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/#configuring-the-refresh-interval)
|
||||
|
||||
# Programmatically Creating GKE Clusters
|
||||
|
||||
The most common way to programmatically deploy GKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Setting up Clusters from Hosted Kubernetes Providers
|
||||
weight: 3
|
||||
---
|
||||
|
||||
In this scenario, Rancher does not provision Kubernetes because it is installed by providers such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service.
|
||||
|
||||
If you use a Kubernetes provider such as Google GKE, Rancher integrates with its cloud APIs, allowing you to create and manage role-based access control for the hosted cluster from the Rancher UI.
|
||||
|
||||
In this use case, Rancher sends a request to a hosted provider using the provider's API. The provider then provisions and hosts the cluster for you. When the cluster finishes building, you can manage it from the Rancher UI along with clusters you've provisioned that are hosted on-prem or in an infrastructure provider.
|
||||
|
||||
Rancher supports the following Kubernetes providers:
|
||||
|
||||
- [Google GKE (Google Kubernetes Engine)](https://cloud.google.com/kubernetes-engine/)
|
||||
- [Amazon EKS (Amazon Elastic Container Service for Kubernetes)](https://aws.amazon.com/eks/)
|
||||
- [Microsoft AKS (Azure Kubernetes Service)](https://azure.microsoft.com/en-us/services/kubernetes-service/)
|
||||
- [Alibaba ACK (Alibaba Cloud Container Service for Kubernetes)](https://www.alibabacloud.com/product/kubernetes)
|
||||
- [Tencent TKE (Tencent Kubernetes Engine)](https://intl.cloud.tencent.com/product/tke)
|
||||
- [Huawei CCE (Huawei Cloud Container Engine)](https://www.huaweicloud.com/en-us/product/cce.html)
|
||||
|
||||
## Hosted Kubernetes Provider Authentication
|
||||
|
||||
When using Rancher to create a cluster hosted by a provider, you are prompted for authentication information. This information is required to access the provider's API. For more information on how to obtain this information, see the following procedures:
|
||||
|
||||
- [Creating a GKE Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/gke)
|
||||
- [Creating an EKS Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/eks)
|
||||
- [Creating an AKS Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks)
|
||||
- [Creating an ACK Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/ack)
|
||||
- [Creating a TKE Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/tke)
|
||||
- [Creating a CCE Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/cce)
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: Creating a Tencent TKE Cluster
|
||||
shortTitle: Tencent Kubernetes Engine
|
||||
weight: 2125
|
||||
---
|
||||
|
||||
You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE). Rancher has already implemented and packaged the [cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/) for TKE, but by default, this cluster driver is `inactive`. In order to launch TKE clusters, you will need to [enable the TKE cluster driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/cluster-drivers/#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning TKE clusters.
|
||||
|
||||
# Prerequisites in Tencent
|
||||
|
||||
>**Note**
|
||||
>Deploying to TKE will incur charges.
|
||||
|
||||
1. Make sure that the account you will be using to create the TKE cluster has the appropriate permissions by referring to the [Cloud Access Management](https://intl.cloud.tencent.com/document/product/598/10600) documentation for details.
|
||||
|
||||
2. Create a [Cloud API Secret ID and Secret Key](https://console.cloud.tencent.com/capi).
|
||||
|
||||
3. Create a [Private Network and Subnet](https://intl.cloud.tencent.com/document/product/215/4927) in the region that you want to deploy your Kubernetes cluster.
|
||||
|
||||
4. Create a [SSH key pair](https://intl.cloud.tencent.com/document/product/213/6092). This key is used to access the nodes in the Kubernetes cluster.
|
||||
|
||||
# Prerequisite in Rancher
|
||||
|
||||
You will need to enable the Tencent TKE cluster driver:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Drivers**.
|
||||
1. In the **Cluster Drivers** tab, go to the **Tencent TKE** cluster driver and click **⋮ > Activate**.
|
||||
|
||||
When the cluster driver is finished downloading, you will be able to create Tencent TKE clusters in Rancher.
|
||||
|
||||
# Create a TKE Cluster
|
||||
|
||||
1. From the **Clusters** page, click **Create**.
|
||||
|
||||
2. Choose **Tencent TKE**.
|
||||
|
||||
3. Enter a **Cluster Name**.
|
||||
|
||||
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
|
||||
5. Configure **Account Access** for the TKE cluster. Complete each drop-down and field using the information obtained in [Prerequisites](#prerequisites-in-tencent).
|
||||
|
||||
| Option | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| Region | From the drop-down chooses the geographical region in which to build your cluster. |
|
||||
| Secret ID | Enter the Secret ID that you obtained from the Tencent Cloud Console. |
|
||||
| Secret Key | Enter the Secret key that you obtained from Tencent Cloud Console. |
|
||||
|
||||
6. Click `Next: Configure Cluster` to set your TKE cluster configurations.
|
||||
|
||||
| Option | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| Kubernetes Version | The TKE only supports Kubernetes version 1.10.5 now. |
|
||||
| Node Count | Enter the amount of worker node you want to purchase for your Kubernetes cluster, up to 100. |
|
||||
| VPC | Select the VPC name that you have created in the Tencent Cloud Console. |
|
||||
| Container Network CIDR | Enter the CIDR range of your Kubernetes cluster, you may check the available range of the CIDR in the VPC service of the Tencent Cloud Console. Default to 172.16.0.0/16. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0)
|
||||
|
||||
7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster.
|
||||
|
||||
| Option | Description |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
|
||||
| Availability Zone | Choose the availability zone of the VPC region. |
|
||||
| Subnet | Select the Subnet that you have created within the VPC, and add a new one if you don't have it in the chosen availability zone. |
|
||||
| Instance Type | From the drop-down chooses the VM instance type that you want to use for the TKE cluster, default to S2.MEDIUM4 (CPU 2 Memory 4 GiB). |
|
||||
|
||||
8. Click `Next: Configure Instance` to configure the VM instance that will use for your TKE cluster.
|
||||
|
||||
Option | Description
|
||||
-------|------------
|
||||
Operating System | The name of the operating system, currently supports Centos7.2x86_64 or ubuntu16.04.1 LTSx86_64
|
||||
Security Group | Security group ID, default does not bind any security groups.
|
||||
Root Disk Type | System disk type. System disk type restrictions are detailed in the [CVM instance configuration](https://cloud.tencent.com/document/product/213/11518).
|
||||
Root Disk Size | System disk size. Linux system adjustment range is 20 - 50G, step size is 1.
|
||||
Data Disk Type | Data disk type, default value to the SSD cloud drive
|
||||
Data Disk Size | Data disk size (GB), the step size is 10
|
||||
Band Width Type | Type of bandwidth, PayByTraffic or PayByHour
|
||||
Band Width | Public network bandwidth (Mbps)
|
||||
Key Pair | Key id, after associating the key can be used to logging to the VM node
|
||||
|
||||
9. Click **Create**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
title: Node Requirements for Rancher Managed Clusters
|
||||
weight: 1
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
|
||||
|
||||
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/)
|
||||
|
||||
Make sure the nodes for the Rancher server fulfill the following requirements:
|
||||
|
||||
- [Operating systems and container runtime requirements](#operating-systems-and-container-runtime-requirements)
|
||||
- [Hardware Requirements](#hardware-requirements)
|
||||
- [Networking Requirements](#networking-requirements)
|
||||
- [Optional: Security Considerations](#optional-security-considerations)
|
||||
|
||||
# Operating Systems and Container Runtime Requirements
|
||||
|
||||
Rancher should work with any modern Linux distribution and any modern Docker version. Linux is required for the etcd and controlplane nodes of all downstream clusters. Worker nodes may run Linux or [Windows Server.](#windows-nodes)
|
||||
|
||||
For details on which OS and Docker versions were tested with each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
|
||||
|
||||
All supported operating systems are 64-bit x86.
|
||||
|
||||
If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/arm64-platform/)
|
||||
|
||||
For information on how to install Docker, refer to the official [Docker documentation.](https://docs.docker.com/)
|
||||
|
||||
### Oracle Linux and RHEL Derived Linux Nodes
|
||||
|
||||
Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
|
||||
|
||||
>**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
|
||||
>
|
||||
> ```
|
||||
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
|
||||
reboot
|
||||
```
|
||||
|
||||
### SUSE Linux Nodes
|
||||
|
||||
SUSE Linux may have a firewall that blocks all ports by default. In that situation, follow [these steps]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports/#opening-suse-linux-ports) to open the ports needed for adding a host to a custom cluster.
|
||||
|
||||
### Flatcar Container Linux Nodes
|
||||
|
||||
When [Launching Kubernetes with Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) using Flatcar Container Linux nodes, it is required to use the following configuration in the [Cluster Config File]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#cluster-config-file)
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Canal">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
network:
|
||||
plugin: canal
|
||||
options:
|
||||
canal_flex_volume_plugin_dir: /opt/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
|
||||
flannel_backend_type: vxlan
|
||||
|
||||
services:
|
||||
kube-controller:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Calico">
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
network:
|
||||
plugin: calico
|
||||
options:
|
||||
calico_flex_volume_plugin_dir: /opt/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds
|
||||
flannel_backend_type: vxlan
|
||||
|
||||
services:
|
||||
kube-controller:
|
||||
extra_args:
|
||||
flex-volume-plugin-dir: /opt/kubernetes/kubelet-plugins/volume/exec/
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
It is also required to enable the Docker service, you can enable the Docker service using the following command:
|
||||
|
||||
```
|
||||
systemctl enable docker.service
|
||||
```
|
||||
|
||||
The Docker service is enabled automatically when using [Node Drivers]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/#node-drivers).
|
||||
|
||||
### Windows Nodes
|
||||
|
||||
Nodes with Windows Server must run Docker Enterprise Edition.
|
||||
|
||||
Windows nodes can be used for worker nodes only. See [Configuring Custom Clusters for Windows]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/)
|
||||
|
||||
# Hardware Requirements
|
||||
|
||||
The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory.
|
||||
|
||||
Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controlplane, and workers) should be hosted on different nodes so that they can scale separately from each other.
|
||||
|
||||
For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
|
||||
|
||||
For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/)
|
||||
|
||||
# Networking Requirements
|
||||
|
||||
For a production cluster, we recommend that you restrict traffic by opening only the ports defined in the port requirements below.
|
||||
|
||||
The ports required to be open are different depending on how the user cluster is launched. Each of the sections below list the ports that need to be opened for different [cluster creation options]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/).
|
||||
|
||||
For a breakdown of the port requirements for etcd nodes, controlplane nodes, and worker nodes in a Kubernetes cluster, refer to the [port requirements for the Rancher Kubernetes Engine.]({{<baseurl>}}/rke/latest/en/os/#ports)
|
||||
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes).
|
||||
|
||||
# Optional: Security Considerations
|
||||
|
||||
If you want to provision a Kubernetes cluster that is compliant with the CIS (Center for Internet Security) Kubernetes Benchmark, we recommend to following our hardening guide to configure your nodes before installing Kubernetes.
|
||||
|
||||
For more information on the hardening guide and details on which version of the guide corresponds to your Rancher and Kubernetes versions, refer to the [security section.]({{<baseurl>}}/rancher/v2.6/en/security/#rancher-hardening-guide)
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Roles for Nodes in Kubernetes
|
||||
weight: 1
|
||||
---
|
||||
|
||||
This section describes the roles for etcd nodes, controlplane nodes, and worker nodes in Kubernetes, and how the roles work together in a cluster.
|
||||
|
||||
This diagram is applicable to Kubernetes clusters [launched with Rancher using RKE.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/).
|
||||
|
||||
<br/>
|
||||
<sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>
|
||||
|
||||
# etcd
|
||||
|
||||
Nodes with the `etcd` role run etcd, which is a consistent and highly available key value store used as Kubernetes’ backing store for all cluster data. etcd replicates the data to each node.
|
||||
|
||||
>**Note:** Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
# controlplane
|
||||
|
||||
Nodes with the `controlplane` role run the Kubernetes master components (excluding `etcd`, as it's a separate role). See [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) for a detailed list of components.
|
||||
|
||||
>**Note:** Nodes with the `controlplane` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
The Kubernetes API server (`kube-apiserver`) scales horizontally. Each node with the role `controlplane` will be added to the NGINX proxy on the nodes with components that need to access the Kubernetes API server. This means that if a node becomes unreachable, the local NGINX proxy on the node will forward the request to another Kubernetes API server in the list.
|
||||
|
||||
### kube-controller-manager
|
||||
|
||||
The Kubernetes controller manager uses leader election using an endpoint in Kubernetes. One instance of the `kube-controller-manager` will create an entry in the Kubernetes endpoints and updates that entry in a configured interval. Other instances will see an active leader and wait for that entry to expire (for example, when a node is unresponsive).
|
||||
|
||||
### kube-scheduler
|
||||
|
||||
The Kubernetes scheduler uses leader election using an endpoint in Kubernetes. One instance of the `kube-scheduler` will create an entry in the Kubernetes endpoints and updates that entry in a configured interval. Other instances will see an active leader and wait for that entry to expire (for example, when a node is unresponsive).
|
||||
|
||||
# worker
|
||||
|
||||
Nodes with the `worker` role run the Kubernetes node components. See [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for a detailed list of components.
|
||||
|
||||
# References
|
||||
|
||||
* [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components)
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Checklist for Production-Ready Clusters
|
||||
weight: 2
|
||||
---
|
||||
|
||||
In this section, we recommend best practices for creating the production-ready Kubernetes clusters that will run your apps and services.
|
||||
|
||||
For a list of requirements for your cluster, including the requirements for OS/Docker, hardware, and networking, refer to the section on [node requirements.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements)
|
||||
|
||||
This is a shortlist of best practices that we strongly recommend for all production clusters.
|
||||
|
||||
For a full list of all the best practices that we recommend, refer to the [best practices section.]({{<baseurl>}}/rancher/v2.6/en/best-practices)
|
||||
|
||||
### Node Requirements
|
||||
|
||||
* Make sure your nodes fulfill all of the [node requirements,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/) including the port requirements.
|
||||
|
||||
### Back up etcd
|
||||
|
||||
* Enable etcd snapshots. Verify that snapshots are being created, and run a disaster recovery scenario to verify the snapshots are valid. etcd is the location where the state of your cluster is stored, and losing etcd data means losing your cluster. Make sure you configure recurring snapshots of etcd for your cluster(s), and make sure the snapshots are stored externally (off the node) as well.
|
||||
|
||||
### Cluster Architecture
|
||||
|
||||
* Nodes should have one of the following role configurations:
|
||||
* `etcd`
|
||||
* `controlplane`
|
||||
* `etcd` and `controlplane`
|
||||
* `worker` (the `worker` role should not be used or added on nodes with the `etcd` or `controlplane` role)
|
||||
* Have at least three nodes with the role `etcd` to survive losing one node. Increase this count for higher node fault toleration, and spread them across (availability) zones to provide even better fault tolerance.
|
||||
* Assign two or more nodes the `controlplane` role for master component high availability.
|
||||
* Assign two or more nodes the `worker` role for workload rescheduling upon node failure.
|
||||
|
||||
For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/nodes-and-roles)
|
||||
|
||||
For more information about the
|
||||
number of nodes for each Kubernetes role, refer to the section on [recommended architecture.]({{<baseurl>}}/rancher/v2.6/en/overview/architecture-recommendations/)
|
||||
|
||||
### Logging and Monitoring
|
||||
|
||||
* Configure alerts/notifiers for Kubernetes components (System Service).
|
||||
* Configure logging for cluster analysis and post-mortems.
|
||||
|
||||
### Reliability
|
||||
|
||||
* Perform load tests on your cluster to verify that its hardware can support your workloads.
|
||||
|
||||
### Networking
|
||||
|
||||
* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://coreos.com/etcd/docs/latest/tuning.html) allow etcd to run in most networks (except really high latency networks).
|
||||
* Cluster nodes should be located within a single region. Most cloud providers provide multiple availability zones within a region, which can be used to create higher availability for your cluster. Using multiple availability zones is fine for nodes with any role. If you are using [Kubernetes Cloud Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) resources, consult the documentation for any restrictions (i.e. zone storage restrictions).
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Recommended Cluster Architecture
|
||||
weight: 1
|
||||
---
|
||||
|
||||
There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`.
|
||||
|
||||
# Separating Worker Nodes from Nodes with Other Roles
|
||||
|
||||
When designing your cluster(s), you have two options:
|
||||
|
||||
* Use dedicated nodes for each role. This ensures resource availability for the components needed for the specified role. It also strictly isolates network traffic between each of the roles according to the [port requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements).
|
||||
* Assign the `etcd` and `controlplane` roles to the same nodes. These nodes must meet the hardware requirements for both roles.
|
||||
|
||||
In either case, the `worker` role should not be used or added to nodes with the `etcd` or `controlplane` role.
|
||||
|
||||
Therefore, each node should have one of the following role configurations:
|
||||
|
||||
* `etcd`
|
||||
* `controlplane`
|
||||
* Both `etcd` and `controlplane`
|
||||
* `worker`
|
||||
|
||||
# Recommended Number of Nodes with Each Role
|
||||
|
||||
The cluster should have:
|
||||
|
||||
- At least three nodes with the role `etcd` to survive losing one node. Increase this count for higher node fault toleration, and spread them across (availability) zones to provide even better fault tolerance.
|
||||
- At least two nodes with the role `controlplane` for master component high availability.
|
||||
- At least two nodes with the role `worker` for workload rescheduling upon node failure.
|
||||
|
||||
For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/nodes-and-roles)
|
||||
|
||||
|
||||
### Number of Controlplane Nodes
|
||||
|
||||
Adding more than one node with the `controlplane` role makes every master component highly available.
|
||||
|
||||
### Number of etcd Nodes
|
||||
|
||||
The number of nodes that you can lose at once while maintaining cluster availability is determined by the number of nodes assigned the `etcd` role. For a cluster with n members, the minimum is (n/2)+1. Therefore, we recommend creating an `etcd` node in 3 different availability zones within a region to survive the loss of one availability zone. If you use only two zones, you can only survive the loss of the zone where you don't lose the majority of nodes.
|
||||
|
||||
| Nodes with `etcd` role | Majority | Failure Tolerance |
|
||||
|--------------|------------|-------------------|
|
||||
| 1 | 1 | 0 |
|
||||
| 2 | 2 | 0 |
|
||||
| 3 | 2 | **1** |
|
||||
| 4 | 3 | 1 |
|
||||
| 5 | 3 | **2** |
|
||||
| 6 | 4 | 2 |
|
||||
| 7 | 4 | **3** |
|
||||
| 8 | 5 | 3 |
|
||||
| 9 | 5 | **4** |
|
||||
|
||||
References:
|
||||
|
||||
* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
|
||||
* [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
|
||||
|
||||
### Number of Worker Nodes
|
||||
|
||||
Adding more than one node with the `worker` role will make sure your workloads can be rescheduled if a node fails.
|
||||
|
||||
### Why Production Requirements are Different for the Rancher Cluster and the Clusters Running Your Applications
|
||||
|
||||
You may have noticed that our [Kubernetes Install]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) instructions do not meet our definition of a production-ready cluster, as there are no dedicated nodes for the `worker` role. However, for your Rancher installation, this three node cluster is valid, because:
|
||||
|
||||
* It allows one `etcd` node failure.
|
||||
* It maintains multiple instances of the master components by having multiple `controlplane` nodes.
|
||||
* No other workloads than Rancher itself should be created on this cluster.
|
||||
|
||||
# References
|
||||
|
||||
* [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components)
|
||||
+288
@@ -0,0 +1,288 @@
|
||||
---
|
||||
title: Registering Existing Clusters
|
||||
weight: 6
|
||||
---
|
||||
|
||||
The cluster registration feature replaced the feature to import clusters.
|
||||
|
||||
The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters)
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Registering a Cluster](#registering-a-cluster)
|
||||
- [Management Capabilities for Registered Clusters](#management-capabilities-for-registered-clusters)
|
||||
- [Configuring K3s Cluster Upgrades](#configuring-k3s-cluster-upgrades)
|
||||
- [Debug Logging and Troubleshooting for Registered K3s Clusters](#debug-logging-and-troubleshooting-for-registered-k3s-clusters)
|
||||
- [Authorized Cluster Endpoint Support for RKE2 and K3s Clusters](#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters)
|
||||
- [Annotating Registered Clusters](#annotating-registered-clusters)
|
||||
|
||||
# Prerequisites
|
||||
|
||||
### Kubernetes Node Roles
|
||||
|
||||
Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher.
|
||||
|
||||
For more information on RKE node roles, see the [best practices.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/#cluster-architecture)
|
||||
|
||||
### Permissions
|
||||
|
||||
If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.
|
||||
|
||||
In order to apply the privilege, you need to run:
|
||||
|
||||
```plain
|
||||
kubectl create clusterrolebinding cluster-admin-binding \
|
||||
--clusterrole cluster-admin \
|
||||
--user [USER_ACCOUNT]
|
||||
```
|
||||
|
||||
before running the `kubectl` command to register the cluster.
|
||||
|
||||
By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
|
||||
|
||||
If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)
|
||||
|
||||
### EKS Clusters
|
||||
|
||||
EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
|
||||
|
||||
# Registering a Cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, **Import Existing**.
|
||||
1. Choose the type of cluster.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. If you are importing a generic Kubernetes cluster in Rancher, perform the following steps for setup:</br>
|
||||
a. Click **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.</br>
|
||||
b. Enable Project Network Isolation to ensure the cluster supports Kubernetes `NetworkPolicy` resources. Users can select the **Project Network Isolation** option under the **Advanced Options** dropdown to do so.
|
||||
1. Click **Create**.
|
||||
1. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite.
|
||||
1. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher.
|
||||
1. If you are using self-signed certificates, you will receive the message `certificate signed by unknown authority`. To work around this validation, copy the command starting with `curl` displayed in Rancher to your clipboard. Then run the command on a node where kubeconfig is configured to point to the cluster you want to import.
|
||||
1. When you finish running the command(s) on your node, click **Done**.
|
||||
|
||||
**Result:**
|
||||
|
||||
- Your cluster is registered and assigned a state of **Pending**. Rancher is deploying resources to manage your cluster.</li>
|
||||
- You can access your cluster after its state is updated to **Active**.
|
||||
- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present).
|
||||
|
||||
|
||||
> **Note:**
|
||||
> You can not re-register a cluster that is currently active in a Rancher setup.
|
||||
|
||||
### Configuring a K3s Cluster to Enable Registration in Rancher
|
||||
|
||||
The K3s server needs to be configured to allow writing to the kubeconfig file.
|
||||
|
||||
This can be accomplished by passing `--write-kubeconfig-mode 644` as a flag during installation:
|
||||
|
||||
```
|
||||
$ curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644
|
||||
```
|
||||
|
||||
The option can also be specified using the environment variable `K3S_KUBECONFIG_MODE`:
|
||||
|
||||
```
|
||||
$ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
|
||||
```
|
||||
|
||||
### Configuring an Imported EKS Cluster with Terraform
|
||||
|
||||
You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
|
||||
|
||||
>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
|
||||
|
||||
The minimum config fields required by Rancher to import EKS clusters with Terraform using `eks_config_v2` are as follows:
|
||||
|
||||
- cloud_credential_id
|
||||
- name
|
||||
- region
|
||||
- imported (this field should always be set to `true` for imported clusters)
|
||||
|
||||
Example YAML configuration for imported EKS clusters:
|
||||
|
||||
```
|
||||
resource "rancher2_cluster" "my-eks-to-import" {
|
||||
name = "my-eks-to-import"
|
||||
description = "Terraform EKS Cluster"
|
||||
eks_config_v2 {
|
||||
cloud_credential_id = rancher2_cloud_credential.aws.id
|
||||
name = var.aws_eks_name
|
||||
region = var.aws_region
|
||||
imported = true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
# Management Capabilities for Registered Clusters
|
||||
|
||||
The control that Rancher has to manage a registered cluster depends on the type of cluster.
|
||||
|
||||
- [Features for All Registered Clusters](#2-5-8-features-for-all-registered-clusters)
|
||||
- [Additional Features for Registered K3s Clusters](#2-5-8-additional-features-for-registered-k3s-clusters)
|
||||
- [Additional Features for Registered EKS and GKE Clusters](#additional-features-for-registered-eks-and-gke-clusters)
|
||||
|
||||
### Features for All Registered Clusters
|
||||
|
||||
After registering a cluster, the cluster owner can:
|
||||
|
||||
- [Manage cluster access]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/) through role-based access control
|
||||
- Enable [monitoring, alerts and notifiers]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/)
|
||||
- Enable [logging]({{<baseurl>}}/rancher/v2.6/en/logging/)
|
||||
- Enable [Istio]({{<baseurl>}}/rancher/v2.6/en/istio/)
|
||||
- Use [pipelines]({{<baseurl>}}/rancher/v2.6/en/project-admin/pipelines/)
|
||||
- Manage projects and workloads
|
||||
|
||||
### Additional Features for Registered K3s Clusters
|
||||
|
||||
[K3s]({{<baseurl>}}/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution.
|
||||
|
||||
When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster:
|
||||
|
||||
- The ability to [upgrade the K3s version]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/upgrading-kubernetes/)
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
|
||||
### Additional Features for Registered EKS and GKE Clusters
|
||||
|
||||
Registering an Amazon EKS cluster or GKE cluster allows Rancher to treat it as though it were created in Rancher.
|
||||
|
||||
Amazon EKS clusters and GKE clusters can now be registered in Rancher. For the most part, these registered clusters are treated the same way as clusters created in the Rancher UI, except for deletion.
|
||||
|
||||
When you delete an EKS cluster or GKE cluster that was created in Rancher, the cluster is destroyed. When you delete a cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
|
||||
|
||||
The capabilities for registered clusters are listed in the table on [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/)
|
||||
|
||||
# Configuring K3s Cluster Upgrades
|
||||
|
||||
> It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider.
|
||||
|
||||
The **concurrency** is the maximum number of nodes that are permitted to be unavailable during an upgrade. If number of unavailable nodes is larger than the **concurrency,** the upgrade will fail. If an upgrade fails, you may need to repair or remove failed nodes before the upgrade can succeed.
|
||||
|
||||
- **Controlplane concurrency:** The maximum number of server nodes to upgrade at a single time; also the maximum unavailable server nodes
|
||||
- **Worker concurrency:** The maximum number worker nodes to upgrade at the same time; also the maximum unavailable worker nodes
|
||||
|
||||
In the K3s documentation, controlplane nodes are called server nodes. These nodes run the Kubernetes master, which maintains the desired state of the cluster. In K3s, these controlplane nodes have the capability to have workloads scheduled to them by default.
|
||||
|
||||
Also in the K3s documentation, nodes with the worker role are called agent nodes. Any workloads or pods that are deployed in the cluster can be scheduled to these nodes by default.
|
||||
|
||||
# Debug Logging and Troubleshooting for Registered K3s Clusters
|
||||
|
||||
Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.
|
||||
|
||||
To enable debug logging on the system upgrade controller deployment, edit the [configmap](https://github.com/rancher/system-upgrade-controller/blob/50a4c8975543d75f1d76a8290001d87dc298bdb4/manifests/system-upgrade-controller.yaml#L32) to set the debug environment variable to true. Then restart the `system-upgrade-controller` pod.
|
||||
|
||||
Logs created by the `system-upgrade-controller` can be viewed by running this command:
|
||||
|
||||
```
|
||||
kubectl logs -n cattle-system system-upgrade-controller
|
||||
```
|
||||
|
||||
The current status of the plans can be viewed with this command:
|
||||
|
||||
```
|
||||
kubectl get plans -A -o yaml
|
||||
```
|
||||
|
||||
If the cluster becomes stuck in upgrading, restart the `system-upgrade-controller`.
|
||||
|
||||
To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed.
|
||||
|
||||
# Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
|
||||
|
||||
_Available as of v2.6.3_
|
||||
|
||||
Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/).
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> - These steps only need to be performed on the control plane nodes of the downstream cluster. You must configure each control plane node individually.
|
||||
>
|
||||
> - The following steps will work on both RKE2 and K3s clusters registered in v2.6.x as well as those registered (or imported) from a previous version of Rancher with an upgrade to v2.6.x.
|
||||
>
|
||||
> - These steps will alter the configuration of the downstream RKE2 and K3s clusters and deploy the `kube-api-authn-webhook`. If a future implementation of the ACE requires an update to the `kube-api-authn-webhook`, then this would also have to be done manually. For more information on this webhook, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/ace/#about-the-kube-api-auth-authentication-webhook).
|
||||
|
||||
###### **Manual steps to be taken on the control plane of each downstream cluster to enable ACE:**
|
||||
|
||||
1. Create a file at `/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml` with the following contents:
|
||||
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
clusters:
|
||||
- name: Default
|
||||
cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: http://127.0.0.1:6440/v1/authenticate
|
||||
users:
|
||||
- name: Default
|
||||
user:
|
||||
insecure-skip-tls-verify: true
|
||||
current-context: webhook
|
||||
contexts:
|
||||
- name: webhook
|
||||
context:
|
||||
user: Default
|
||||
cluster: Default
|
||||
|
||||
1. Add the following to the config file (or create one if it doesn’t exist); note that the default location is `/etc/rancher/{rke2,k3s}/config.yaml`:
|
||||
|
||||
kube-apiserver-arg:
|
||||
- authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml
|
||||
|
||||
1. Run the following commands:
|
||||
|
||||
sudo systemctl stop {rke2,k3s}-server
|
||||
sudo systemctl start {rke2,k3s}-server
|
||||
|
||||
1. Finally, you **must** go back to the Rancher UI and edit the imported cluster there to complete the ACE enablement. Click on **⋮ > Edit Config**, then click the **Networking** tab under Cluster Configuration. Finally, click the **Enabled** button for **Authorized Endpoint**. Once the ACE is enabled, you then have the option of entering a fully qualified domain name (FQDN) and certificate information.
|
||||
|
||||
>**Note:** The <b>FQDN</b> field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the <b>CA Certificates</b> field.
|
||||
|
||||
# Annotating Registered Clusters
|
||||
|
||||
For all types of registered Kubernetes clusters except for K3s Kubernetes clusters, Rancher doesn't have any information about how the cluster is provisioned or configured.
|
||||
|
||||
Therefore, when Rancher registers a cluster, it assumes that several capabilities are disabled by default. Rancher assumes this in order to avoid exposing UI options to the user even when the capabilities are not enabled in the registered cluster.
|
||||
|
||||
However, if the cluster has a certain capability, such as the ability to use a pod security policy, a user of that cluster might still want to select pod security policies for the cluster in the Rancher UI. In order to do that, the user will need to manually indicate to Rancher that pod security policies are enabled for the cluster.
|
||||
|
||||
By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given a pod security policy, or another capability, outside of Rancher.
|
||||
|
||||
This example annotation indicates that a pod security policy is enabled:
|
||||
|
||||
```
|
||||
"capabilities.cattle.io/pspEnabled": "true"
|
||||
```
|
||||
|
||||
The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped.
|
||||
|
||||
```
|
||||
"capabilities.cattle.io/ingressCapabilities": "[
|
||||
{
|
||||
"customDefaultBackend":true,
|
||||
"ingressProvider":"asdf"
|
||||
}
|
||||
]"
|
||||
```
|
||||
|
||||
These capabilities can be annotated for the cluster:
|
||||
|
||||
- `ingressCapabilities`
|
||||
- `loadBalancerCapabilities`
|
||||
- `nodePoolScalingSupported`
|
||||
- `nodePortRange`
|
||||
- `pspEnabled`
|
||||
- `taintSupport`
|
||||
|
||||
All the capabilities and their type definitions can be viewed in the Rancher API view, at `[Rancher Server URL]/v3/schemas/capabilities`.
|
||||
|
||||
To annotate a registered cluster,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the custom cluster you want to annotate and click **⋮ > Edit Config**.
|
||||
1. Expand the **Labels & Annotations** section.
|
||||
1. Click **Add Annotation**.
|
||||
1. Add an annotation to the cluster with the format `capabilities/<capability>: <value>` where `value` is the cluster capability that will be overridden by the annotation. In this scenario, Rancher is not aware of any capabilities of the cluster until you add the annotation.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Behavior Differences Between RKE1 and RKE2
|
||||
weight: 2450
|
||||
---
|
||||
|
||||
RKE2, also known as RKE Government, is a Kubernetes distribution that focuses on security and compliance for U.S. Federal Government entities. It is considered the next iteration of the Rancher Kubernetes Engine, now known as RKE1.
|
||||
|
||||
RKE1 and RKE2 have several slight behavioral differences to note, and this page will highlight some of these at a high level.
|
||||
|
||||
### Control Plane Components
|
||||
|
||||
RKE1 uses Docker for deploying and managing control plane components, and it also uses Docker as the container runtime for Kubernetes. By contrast, RKE2 launches control plane components as static pods that are managed by the kubelet. RKE2's container runtime is containerd, which allows things such as container registry mirroring (RKE1 with Docker does not).
|
||||
|
||||
### Cluster API
|
||||
|
||||
RKE2/K3s provisioning is built on top of the Cluster API (CAPI) upstream framework which often makes RKE2-provisioned clusters behave differently than RKE1-provisioned clusters.
|
||||
|
||||
When you make changes to your cluster configuration in RKE2, this **may** result in nodes reprovisioning. This is controlled by CAPI controllers and not by Rancher itself. Note that for etcd nodes, the same behavior does not apply.
|
||||
|
||||
The following are some specific example configuration changes that may cause the described behavior:
|
||||
|
||||
- When editing the cluster and enabling `drain before delete`, the existing control plane nodes and worker are deleted and new nodes are created.
|
||||
|
||||
- When nodes are being provisioned and a scale down operation is performed, rather than scaling down the desired number of nodes, it is possible that the currently provisioning nodes get deleted and new nodes are provisioned to reach the desired node count. Please note that this is a bug in Cluster API, and it will be fixed in an upcoming release. Once fixed, Rancher will update the documentation.
|
||||
|
||||
Users who are used to RKE1 provisioning should take note of this new RKE2 behavior which may be unexpected.
|
||||
|
||||
### Terminology
|
||||
|
||||
You will notice that some terms have changed or gone away going from RKE1 to RKE2. For example, in RKE1 provisioning, you use **node templates**; in RKE2 provisioning, you can configure your cluster node pools when creating or editing the cluster. Another example is that the term **node pool** in RKE1 is now known as **machine pool** in RKE2.
|
||||
|
||||
|
||||
|
||||
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
---
|
||||
title: Setting up the Amazon Cloud Provider
|
||||
weight: 1
|
||||
---
|
||||
|
||||
When using the `Amazon` cloud provider, you can leverage the following capabilities:
|
||||
|
||||
- **Load Balancers:** Launches an AWS Elastic Load Balancer (ELB) when choosing `Layer-4 Load Balancer` in **Port Mapping** or when launching a `Service` with `type: LoadBalancer`.
|
||||
- **Persistent Volumes**: Allows you to use AWS Elastic Block Stores (EBS) for persistent volumes.
|
||||
|
||||
See [cloud-provider-aws README](https://kubernetes.github.io/cloud-provider-aws/) for all information regarding the Amazon cloud provider.
|
||||
|
||||
To set up the Amazon cloud provider,
|
||||
|
||||
1. [Create an IAM role and attach to the instances](#1-create-an-iam-role-and-attach-to-the-instances)
|
||||
2. [Configure the ClusterID](#2-configure-the-clusterid)
|
||||
|
||||
### 1. Create an IAM Role and attach to the instances
|
||||
|
||||
All nodes added to the cluster must be able to interact with EC2 so that they can create and remove resources. You can enable this interaction by using an IAM role attached to the instance. See [Amazon documentation: Creating an IAM Role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#create-iam-role) how to create an IAM role. There are two example policies:
|
||||
|
||||
* The first policy is for the nodes with the `controlplane` role. These nodes have to be able to create/remove EC2 resources. The following IAM policy is an example, please remove any unneeded permissions for your use case.
|
||||
* The second policy is for the nodes with the `etcd` or `worker` role. These nodes only have to be able to retrieve information from EC2.
|
||||
|
||||
While creating an [Amazon EC2 cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/), you must fill in the **IAM Instance Profile Name** (not ARN) of the created IAM role when creating the **Node Template**.
|
||||
|
||||
While creating a [Custom cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes), you must manually attach the IAM role to the instance(s).
|
||||
|
||||
IAM Policy for nodes with the `controlplane` role:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"autoscaling:DescribeAutoScalingGroups",
|
||||
"autoscaling:DescribeLaunchConfigurations",
|
||||
"autoscaling:DescribeTags",
|
||||
"ec2:DescribeInstances",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeVolumes",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateVolume",
|
||||
"ec2:ModifyInstanceAttribute",
|
||||
"ec2:ModifyVolume",
|
||||
"ec2:AttachVolume",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteVolume",
|
||||
"ec2:DetachVolume",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:DescribeVpcs",
|
||||
"elasticloadbalancing:AddTags",
|
||||
"elasticloadbalancing:AttachLoadBalancerToSubnets",
|
||||
"elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
|
||||
"elasticloadbalancing:CreateLoadBalancer",
|
||||
"elasticloadbalancing:CreateLoadBalancerPolicy",
|
||||
"elasticloadbalancing:CreateLoadBalancerListeners",
|
||||
"elasticloadbalancing:ConfigureHealthCheck",
|
||||
"elasticloadbalancing:DeleteLoadBalancer",
|
||||
"elasticloadbalancing:DeleteLoadBalancerListeners",
|
||||
"elasticloadbalancing:DescribeLoadBalancers",
|
||||
"elasticloadbalancing:DescribeLoadBalancerAttributes",
|
||||
"elasticloadbalancing:DetachLoadBalancerFromSubnets",
|
||||
"elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
|
||||
"elasticloadbalancing:ModifyLoadBalancerAttributes",
|
||||
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
|
||||
"elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
|
||||
"elasticloadbalancing:AddTags",
|
||||
"elasticloadbalancing:CreateListener",
|
||||
"elasticloadbalancing:CreateTargetGroup",
|
||||
"elasticloadbalancing:DeleteListener",
|
||||
"elasticloadbalancing:DeleteTargetGroup",
|
||||
"elasticloadbalancing:DescribeListeners",
|
||||
"elasticloadbalancing:DescribeLoadBalancerPolicies",
|
||||
"elasticloadbalancing:DescribeTargetGroups",
|
||||
"elasticloadbalancing:DescribeTargetHealth",
|
||||
"elasticloadbalancing:ModifyListener",
|
||||
"elasticloadbalancing:ModifyTargetGroup",
|
||||
"elasticloadbalancing:RegisterTargets",
|
||||
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
|
||||
"iam:CreateServiceLinkedRole",
|
||||
"kms:DescribeKey"
|
||||
],
|
||||
"Resource": [
|
||||
"*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
IAM policy for nodes with the `etcd` or `worker` role:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:DescribeInstances",
|
||||
"ec2:DescribeRegions",
|
||||
"ecr:GetAuthorizationToken",
|
||||
"ecr:BatchCheckLayerAvailability",
|
||||
"ecr:GetDownloadUrlForLayer",
|
||||
"ecr:GetRepositoryPolicy",
|
||||
"ecr:DescribeRepositories",
|
||||
"ecr:ListImages",
|
||||
"ecr:BatchGetImage"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Configure the ClusterID
|
||||
|
||||
The following resources need to tagged with a `ClusterID`:
|
||||
|
||||
- **Nodes**: All hosts added in Rancher.
|
||||
- **Subnet**: The subnet used for your cluster.
|
||||
- **Security Group**: The security group used for your cluster.
|
||||
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating an Elastic Load Balancer (ELB).
|
||||
|
||||
When you create an [Amazon EC2 Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/), the `ClusterID` is automatically configured for the created nodes. Other resources still need to be tagged manually.
|
||||
|
||||
Use the following tag:
|
||||
|
||||
**Key** = `kubernetes.io/cluster/CLUSTERID` **Value** = `owned`
|
||||
|
||||
`CLUSTERID` can be any string you like, as long as it is equal across all tags set.
|
||||
|
||||
Setting the value of the tag to `owned` tells the cluster that all resources with this tag are owned and managed by this cluster. If you share resources between clusters, you can change the tag to:
|
||||
|
||||
**Key** = `kubernetes.io/cluster/CLUSTERID` **Value** = `shared`.
|
||||
|
||||
### Using Amazon Elastic Container Registry (ECR)
|
||||
|
||||
The kubelet component has the ability to automatically obtain ECR credentials, when the IAM profile mentioned in [Create an IAM Role and attach to the instances](#1-create-an-iam-role-and-attach-to-the-instances) is attached to the instance(s). When using a Kubernetes version older than v1.15.0, the Amazon cloud provider needs be configured in the cluster. Starting with Kubernetes version v1.15.0, the kubelet can obtain ECR credentials without having the Amazon cloud provider configured in the cluster.
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Setting up the Azure Cloud Provider
|
||||
weight: 2
|
||||
---
|
||||
|
||||
When using the `Azure` cloud provider, you can leverage the following capabilities:
|
||||
|
||||
- **Load Balancers:** Launches an Azure Load Balancer within a specific Network Security Group.
|
||||
|
||||
- **Persistent Volumes:** Supports using Azure Blob disks and Azure Managed Disks with standard and premium storage accounts.
|
||||
|
||||
- **Network Storage:** Support Azure Files via CIFS mounts.
|
||||
|
||||
The following account types are not supported for Azure Subscriptions:
|
||||
|
||||
- Single tenant accounts (i.e. accounts with no subscriptions).
|
||||
- Multi-subscription accounts.
|
||||
|
||||
# Prerequisites for RKE and RKE2
|
||||
|
||||
To set up the Azure cloud provider for both RKE and RKE2, the following credentials need to be configured:
|
||||
|
||||
1. [Set up the Azure Tenant ID](#1-set-up-the-azure-tenant-id)
|
||||
2. [Set up the Azure Client ID and Azure Client Secret](#2-set-up-the-azure-client-id-and-azure-client-secret)
|
||||
3. [Configure App Registration Permissions](#3-configure-app-registration-permissions)
|
||||
4. [Set up Azure Network Security Group Name](#4-set-up-azure-network-security-group-name)
|
||||
|
||||
### 1. Set up the Azure Tenant ID
|
||||
|
||||
Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active Directory** and select **Properties**. Your **Directory ID** is your **Tenant ID** (tenantID).
|
||||
|
||||
If you want to use the Azure CLI, you can run the command `az account show` to get the information.
|
||||
|
||||
### 2. Set up the Azure Client ID and Azure Client Secret
|
||||
|
||||
Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
|
||||
|
||||
1. Select **Azure Active Directory**.
|
||||
1. Select **App registrations**.
|
||||
1. Select **New application registration**.
|
||||
1. Choose a **Name**, select `Web app / API` as **Application Type** and a **Sign-on URL** which can be anything in this case.
|
||||
1. Select **Create**.
|
||||
|
||||
In the **App registrations** view, you should see your created App registration. The value shown in the column **APPLICATION ID** is what you need to use as **Azure Client ID**.
|
||||
|
||||
The next step is to generate the **Azure Client Secret**:
|
||||
|
||||
1. Open your created App registration.
|
||||
1. In the **Settings** view, open **Keys**.
|
||||
1. Enter a **Key description**, select an expiration time and select **Save**.
|
||||
1. The generated value shown in the column **Value** is what you need to use as **Azure Client Secret**. This value will only be shown once.
|
||||
|
||||
### 3. Configure App Registration Permissions
|
||||
|
||||
The last thing you will need to do, is assign the appropriate permissions to your App registration.
|
||||
|
||||
1. Go to **More services**, search for **Subscriptions** and open it.
|
||||
1. Open **Access control (IAM)**.
|
||||
1. Select **Add**.
|
||||
1. For **Role**, select `Contributor`.
|
||||
1. For **Select**, select your created App registration name.
|
||||
1. Select **Save**.
|
||||
|
||||
### 4. Set up Azure Network Security Group Name
|
||||
|
||||
A custom Azure Network Security Group (securityGroupName) is needed to allow Azure Load Balancers to work.
|
||||
|
||||
If you provision hosts using Rancher Machine Azure driver, you will need to edit them manually to assign them to this Network Security Group.
|
||||
|
||||
You should already assign custom hosts to this Network Security Group during provisioning.
|
||||
|
||||
Only hosts expected to be load balancer back ends need to be in this group.
|
||||
|
||||
# RKE2 Cluster Set-up in Rancher
|
||||
|
||||
1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
|
||||
|
||||
1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
|
||||
* You can click on "Show Advanced" to see more of these automatically generated names and update them if
|
||||
necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
|
||||
* An example is provided below. You will modify it as needed.
|
||||
|
||||
<details id="v2.6.0-cloud-provider-config-file">
|
||||
<summary>Example Cloud Provider Config</summary>
|
||||
|
||||
```yaml
|
||||
{
|
||||
"cloud":"AzurePublicCloud",
|
||||
"tenantId": "YOUR TENANTID HERE",
|
||||
"aadClientId": "YOUR AADCLIENTID HERE",
|
||||
"aadClientSecret": "YOUR AADCLIENTSECRET HERE",
|
||||
"subscriptionId": "YOUR SUBSCRIPTIONID HERE",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
"securityGroupName": "rancher-managed-KA4jV9V2",
|
||||
"securityGroupResourceGroup": "docker-machine",
|
||||
"vnetName": "docker-machine-vnet",
|
||||
"vnetResourceGroup": "docker-machine",
|
||||
"primaryAvailabilitySetName": "docker-machine",
|
||||
"routeTableResourceGroup": "docker-machine",
|
||||
"cloudProviderBackoff": false,
|
||||
"useManagedIdentityExtension": false,
|
||||
"useInstanceMetadata": true
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
|
||||
|
||||
1. Click the **Create** button to submit the form and create the cluster.
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Setting up Cloud Providers
|
||||
weight: 2300
|
||||
---
|
||||
A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes.
|
||||
|
||||
When a cloud provider is set up in Rancher, the Rancher server can automatically provision new nodes, load balancers or persistent storage devices when launching Kubernetes definitions, if the cloud provider you're using supports such automation.
|
||||
|
||||
Your cluster will not provision correctly if you configure a cloud provider cluster of nodes that do not meet the prerequisites.
|
||||
|
||||
By default, the **Cloud Provider** option is set to `None`.
|
||||
|
||||
The following cloud providers can be enabled:
|
||||
|
||||
* Amazon
|
||||
* Azure
|
||||
* GCE (Google Compute Engine)
|
||||
* vSphere
|
||||
|
||||
### Setting up the Amazon Cloud Provider
|
||||
|
||||
For details on enabling the Amazon cloud provider, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/amazon)
|
||||
|
||||
### Setting up the Azure Cloud Provider
|
||||
|
||||
For details on enabling the Azure cloud provider, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure)
|
||||
|
||||
### Setting up the GCE Cloud Provider
|
||||
|
||||
For details on enabling the Google Compute Engine cloud provider, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/gce)
|
||||
|
||||
### Setting up the vSphere Cloud Provider
|
||||
|
||||
For details on enabling the vSphere cloud provider, refer to [this page.](./vsphere)
|
||||
|
||||
### Setting up a Custom Cloud Provider
|
||||
|
||||
The `Custom` cloud provider is available if you want to configure any Kubernetes cloud provider.
|
||||
|
||||
For the custom cloud provider option, you can refer to the [RKE docs]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration:
|
||||
|
||||
* [vSphere]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/vsphere/)
|
||||
* [OpenStack]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/openstack/)
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Setting up the Google Compute Engine Cloud Provider
|
||||
weight: 3
|
||||
---
|
||||
|
||||
In this section, you'll learn how to enable the Google Compute Engine (GCE) cloud provider for custom clusters in Rancher. A custom cluster is one in which Rancher installs Kubernetes on existing nodes.
|
||||
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#gce)
|
||||
|
||||
> **Prerequisites:** The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
|
||||
If you are using Calico,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration:
|
||||
|
||||
```
|
||||
rancher_kubernetes_engine_config:
|
||||
cloud_provider:
|
||||
name: gce
|
||||
customCloudProvider: |-
|
||||
[Global]
|
||||
project-id=<your project ID, optional>
|
||||
network-name=<your network, optional if using default network>
|
||||
subnetwork-name=<your subnetwork of the above network, optional if using default network>
|
||||
node-instance-prefix=<your instance group name/your instance name specific prefix, required>
|
||||
node-tags=<your network tags, must patch one or some tags, required>
|
||||
network:
|
||||
options:
|
||||
calico_cloud_provider: "gce"
|
||||
plugin: "calico"
|
||||
```
|
||||
|
||||
If you are using Canal or Flannel,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration:
|
||||
|
||||
```
|
||||
rancher_kubernetes_engine_config:
|
||||
cloud_provider:
|
||||
name: gce
|
||||
customCloudProvider: |-
|
||||
[Global]
|
||||
project-id=<your project ID, optional>
|
||||
network-name=<your network, optional if using default network>
|
||||
subnetwork-name=<your subnetwork of the above network, optional if using default network>
|
||||
node-instance-prefix=<your instance group name/your instance name specific prefix, required>
|
||||
node-tags=<your network tags, must patch one or some tags, required>
|
||||
services:
|
||||
kube_controller:
|
||||
extra_args:
|
||||
configure-cloud-routes: true # we need to allow the cloud provider configure the routes for the hosts
|
||||
```
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: How to Configure In-tree vSphere Cloud Provider
|
||||
shortTitle: In-tree Cloud Provider
|
||||
weight: 10
|
||||
---
|
||||
|
||||
To set up the in-tree vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:
|
||||
|
||||
1. Set **Cloud Provider** option to `Custom` or `Custom (In-Tree)`.
|
||||
1. Click on **Edit as YAML**
|
||||
1. Insert the following structure to the pre-populated cluster YAML. This structure must be placed under `rancher_kubernetes_engine_config`. Note that the `name` *must* be set to `vsphere`.
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
cloud_provider:
|
||||
name: vsphere
|
||||
vsphereCloudProvider:
|
||||
[Insert provider configuration]
|
||||
```
|
||||
|
||||
Rancher uses RKE (the Rancher Kubernetes Engine) to provision Kubernetes clusters. Refer to the [vSphere configuration reference in the RKE documentation]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/vsphere/config-reference/) for details about the properties of the `vsphereCloudProvider` directive.
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: How to Configure Out-of-tree vSphere Cloud Provider
|
||||
shortTitle: Out-of-tree Cloud Provider
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after bringing up a cluster.
|
||||
|
||||
# Prerequisites
|
||||
|
||||
The vSphere versions supported:
|
||||
|
||||
* 6.7u3
|
||||
* 7.0u1 or higher.
|
||||
|
||||
The Kubernetes version must be 1.19 or higher.
|
||||
|
||||
Using the vSphere out-of-tree cloud provider requires Linux nodes and is not supported on Windows.
|
||||
|
||||
# Installation
|
||||
|
||||
The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).
|
||||
|
||||
### 1. Create a vSphere cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **VMware vSphere** or **Custom**.
|
||||
1. On the **Basics** tab in the **Cluster Configuration** section, set the **Cloud Provider** to **vSphere**.
|
||||
1. In the **Add-On Config** tab, the vSphere Cloud Provider (CPI) and Storage Provider (CSI) options.
|
||||
1. Finish creating your cluster.
|
||||
|
||||
### 2. Install the CPI plugin
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where the vSphere CPI plugin will be installed and click **Explore**.
|
||||
1. Click **Apps & Marketplace > Charts**.
|
||||
1. Click **vSphere CPI**.
|
||||
1. Fill out the required vCenter details.
|
||||
1. vSphere CPI initializes all nodes with ProviderID which is needed by the vSphere CSI driver. Check if all nodes are initialized with the ProviderID before installing CSI driver with the following command:
|
||||
|
||||
```
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
|
||||
### 3. Installing the CSI plugin
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where the vSphere CSI plugin will be installed and click **Explore**.
|
||||
1. Click **Apps & Marketplace > Charts**.
|
||||
1. Click **vSphere CSI**.
|
||||
1. Click **Install**.
|
||||
1. Fill out the required vCenter details. On the **Features** tab, set **Enable CSI Migration** to **false**.
|
||||
3. On the **Storage** tab, fill out the details for the StorageClass. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner.
|
||||
1. Click **Install**.
|
||||
|
||||
|
||||
# Using the CSI driver for provisioning volumes
|
||||
|
||||
The CSI chart by default creates a storageClass.
|
||||
|
||||
If that option was not selected while launching the chart, create a storageClass with the `csi.vsphere.vmware.com` as the provisioner.
|
||||
|
||||
All volumes provisioned using this StorageClass will get provisioned by the CSI driver.
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: Migrating vSphere In-tree Volumes to CSI
|
||||
weight: 5
|
||||
---
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration.
|
||||
|
||||
It follows the steps provided in the official [vSphere migration documentation](https://vsphere-csi-driver.sigs.k8s.io/features/vsphere_csi_migration.html) and provides the steps to be performed in Rancher.
|
||||
|
||||
### Cloud-config Format Limitation
|
||||
|
||||
Existing volumes that were provisioned using the following cloud-config format will NOT get migrated due to an existing bug in vsphere CSI.
|
||||
|
||||
If the cloud-config has this format for datastore and resource pool path, vsphere CSI driver cannot recognize it:
|
||||
|
||||
```yaml
|
||||
default-datastore: </datacenter>/datastore/<default-datastore-name>
|
||||
resourcepool-path: "</datacenter>/host/<cluster-name>/Resources/<resource-pool-name>"
|
||||
```
|
||||
|
||||
Volumes provisioned with the in-tree provider using the following format will get migrated correctly:
|
||||
|
||||
```yaml
|
||||
default-datastore: <default-datastore-name>
|
||||
resourcepool-path: "<cluster-name>/Resources/<resource-pool-name>"
|
||||
```
|
||||
|
||||
Upstream bug: https://github.com/kubernetes-sigs/vsphere-csi-driver/issues/628
|
||||
|
||||
Rancher issue tracking this bug: https://github.com/rancher/rancher/issues/31105
|
||||
|
||||
# Prerequisites
|
||||
|
||||
- vSphere CSI Migration requires vSphere 7.0u1. In order to be able to manage existing in-tree vSphere volumes, upgrade vSphere to 7.0u1.
|
||||
- The Kubernetes version must be 1.19 or higher.
|
||||
|
||||
# Migration
|
||||
|
||||
### 1. Install the CPI plugin
|
||||
|
||||
Before installing CPI, we need to taint all nodes with `node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule`.
|
||||
|
||||
This can be done by running the following commands:
|
||||
|
||||
```
|
||||
curl -O https://raw.githubusercontent.com/rancher/helm3-charts/56b622f519728378abeddfe95074f1b87ab73b1e/charts/vsphere-cpi/taints.sh
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```
|
||||
wget https://raw.githubusercontent.com/rancher/helm3-charts/56b622f519728378abeddfe95074f1b87ab73b1e/charts/vsphere-cpi/taints.sh
|
||||
chmod +x taints.sh
|
||||
./taints.sh <path to kubeconfig if running the command outside the cluster>
|
||||
```
|
||||
|
||||
Once all nodes are tainted by the running the script, launch the Helm vSphere CPI chart.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where the vSphere CPI chart will be installed and click **Explore**.
|
||||
1. Click **Apps & Marketplace > Charts**.
|
||||
1. Click **vSphere CPI**..
|
||||
1. Click **Install**.
|
||||
1. Fill out the required vCenter details and click **Install**.
|
||||
|
||||
vSphere CPI initializes all nodes with ProviderID, which is needed by the vSphere CSI driver.
|
||||
|
||||
Check if all nodes are initialized with the ProviderID with the following command:
|
||||
|
||||
```
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
|
||||
### 2. Install the CSI driver
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where the vSphere CSI chart will be installed and click **Explore**.
|
||||
1. Click **Apps & Marketplace > Charts**.
|
||||
1. Click **vSphere CSI**..
|
||||
1. Click **Install**.
|
||||
1. Fill out the required vCenter details and click **Install**.
|
||||
1. Check **Customize Helm options before install** and click **Next**.
|
||||
1. On the **Features** tab, check **Enable CSI Migration**.
|
||||
1. Optionally, go to the **Storage** tab and set up a datastore. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner. You can provide the URL of the datastore to be used for CSI volume provisioning while creating this StorageClass. The datastore URL can be found in the vSphere client by selecting the datastore and going to the Summary tab. Fill out the details for the StorageClass.
|
||||
1. Click **Install**.
|
||||
|
||||
### 3. Edit the cluster to enable CSI migration feature flags
|
||||
|
||||
1. While editing the cluster, if the Kubernetes version is less than 1.19, select Kubernetes version 1.19 or higher from the **Kubernetes Version** dropdown.
|
||||
2. For enabling feature flags, click on "Edit as YAML", and add the following under kube-controller and kubelet:
|
||||
|
||||
```yaml
|
||||
extra_args:
|
||||
feature-gates: "CSIMigration=true,CSIMigrationvSphere=true"
|
||||
```
|
||||
|
||||
### 4. Drain worker nodes
|
||||
|
||||
Worker nodes must be drained during the upgrade before changing the kubelet and kube-controller-manager args.
|
||||
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you will drain worker nodes and click **⋮ > Edit Config**.
|
||||
1. In the **Advanced Options** section, set the field **Maximum Worker Nodes Unavailable** to 1.
|
||||
1. To drain the nodes during upgrade, select **Drain Nodes > Yes**.
|
||||
1. Set **Force** and **Delete Local Data** to **true**.
|
||||
1. Click **Save** to upgrade the cluster.
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: Setting up the vSphere Cloud Provider
|
||||
weight: 4
|
||||
---
|
||||
|
||||
In this section, you'll learn how to set up a vSphere cloud provider for a Rancher managed RKE Kubernetes cluster in vSphere.
|
||||
|
||||
# In-tree Cloud Provider
|
||||
|
||||
To use the in-tree vSphere cloud provider, you will need to use an RKE configuration option. For details, refer to [this page.](./in-tree)
|
||||
|
||||
# Out-of-tree Cloud Provider
|
||||
|
||||
To set up the out-of-tree vSphere cloud provider, you will need to install Helm charts from the Rancher marketplace. For details, refer to [this page.](./out-of-tree)
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Rancher Agent Options
|
||||
weight: 2500
|
||||
---
|
||||
|
||||
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes) and add the options to the generated `docker run` command when adding a node.
|
||||
|
||||
For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/#3-node-agents)
|
||||
|
||||
## General options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--server` | `CATTLE_SERVER` | The configured Rancher `server-url` setting which the agent connects to |
|
||||
| `--token` | `CATTLE_TOKEN` | Token that is needed to register the node in Rancher |
|
||||
| `--ca-checksum` | `CATTLE_CA_CHECKSUM` | The SHA256 checksum of the configured Rancher `cacerts` setting to validate |
|
||||
| `--node-name` | `CATTLE_NODE_NAME` | Override the hostname that is used to register the node (defaults to `hostname -s`) |
|
||||
| `--label` | `CATTLE_NODE_LABEL` | Add node labels to the node. For multiple labels, pass additional `--label` options. (`--label key=value`) |
|
||||
| `--taints` | `CATTLE_NODE_TAINTS` | Add node taints to the node. For multiple taints, pass additional `--taints` options. (`--taints key=value:effect`) |
|
||||
|
||||
## Role options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--all-roles` | `ALL=true` | Apply all roles (`etcd`,`controlplane`,`worker`) to the node |
|
||||
| `--etcd` | `ETCD=true` | Apply the role `etcd` to the node |
|
||||
| `--controlplane` | `CONTROL=true` | Apply the role `controlplane` to the node |
|
||||
| `--worker` | `WORKER=true` | Apply the role `worker` to the node |
|
||||
|
||||
## IP address options
|
||||
|
||||
| Parameter | Environment variable | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| `--address` | `CATTLE_ADDRESS` | The IP address the node will be registered with (defaults to the IP used to reach `8.8.8.8`) |
|
||||
| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | The IP address used for inter-host communication on a private network |
|
||||
|
||||
### Dynamic IP address options
|
||||
|
||||
For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
|
||||
|
||||
| Value | Example | Description |
|
||||
| ---------- | -------------------- | ----------- |
|
||||
| Interface name | `--address eth0` | The first configured IP address will be retrieved from the given interface |
|
||||
| `ipify` | `--address ipify` | Value retrieved from `https://api.ipify.org` will be used |
|
||||
| `awslocal` | `--address awslocal` | Value retrieved from `http://169.254.169.254/latest/meta-data/local-ipv4` will be used |
|
||||
| `awspublic` | `--address awspublic` | Value retrieved from `http://169.254.169.254/latest/meta-data/public-ipv4` will be used |
|
||||
| `doprivate` | `--address doprivate` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` will be used |
|
||||
| `dopublic` | `--address dopublic` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` will be used |
|
||||
| `azprivate` | `--address azprivate` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` will be used |
|
||||
| `azpublic` | `--address azpublic` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` will be used |
|
||||
| `gceinternal` | `--address gceinternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` will be used |
|
||||
| `gceexternal` | `--address gceexternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` will be used |
|
||||
| `packetlocal` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` will be used |
|
||||
| `packetpublic` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` will be used |
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
title: Launching Kubernetes on Existing Custom Nodes
|
||||
description: To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements
|
||||
metaDescription: "To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements"
|
||||
weight: 2225
|
||||
---
|
||||
|
||||
When you create a custom cluster, Rancher uses RKE (the Rancher Kubernetes Engine) to create a Kubernetes cluster in on-prem bare-metal servers, on-prem virtual machines, or in any node hosted by an infrastructure provider.
|
||||
|
||||
To use this option you'll need access to servers you intend to use in your Kubernetes cluster. Provision each server according to the [requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements), which includes some hardware specifications and Docker. After you install Docker on each server, you willl also run the command provided in the Rancher UI on each server to turn each one into a Kubernetes node.
|
||||
|
||||
This section describes how to set up a custom cluster.
|
||||
|
||||
# Creating a Cluster with Custom Nodes
|
||||
|
||||
>**Want to use Windows hosts as Kubernetes workers?**
|
||||
>
|
||||
>See [Configuring Custom Clusters for Windows]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/) before you start.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Provision a Linux Host](#1-provision-a-linux-host)
|
||||
- [2. Create the Custom Cluster](#2-create-the-custom-cluster)
|
||||
- [3. Amazon Only: Tag Resources](#3-amazon-only-tag-resources)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### 1. Provision a Linux Host
|
||||
|
||||
Begin creation of a custom cluster by provisioning a Linux host. Your host can be:
|
||||
|
||||
- A cloud-host virtual machine (VM)
|
||||
- An on-prem VM
|
||||
- A bare-metal server
|
||||
|
||||
If you want to reuse a node from a previous custom cluster, [clean the node]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cleaning-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
|
||||
|
||||
Provision the host according to the [installation requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements) and the [checklist for production-ready clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production)
|
||||
|
||||
If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) when provisioning the host.
|
||||
|
||||
### 2. Create the Custom Cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Custom**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Use **Cluster Configuration** section to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**.
|
||||
|
||||
>**Using Windows nodes as Kubernetes workers?**
|
||||
>
|
||||
>- See [Enable the Windows Support Option]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
>- The only Network Provider available for clusters with Windows support is Flannel.
|
||||
>
|
||||
>**Dual-stack on Amazon EC2:** If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
|
||||
|
||||
6. <a id="step-6"></a>Click **Next**.
|
||||
|
||||
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
|
||||
7. From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.]({{<baseurl>}}/rancher/v2.6/en/overview/concepts/#roles-for-nodes-in-kubernetes-clusters)
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
>**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
|
||||
|
||||
11. When you finish running the command(s) on your Linux host(s), click **Done**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
|
||||
### 3. Amazon Only: Tag Resources
|
||||
|
||||
If you have configured your cluster to use Amazon as **Cloud Provider**, tag your AWS resources with a cluster ID.
|
||||
|
||||
[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
|
||||
|
||||
The following resources need to be tagged with a `ClusterID`:
|
||||
|
||||
- **Nodes**: All hosts added in Rancher.
|
||||
- **Subnet**: The subnet used for your cluster
|
||||
- **Security Group**: The security group used for your cluster.
|
||||
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
|
||||
|
||||
The tag that should be used is:
|
||||
|
||||
```
|
||||
Key=kubernetes.io/cluster/<CLUSTERID>, Value=owned
|
||||
```
|
||||
|
||||
`<CLUSTERID>` can be any string you choose. However, the same string must be used on every resource you tag. Setting the tag value to `owned` informs the cluster that all resources tagged with the `<CLUSTERID>` are owned and managed by this cluster.
|
||||
|
||||
If you share resources between clusters, you can change the tag to:
|
||||
|
||||
```
|
||||
Key=kubernetes.io/cluster/CLUSTERID, Value=shared
|
||||
```
|
||||
|
||||
# Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
+121
@@ -0,0 +1,121 @@
|
||||
---
|
||||
title: Azure Machine Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
### Environment
|
||||
|
||||
Microsoft provides multiple [clouds](https://docs.microsoft.com/en-us/cli/azure/cloud?view=azure-cli-latest) for compliance with regional laws, which are available for your use:
|
||||
|
||||
- AzurePublicCloud
|
||||
- AzureGermanCloud
|
||||
- AzureChinaCloud
|
||||
- AzureUSGovernmentCloud
|
||||
|
||||
### Location
|
||||
|
||||
Configure the cluster and node [location](https://docs.microsoft.com/en-us/azure/virtual-machines/regions).
|
||||
|
||||
### Resource Group
|
||||
|
||||
A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.
|
||||
|
||||
Use an existing resource group or enter a resource group name and one will be created for you.
|
||||
|
||||
For information on managing resource groups, see the [Azure documentation.](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal)
|
||||
|
||||
### Availability Set (unmanaged)
|
||||
|
||||
Name or ID of an existing [availability set](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview) to add the VM to.
|
||||
|
||||
### Image
|
||||
|
||||
The name of the operating system image provided as an ARM resource identifier. Requires using managed disk.
|
||||
|
||||
### VM Size
|
||||
|
||||
Choose a size for each VM in the node pool. For details about each VM size, see [this page.](https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/)
|
||||
|
||||
## Advanced Options
|
||||
|
||||
### Fault Domain Count
|
||||
|
||||
Fault domains define the group of virtual machines that share a common power source and network switch. If the availability set has already been created, the fault domain count will be ignored.
|
||||
|
||||
For more information on fault domains, see [refer here](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview#how-do-availability-sets-work).
|
||||
|
||||
### Update Domain Count
|
||||
|
||||
Update domains indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. If the availability set has already been created, the update domain count will be ignored.
|
||||
|
||||
For more information on update domains, see [refer here](https://docs.microsoft.com/en-us/azure/virtual-machines/availability-set-overview#how-do-availability-sets-work).
|
||||
|
||||
### Purchase Plan
|
||||
|
||||
Some VM images in the Azure Marketplace require a plan. If applicable, select a purchase plan, formatted as `publisher:product:plan`, to use with your chosen image.
|
||||
|
||||
### Subnet
|
||||
|
||||
The name of the subnet when creating a new VNet or referencing an existing one.
|
||||
|
||||
Default: `docker-machine`
|
||||
|
||||
### Subnet Prefix
|
||||
|
||||
The subnet IP address prefix to use when creating a new VNet in CIDR format.
|
||||
|
||||
Default: `192.168.0.0/16`
|
||||
|
||||
### Virtual Network
|
||||
|
||||
The [virtual network](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview) to use or create if one does not exist. Formatted as `[resourcegroup:]name`.
|
||||
|
||||
### Public IP Options
|
||||
|
||||
#### No Public IP
|
||||
|
||||
Do not allocate a public IP address.
|
||||
|
||||
#### Static Public IP
|
||||
|
||||
Allocate a static public IP address.
|
||||
|
||||
### Use Private IP
|
||||
|
||||
Use a static private IP address.
|
||||
|
||||
### Private IP Address
|
||||
|
||||
Configure a static private IP address to use.
|
||||
|
||||
### Network Security Group
|
||||
|
||||
The [network security group](https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview) to use. All nodes using this template will use the supplied network security group. If no network security group is provided, a new one will be created for each node.
|
||||
|
||||
### DNS Label
|
||||
|
||||
A unique DNS name label for the public IP address.
|
||||
|
||||
### Storage Type
|
||||
|
||||
The [storage account](https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview) type to use with your VMs. Options include Standard LRS, Standard ZRS, Standard GRS, Standard RAGRS, and Premium LRS.
|
||||
|
||||
### Use Managed Disks
|
||||
|
||||
[Azure managed disks](https://docs.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview) are block-level storage volumes that are managed by Azure and used with Azure Virtual Machines. Managed disks are designed for 99.999% availability. Managed disks achieve this by providing you with three replicas of your data, allowing for high durability.
|
||||
|
||||
### Managed Disk Size
|
||||
|
||||
The size in GB for the disk for each node.
|
||||
|
||||
### SSH Username
|
||||
|
||||
The username used to create an SSH connection to your nodes.
|
||||
|
||||
### Open Port
|
||||
|
||||
Opens inbound traffic on specified ports. When using an existing Network Security Group, Open Ports are ignored.
|
||||
|
||||
Default: `2379/tcp, 2380/tcp, 6443/tcp, 9796/tcp, 10250/tcp, 10251/tcp, 10252/tcp, 10256/tcp` and `8472/udp, 4789/udp`
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Azure Node Template Configuration
|
||||
weight: 1
|
||||
---
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
- **Placement** sets the geographical region where your cluster is hosted and other location metadata.
|
||||
- **Network** configures the networking used in your cluster.
|
||||
- **Instance** customizes your VM configuration.
|
||||
|
||||
The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:
|
||||
|
||||
- **Labels:** For information on labels, refer to the [Docker object label documentation.](https://docs.docker.com/config/labels-custom-metadata/)
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
+142
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Creating an Azure Cluster
|
||||
shortTitle: Azure
|
||||
weight: 2220
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Azure through Rancher.
|
||||
|
||||
First, you will set up your Azure cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in Azure.
|
||||
|
||||
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
|
||||
> - Terminate the SSL/TLS on the internal load balancer
|
||||
> - Use the L7 load balancer
|
||||
|
||||
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
For more information on configuring Azure node templates, refer to the [Azure node template configuration reference.](./azure-node-template-config)
|
||||
|
||||
- [Preparation in Azure](#preparation-in-azure)
|
||||
- [Creating an Azure Cluster](#creating-an-azure-cluster)
|
||||
|
||||
# Preparation in Azure
|
||||
|
||||
Before creating a node template in Rancher using a cloud infrastructure such as Azure, we must configure Rancher to allow the manipulation of resources in an Azure subscription.
|
||||
|
||||
To do this, we will first create a new Azure **service principal (SP)** in Azure **Active Directory (AD)**, which, in Azure, is an application user who has permission to manage Azure resources.
|
||||
|
||||
The following is a template `az cli` script that you have to run for creating an service principal, where you have to enter your SP name, role, and scope:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--name="<Rancher ServicePrincipal name>" \
|
||||
--role="Contributor" \
|
||||
--scopes="/subscriptions/<subscription Id>"
|
||||
```
|
||||
|
||||
The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, and *The client secret*. This information will be used when you create a node template for Azure.
|
||||
|
||||
# Creating an Azure Cluster
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **Azure**.
|
||||
1. Enter your Azure credentials.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for Azure will allow Rancher to provision new nodes in Azure. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Add Template**.
|
||||
1. Click **Azure**.
|
||||
1. Fill out a node template for Azure. For help filling out the form, refer to [Azure Node Template Configuration.](./azure-node-template-config)
|
||||
|
||||
### 3. Create a cluster with node pools using the node template
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Azure.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Azure**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. In the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
If you already have a set of cloud credentials to use, skip this section.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **Azure**.
|
||||
1. Enter your Azure credentials.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create your cluster
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Azure.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Toggle the switch to **RKE2/K3s**.
|
||||
1. Click **Azure**.
|
||||
1. Select a **Cloud Credential**, if more than one exists. Otherwise, it's preselected.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Create a machine pool for each Kubernetes role. Refer to the [best practices]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools#node-roles-in-rke2) for recommendations on role assignments and counts.
|
||||
1. For each machine pool, define the machine configuration. Refer to the [Azure machine configuration reference]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/azure-machine-config/) for information on configuration options.
|
||||
1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2 cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/)
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
|
||||
### Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Creating a DigitalOcean Cluster
|
||||
shortTitle: DigitalOcean
|
||||
weight: 2215
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in DigitalOcean.
|
||||
|
||||
First, you will set up your DigitalOcean cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in DigitalOcean.
|
||||
|
||||
Then you will create a DigitalOcean cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **DigitalOcean**.
|
||||
1. Enter your Digital Ocean credentials.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for DigitalOcean will allow Rancher to provision new nodes in DigitalOcean. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Add Template**.
|
||||
1. Click **DigitalOcean**.
|
||||
1. Fill out a node template for DigitalOcean. For help filling out the form, refer to [DigitalOcean Node Template Configuration.](./do-node-template-config)
|
||||
|
||||
### 3. Create a cluster with node pools using the node template
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **DigitalOcean**.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Add one or more node pools to your cluster. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. **In the Cluster Configuration** section, choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
If you already have a set of cloud credentials to use, skip this section.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **DigitalOcean**.
|
||||
1. Enter your Digital Ocean credentials.
|
||||
1. Click **Create**.
|
||||
|
||||
### 2. Create your cluster
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in DigitalOcean.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Toggle the switch to **RKE2/K3s**.
|
||||
1. Click **DigitalOcean**.
|
||||
1. Select a **Cloud Credential**, if more than one exists. Otherwise, it's preselected.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Create a machine pool for each Kubernetes role. Refer to the [best practices]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools#node-roles-in-rke2) for recommendations on role assignments and counts.
|
||||
1. For each machine pool, define the machine configuration. Refer to the [DigitalOcean machine configuration reference]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/do-machine-config/) for information on configuration options.
|
||||
1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2 cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/)
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
# Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: DigitalOcean Machine Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
For more details about DigitalOcean, Droplets, refer to the [official documentation](https://docs.digitalocean.com/products/compute/).
|
||||
|
||||
### Region
|
||||
|
||||
Configure the [region](https://docs.digitalocean.com/products/app-platform/concepts/region/) where Droplets are created.
|
||||
|
||||
### Size
|
||||
|
||||
Configure the [size](https://docs.digitalocean.com/products/droplets/resources/choose-plan/) of Droplets.
|
||||
|
||||
### OS Image
|
||||
|
||||
Configure the operating system [image](https://docs.digitalocean.com/products/images/) Droplets are created from.
|
||||
|
||||
### Monitoring
|
||||
|
||||
Enable the DigitalOcean agent for additional [monitoring](https://docs.digitalocean.com/products/monitoring/).
|
||||
|
||||
### IPv6
|
||||
|
||||
Enable IPv6 for Droplets.
|
||||
|
||||
### Private Networking
|
||||
|
||||
Enable private networking for Droplets.
|
||||
|
||||
### Droplet Tags
|
||||
|
||||
Apply a tag (label) to a Droplet. Tags may only contain letters, numbers, colons, dashes, and underscores. For example, `my_server`.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: DigitalOcean Node Template Configuration
|
||||
weight: 1
|
||||
----
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
### Droplet Options
|
||||
|
||||
The **Droplet Options** provision your cluster's geographical region and specifications.
|
||||
|
||||
### Docker Daemon
|
||||
|
||||
The [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:
|
||||
|
||||
- **Labels:** For information on labels, refer to the [Docker object label documentation.](https://docs.docker.com/config/labels-custom-metadata/)
|
||||
- **Docker Engine Install URL:** Determines what Docker version will be installed on the instance.
|
||||
- **Registry mirrors:** Docker Registry mirror to be used by the Docker daemon
|
||||
- **Other advanced options:** Refer to the [Docker daemon option reference](https://docs.docker.com/engine/reference/commandline/dockerd/)
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: EC2 Machine Configuration Reference
|
||||
weight: 2
|
||||
---
|
||||
|
||||
For more details about EC2 nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
### Region
|
||||
|
||||
The geographical [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in which to build your cluster.
|
||||
|
||||
### Zone
|
||||
|
||||
The [zone](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones), an isolated location within a region to build your cluster
|
||||
|
||||
### Instance Type
|
||||
|
||||
The [instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), which determines the hardware characteristics, used to provision your cluster.
|
||||
|
||||
### Root Disk Size
|
||||
|
||||
Configure the size (in GB) for your [root device](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html).
|
||||
|
||||
### VPC/Subnet
|
||||
|
||||
The [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) or specific [subnet](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html), an IP range in your VPC, to add your resources to.
|
||||
|
||||
### IAM Instance Profile Name
|
||||
|
||||
The name of the [instance profile] used to pass an IAM role to an EC2 instance.
|
||||
|
||||
## Advanced Options
|
||||
|
||||
### AMI ID
|
||||
|
||||
The [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) used for the nodes in your cluster.
|
||||
|
||||
### SSH Username for AMI
|
||||
|
||||
The username for connecting to your launched instances. Refer to [here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html) for the default usernames to selected AMIs. For AMIs not listed, check with the AMI provider.
|
||||
|
||||
### Security Group
|
||||
|
||||
Choose the default security group or configure a security group.
|
||||
|
||||
Please refer to [Amazon EC2 security group when using Node Driver]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports/#rancher-aws-ec2-security-group) to see what rules are created in the `rancher-nodes` Security Group.
|
||||
|
||||
### EBS Root Volume Type
|
||||
|
||||
The [EBS volume type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) to use for the root device.
|
||||
|
||||
### Encrypt EBS Volume
|
||||
|
||||
Enable [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html).
|
||||
|
||||
### Request Spot Instance
|
||||
|
||||
Enable option to [request spot instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html) and specify the maximum instance price per hour you're willing to pay.
|
||||
|
||||
### Use only private address
|
||||
|
||||
Enable option on use only [private addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html).
|
||||
|
||||
### EBS-Optimized Instance
|
||||
|
||||
Use an [EBS-optimized instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html).
|
||||
|
||||
### Allow access to EC2 metadata
|
||||
|
||||
Enable access to [EC2 metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).
|
||||
|
||||
### Use tokens for metadata
|
||||
|
||||
Use [Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), a token-based method to access metadata.
|
||||
|
||||
### Add Tag
|
||||
|
||||
Add metadata using [tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) to categorize resources.
|
||||
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: EC2 Node Template Configuration
|
||||
weight: 1
|
||||
---
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
### Region
|
||||
|
||||
In the **Region** field, select the same region that you used when creating your cloud credentials.
|
||||
|
||||
### Cloud Credentials
|
||||
|
||||
Your AWS account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.6/en/user-settings/cloud-credentials/)
|
||||
|
||||
See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
|
||||
|
||||
See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy.
|
||||
|
||||
See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach an IAM
|
||||
|
||||
See our three example JSON policies:
|
||||
|
||||
- [Example IAM Policy]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy)
|
||||
- [Example IAM Policy with PassRole]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers) or want to pass an IAM Profile to an instance)
|
||||
- [Example IAM Policy to allow encrypted EBS volumes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy-to-allow-encrypted-ebs-volumes) policy to an user.
|
||||
|
||||
### Authenticate & Configure Nodes
|
||||
|
||||
Choose an availability zone and network settings for your cluster.
|
||||
|
||||
### Security Group
|
||||
|
||||
Choose the default security group or configure a security group.
|
||||
|
||||
Please refer to [Amazon EC2 security group when using Node Driver]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports/#rancher-aws-ec2-security-group) to see what rules are created in the `rancher-nodes` Security Group.
|
||||
|
||||
---
|
||||
**_New in v2.6.4_**
|
||||
|
||||
If you provide your own security group for an EC2 instance, please note that Rancher will not modify it. As such, you will be responsible for ensuring that your security group is set to allow the [necessary ports for Rancher to provision the instance]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/ports/#ports-for-rancher-server-nodes-on-rke). For more information on controlling inbound and outbound traffic to EC2 instances with security groups, refer [here](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#WorkingWithSecurityGroups).
|
||||
|
||||
### Instance Options
|
||||
|
||||
Configure the instances that will be created. Make sure you configure the correct **SSH User** for the configured AMI. It is possible that a selected region does not support the default instance type. In this scenario you must select an instance type that does exist, otherwise an error will occur stating the requested configuration is not supported.
|
||||
|
||||
If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers), you will need an additional permission in your policy. See [Example IAM policy with PassRole](#example-iam-policy-with-passrole) for an example policy.
|
||||
|
||||
### Engine Options
|
||||
|
||||
In the **Engine Options** section of the node template, you can configure the Docker daemon. You may want to specify the docker version or a Docker registry mirror.
|
||||
@@ -0,0 +1,279 @@
|
||||
---
|
||||
title: Creating an Amazon EC2 Cluster
|
||||
shortTitle: Amazon EC2
|
||||
description: Learn the prerequisites and steps required in order for you to create an Amazon EC2 cluster using Rancher
|
||||
weight: 2210
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Amazon EC2.
|
||||
|
||||
First, you will set up your EC2 cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision new nodes in EC2.
|
||||
|
||||
Then you will create an EC2 cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- **AWS EC2 Access Key and Secret Key** that will be used to create the instances. See [Amazon Documentation: Creating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) how to create an Access Key and Secret Key.
|
||||
- **IAM Policy created** to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our three example JSON policies below:
|
||||
- [Example IAM Policy](#example-iam-policy)
|
||||
- [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers) or want to pass an IAM Profile to an instance)
|
||||
- [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
|
||||
- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.
|
||||
|
||||
# Creating an EC2 Cluster
|
||||
|
||||
The steps to create a cluster differ based on your Rancher version.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials and information from EC2](#2-create-a-node-template-with-your-cloud-credentials-and-information-from-ec2)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **Amazon**.
|
||||
1. Enter a name for the cloud credential.
|
||||
1. In the **Default Region** field, select the AWS region where your cluster nodes will be located.
|
||||
1. Enter your AWS EC2 **Access Key** and **Secret Key**.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials and information from EC2
|
||||
|
||||
Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for EC2 will allow Rancher to provision new nodes in EC2. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**
|
||||
1. Click **Add Template**.
|
||||
1. Fill out a node template for EC2. For help filling out the form, refer to [EC2 Node Template Configuration.](./ec2-node-template-config)
|
||||
1. Click **Create**.
|
||||
|
||||
>**Note:** If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
|
||||
### 3. Create a cluster with node pools using the node template
|
||||
|
||||
Add one or more node pools to your cluster. For more information about node pools, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Amazon EC2**.
|
||||
1. Create a node pool for each Kubernetes role. For each node pool, choose a node template that you created. For more information about node pools, including best practices for assigning Kubernetes roles to them, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools)
|
||||
1. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. Refer to [Selecting Cloud Providers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) to configure the Kubernetes Cloud Provider. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
>**Note:** If you want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements]({{<baseurl>}}/rke//latest/en/config-options/dual-stack#requirements) that must be taken into consideration.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
If you already have a set of cloud credentials to use, skip this section.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **Amazon**.
|
||||
1. Enter a name for the cloud credential.
|
||||
1. In the **Default Region** field, select the AWS region where your cluster nodes will be located.
|
||||
1. Enter your AWS EC2 **Access Key** and **Secret Key**.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create your cluster
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Toggle the switch to **RKE2/K3s**.
|
||||
1. Click **Amazon EC2**.
|
||||
1. Select a **Cloud Credential**, if more than one exists. Otherwise, it's preselected.
|
||||
1. Enter a **Cluster Name**.
|
||||
1. Create a machine pool for each Kubernetes role. Refer to the [best practices]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools#node-roles-in-rke2) for recommendations on role assignments and counts.
|
||||
1. For each machine pool, define the machine configuration. Refer to [the EC2 machine configuration reference]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/ec2-machine-config/) for information on configuration options.
|
||||
1. Use the **Cluster Configuration** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. For help configuring the cluster, refer to the [RKE2 cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/)
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Click **Create**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
### Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
# IAM Policies
|
||||
|
||||
### Example IAM Policy
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VisualEditor0",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:Describe*",
|
||||
"ec2:ImportKeyPair",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:ModifyInstanceMetadataOptions"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VisualEditor1",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:ec2:REGION::image/ami-*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:instance/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:placement-group/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:volume/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:subnet/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:key-pair/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:network-interface/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:security-group/*"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Sid": "VisualEditor2",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RebootInstances",
|
||||
"ec2:TerminateInstances",
|
||||
"ec2:StartInstances",
|
||||
"ec2:StopInstances"
|
||||
],
|
||||
"Resource": "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:instance/*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Example IAM Policy with PassRole
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VisualEditor0",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:Describe*",
|
||||
"ec2:ImportKeyPair",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:ModifyInstanceMetadataOptions"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VisualEditor1",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:ec2:REGION::image/ami-*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:instance/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:placement-group/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:volume/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:subnet/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:key-pair/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:network-interface/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:security-group/*",
|
||||
"arn:aws:iam::AWS_ACCOUNT_ID:role/YOUR_ROLE_NAME"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Sid": "VisualEditor2",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RebootInstances",
|
||||
"ec2:TerminateInstances",
|
||||
"ec2:StartInstances",
|
||||
"ec2:StopInstances"
|
||||
],
|
||||
"Resource": "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:instance/*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Example IAM Policy to allow encrypted EBS volumes
|
||||
``` json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"kms:Decrypt",
|
||||
"kms:GenerateDataKeyWithoutPlaintext",
|
||||
"kms:Encrypt",
|
||||
"kms:DescribeKey",
|
||||
"kms:CreateGrant",
|
||||
"ec2:DetachVolume",
|
||||
"ec2:AttachVolume",
|
||||
"ec2:DeleteSnapshot",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateVolume",
|
||||
"ec2:DeleteVolume",
|
||||
"ec2:CreateSnapshot"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:volume/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:instance/*",
|
||||
"arn:aws:ec2:REGION:AWS_ACCOUNT_ID:snapshot/*",
|
||||
"arn:aws:kms:REGION:AWS_ACCOUNT_ID:key/KMS_KEY_ID"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:DescribeInstances",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVolumes",
|
||||
"ec2:DescribeSnapshots"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
---
|
||||
title: Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
weight: 2205
|
||||
---
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [RKE Clusters](#rke-clusters)
|
||||
- [Node templates](#node-templates)
|
||||
- [Node labels](#node-labels)
|
||||
- [Node taints](#node-taints)
|
||||
- [Administrator control of node templates](#administrator-control-of-node-templates)
|
||||
- [Node pools](#node-pools)
|
||||
- [Node pool taints](#node-pool-taints)
|
||||
- [About node auto-replace](#about-node-auto-replace)
|
||||
- [Enabling node auto-replace](#enabling-node-auto-replace)
|
||||
- [Disabling node auto-replace](#disabling-node-auto-replace)
|
||||
- [Cloud credentials](#cloud-credentials)
|
||||
- [Node drivers](#node-drivers)
|
||||
- [RKE2 Clusters](#rke2-clusters)
|
||||
- [Node roles in RKE2](#node-roles-in-rke2)
|
||||
|
||||
When you create an RKE or RKE2 cluster using a node template in Rancher, each resulting node pool is shown in a new **Machine Pools** tab. You can see the machine pools by doing the following:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click the name of the RKE or RKE2 cluster.
|
||||
|
||||
## RKE Clusters
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This node template defines the parameters you want to use to launch nodes in your infrastructure providers or cloud providers.
|
||||
|
||||
One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
|
||||
The available cloud providers to create a node template are decided based on active [node drivers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-drivers).
|
||||
|
||||
### Node Templates
|
||||
|
||||
A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. These nodes can be launched from the UI. Rancher uses [Docker Machine](https://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.
|
||||
|
||||
After you create a node template in Rancher, it's saved so that you can use this template again to create node pools. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
|
||||
|
||||
#### Node Labels
|
||||
|
||||
You can add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) on each node template, so that any nodes created from the node template will automatically have these labels on them.
|
||||
|
||||
Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
|
||||
|
||||
#### Node Taints
|
||||
|
||||
You can add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on each node template, so that any nodes created from the node template will automatically have these taints on them.
|
||||
|
||||
Since taints can be added at a node template and node pool, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
|
||||
|
||||
#### Administrator Control of Node Templates
|
||||
|
||||
Administrators can control all node templates. Admins can now maintain all the node templates within Rancher. When a node template owner is no longer using Rancher, the node templates created by them can be managed by administrators so the cluster can continue to be updated and maintained.
|
||||
|
||||
To access all node templates, an administrator will need to do the following:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
|
||||
**Result:** All node templates are listed. The templates can be edited or cloned by clicking the **⋮**.
|
||||
|
||||
### Node Pools
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template](#node-templates).
|
||||
|
||||
A node template defines the configuration of a node, like what operating system to use, number of CPUs, and amount of memory.
|
||||
|
||||
The benefit of using a node pool is that if a node is destroyed or deleted, you can increase the number of live nodes to compensate for the node that was lost. The node pool helps you ensure that the count of the node pool is as expected.
|
||||
|
||||
Each node pool must have one or more nodes roles assigned.
|
||||
|
||||
Each node role (i.e. etcd, controlplane, and worker) should be assigned to a distinct node pool. Although it is possible to assign multiple node roles to a node pool, this should not be done for production clusters.
|
||||
|
||||
The recommended setup is to have:
|
||||
|
||||
- a node pool with the etcd node role and a count of three
|
||||
- a node pool with the controlplane node role and a count of at least two
|
||||
- a node pool with the worker node role and a count of at least two
|
||||
|
||||
**RKE1 downstream cluster nodes in an air-gapped environment:**
|
||||
|
||||
By default, Rancher tries to run the Docker Install script when provisioning RKE1 downstream cluster nodes, such as in vSphere. However, the Rancher Docker installation script would fail in air-gapped environments. To work around this issue, you may choose to skip installing Docker when creating a Node Template where Docker is pre-installed onto a VM image. You can accomplish this by selecting **None** in the dropdown list for `Docker Install URL` under **Engine Options** in the Rancher UI.
|
||||
|
||||
<figcaption>**Engine Options Dropdown:**</figcaption>
|
||||
|
||||
|
||||
#### Node Pool Taints
|
||||
|
||||
If you haven't defined [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on your node template, you can add taints for each node pool. The benefit of adding taints at a node pool is beneficial over adding it at a node template is that you can swap out the node templates without worrying if the taint is on the node template.
|
||||
|
||||
For each taint, they will automatically be added to any created node in the node pool. Therefore, if you add taints to a node pool that have existing nodes, the taints won't apply to existing nodes in the node pool, but any new node added into the node pool will get the taint.
|
||||
|
||||
When there are taints on the node pool and node template, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
|
||||
|
||||
#### About Node Auto-replace
|
||||
|
||||
If a node is in a node pool, Rancher can automatically replace unreachable nodes. Rancher will use the existing node template for the given node pool to recreate the node if it becomes inactive for a specified number of minutes.
|
||||
|
||||
> **Important:** Self-healing node pools are designed to help you replace worker nodes for <b>stateless</b> applications. It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
|
||||
Node auto-replace works on top of the Kubernetes node controller. The node controller periodically checks the status of all the nodes (configurable via the `--node-monitor-period` flag of the `kube-controller`). When a node is unreachable, the node controller will taint that node. When this occurs, Rancher will begin its deletion countdown. You can configure the amount of time Rancher waits to delete the node. If the taint is not removed before the deletion countdown ends, Rancher will proceed to delete the node object. Rancher will then provision a node in accordance with the set quantity of the node pool.
|
||||
|
||||
#### Enabling Node Auto-replace
|
||||
|
||||
When you create the node pool, you can specify the amount of time in minutes that Rancher will wait to replace an unresponsive node.
|
||||
|
||||
1. In the form for creating or editing a cluster, go to the **Node Pools** section.
|
||||
1. Go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter the number of minutes that Rancher should wait for a node to respond before replacing the node.
|
||||
1. Fill out the rest of the form for creating or editing the cluster.
|
||||
|
||||
**Result:** Node auto-replace is enabled for the node pool.
|
||||
|
||||
#### Disabling Node Auto-replace
|
||||
|
||||
You can disable node auto-replace from the Rancher UI with the following steps:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to disable node auto-replace and click **⋮ > Edit Config**.
|
||||
1. In the **Node Pools** section, go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter 0.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Node auto-replace is disabled for the node pool.
|
||||
|
||||
### Cloud Credentials
|
||||
|
||||
Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:
|
||||
|
||||
- Credentials are stored as a Kubernetes secret, which is not only more secure, but it also allows you to edit a node template without having to enter your credentials every time.
|
||||
|
||||
- After the cloud credential is created, it can be re-used to create additional node templates.
|
||||
|
||||
- Multiple node templates can share the same cloud credential to create node pools. If your key is compromised or expired, the cloud credential can be updated in a single place, which allows all node templates that are using it to be updated at once.
|
||||
|
||||
After cloud credentials are created, the user can start [managing the cloud credentials that they created]({{<baseurl>}}/rancher/v2.6/en/user-settings/cloud-credentials/).
|
||||
|
||||
### Node Drivers
|
||||
|
||||
If you don't find the node driver that you want to use, you can see if it is available in Rancher's built-in [node drivers and activate it]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/node-drivers/#activating-deactivating-node-drivers), or you can [add your own custom node driver]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/node-drivers/#adding-custom-node-drivers).
|
||||
|
||||
## RKE2 Clusters
|
||||
|
||||
Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
> **Note:** For RKE2 cluster templates, please refer to [this page]({{<baseurl>}}/rancher/v2.6/en/admin-settings/cluster-templates/#rke2-cluster-template) for additional information.
|
||||
|
||||
### Node Roles
|
||||
|
||||
The RKE2 CLI exposes two roles, `server` and `agent`, which represent the Kubernetes node-roles `etcd` + `controlplane` and `worker` respectively. With RKE2 integration in Rancher v2.6, RKE2 node pools can represent more fine-grained role assignments such that `etcd` and `controlplane` roles can be represented.
|
||||
|
||||
The same functionality of using `etcd`, `controlplane` and `worker` nodes is possible in the RKE2 CLI by using flags and node tainting to control where workloads and the Kubernetes master were scheduled. The reason those roles were not implemented as first-class roles in the RKE2 CLI is that RKE2 is conceptualized as a set of raw building blocks that are best leveraged through an orchestration system such as Rancher.
|
||||
|
||||
The implementation of the three node roles in Rancher means that Rancher managed RKE2 clusters are able to easily leverage all of the same architectural best practices that are recommended for RKE clusters.
|
||||
|
||||
In our [recommended cluster architecture]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/recommended-architecture/), we outline how many nodes of each role clusters should have:
|
||||
|
||||
- At least three nodes with the role etcd to survive losing one node
|
||||
- At least two nodes with the role controlplane for master component high availability
|
||||
- At least two nodes with the role worker for workload rescheduling upon node failure
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Nutanix Node Template Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
- [Account Access](#account-access)
|
||||
- [Scheduling](#scheduling)
|
||||
- [Instance Options](#instance-options)
|
||||
- [Networks](#networks)
|
||||
- [VM Categories](#vm-categories)
|
||||
- [cloud-init](#cloud-init)
|
||||
|
||||
# Account Access
|
||||
|
||||
| Parameter | Required | Description | Default
|
||||
|:-----------------------------|:--------:|:-----------------------------------------------------------------|:-----
|
||||
| Management Endpoint | ✓ | Hostname/IP address of Prism Central |
|
||||
| Username | ✓ | Username of the Prism Central user |
|
||||
| Password | ✓ | Password of the Prism Central user |
|
||||
| Allow insecure communication | | Set to true to allow insecure SSL communication to Prism Central | False
|
||||
|
||||
# Scheduling
|
||||
|
||||
Choose what Nutanix cluster the virtual machine will be scheduled to.
|
||||
|
||||
| Parameter | Required | Description
|
||||
|:----------|:--------:|:----------------------------------------------------------------------------
|
||||
| Cluster | ✓ | Name of the Nutanix cluster where the VM should be deployed (case sensitive)
|
||||
|
||||
# Instance Options
|
||||
|
||||
In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.
|
||||
|
||||
| Parameter | Required | Description | Default
|
||||
|:---------------------|:--------:|:--------------------------------------------------------------------------------------------|:-------
|
||||
| CPUs | | Number of vCPUs allocated to the VM (cores) | 2
|
||||
| Memory | | Amount of RAM allocated to the VM (MB) | 2 GB
|
||||
| Template Image | ✓ | Name of the Disk Image template to clone as the VM's primary disk (must support cloud-init) |
|
||||
| VM Disk Size | | New size of the VM's primary disk (in GiB) |
|
||||
| Additional Disk Size | | Size of an additional disk to add to the VM (in GiB) |
|
||||
| Storage Container | | Storage container _UUID_ in which to provision an additional disk |
|
||||
| Cloud Config YAML | | Cloud-init to provide to the VM (will be patched with Rancher root user) |
|
||||
| Network | ✓ | Name(s) of the network(s) to attach to the VM |
|
||||
| VM Categories | | Name(s) of any categories to be applied to the VM |
|
||||
|
||||
The VM may use any modern Linux operating system that is configured with support for [cloud-init](https://cloudinit.readthedocs.io/en/latest/) using the [Config Drive v2 datasource](https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html).
|
||||
|
||||
# Networks
|
||||
|
||||
The node template allows a VM to be provisioned with multiple networks. In the **Network** field, you can click **Add** to add any networks available to you in AOS.
|
||||
|
||||
# VM Categories
|
||||
|
||||
A category is a grouping of entities into a key value pair. Typically, VMs are assigned to a category based on some criteria. Policies can then be tied to those entities that are assigned (grouped by) a specific category value.
|
||||
|
||||
# cloud-init
|
||||
|
||||
[Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users or authorizing SSH keys.
|
||||
|
||||
To make use of cloud-init initialization, paste a cloud config using valid YAML syntax into the **Cloud Config YAML** field. Refer to the [cloud-init documentation](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) for a commented set of examples of supported cloud config directives.
|
||||
|
||||
Note that cloud-init based network configuration is not recommended and only supported via user data `runcmd` rather than by NoCloud or other network configuration datasources.
|
||||
|
||||
Nutanix IP Address Management (IPAM) or another DHCP service is recommended.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Creating a Nutanix AOS Cluster
|
||||
shortTitle: Nutanix
|
||||
description: Use Rancher to create a Nutanix AOS (AHV) cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
metaDescription: Use Rancher to create a Nutanix AOS (AHV) cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
weight: 2225
|
||||
---
|
||||
|
||||
[Nutanix Acropolis Operating System](https://www.nutanix.com/products/acropolis) (Nutanix AOS) is an operating system for the Nutanix hyper-converged infrastructure platform. AOS comes with a built-in hypervisor called [Acropolis Hypervisor](https://www.nutanix.com/products/ahv), or AHV. By using Rancher with Nutanix AOS (AHV), you can bring cloud operations on-premises.
|
||||
|
||||
Rancher can provision nodes in AOS (AHV) and install Kubernetes on them. When creating a Kubernetes cluster in AOS, Rancher first provisions the specified number of virtual machines by communicating with the Prism Central API. Then it installs Kubernetes on top of the VMs.
|
||||
|
||||
A Nutanix cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
- [Creating a Nutanix Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters/#creating-a-nutanix-aos-cluster)
|
||||
- [Provisioning Storage]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters)
|
||||
|
||||
# Creating a Nutanix Cluster
|
||||
|
||||
In [this section,](./provisioning-nutanix-clusters) you'll learn how to use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Nutanix AOS.
|
||||
+90
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: Provisioning Kubernetes Clusters in Nutanix AOS
|
||||
weight: 1
|
||||
---
|
||||
|
||||
To use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in Nutanix AOS (AHV):
|
||||
|
||||
1. Locate Rancher's built-in Nutanix [node driver and activate it]({{<baseurl>}}/rancher/v2.6/en/admin-settings/drivers/node-drivers/#activating-deactivating-node-drivers).
|
||||
|
||||
1. Create a node template, which Rancher will use to provision nodes in Nutanix AOS.
|
||||
|
||||
1. Create a Nutanix AOS cluster in Rancher. When configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
For details on configuring the Nutanix AOS node template, refer to the [Nutanix AOS node template configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/)
|
||||
|
||||
For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/)
|
||||
|
||||
- [Preparation in Nutanix AOS](#preparation-in-nutanix-aos)
|
||||
- [Creating a Nutanix AOS Cluster](#creating-a-nutanix-aos-cluster)
|
||||
|
||||
# Preparation in Nutanix AOS
|
||||
|
||||
The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters.
|
||||
|
||||
**Note:** The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.
|
||||
|
||||
### Create Credentials in Nutanix AOS
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials.
|
||||
|
||||
### Network Permissions
|
||||
|
||||
You must ensure that the hosts running the Rancher server are able to establish the following network connections:
|
||||
|
||||
- To the Nutanix Prism Central API (usually port 9440/TCP).
|
||||
- To port 22/TCP and 2376/TCP on the created VMs
|
||||
|
||||
See [Node Networking Requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.
|
||||
|
||||
### VM-VM Anti-Affinity Policies
|
||||
|
||||
Setting up [VM-VM Anti-Affinity Policies](https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_1:ahv-vm-anti-affinity-t.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate AHV hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.
|
||||
|
||||
# Creating a Nutanix AOS Cluster
|
||||
|
||||
1. [Create a node template ](#1-create-a-node-template)
|
||||
2. [Create a cluster with node pools using the node template](#2-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create a node template
|
||||
|
||||
Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for Nutanix AOS will allow Rancher to provision new nodes in Nutanix AOS. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Create**.
|
||||
1. Click **Add Template**.
|
||||
1. Click **Nutanix**.
|
||||
1. Fill out a node template for Nutanix AOS. For help filling out the form, refer to the Nutanix AOS node template [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/).
|
||||
1. Click **Create**.
|
||||
|
||||
### 2. Create a cluster with node pools using the node template
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Nutanix AOS.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Nutanix**.
|
||||
1. Enter a **Cluster Name**, then click **Continue**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users who can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used, and whether you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:** Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
|
||||
# Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
+160
@@ -0,0 +1,160 @@
|
||||
---
|
||||
title: Creating a vSphere Virtual Machine Template
|
||||
weight: 4
|
||||
---
|
||||
|
||||
Creating virtual machines in a repeatable and reliable fashion can often be difficult. VMware vSphere offers the ability to build one VM that can then be converted to a template. The template can then be used to create identically configured VMs. Rancher leverages this capability within node pools to create identical RKE1 and RKE2 nodes.
|
||||
|
||||
In order to leverage the template to create new VMs, Rancher has some [specific requirements](#requirements) that the VM must have pre-installed. After you configure the VM with these requirements, you will next need to [prepare the VM](#preparing-your-vm) before [creating the template](#creating-a-template). Finally, once preparation is complete, the VM can be [converted to a template](#converting-to-a-template) and [moved into a content library](#moving-to-a-content-library), ready for Rancher node pool usage.
|
||||
|
||||
- [Requirements](#requirements)
|
||||
- [Creating a Template](#creating-a-template)
|
||||
- [Preparing Your VM](#preparing-your-vm)
|
||||
- [Converting to a Template](#converting-to-a-template)
|
||||
- [Moving to a content library](#moving-to-a-content-library)
|
||||
- [Other Resources](#other-resources)
|
||||
|
||||
# Requirements
|
||||
|
||||
There is specific tooling required for both Linux and Windows VMs to be usable by the vSphere node driver. The most critical dependency is [cloud-init](https://cloud-init.io/) for Linux and [cloudbase-init](https://cloudbase.it/cloudbase-init/) for Windows. Both of these are used for provisioning the VMs by configuring the hostname and by setting up the SSH access and the default Rancher user. Users can add additional content to these as desired if other configuration is needed. In addition, other requirements are listed below for reference.
|
||||
|
||||
**Note:** If you have any specific firewall rules or configuration, you will need to add this to the VM before creating a template.
|
||||
|
||||
## Linux Dependencies
|
||||
|
||||
The packages that need to be installed on the template are listed below. These will have slightly different names based on distribution; some distributions ship these by default, for example.
|
||||
|
||||
* curl
|
||||
* wget
|
||||
* git
|
||||
* net-tools
|
||||
* unzip
|
||||
* apparmor-parser
|
||||
* ca-certificates
|
||||
* cloud-init
|
||||
* cloud-guest-utils
|
||||
* cloud-image-utils
|
||||
* growpart
|
||||
* cloud-initramfs-growroot
|
||||
* open-iscsi
|
||||
* openssh-server
|
||||
* [open-vm-tools](https://docs.vmware.com/en/VMware-Tools/11.3.0/com.vmware.vsphere.vmwaretools.doc/GUID-8B6EA5B7-453B-48AA-92E5-DB7F061341D1.html)
|
||||
|
||||
## Windows Dependencies
|
||||
|
||||
The list of packages that need to be installed on the template is as follows:
|
||||
|
||||
* Windows Container Feature
|
||||
* [cloudbase-init](https://cloudbase.it/cloudbase-init/#download)
|
||||
* [Docker EE](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker) - RKE1 Only
|
||||
|
||||
**Important to note: The configuration for Windows templates varies between RKE1 and RKE2:**
|
||||
- RKE1 leverages Docker, so any RKE1 templates need to have Docker EE pre-installed as well
|
||||
- RKE2 does not require Docker EE, and thus it does not need to be installed
|
||||
|
||||
# Creating a Template
|
||||
|
||||
You may either manually create your VM or you can utilize [other alternatives](#alternatives-to-manual-creation) to create your VM.
|
||||
|
||||
## Manual Creation
|
||||
1. Manually create your VM by following [these instructions](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AE8AFBF1-75D1-4172-988C-378C35C9FAF2.html) from VMware. Once you have a VM running, you can manually install the dependencies listed above to configure the VM correctly for the vSphere node driver.
|
||||
2. Customize as needed based on your specific environment and requirements.
|
||||
3. Proceed with the final preparation before creating your template.
|
||||
|
||||
## Alternatives to Manual Creation
|
||||
|
||||
Other alternative options to create VMs are listed below:
|
||||
|
||||
* [VMware PowerCLI](https://developer.vmware.com/powercli)
|
||||
* [Packer](https://www.packer.io/)
|
||||
* [SaltStack](https://saltproject.io/)
|
||||
* [Ansible](https://www.ansible.com/)
|
||||
|
||||
Packer is a frequently-used alternative. Refer to this [reference](https://github.com/vmware-samples/packer-examples-for-vsphere) for examples of its usage with vSphere.
|
||||
|
||||
# Preparing Your VM
|
||||
|
||||
After creating a VM with all the required dependencies (and any additional required items), you must perform the most critical step next: preparing the VM to be turned into a template. This preparation will reset critical data such as the VM hostname, IPs, etc., to prevent that information from being brought into a new VM. If you fail to perform this step, you could create a VM with the same hostname, IP address, etc.
|
||||
|
||||
Note that these preparatory steps differ between Linux and Windows.
|
||||
|
||||
## Linux Preparation
|
||||
|
||||
The commands below will reset your VM in Linux:
|
||||
|
||||
```Bash
|
||||
# Cleaning logs.
|
||||
if [ -f /var/log/audit/audit.log ]; then
|
||||
cat /dev/null > /var/log/audit/audit.log
|
||||
fi
|
||||
if [ -f /var/log/wtmp ]; then
|
||||
cat /dev/null > /var/log/wtmp
|
||||
fi
|
||||
if [ -f /var/log/lastlog ]; then
|
||||
cat /dev/null > /var/log/lastlog
|
||||
fi
|
||||
|
||||
# Cleaning udev rules.
|
||||
if [ -f /etc/udev/rules.d/70-persistent-net.rules ]; then
|
||||
rm /etc/udev/rules.d/70-persistent-net.rules
|
||||
fi
|
||||
|
||||
# Cleaning the /tmp directories
|
||||
rm -rf /tmp/*
|
||||
rm -rf /var/tmp/*
|
||||
|
||||
# Cleaning the SSH host keys
|
||||
rm -f /etc/ssh/ssh_host_*
|
||||
|
||||
# Cleaning the machine-id
|
||||
truncate -s 0 /etc/machine-id
|
||||
rm /var/lib/dbus/machine-id
|
||||
ln -s /etc/machine-id /var/lib/dbus/machine-id
|
||||
|
||||
# Cleaning the shell history
|
||||
unset HISTFILE
|
||||
history -cw
|
||||
echo > ~/.bash_history
|
||||
rm -fr /root/.bash_history
|
||||
|
||||
# Truncating hostname, hosts, resolv.conf and setting hostname to localhost
|
||||
truncate -s 0 /etc/{hostname,hosts,resolv.conf}
|
||||
hostnamectl set-hostname localhost
|
||||
|
||||
# Clean cloud-init
|
||||
cloud-init clean -s -l
|
||||
```
|
||||
|
||||
## Windows Preparation
|
||||
|
||||
Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows:
|
||||
|
||||
```PowerShell
|
||||
sysprep.exe /generalize /shutdown /oobe
|
||||
```
|
||||
|
||||
# Converting to a Template
|
||||
|
||||
1. Shut down and stop the VM.
|
||||
2. Right-click on the VM in the inventory list and select **Template**.
|
||||
3. Click on **Convert to Template**.
|
||||
|
||||
**Result:** Once the process has completed, a template will be available for use.
|
||||
|
||||
For additional information on converting a VM to a template, see the [VMware guide](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-5B3737CC-28DB-4334-BD18-6E12011CDC9F.html).
|
||||
|
||||
# Moving to a Content library
|
||||
|
||||
Rancher has the ability to use templates provided by a content library. Content libraries store and manage content within vSphere, and they also offer the ability to publish and share that content.
|
||||
|
||||
Below are some helpful links on content libraries:
|
||||
|
||||
* [Create a content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-2A0F1C13-7336-45CE-B211-610D39A6E1F4.html)
|
||||
* [Clone the template to the content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AC1545F0-F8BA-4CD2-96EB-21B3DFAA1DC1.html)
|
||||
|
||||
# Other Resources
|
||||
|
||||
Here is a list of additional resources that may be useful:
|
||||
|
||||
* [Tutorial for creating a Linux template](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/manage/hybrid/server/best-practices/vmware-ubuntu-template)
|
||||
* [Tutorial for creating a Windows template](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/manage/hybrid/server/best-practices/vmware-windows-template)
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Creating Credentials in the vSphere Console
|
||||
weight: 3
|
||||
---
|
||||
|
||||
This section describes how to create a vSphere username and password. You will need to provide these vSphere credentials to Rancher, which allows Rancher to provision resources in vSphere.
|
||||
|
||||
The following table lists the permissions required for the vSphere user account:
|
||||
|
||||
| Privilege Group | Operations |
|
||||
|:----------------------|:-----------------------------------------------------------------------|
|
||||
| Datastore | AllocateSpace </br> Browse </br> FileManagement (Low level file operations) </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
|
||||
| Global | Set custom attribute |
|
||||
| Network | Assign |
|
||||
| Resource | AssignVMToPool |
|
||||
| Virtual Machine | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
|
||||
| vSphere Tagging | Assign or Unassign vSphere Tag </br> Assign or Unassign vSphere Tag on Object |
|
||||
|
||||
The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:
|
||||
|
||||
1. From the **vSphere** console, go to the **Administration** page.
|
||||
|
||||
2. Go to the **Roles** tab.
|
||||
|
||||
3. Create a new role. Give it a name and select the privileges listed in the permissions table above.
|
||||
|
||||
{{< img "/img/rancher/rancherroles1.png" "image" >}}
|
||||
|
||||
4. Go to the **Users and Groups** tab.
|
||||
|
||||
5. Create a new user. Fill out the form and then click **OK**. Make sure to note the username and password, because you will need it when configuring node templates in Rancher.
|
||||
|
||||
{{< img "/img/rancher/rancheruser.png" "image" >}}
|
||||
|
||||
6. Go to the **Global Permissions** tab.
|
||||
|
||||
7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
|
||||
|
||||
{{< img "/img/rancher/globalpermissionuser.png" "image" >}}
|
||||
|
||||
{{< img "/img/rancher/globalpermissionrole.png" "image" >}}
|
||||
|
||||
**Result:** You now have credentials that Rancher can use to manipulate vSphere resources.
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: Provisioning Kubernetes Clusters in vSphere
|
||||
weight: 1
|
||||
---
|
||||
|
||||
In this section, you'll learn how to use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
|
||||
First, you will set up your vSphere cloud credentials in Rancher. Then you will use your cloud credentials to create a node template, which Rancher will use to provision nodes in vSphere.
|
||||
|
||||
Then you will create a vSphere cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
For details on configuring the vSphere node template, refer to the [vSphere node template configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/)
|
||||
|
||||
For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
- [Preparation in vSphere](#preparation-in-vsphere)
|
||||
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
|
||||
|
||||
# Preparation in vSphere
|
||||
|
||||
This section describes the requirements for setting up vSphere so that Rancher can provision VMs and clusters.
|
||||
|
||||
The node templates are documented and tested with the vSphere Web Services API version 6.5.
|
||||
|
||||
### Create Credentials in vSphere
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a vSphere user with sufficient permissions. When you set up a node template, the template will need to use these vSphere credentials.
|
||||
|
||||
Refer to this [how-to guide]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials) for instructions on how to create a user in vSphere with the required permissions. These steps result in a username and password that you will need to provide to Rancher, which allows Rancher to provision resources in vSphere.
|
||||
|
||||
### Network Permissions
|
||||
|
||||
It must be ensured that the hosts running the Rancher server are able to establish the following network connections:
|
||||
|
||||
- To the vSphere API on the vCenter server (usually port 443/TCP).
|
||||
- To the Host API (port 443/TCP) on all ESXi hosts used to instantiate virtual machines for the clusters (*only required when using the ISO creation method*).
|
||||
- To port 22/TCP and 2376/TCP on the created VMs
|
||||
|
||||
See [Node Networking Requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.
|
||||
|
||||
### Valid ESXi License for vSphere API Access
|
||||
|
||||
The free ESXi license does not support API access. The vSphere servers must have a valid or evaluation ESXi license.
|
||||
|
||||
### VM-VM Affinity Rules for Clusters with DRS
|
||||
|
||||
If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes.
|
||||
|
||||
# Creating a vSphere Cluster
|
||||
|
||||
The a vSphere cluster is created in Rancher depends on the Rancher version.
|
||||
|
||||
1. [Create your cloud credentials](#1-create-your-cloud-credentials)
|
||||
2. [Create a node template with your cloud credentials](#2-create-a-node-template-with-your-cloud-credentials)
|
||||
3. [Create a cluster with node pools using the node template](#3-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create your cloud credentials
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click **VMware vSphere**.
|
||||
1. Enter your vSphere credentials. For help, refer to **Account Access** in the [node template configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/)
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** You have created the cloud credentials that will be used to provision nodes in your cluster. You can reuse these credentials for other node templates, or in other clusters.
|
||||
|
||||
### 2. Create a node template with your cloud credentials
|
||||
|
||||
Creating a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for vSphere will allow Rancher to provision new nodes in vSphere. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Create**.
|
||||
1. Click **Add Template**.
|
||||
1. Click **vSphere**.
|
||||
1. Fill out a node template for vSphere. For help filling out the form, refer to the vSphere node template [configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/).
|
||||
1. Click **Create**.
|
||||
|
||||
### 3. Create a cluster with node pools using the node template
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in vSphere.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **VMware vSphere**.
|
||||
1. Enter a **Cluster Name** and use your vSphere cloud credentials. Click **Continue**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
1. If you want to dynamically provision persistent storage or other infrastructure later, you will need to enable the vSphere cloud provider by modifying the cluster YAML file. For details, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
|
||||
# Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
- **Provision Storage:** For an example of how to provision storage in vSphere using Rancher, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/examples/vsphere) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: VSphere Node Template Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
- [Account Access](#account-access)
|
||||
- [Scheduling](#scheduling)
|
||||
- [Instance Options](#instance-options)
|
||||
- [Networks](#networks)
|
||||
- [Node tags and custom attributes](#node-tags-and-custom-attributes)
|
||||
- [cloud-init](#cloud-init)
|
||||
|
||||
# Account Access
|
||||
|
||||
| Parameter | Required | Description |
|
||||
|:----------------------|:--------:|:-----|
|
||||
| Cloud Credentials | * | Your vSphere account access information, stored in a [cloud credential.]({{<baseurl>}}/rancher/v2.6/en/user-settings/cloud-credentials/) |
|
||||
|
||||
Your cloud credential has these fields:
|
||||
|
||||
| Credential Field | Description |
|
||||
|-----------------|--------------|
|
||||
| vCenter or ESXi Server | Enter the vCenter or ESXi hostname/IP. ESXi is the virtualization platform where you create and run virtual machines and virtual appliances. vCenter Server is the service through which you manage multiple hosts connected in a network and pool host resources. |
|
||||
| Port | Optional: configure configure the port of the vCenter or ESXi server. |
|
||||
| Username and password | Enter your vSphere login username and password. |
|
||||
|
||||
# Scheduling
|
||||
|
||||
Choose what hypervisor the virtual machine will be scheduled to.
|
||||
|
||||
The fields in the **Scheduling** section should auto-populate with the data center and other scheduling options that are available to you in vSphere.
|
||||
|
||||
| Field | Required | Explanation |
|
||||
|---------|---------------|-----------|
|
||||
| Data Center | * | Choose the name/path of the data center where the VM will be scheduled. |
|
||||
| Resource Pool | | Name of the resource pool to schedule the VMs in. Resource pools can be used to partition available CPU and memory resources of a standalone host or cluster, and they can also be nested. Leave blank for standalone ESXi. If not specified, the default resource pool is used. |
|
||||
| Data Store | * | If you have a data store cluster, you can toggle the **Data Store** field. This lets you select a data store cluster where your VM will be scheduled to. If the field is not toggled, you can select an individual disk. |
|
||||
| Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. |
|
||||
| Host | | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored. |
|
||||
|
||||
# Instance Options
|
||||
|
||||
In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template.
|
||||
|
||||
| Parameter | Required | Description |
|
||||
|:----------------|:--------:|:-----------|
|
||||
| CPUs | * | Number of vCPUS to assign to VMs. |
|
||||
| Memory | * | Amount of memory to assign to VMs. |
|
||||
| Disk | * | Size of the disk (in MB) to attach to the VMs. |
|
||||
| Creation method | * | The method for setting up an operating system on the node. The operating system can be installed from an ISO or from a VM template. Depending on the creation method, you will also have to specify a VM template, content library, existing VM, or ISO. For more information on creation methods, refer to [About VM Creation Methods.](#about-vm-creation-methods) |
|
||||
| Cloud Init | | URL of a `cloud-config.yml` file or URL to provision VMs with. This file allows further customization of the operating system, such as network configuration, DNS servers, or system daemons. The operating system must support `cloud-init`. |
|
||||
| Networks | | Name(s) of the network to attach the VM to. |
|
||||
| Configuration Parameters used for guestinfo | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{< baseurl >}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). |
|
||||
|
||||
|
||||
### About VM Creation Methods
|
||||
|
||||
In the **Creation method** field, configure the method used to provision VMs in vSphere. Available options include creating VMs that boot from a RancherOS ISO or creating VMs by cloning from an existing virtual machine or [VM template](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-F7BF0E6B-7C4F-4E46-8BBF-76229AEA7220.html).
|
||||
|
||||
The existing VM or template may use any modern Linux operating system that is configured with support for [cloud-init](https://cloudinit.readthedocs.io/en/latest/) using the [NoCloud datasource](https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html).
|
||||
|
||||
Choose the way that the VM will be created:
|
||||
|
||||
- **Deploy from template: Data Center:** Choose a VM template that exists in the data center that you selected.
|
||||
- **Deploy from template: Content Library:** First, select the [Content Library](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-254B2CE8-20A8-43F0-90E8-3F6776C2C896.html) that contains your template, then select the template from the populated list **Library templates**.
|
||||
- **Clone an existing virtual machine:** In the **Virtual machine** field, choose an existing VM that the new VM will be cloned from.
|
||||
- **Install from boot2docker ISO:** Ensure that the **OS ISO URL** field contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). Note that this URL must be accessible from the nodes running your Rancher server installation.
|
||||
|
||||
# Networks
|
||||
|
||||
The node template now allows a VM to be provisioned with multiple networks. In the **Networks** field, you can now click **Add Network** to add any networks available to you in vSphere.
|
||||
|
||||
# Node Tags and Custom Attributes
|
||||
|
||||
Tags allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects.
|
||||
|
||||
For tags, all your vSphere tags will show up as options to select from in your node template.
|
||||
|
||||
In the custom attributes, Rancher will let you select all the custom attributes you have already set up in vSphere. The custom attributes are keys and you can enter values for each one.
|
||||
|
||||
> **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere.
|
||||
|
||||
# cloud-init
|
||||
|
||||
[Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network.
|
||||
|
||||
To make use of cloud-init initialization, create a cloud config file using valid YAML syntax and paste the file content in the the **Cloud Init** field. Refer to the [cloud-init documentation.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) for a commented set of examples of supported cloud config directives.
|
||||
|
||||
Note that cloud-init is not supported when using the ISO creation method.
|
||||
+58
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Creating a vSphere Cluster
|
||||
shortTitle: vSphere
|
||||
description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
metaDescription: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
weight: 2225
|
||||
---
|
||||
|
||||
By using Rancher with vSphere, you can bring cloud operations on-premises.
|
||||
|
||||
Rancher can provision nodes in vSphere and install Kubernetes on them. When creating a Kubernetes cluster in vSphere, Rancher first provisions the specified number of virtual machines by communicating with the vCenter API. Then it installs Kubernetes on top of them.
|
||||
|
||||
A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3)
|
||||
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
|
||||
- [Provisioning Storage](#provisioning-storage)
|
||||
- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider)
|
||||
|
||||
# vSphere Enhancements in Rancher v2.3
|
||||
|
||||
The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:
|
||||
|
||||
### Self-healing Node Pools
|
||||
|
||||
One of the biggest advantages of provisioning vSphere nodes with Rancher is that it allows you to take advantage of Rancher's self-healing node pools, also called the [node auto-replace feature,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#about-node-auto-replace) in your on-premises clusters. Self-healing node pools are designed to help you replace worker nodes for stateless applications. When Rancher provisions nodes from a node template, Rancher can automatically replace unreachable nodes.
|
||||
|
||||
> **Important:** It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
|
||||
### Dynamically Populated Options for Instances and Scheduling
|
||||
|
||||
Node templates for vSphere have been updated so that when you create a node template with your vSphere credentials, the template is automatically populated with the same options for provisioning VMs that you have access to in the vSphere console.
|
||||
|
||||
For the fields to be populated, your setup needs to fulfill the [prerequisites.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/#prerequisites)
|
||||
|
||||
### More Supported Operating Systems
|
||||
|
||||
You can provision VMs with any operating system that supports `cloud-init`. Only YAML format is supported for the [cloud config.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)
|
||||
|
||||
### Video Walkthrough of v2.3.3 Node Template Features
|
||||
|
||||
In this YouTube video, we demonstrate how to set up a node template with the new features designed to help you bring cloud operations to on-premises clusters.
|
||||
|
||||
{{< youtube id="dPIwg6x1AlU">}}
|
||||
|
||||
# Creating a vSphere Cluster
|
||||
|
||||
In [this section,](./provisioning-vsphere-clusters) you'll learn how to use Rancher to install an [RKE]({{<baseurl>}}/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
|
||||
# Provisioning Storage
|
||||
|
||||
For an example of how to provision storage in vSphere using Rancher, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/examples/vsphere) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
|
||||
# Enabling the vSphere Cloud Provider
|
||||
|
||||
When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices.
|
||||
|
||||
For details, refer to the section on [enabling the vSphere cloud provider.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere)
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: RKE Cluster Configuration
|
||||
weight: 2300
|
||||
---
|
||||
|
||||
This page has moved [here.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference)
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Rancher Agents
|
||||
weight: 2400
|
||||
---
|
||||
|
||||
There are two different agent resources deployed on Rancher managed clusters:
|
||||
|
||||
- [cattle-cluster-agent](#cattle-cluster-agent)
|
||||
- [cattle-node-agent](#cattle-node-agent)
|
||||
|
||||
For a conceptual overview of how the Rancher server provisions clusters and communicates with them, refer to the [architecture]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/)
|
||||
|
||||
### cattle-cluster-agent
|
||||
|
||||
The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) clusters. The `cattle-cluster-agent` is deployed using a Deployment resource.
|
||||
|
||||
### cattle-node-agent
|
||||
|
||||
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) clusters when `cattle-cluster-agent` is unavailable.
|
||||
|
||||
### Scheduling rules
|
||||
|
||||
The `cattle-cluster-agent` uses a fixed fixed set of tolerations (listed below, if no controlplane nodes are visible in the cluster) or dynamically added tolerations based on taints applied to the controlplane nodes. This structure allows for [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`. The default tolerations are described below. If controlplane nodes are present the cluster, the tolerations will be replaced with tolerations matching the taints on the controlplane nodes.
|
||||
|
||||
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
|
||||
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
|
||||
| `cattle-cluster-agent` | `beta.kubernetes.io/os:NotIn:windows` | none | **Note:** These are the default tolerations, and will be replaced by tolerations matching taints applied to controlplane nodes.<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/controlplane`<br/>`value:true`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/control-plane`<br/>`operator:Exists`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/master`<br/>`operator:Exists` |
|
||||
| `cattle-node-agent` | `beta.kubernetes.io/os:NotIn:windows` | none | `operator:Exists` |
|
||||
|
||||
The `cattle-cluster-agent` Deployment has preferred scheduling rules using `preferredDuringSchedulingIgnoredDuringExecution`, favoring to be scheduled on nodes with the `controlplane` node. When there are no controlplane nodes visible in the cluster (this is usually the case when using [Clusters from Hosted Kubernetes Providers]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/)), you can add the label `cattle.io/cluster-agent=true` on a node to prefer scheduling the `cattle-cluster-agent` pod to that node.
|
||||
|
||||
See [Kubernetes: Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) to find more information about scheduling rules.
|
||||
|
||||
The `preferredDuringSchedulingIgnoredDuringExecution` configuration is shown in the table below:
|
||||
|
||||
| Weight | Expression |
|
||||
| ------ | ------------------------------------------------ |
|
||||
| 100 | `node-role.kubernetes.io/controlplane:In:"true"` |
|
||||
| 100 | `node-role.kubernetes.io/control-plane:In:"true"` |
|
||||
| 100 | `node-role.kubernetes.io/master:In:"true"` |
|
||||
| 1 | `cattle.io/cluster-agent:In:"true"` |
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: Launching Kubernetes with Rancher
|
||||
weight: 4
|
||||
---
|
||||
|
||||
You can have Rancher launch a Kubernetes cluster using any nodes you want. When Rancher deploys Kubernetes onto these nodes, you can choose between [Rancher Kubernetes Engine]({{<baseurl>}}/rke/latest/en/) (RKE) or [RKE2](https://docs.rke2.io) distributions. Rancher can launch Kubernetes on any computers, including:
|
||||
|
||||
- Bare-metal servers
|
||||
- On-premise virtual machines
|
||||
- Virtual machines hosted by an infrastructure provider
|
||||
|
||||
Rancher can install Kubernetes on existing nodes, or it can dynamically provision nodes in an infrastructure provider and install Kubernetes on them.
|
||||
|
||||
Rancher can also create pools of nodes. One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
|
||||
## RKE
|
||||
|
||||
### Requirements
|
||||
|
||||
If you use RKE to set up a cluster, your nodes must meet the [requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements) for nodes in downstream user clusters.
|
||||
|
||||
### Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates). This node template defines the parameters you want to use to launch nodes in your cloud providers.
|
||||
|
||||
One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
|
||||
For more information, refer to the section on [launching Kubernetes on new nodes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/)
|
||||
|
||||
### Launching Kubernetes on Existing Custom Nodes
|
||||
|
||||
In this scenario, you want to install Kubernetes on bare-metal servers, on-prem virtual machines, or virtual machines that already exist in a cloud provider. With this option, you will run a Rancher agent Docker container on the machine.
|
||||
|
||||
If you want to reuse a node from a previous custom cluster, [clean the node]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cleaning-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
|
||||
|
||||
For more information, refer to the section on [custom nodes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/)
|
||||
|
||||
# Programmatically Creating RKE Clusters
|
||||
|
||||
The most common way to programmatically deploy RKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster)
|
||||
|
||||
## RKE2
|
||||
|
||||
Rancher v2.6 introduced provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector. In Rancher v.2.6.4 and earlier, RKE2 provisioning was in tech preview.
|
||||
|
||||
Note that in Rancher v2.6.5, RKE2 provisioning became GA.
|
||||
|
||||
### Requirements
|
||||
|
||||
If you use RKE2 to set up a cluster, your nodes must meet the [requirements](https://docs.rke2.io/install/requirements/) for nodes in downstream user clusters.
|
||||
|
||||
### Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
|
||||
RKE2 provisioning is built on top of a new provisioning framework that leverages the upstream [Cluster API](https://github.com/kubernetes-sigs/cluster-api) project. With this new provisioning framework, you can:
|
||||
|
||||
- Provision RKE2 clusters onto any provider for which Rancher has a node driver
|
||||
- Fully configure RKE2 clusters within Rancher
|
||||
- Choose CNI options Calico, Cilium, and Multus in addition to Canal
|
||||
|
||||
RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.
|
||||
|
||||
Windows features for RKE2 include:
|
||||
|
||||
- Windows supports the vSphere node driver
|
||||
- Calico CNI for Windows RKE2 custom clusters
|
||||
- Project Network Isolation (PNI) for Calico
|
||||
- Windows Containers with RKE2 powered by containerd
|
||||
- Provisioning of Windows RKE2 clusters through Terraform
|
||||
- Provisioning of Windows RKE2 custom clusters directly from the Rancher UI
|
||||
|
||||
Windows Support for RKE2 Custom Clusters requires choosing Calico as the CNI.
|
||||
|
||||
### Launching Kubernetes on Existing Custom Nodes
|
||||
|
||||
RKE2 provisioning also allows you to install custom clusters on pre-provisioned VMs or bare-metal nodes.
|
||||
|
||||
If you want to reuse a node from a previous custom cluster, clean the node before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
|
||||
|
||||
# Programmatically Creating RKE2 Clusters
|
||||
|
||||
The most common way to programmatically deploy RKE2 clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster_v2)
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Configuration for Storage Classes in Azure
|
||||
weight: 3
|
||||
---
|
||||
|
||||
If you are using Azure VMs for your nodes, you can use [Azure files](https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv) as a StorageClass for the cluster.
|
||||
|
||||
In order to have the Azure platform create the required storage resources, follow these steps:
|
||||
|
||||
1. [Configure the Azure cloud provider.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure)
|
||||
1. Configure `kubectl` to connect to your cluster.
|
||||
1. Copy the `ClusterRole` and `ClusterRoleBinding` manifest for the service account:
|
||||
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: system:azure-cloud-provider
|
||||
rules:
|
||||
- apiGroups: ['']
|
||||
resources: ['secrets']
|
||||
verbs: ['get','create']
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: system:azure-cloud-provider
|
||||
roleRef:
|
||||
kind: ClusterRole
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: system:azure-cloud-provider
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: persistent-volume-binder
|
||||
namespace: kube-system
|
||||
|
||||
1. Create these in your cluster using one of the follow command.
|
||||
|
||||
```
|
||||
# kubectl create -f <MANIFEST>
|
||||
```
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Networking Requirements for Host Gateway (L2bridge)
|
||||
weight: 1000
|
||||
---
|
||||
|
||||
This section describes how to configure custom Windows clusters that are using *Host Gateway (L2bridge)* mode.
|
||||
|
||||
### Disabling Private IP Address Checks
|
||||
|
||||
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) (By default, a VM cannot forward a packet originated by another VM)
|
||||
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)
|
||||
|
||||
### Cloud-hosted VM Routes Configuration
|
||||
|
||||
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.
|
||||
|
||||
- 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).
|
||||
+281
@@ -0,0 +1,281 @@
|
||||
---
|
||||
title: Launching Kubernetes on Windows Clusters
|
||||
weight: 2240
|
||||
---
|
||||
|
||||
When provisioning a [custom cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes) using Rancher, Rancher uses RKE (the Rancher Kubernetes Engine) to install Kubernetes on your existing nodes.
|
||||
|
||||
In a Windows cluster provisioned with Rancher, the cluster must contain both Linux and Windows nodes. The Kubernetes controlplane can only run on Linux nodes, and the Windows nodes can only have the worker role. Windows nodes can only be used for deploying workloads.
|
||||
|
||||
Some other requirements for Windows clusters include:
|
||||
|
||||
- You can only add Windows nodes to a cluster if Windows support is enabled when the cluster is created. Windows support cannot be enabled for existing clusters.
|
||||
- Kubernetes 1.15+ is required.
|
||||
- The Flannel network provider must be used.
|
||||
- Windows nodes must have 50 GB of disk space.
|
||||
|
||||
For the full list of requirements, see [this section.](#requirements-for-windows-clusters)
|
||||
|
||||
For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/).
|
||||
|
||||
This guide covers the following topics:
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [Changes in Rancher v2.6](#changes-in-rancher-v2-6)
|
||||
- [Requirements](#requirements-for-windows-clusters)
|
||||
- [Tutorial: How to Create a Cluster with Windows Support](#tutorial-how-to-create-a-cluster-with-windows-support)
|
||||
- [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure)
|
||||
<!-- /TOC -->
|
||||
|
||||
# Changes in Rancher v2.6
|
||||
|
||||
Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
As of Rancher v2.6.5, provisioning for RKE2 is GA.
|
||||
|
||||
The RKE2 provisioning feature also includes installing RKE2 on Windows clusters. Windows features for RKE2 include:
|
||||
|
||||
- Windows Containers with RKE2 powered by containerd
|
||||
- Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
|
||||
- Calico CNI for Windows RKE2 custom clusters
|
||||
- SAC releases of Windows Server (2004 and 20H2) are included in the technical preview
|
||||
|
||||
Windows Support for RKE2 Custom Clusters requires choosing Calico as the CNI.
|
||||
|
||||
>**Important:** Rancher will allow Windows workload pods to deploy on both Windows and Linux worker nodes by default. When creating mixed clusters in RKE2, you must edit the `nodeSelector` in the chart to direct the pods to be placed onto a compatible Windows node. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) for more information on how to use `nodeSelector` to assign pods to nodes.
|
||||
|
||||
# Requirements for Windows Clusters
|
||||
|
||||
The general node requirements for networking, operating systems, and Docker are the same as the node requirements for a [Rancher installation]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/).
|
||||
|
||||
### OS and Docker Requirements
|
||||
|
||||
Our support for Windows Server and Windows containers match the Microsoft official lifecycle for LTSC (Long-Term Servicing Channel) and SAC (Semi-Annual Channel).
|
||||
|
||||
For the support lifecycle dates for Windows Server, see the [Microsoft Documentation.](https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info)
|
||||
|
||||
### Kubernetes Version
|
||||
|
||||
Kubernetes v1.15+ is required.
|
||||
|
||||
If you are using Kubernetes v1.21 with Windows Server 20H2 Standard Core, the patch "2019-08 Servicing Stack Update for Windows Server" must be installed on the node.
|
||||
|
||||
### Node Requirements
|
||||
|
||||
The hosts in the cluster need to have at least:
|
||||
|
||||
- 2 core CPUs
|
||||
- 5 GB memory
|
||||
- 50 GB disk space
|
||||
|
||||
Rancher will not provision the node if the node does not meet these requirements.
|
||||
|
||||
### Networking Requirements
|
||||
|
||||
Before provisioning a new cluster, be sure that you have already installed Rancher on a device that accepts inbound network traffic. This is required in order for the cluster nodes to communicate with Rancher. If you have not already installed Rancher, please refer to the [installation documentation]({{<baseurl>}}/rancher/v2.6/en/installation/) before proceeding with this guide.
|
||||
|
||||
Rancher only supports Windows using Flannel as the network provider.
|
||||
|
||||
There are two network 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). The default option is **VXLAN (Overlay)** mode.
|
||||
|
||||
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 details, refer to the [documentation on configuring cloud-hosted VM routes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
|
||||
|
||||
For **VXLAN (Overlay)** networking, the [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix must be installed. Most cloud-hosted VMs already have this hotfix.
|
||||
|
||||
If you are configuring DHCP options sets for an AWS virtual private cloud, note that in the `domain-name` option field, only one domain name can be specified. According to the DHCP options [documentation:](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)
|
||||
|
||||
> Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name.
|
||||
|
||||
### Rancher on vSphere with ESXi 6.7u2 and above
|
||||
|
||||
If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `<VM network interface>` must be customized to the host `vmxnet3` network interface, e.g., `ens192`:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Disable vmxnet3 hardware offloading feature
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-segmentation off
|
||||
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-csum-segmentation off
|
||||
StandardOutput=journal
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
Then set the appropriate permissions on the systemd unit file:
|
||||
```
|
||||
chmod 0644 /etc/systemd/system/disable_hw_offloading.service
|
||||
```
|
||||
Finally, enable the systemd service:
|
||||
```
|
||||
systemctl enable disable_hw_offloading.service
|
||||
```
|
||||
|
||||
### Architecture Requirements
|
||||
|
||||
The Kubernetes cluster management nodes (`etcd` and `controlplane`) must be run on Linux nodes.
|
||||
|
||||
The `worker` nodes, which is where your workloads will be deployed on, will typically be Windows nodes, but there must be at least one `worker` node that is run on Linux in order to run the Rancher cluster agent, DNS, metrics server, and Ingress related containers.
|
||||
|
||||
We recommend the minimum three-node architecture listed in the table below, but you can always add additional Linux and Windows workers to scale up your cluster for redundancy:
|
||||
|
||||
<a id="guide-architecture"></a>
|
||||
|
||||
| Node | Operating System | Kubernetes Cluster Role(s) | Purpose |
|
||||
| ------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| Node 1 | Linux (Ubuntu Server 18.04 recommended) | Control plane, etcd, worker | Manage the Kubernetes cluster |
|
||||
| Node 2 | Linux (Ubuntu Server 18.04 recommended) | Worker | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
|
||||
| Node 3 | Windows (Windows Server core version 1809 or above) | Worker | Run your Windows containers |
|
||||
|
||||
### 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 core version 1809 or above. If you have existing containers built for an earlier Windows Server core version, they must be re-built on Windows Server core version 1809 or above.
|
||||
|
||||
### Cloud Provider Specific Requirements
|
||||
|
||||
If you set a Kubernetes cloud provider in your cluster, some additional steps are required. You might want to set a cloud provider if you want to want to leverage a cloud provider's capabilities, for example, to automatically provision storage, load balancers, or other infrastructure for your cluster. Refer to [this page]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) for details on how to configure a cloud provider cluster of nodes that meet the prerequisites.
|
||||
|
||||
If you are using the GCE (Google Compute Engine) cloud provider, you must do the following:
|
||||
|
||||
- Enable the GCE cloud provider in the `cluster.yml` by following [these steps.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/gce)
|
||||
- When provisioning the cluster in Rancher, choose **Custom cloud provider** as the cloud provider in the Rancher UI.
|
||||
|
||||
# Tutorial: How to Create a Cluster with Windows Support
|
||||
|
||||
This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#guide-architecture)
|
||||
|
||||
When you provision a cluster with Rancher on existing nodes, you will add nodes to the cluster by installing the [Rancher agent]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/agent-options/) on each one. When you create or edit your cluster from the Rancher UI, you will see a **Customize Node Run Command** that you can run on each server to add it to your cluster.
|
||||
|
||||
To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
1. [Provision Hosts](#1-provision-hosts)
|
||||
1. [Create the Cluster on Existing Nodes](#2-create-the-cluster-on-existing-nodes)
|
||||
1. [Add Nodes to the Cluster](#3-add-nodes-to-the-cluster)
|
||||
1. [Optional: Configuration for Azure Files](#4-optional-configuration-for-azure-files)
|
||||
<!-- /TOC -->
|
||||
|
||||
# 1. Provision Hosts
|
||||
|
||||
To begin provisioning a cluster on existing nodes with Windows support, prepare your hosts.
|
||||
|
||||
Your hosts can be:
|
||||
|
||||
- Cloud-hosted VMs
|
||||
- VMs from virtualization clusters
|
||||
- Bare-metal servers
|
||||
|
||||
You will provision three nodes:
|
||||
|
||||
- One Linux node, which manages the Kubernetes control plane and stores your `etcd`
|
||||
- A second Linux node, which will be another worker node
|
||||
- The Windows node, which will run your Windows containers as a worker node
|
||||
|
||||
| Node | Operating System |
|
||||
| ------ | ------------------------------------------------------------ |
|
||||
| Node 1 | Linux (Ubuntu Server 18.04 recommended) |
|
||||
| Node 2 | Linux (Ubuntu Server 18.04 recommended) |
|
||||
| Node 3 | Windows (Windows Server core version 1809 or above required) |
|
||||
|
||||
If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers)
|
||||
|
||||
# 2. Create the Cluster on Existing Nodes
|
||||
|
||||
The instructions for creating a Windows cluster on existing nodes are very similar to the general [instructions for creating a custom cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/) with some Windows-specific requirements.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Custom**.
|
||||
1. Enter a name for your cluster in the **Cluster Name** field.
|
||||
1. In the **Kubernetes Version** dropdown menu, select v1.19 or above.
|
||||
1. In the **Network Provider** field, select **Flannel**.
|
||||
1. In the **Windows Support** section, click **Enabled**.
|
||||
1. Optional: After you enable Windows support, you will be able to choose the Flannel backend. There are two network 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). The default option is **VXLAN (Overlay)** mode.
|
||||
1. Click **Next**.
|
||||
|
||||
> **Important:** For <b>Host Gateway (L2bridge)</b> 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 details, refer to the [documentation on configuring cloud-hosted VM routes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/host-gateway-requirements/#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
|
||||
|
||||
# 3. Add Nodes to the Cluster
|
||||
|
||||
This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.
|
||||
|
||||
### Add Linux Master Node
|
||||
|
||||
In this section, we fill out a form on the Rancher UI to get a custom command to install the Rancher agent on the Linux master node. Then we will copy the command and run it on our Linux master node to register the node in the cluster.
|
||||
|
||||
The first node in your cluster should be a Linux host has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.
|
||||
|
||||
1. In the **Node Operating System** section, click **Linux**.
|
||||
1. In the **Node Role** section, choose at least **etcd** and **Control Plane**. We recommend selecting all three.
|
||||
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/agent-options/) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
|
||||
1. Copy the command displayed on the screen to your clipboard.
|
||||
1. SSH into your Linux host and run the command that you copied to your clipboard.
|
||||
1. When you are finished provisioning your Linux node(s), select **Done**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
|
||||
It may take a few minutes for the node to be registered in your cluster.
|
||||
|
||||
### Add Linux Worker Node
|
||||
|
||||
In this section, we run a command to register the Linux worker node to the cluster.
|
||||
|
||||
After the initial provisioning of your cluster, your cluster only has a single Linux host. Next, we add another Linux `worker` host, which will be used to support _Rancher cluster agent_, _Metrics server_, _DNS_ and _Ingress_ for your cluster.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **⋮ > Edit Config**.
|
||||
1. Scroll down to **Node Operating System**. Choose **Linux**.
|
||||
1. In the **Customize Node Run Command** section, go to the **Node Options** and 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. It may take a few minutes for the node to be registered in your cluster.
|
||||
|
||||
> **Note:** Taints on Linux Worker Nodes
|
||||
>
|
||||
> For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.
|
||||
|
||||
> | Taint Key | Taint Value | Taint Effect |
|
||||
> | -------------- | ----------- | ------------ |
|
||||
> | `cattle.io/os` | `linux` | `NoSchedule` |
|
||||
|
||||
### Add a Windows Worker Node
|
||||
|
||||
In this section, we run a command to register the Windows worker node to the cluster.
|
||||
|
||||
You can add Windows hosts to the cluster by editing the cluster and choosing the **Windows** option.
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **⋮ > Edit Config**.
|
||||
1. Scroll down to **Node Operating System**. Choose **Windows**. Note: You will see that the **worker** role is the only available 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 instructions 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. It may take a few minutes for the node to be registered in your cluster. You now have a Windows Kubernetes cluster.
|
||||
|
||||
### Optional Next Steps
|
||||
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through the Rancher server. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
# Configuration for Storage Classes in Azure
|
||||
|
||||
If you are using Azure VMs for your nodes, you can use [Azure files](https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv) as a StorageClass for the cluster. For details, refer to [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/azure-storageclass)
|
||||
+47
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Windows and Linux Cluster Feature Parity
|
||||
weight: 3
|
||||
---
|
||||
|
||||
Windows clusters do not share the same feature support as Linux clusters.
|
||||
|
||||
The following chart describes the feature parity between Windows and Linux on Rancher:
|
||||
|
||||
**Component** | **Linux** | **Windows**
|
||||
--- | --- | ---
|
||||
**Distributions** | |
|
||||
RKE | Supported | Supported
|
||||
RKE2 | Supported | Supported
|
||||
K3S | Supported | Not Supported
|
||||
EKS | Supported | Not Supported
|
||||
GKE | Supported | Not Supported
|
||||
AKS | Supported | Not Supported
|
||||
**Rancher Components** | |
|
||||
Server | Supported | Not Supported
|
||||
Agent | Supported | Supported
|
||||
Fleet | Supported | Supported
|
||||
EKS Operator | Supported | Not Supported
|
||||
AKS Operator | Not Supported | Not Supported
|
||||
GKE Operator | Not Supported | Not Supported
|
||||
Alerting v1 | Supported | Supported
|
||||
Monitoring v1 | Supported | Supported
|
||||
Logging v1 | Supported | Supported
|
||||
Monitoring/Alerting v2 | Supported | Supported
|
||||
Logging v2 | Supported | Supported
|
||||
Istio | Supported | Not Supported
|
||||
Catalog v1 | Supported | Not Supported
|
||||
Catalog v2 | Supported | Not Supported
|
||||
OPA | Supported | Not Supported
|
||||
Longhorn | Supported | Not Supported
|
||||
CIS Scans | Supported | Not Supported
|
||||
Backup/Restore Operator | Supported | Not Supported
|
||||
**CNI / Add-ons** | |
|
||||
Flannel | Supported | Supported
|
||||
Canal | Supported | Not Supported
|
||||
Calico | Supported | Supported (RKE2 Only)
|
||||
Cilium | Supported | Not Supported
|
||||
Multus | Supported | Not Supported
|
||||
Traefik | Supported | Not Supported
|
||||
NGINX Ingress | Supported | Not Supported
|
||||
|
||||
For updated information on feature support, you may visit [rancher/windows](https://github.com/rancher/windows) on GitHub.
|
||||
Reference in New Issue
Block a user