Merge pull request #4099 from rancher/master-to-staging

Master to staging
2026-09-25 04:28:15 +00:00 · 2022-05-11 19:39:48 -04:00
parent feec8eff39 31582ca534
commit f0b697fecf
9 changed files with 203 additions and 21 deletions
@@ -163,4 +163,4 @@ Example: `docker tag coredns-coredns:1.6.3 mycustomreg:5000/coredns-coredns`

 Last, push the images to the private registry.

-Example: `docker push mycustomreg:5000/coredns-coredns`
+Example: `docker push mycustomreg.com:5000/coredns-coredns`
@@ -101,7 +101,7 @@ The table below details the parameters for the group schema configuration.
 | Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects. See description of user schema `Search Attribute`. |
 | Search Filter | This filter gets applied to the list of groups that is searched when Rancher attempts to add groups to a site access list or tries to add groups to clusters or projects. For example, a group search filter could be <code>(&#124;(cn=group1)(cn=group2))</code>. Note: If the search filter does not use [valid AD search syntax,](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax) the list of groups will be empty. |
 | Group DN Attribute | The name of the group attribute whose format matches the values in the user attribute describing a the user's memberships. See  `User Member Attribute`. |
-| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members. We advise avoiding nested groups when possible). |
+| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organization makes use of these nested memberships (i.e., you have groups that contain other groups as members. We advise avoiding nested groups when possible). |

 ---

@@ -153,7 +153,7 @@ This command performs an LDAP search with the search base set to the domain root

 Since in this case the user's DN is `CN=John Doe,CN=Users,DC=acme,DC=com` [5], we should configure the **User Search Base** with the parent node DN `CN=Users,DC=acme,DC=com`.

-Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, ie. `OU=Groups,DC=acme,DC=com`.
+Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, i.e., `OU=Groups,DC=acme,DC=com`.

 ### Identify User Schema

@@ -166,7 +166,7 @@ The output of the above `ldapsearch` query also allows to determine the correct

 > **Note:**
 >
-> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
+> If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.

 We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.

@@ -101,7 +101,7 @@ The table below details the parameters for the group schema configuration.
 | Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects. See description of user schema `Search Attribute`. |
 | Search Filter | This filter gets applied to the list of groups that is searched when Rancher attempts to add groups to a site access list or tries to add groups to clusters or projects. For example, a group search filter could be <code>(&#124;(cn=group1)(cn=group2))</code>. Note: If the search filter does not use [valid AD search syntax,](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax) the list of groups will be empty. |
 | Group DN Attribute | The name of the group attribute whose format matches the values in the user attribute describing a the user's memberships. See  `User Member Attribute`. |
-| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members. We advise avoiding nested groups when possible). |
+| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organization makes use of these nested memberships (i.e., you have groups that contain other groups as members. We advise avoiding nested groups when possible to avoid potential performance issues when there is a large amount of nested memberships). |

 ---

@@ -153,7 +153,7 @@ This command performs an LDAP search with the search base set to the domain root

 Since in this case the user's DN is `CN=John Doe,CN=Users,DC=acme,DC=com` [5], we should configure the **User Search Base** with the parent node DN `CN=Users,DC=acme,DC=com`.

-Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, ie. `OU=Groups,DC=acme,DC=com`.
+Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, i.e., `OU=Groups,DC=acme,DC=com`.

 ### Identify User Schema

@@ -166,7 +166,7 @@ The output of the above `ldapsearch` query also allows to determine the correct

 > **Note:**
 >
-> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
+> If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.

 We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.

@@ -6,7 +6,7 @@ weight: 2220

 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. 
+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.

@@ -25,29 +25,31 @@ For more information on configuring Azure node templates, refer to the [Azure no
 - [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 %}}
