mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Merge pull request #3158 from catherineluse/temp
Merge master to staging
This commit is contained in:
Catherine Luse
+5
@@ -231,6 +231,7 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"Sid": "EC2Permisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeVpcs",
|
||||
@@ -238,6 +239,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
@@ -248,6 +251,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ All nodes added to the cluster must be able to interact with EC2 so that they ca
|
||||
* 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.0-v2.4/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 an [Amazon EC2 cluster]({{<baseurl>}}/rancher/v2.0-v2.4/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.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes), you must manually attach the IAM role to the instance(s).
|
||||
|
||||
|
||||
@@ -49,8 +49,7 @@ When [adding your catalog]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/custom/add
|
||||
| Username (Optional) | Username or OAuth Token |
|
||||
| Password (Optional) | If you are authenticating using a username, enter the associated password. If you are using an OAuth token, use `x-oauth-basic`. |
|
||||
| Branch | For a Git repository, the branch name. Default: `master`. For a Helm Chart repository, this field is ignored. |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.](
|
||||
{{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/#catalog-helm-deployment-versions) |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/#catalog-helm-deployment-versions) |
|
||||
|
||||
# Private Repositories
|
||||
|
||||
|
||||
@@ -517,6 +517,7 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"Sid": "EC2Permisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeVpcs",
|
||||
@@ -524,6 +525,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
@@ -534,6 +537,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ All nodes added to the cluster must be able to interact with EC2 so that they ca
|
||||
* 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.5/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 an [Amazon EC2 cluster]({{<baseurl>}}/rancher/v2.5/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.5/en/cluster-provisioning/rke-clusters/custom-nodes), you must manually attach the IAM role to the instance(s).
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ In this section, you'll learn how to deploy Rancher on a Kubernetes cluster usin
|
||||
|
||||
# Prerequisites
|
||||
|
||||
- [A Kubernetes Cluster](#kubernetes-cluster)
|
||||
- [Kubernetes Cluster](#kubernetes-cluster)
|
||||
- [CLI Tools](#cli-tools)
|
||||
- [Ingress Controller (Only for Hosted Kubernetes)](#ingress-controller-for-hosted-kubernetes)
|
||||
|
||||
@@ -43,7 +43,7 @@ Refer to the [instructions provided by the Helm project](https://helm.sh/docs/in
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
|
||||
- [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.5/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
|
||||
|
||||
### Ingress Controller (for Hosted Kubernetes)
|
||||
### Ingress Controller (For Hosted Kubernetes)
|
||||
|
||||
To deploy Rancher v2.5 on a hosted Kubernetes cluster such as EKS, GKE, or AKS, you should deploy a compatible Ingress controller first to configure [SSL termination on Rancher.](#3-choose-your-ssl-configuration)
|
||||
|
||||
@@ -65,17 +65,25 @@ To choose a version of Helm to install Rancher with, refer to the [Helm version
|
||||
|
||||
To set up Rancher,
|
||||
|
||||
1. [Add the Helm chart repository](#1-add-the-helm-chart-repository)
|
||||
2. [Create a namespace for Rancher](#2-create-a-namespace-for-rancher)
|
||||
3. [Choose your SSL configuration](#3-choose-your-ssl-configuration)
|
||||
4. [Install cert-manager](#4-install-cert-manager) (unless you are bringing your own certificates, or TLS will be terminated on a load balancer)
|
||||
5. [Install Rancher with Helm and your chosen certificate option](#5-install-rancher-with-helm-and-your-chosen-certificate-option)
|
||||
6. [Verify that the Rancher server is successfully deployed](#6-verify-that-the-rancher-server-is-successfully-deployed)
|
||||
7. [Save your options](#7-save-your-options)
|
||||
1. [Install the required CLI tools](#1-install-the-required-cli-tools)
|
||||
2. [Add the Helm chart repository](#2-add-the-helm-chart-repository)
|
||||
3. [Create a namespace for Rancher](#3-create-a-namespace-for-rancher)
|
||||
4. [Choose your SSL configuration](#4-choose-your-ssl-configuration)
|
||||
5. [Install cert-manager](#5-install-cert-manager) (unless you are bringing your own certificates, or TLS will be terminated on a load balancer)
|
||||
6. [Install Rancher with Helm and your chosen certificate option](#6-install-rancher-with-helm-and-your-chosen-certificate-option)
|
||||
7. [Verify that the Rancher server is successfully deployed](#7-verify-that-the-rancher-server-is-successfully-deployed)
|
||||
8. [Save your options](#8-save-your-options)
|
||||
|
||||
### 1. Install the Required CLI Tools
|
||||
|
||||
The following CLI tools are required for setting up the Kubernetes cluster. Please make sure these tools are installed and available in your `$PATH`.
|
||||
|
||||
### 1. Add the Helm Chart Repository
|
||||
Refer to the [instructions provided by the Helm project](https://helm.sh/docs/intro/install/) for your specific platform.
|
||||
|
||||
- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
|
||||
- [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes. Refer to the [Helm version requirements]({{<baseurl>}}/rancher/v2.5/en/installation/options/helm-version) to choose a version of Helm to install Rancher.
|
||||
|
||||
### 2. Add the Helm Chart Repository
|
||||
|
||||
Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/#helm-chart-repositories).
|
||||
|
||||
@@ -85,7 +93,7 @@ Use `helm repo add` command to add the Helm chart repository that contains chart
|
||||
helm repo add rancher-<CHART_REPO> https://releases.rancher.com/server-charts/<CHART_REPO>
|
||||
```
|
||||
|
||||
### 2. Create a Namespace for Rancher
|
||||
### 3. Create a Namespace for Rancher
|
||||
|
||||
We'll need to define a Kubernetes namespace where the resources created by the Chart should be installed. This should always be `cattle-system`:
|
||||
|
||||
@@ -93,7 +101,7 @@ We'll need to define a Kubernetes namespace where the resources created by the C
|
||||
kubectl create namespace cattle-system
|
||||
```
|
||||
|
||||
### 3. Choose your SSL Configuration
|
||||
### 4. Choose your SSL Configuration
|
||||
|
||||
The Rancher management server is designed to be secure by default and requires SSL/TLS configuration.
|
||||
|
||||
@@ -112,7 +120,7 @@ There are three recommended options for the source of the certificate used for T
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [yes](#5-install-cert-manager) |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | no |
|
||||
|
||||
### 4. Install cert-manager
|
||||
### 5. Install cert-manager
|
||||
|
||||
> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
|
||||
|
||||
@@ -167,7 +175,7 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
### 5. Install Rancher with Helm and Your Chosen Certificate Option
|
||||
### 6. Install Rancher with Helm and Your Chosen Certificate Option
|
||||
|
||||
The exact command to install Rancher differs depending on the certificate configuration.
|
||||
|
||||
@@ -269,7 +277,7 @@ The Rancher chart configuration has many options for customizing the installatio
|
||||
See the [Chart Options]({{<baseurl>}}/rancher/v2.5/en/installation/resources/chart-options/) for the full list of options.
|
||||
|
||||
|
||||
### 6. Verify that the Rancher Server is Successfully Deployed
|
||||
### 7. Verify that the Rancher Server is Successfully Deployed
|
||||
|
||||
After adding the secrets, check if Rancher was rolled out successfully:
|
||||
|
||||
@@ -289,7 +297,7 @@ rancher 3 3 3 3 3m
|
||||
|
||||
It should show the same count for `DESIRED` and `AVAILABLE`.
|
||||
|
||||
### 7. Save Your Options
|
||||
### 8. Save Your Options
|
||||
|
||||
Make sure you save the `--set` options you used. You will need to use the same options when you upgrade Rancher to new versions with Helm.
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ Create the RancherD config file at `/etc/rancher/rke2/config.yaml`:
|
||||
```yaml
|
||||
token: my-shared-secret
|
||||
tls-san:
|
||||
- https://my-fixed-registration-address.com
|
||||
- my-fixed-registration-address.com
|
||||
- another-kubernetes-domain.com
|
||||
```
|
||||
|
||||
|
||||
@@ -59,6 +59,7 @@ As an [administrator]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-p
|
||||
>
|
||||
> - Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
|
||||
> - Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](#setting-resource-limits-and-requests)
|
||||
> - When installing monitoring on an RKE cluster using RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
|
||||
|
||||
|
||||
1. In the Rancher UI, go to the cluster where you want to install monitoring and click **Cluster Explorer.**
|
||||
|
||||
@@ -39,7 +39,6 @@ Suggestions include:
|
||||
- `azure_location` - Microsoft Azure region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
|
||||
- `ssh_key_file_name` - Use a specific SSH key instead of `~/.ssh/id_rsa` (public key is assumed to be `${ssh_key_file_name}.pub`)
|
||||
|
||||
1. Run `terraform init`.
|
||||
|
||||
@@ -56,7 +55,7 @@ Suggestions include:
|
||||
```
|
||||
|
||||
1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
|
||||
|
||||
2. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/azure`.
|
||||
#### Result
|
||||
|
||||
Two Kubernetes clusters are deployed into your Azure account, one running Rancher Server and the other ready for experimentation deployments.
|
||||
|
||||
-49
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: vSphere Out-of-tree Cloud Provider
|
||||
weight: 10
|
||||
---
|
||||
_Available as of v2.5.6_
|
||||
|
||||
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 CPI and CSI plugins after bringing up a cluster.
|
||||
|
||||
# Prerequisites
|
||||
|
||||
The vSphere version must be 6.7U3 or higher.
|
||||
|
||||
# Installation
|
||||
|
||||
The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).
|
||||
|
||||
### 1. Create a vSphere cluster
|
||||
|
||||
1. On the Clusters page, click on **Add Cluster** and select the **vSphere** option.
|
||||
1. Under **Cluster Options > In-Tree Cloud Provider** select **External**.
|
||||
1. Click **Create**.
|
||||
|
||||
### 2. Install the CPI plugin
|
||||
|
||||
1. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
1. Select the **vsphere-cpi** chart from the **helm3-library** catalog. 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. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
1. Select the **vsphere-csi** chart from the **helm3-library** catalog. Fill out the required vCenter details.
|
||||
2. Set **Enable CSI Migration** to **false**.
|
||||
3. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner. Fill out the details for the StorageClass and launch the chart.
|
||||
|
||||
|
||||
# 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.
|
||||
-99
@@ -1,99 +0,0 @@
|
||||
---
|
||||
title: Migrating vSphere In-tree Volumes to CSI
|
||||
weight: 5
|
||||
---
|
||||
_Available as of v2.5.6_
|
||||
|
||||
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. Within a project, select **Apps > Launch.**
|
||||
2. Select the **vsphere-cpi** chart from the **helm3-library** catalog.
|
||||
3. Fill out the required vCenter details and click **Launch**.
|
||||
|
||||
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. Within a project, select **Apps > Launch** and select the **vsphere-csi** chart from the **helm3-library** catalog.
|
||||
1. Fill out the required vCenter details and click **Launch**.
|
||||
1. Set **Enable CSI Migration** to **true**.
|
||||
1. 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 and click **Launch**.
|
||||
|
||||
### 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 **Edit as Form** and then click on "Advanced Options."
|
||||
1. Set the field **Maximum Worker Nodes Unavailable** to count of 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.
|
||||
@@ -518,6 +518,7 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"Sid": "EC2Permisssions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeVpcs",
|
||||
@@ -525,6 +526,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
@@ -535,6 +538,8 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ All nodes added to the cluster must be able to interact with EC2 so that they ca
|
||||
* 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.x/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 an [Amazon EC2 cluster]({{<baseurl>}}/rancher/v2.x/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.x/en/cluster-provisioning/rke-clusters/custom-nodes), you must manually attach the IAM role to the instance(s).
|
||||
|
||||
|
||||
@@ -48,8 +48,7 @@ When [adding your catalog]({{<baseurl>}}/rancher/v2.x/en/catalog/custom/adding/)
|
||||
| Username (Optional) | Username or OAuth Token |
|
||||
| Password (Optional) | If you are authenticating using a username, enter the associated password. If you are using an OAuth token, use `x-oauth-basic`. |
|
||||
| Branch | For a Git repository, the branch name. Default: `master`. For a Helm Chart repository, this field is ignored. |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.](
|
||||
{{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/#catalog-helm-deployment-versions) |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.]({{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/#catalog-helm-deployment-versions) |
|
||||
|
||||
# Private Repositories
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ Create the RancherD config file at `/etc/rancher/rke2/config.yaml`:
|
||||
```yaml
|
||||
token: my-shared-secret
|
||||
tls-san:
|
||||
- https://my-fixed-registration-address.com
|
||||
- my-fixed-registration-address.com
|
||||
- another-kubernetes-domain.com
|
||||
```
|
||||
|
||||
@@ -237,4 +237,4 @@ rancherd-uninstall.sh
|
||||
|
||||
# RKE2 Documentation
|
||||
|
||||
For more information on RKE2, the Kubernetes distribution used to provision the underlying cluster, refer to the documentation [here.](https://docs.rke2.io/)
|
||||
For more information on RKE2, the Kubernetes distribution used to provision the underlying cluster, refer to the documentation [here.](https://docs.rke2.io/)
|
||||
|
||||
@@ -9,7 +9,7 @@ This section describes how to install a Kubernetes cluster according to the [bes
|
||||
|
||||
# Prerequisites
|
||||
|
||||
These instructions assume you have set up three nodes, a load balancer, a DNS record, [this section.](({{<baseurl>}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
These instructions assume you have set up three nodes, a load balancer, a DNS record, [this section.]({{<baseurl>}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
|
||||
Note that in order for RKE2 to work correctly with the load balancer, you need to set up two listeners: one for the supervisor on port 9345, and one for the Kubernetes API on port 6443.
|
||||
|
||||
|
||||
@@ -54,6 +54,7 @@ As an [administrator]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/global-p
|
||||
>
|
||||
> - Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
|
||||
> - Make sure your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. A breakdown of the resource limits and requests is [here.](#setting-resource-limits-and-requests)
|
||||
> - When installing monitoring on an RKE cluster using RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
|
||||
|
||||
|
||||
1. In the Rancher UI, go to the cluster where you want to install monitoring and click **Cluster Explorer.**
|
||||
|
||||
@@ -39,7 +39,6 @@ Suggestions include:
|
||||
- `azure_location` - Microsoft Azure region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
- `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
|
||||
- `ssh_key_file_name` - Use a specific SSH key instead of `~/.ssh/id_rsa` (public key is assumed to be `${ssh_key_file_name}.pub`)
|
||||
|
||||
1. Run `terraform init`.
|
||||
|
||||
@@ -56,6 +55,7 @@ Suggestions include:
|
||||
```
|
||||
|
||||
1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
|
||||
2. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/azure`.
|
||||
|
||||
#### Result
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ Create a bash script file called `account_update.sh`. Be sure to `chmod +x accou
|
||||
```
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o json | jq -r '.items[].metadata.name'); do
|
||||
for namespace in $(kubectl get namespaces -o custom-columns=NAME:.metadata.name --no-headers); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user