+{{% tab "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**.
@@ -57,7 +59,7 @@ The creation of this service principal returns three pieces of identification in
 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. 
+**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

@@ -82,17 +84,76 @@ Use Rancher to create a Kubernetes cluster in Azure.
 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**.

-**Result:** 
+{{% /tab %}}
+{{% tab "RKE2" %}}
+
+### 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 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. 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**.
+
+{{% /tab %}}
+{{% tab "RKE2 - Cluster 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**.
+
+### 2. Add your cluster template
+
+1. Follow these [instructions]({{<baseurl>}}/rancher/v2.6/en/admin-settings/cluster-templates/#adding-a-cluster-template-to-rancher) to add a cluster template to Rancher.
+
+### 3. Create your cluster using a cluster template
+
+1. Click **☰ > Cluster Management**.
+1. Under the **Use a Catalog Template to create a cluster** section, click **catalog-template**.
+1. Enter a name for the cluster.
+1. Select cloud credentials to use.
+1. Select the **Infrastructure Provider**. If you are using Rancher's [example cluster templates](https://github.com/rancher/cluster-template-examples), select `azure`.
+1. Choose a **Kubernetes Version**.
+1. Configure your nodepools. For help with configurations, refer to [Azure Node Template Configuration.](./azure-node-template-config)
+1. Click **Install**.
+
+{{% /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: 
+**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:
@@ -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`
@@ -24,7 +24,7 @@ Repository | URL | Description
 Rancher | https://github.com/rancher/rancher | This repository is the main source code for Rancher 2.x.
 Types | https://github.com/rancher/types | This repository is the repository that has all the API types for Rancher 2.x.
 API Framework | https://github.com/rancher/norman | This repository is an API framework for building Rancher style APIs backed by Kubernetes Custom Resources.
-User Interface | https://github.com/rancher/ui | This repository is the source of the UI.
+User Interface | https://github.com/rancher/dashboard/ | This repository is the source of the Dashboard UI.
 (Rancher) Docker Machine | https://github.com/rancher/machine | This repository is the source of the Docker Machine binary used when using Node Drivers. This is a fork of the `docker/machine` repository.
 machine-package | https://github.com/rancher/machine-package | This repository is used to build the Rancher Docker Machine binary.
 kontainer-engine | https://github.com/rancher/kontainer-engine | This repository is the source of kontainer-engine, the tool to provision hosted Kubernetes clusters.
@@ -36,7 +36,7 @@ loglevel repository | https://github.com/rancher/loglevel | This repository is t

 To see all libraries/projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.

-![Rancher diagram]({{<baseurl>}}/img/rancher/ranchercomponentsdiagram.svg)<br/>
+![Rancher diagram]({{<baseurl>}}/img/rancher/ranchercomponentsdiagram-2.6.svg)<br/>
 <sup>Rancher components used for provisioning/managing Kubernetes clusters.</sup>

 # Building
@@ -68,7 +68,7 @@ net.bridge.bridge-nf-call-iptables=1

 For the container runtime, K3s should work with any modern version of Docker or containerd.

-Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script. 
+Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/) To specify the K3s version, use the INSTALL_K3S_VERSION environment variable when running the K3s installation script.

 If you are installing Rancher on a K3s cluster with **Raspbian Buster**, follow [these steps]({{<baseurl>}}/k3s/latest/en/advanced/#enabling-legacy-iptables-on-raspbian-buster) to switch to legacy iptables.

@@ -82,8 +82,6 @@ For details on which OS versions were tested with RKE2, refer to the [support ma

 Docker is not required for RKE2 installs.

-The Ingress should be deployed as DaemonSet to ensure your load balancer can successfully route traffic to all nodes. Currently, RKE2 deploys nginx-ingress as a deployment by default, so you will need to deploy it as a DaemonSet by following [these steps.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2/#5-configure-nginx-to-be-a-daemonset)
-
 ### Installing Docker

 Docker is required for Helm chart installs, and it can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/installing-docker) to install Docker with one command.
@@ -133,7 +133,7 @@ Using a Kubeconfig for each downstream cluster update the environment variable f

 ```
 $ kubectl edit -n cattle-system ds/cattle-node-agent
-$ kubectl edit -n cattle-system deployment/cluster-agent
+$ kubectl edit -n cattle-system deployment/cattle-cluster-agent
 ```

 ### Method 3: Recreate Rancher agents