mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-27 15:18:26 +00:00
Replace the word ellipsis with vertical ellipsis
This commit is contained in:
@@ -46,7 +46,7 @@ The way that the metadata is configured depends on the Rancher version.
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
1. Go to the **rke-metadata-config** section. Click the **Ellipsis (...)** and click **Edit.**
|
||||
1. Go to the **rke-metadata-config** section. Click the **⋮** and click **Edit.**
|
||||
1. You can optionally fill in the following parameters:
|
||||
|
||||
- `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
|
||||
@@ -60,7 +60,7 @@ However, if you have an [air gap setup,](#air-gap-setups) you will need to mirro
|
||||
To edit the metadata config in Rancher,
|
||||
|
||||
1. Go to the **Global** view and click the **Settings** tab.
|
||||
1. Go to the **rke-metadata-config** section. Click the **Ellipsis (...)** and click **Edit.**
|
||||
1. Go to the **rke-metadata-config** section. Click the **⋮** and click **Edit.**
|
||||
1. You can optionally fill in the following parameters:
|
||||
|
||||
- `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
|
||||
|
||||
@@ -67,7 +67,7 @@ To assign the role to a new cluster member,
|
||||
|
||||
To assign any custom role to an existing cluster member,
|
||||
|
||||
1. Go to the member you want to give the role to. Click the **Ellipsis (...) > View in API.**
|
||||
1. Go to the member you want to give the role to. Click the **⋮ > View in API.**
|
||||
1. In the **roleTemplateId** field, go to the drop-down menu and choose the role you want to assign to the member. Click **Show Request** and **Send Request.**
|
||||
|
||||
**Result:** The member has the assigned role.
|
||||
@@ -157,7 +157,7 @@ You can change the cluster or project role(s) that are automatically assigned to
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu. Select either the **Cluster** or **Project** tab.
|
||||
|
||||
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **Ellipsis > Edit**.
|
||||
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **⋮ > Edit**.
|
||||
|
||||
1. Enable the role as default.
|
||||
{{% accordion id="cluster" label="For Clusters" %}}
|
||||
|
||||
@@ -105,7 +105,7 @@ The custom global role can then be assigned to a user or group so that the custo
|
||||
To create a custom global role based on an existing role,
|
||||
|
||||
1. Go to the **Global** view and click **Security > Roles.**
|
||||
1. On the **Global** tab, go to the role that the custom global role will be based on. Click **Ellipsis (…) > Clone.**
|
||||
1. On the **Global** tab, go to the role that the custom global role will be based on. Click **⋮ (…) > Clone.**
|
||||
1. Enter a name for the role.
|
||||
1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.**
|
||||
1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
|
||||
@@ -135,7 +135,7 @@ Custom global roles can be deleted, but built-in roles cannot be deleted.
|
||||
To delete a custom global role,
|
||||
|
||||
1. Go to the **Global** view and click **Security > Roles.**
|
||||
2. On the **Global** tab, go to the custom global role that should be deleted and click **Ellipsis (…) > Delete.**
|
||||
2. On the **Global** tab, go to the custom global role that should be deleted and click **⋮ (…) > Delete.**
|
||||
3. Click **Delete.**
|
||||
|
||||
## Assigning a Custom Global Role to a Group
|
||||
|
||||
@@ -102,7 +102,7 @@ To change the default global permissions that are assigned to external users upo
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu. Make sure the **Global** tab is selected.
|
||||
|
||||
1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **Ellipsis > Edit**.
|
||||
1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit**.
|
||||
|
||||
1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**.
|
||||
|
||||
@@ -116,7 +116,7 @@ To configure permission for a user,
|
||||
|
||||
1. Go to the **Users** tab.
|
||||
|
||||
1. On this page, go to the user whose access level you want to change and click **Ellipsis (...) > Edit.**
|
||||
1. On this page, go to the user whose access level you want to change and click **⋮ > Edit.**
|
||||
|
||||
1. In the **Global Permissions** section, click **Custom.**
|
||||
|
||||
|
||||
@@ -32,6 +32,6 @@ You can lock roles in two contexts:
|
||||
|
||||
1. From the **Global** view, select **Security** > **Roles**.
|
||||
|
||||
2. From the role that you want to lock (or unlock), select **Vertical Ellipsis (...)** > **Edit**.
|
||||
2. From the role that you want to lock (or unlock), select **⋮** > **Edit**.
|
||||
|
||||
3. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.
|
||||
|
||||
@@ -53,7 +53,7 @@ RKE templates cannot be applied to existing clusters, except if you save an exis
|
||||
To convert an existing cluster to use an RKE template,
|
||||
|
||||
1. From the **Global** view in Rancher, click the **Clusters** tab.
|
||||
1. Go to the cluster that will be converted to use an RKE template. Click **Ellipsis (...)** > **Save as RKE Template.**
|
||||
1. Go to the cluster that will be converted to use an RKE template. Click **⋮** > **Save as RKE Template.**
|
||||
1. Enter a name for the template in the form that appears, and click **Create.**
|
||||
|
||||
**Results:**
|
||||
|
||||
+10
-10
@@ -51,7 +51,7 @@ You can't edit individual revisions. Since you can't edit individual revisions o
|
||||
When new template revisions are created, clusters using an older revision of the template are unaffected.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template that you want to edit and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. Go to the template that you want to edit and click the **⋮ > Edit.**
|
||||
1. Edit the required information and click **Save.**
|
||||
1. Optional: You can change the default revision of this template and also change who it is shared with.
|
||||
|
||||
@@ -62,7 +62,7 @@ When new template revisions are created, clusters using an older revision of the
|
||||
When you no longer use an RKE template for any of your clusters, you can delete it.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the RKE template that you want to delete and click the **Vertical Ellipsis (...) > Delete.**
|
||||
1. Go to the RKE template that you want to delete and click the **⋮ > Delete.**
|
||||
1. Confirm the deletion when prompted.
|
||||
|
||||
**Result:** The template is deleted.
|
||||
@@ -72,7 +72,7 @@ When you no longer use an RKE template for any of your clusters, you can delete
|
||||
You can clone the default template revision and quickly update its settings rather than creating a new revision from scratch. Cloning templates saves you the hassle of re-entering the access keys and other parameters needed for cluster creation.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the RKE template that you want to clone and click the **Vertical Ellipsis (...) > New Revision From Default.**
|
||||
1. Go to the RKE template that you want to clone and click the **⋮ > New Revision From Default.**
|
||||
1. Complete the rest of the form to create a new revision.
|
||||
|
||||
**Result:** The RKE template revision is cloned and configured.
|
||||
@@ -82,7 +82,7 @@ You can clone the default template revision and quickly update its settings rath
|
||||
When creating new RKE template revisions from your user settings, you can clone an existing revision and quickly update its settings rather than creating a new one from scratch. Cloning template revisions saves you the hassle of re-entering the cluster parameters.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template revision you want to clone. Then select **Ellipsis > Clone Revision.**
|
||||
1. Go to the template revision you want to clone. Then select **⋮ > Clone Revision.**
|
||||
1. Complete the rest of the form.
|
||||
|
||||
**Result:** The RKE template revision is cloned and configured. You can use the RKE template revision later when you provision a cluster. Any existing cluster using this RKE template can be upgraded to this new revision.
|
||||
@@ -94,7 +94,7 @@ When you no longer want an RKE template revision to be used for creating new clu
|
||||
You can disable the revision if it is not being used by any cluster.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template revision you want to disable. Then select **Ellipsis > Disable.**
|
||||
1. Go to the template revision you want to disable. Then select **⋮ > Disable.**
|
||||
|
||||
**Result:** The RKE template revision cannot be used to create a new cluster.
|
||||
|
||||
@@ -103,7 +103,7 @@ You can disable the revision if it is not being used by any cluster.
|
||||
If you decide that a disabled RKE template revision should be used to create new clusters, you can re-enable it.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template revision you want to re-enable. Then select **Ellipsis > Enable.**
|
||||
1. Go to the template revision you want to re-enable. Then select **⋮ > Enable.**
|
||||
|
||||
**Result:** The RKE template revision can be used to create a new cluster.
|
||||
|
||||
@@ -114,7 +114,7 @@ When end users create a cluster using an RKE template, they can choose which rev
|
||||
To set an RKE template revision as default,
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the RKE template revision that should be default and click the **Ellipsis (...) > Set as Default.**
|
||||
1. Go to the RKE template revision that should be default and click the **⋮ > Set as Default.**
|
||||
|
||||
**Result:** The RKE template revision will be used as the default option when clusters are created with the template.
|
||||
|
||||
@@ -125,7 +125,7 @@ You can delete all revisions of a template except for the default revision.
|
||||
To permanently delete a revision,
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the RKE template revision that should be deleted and click the **Ellipsis (...) > Delete.**
|
||||
1. Go to the RKE template revision that should be deleted and click the **⋮ > Delete.**
|
||||
|
||||
**Result:** The RKE template revision is deleted.
|
||||
|
||||
@@ -137,7 +137,7 @@ To permanently delete a revision,
|
||||
To upgrade a cluster to use a new template revision,
|
||||
|
||||
1. From the **Global** view in Rancher, click the **Clusters** tab.
|
||||
1. Go to the cluster that you want to upgrade and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the cluster that you want to upgrade and click **⋮ > Edit.**
|
||||
1. In the **Cluster Options** section, click the dropdown menu for the template revision, then select the new template revision.
|
||||
1. Click **Save.**
|
||||
|
||||
@@ -152,7 +152,7 @@ This exports the cluster's settings as a new RKE template, and also binds the cl
|
||||
To convert an existing cluster to use an RKE template,
|
||||
|
||||
1. From the **Global** view in Rancher, click the **Clusters** tab.
|
||||
1. Go to the cluster that will be converted to use an RKE template. Click **Ellipsis (...)** > **Save as RKE Template.**
|
||||
1. Go to the cluster that will be converted to use an RKE template. Click **⋮** > **Save as RKE Template.**
|
||||
1. Enter a name for the template in the form that appears, and click **Create.**
|
||||
|
||||
**Results:**
|
||||
|
||||
@@ -24,7 +24,7 @@ Administrators can give users permission to create RKE templates in two ways:
|
||||
|
||||
An administrator can individually grant the role **Create RKE Templates** to any existing user by following these steps:
|
||||
|
||||
1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **⋮ > Edit.**
|
||||
1. In the **Global Permissions** section, choose **Custom** and select the **Create RKE Templates** role along with any other roles the user should have. Click **Save.**
|
||||
|
||||
**Result:** The user has permission to create RKE templates.
|
||||
@@ -34,7 +34,7 @@ An administrator can individually grant the role **Create RKE Templates** to any
|
||||
Alternatively, the administrator can give all new users the default permission to create RKE templates by following the following steps. This will not affect the permissions of existing users.
|
||||
|
||||
1. From the **Global** view, click **Security > Roles.**
|
||||
1. Under the **Global** roles tab, go to the role **Create RKE Templates** and click the **Vertical Ellipsis (...) > Edit**.
|
||||
1. Under the **Global** roles tab, go to the role **Create RKE Templates** and click the **⋮ > Edit**.
|
||||
1. Select the option **Yes: Default role for new users** and click **Save.**
|
||||
|
||||
**Result:** Any new user created in this Rancher installation will be able to create RKE templates. Existing users will not get this permission.
|
||||
@@ -43,7 +43,7 @@ Alternatively, the administrator can give all new users the default permission t
|
||||
|
||||
Administrators can remove a user's permission to create templates with the following steps:
|
||||
|
||||
1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. From the global view, click the **Users** tab. Choose the user you want to edit and click the **⋮ > Edit.**
|
||||
1. In the **Global Permissions** section, un-check the box for **Create RKE Templates**. In this section, you can change the user back to a standard user, or give the user a different set of custom permissions.
|
||||
1. Click **Save.**
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ You might want to require new clusters to use a template to ensure that any clus
|
||||
To require new clusters to use an RKE template, administrators can turn on RKE template enforcement with the following steps:
|
||||
|
||||
1. From the **Global** view, click the **Settings** tab.
|
||||
1. Go to the `cluster-template-enforcement` setting. Click the vertical **Ellipsis (...)** and click **Edit.**
|
||||
1. Go to the `cluster-template-enforcement` setting. Click the vertical **⋮** and click **Edit.**
|
||||
1. Set the value to **True** and click **Save.**
|
||||
|
||||
**Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.
|
||||
@@ -32,7 +32,7 @@ To require new clusters to use an RKE template, administrators can turn on RKE t
|
||||
To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps:
|
||||
|
||||
1. From the **Global** view, click the **Settings** tab.
|
||||
1. Go to the `cluster-template-enforcement` setting. Click the vertical **Ellipsis (...)** and click **Edit.**
|
||||
1. Go to the `cluster-template-enforcement` setting. Click the vertical **⋮** and click **Edit.**
|
||||
1. Set the value to **False** and click **Save.**
|
||||
|
||||
**Result:** When clusters are provisioned by Rancher, they don't need to use a template.
|
||||
|
||||
+3
-3
@@ -28,7 +28,7 @@ There are several ways to share templates:
|
||||
To allow users or groups to create clusters using your template, you can give them the basic **User** access level for the template.
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template that you want to share and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. Go to the template that you want to share and click the **⋮ > Edit.**
|
||||
1. In the **Share Template** section, click on **Add Member**.
|
||||
1. Search in the **Name** field for the user or group you want to share the template with.
|
||||
1. Choose the **User** access type.
|
||||
@@ -39,7 +39,7 @@ To allow users or groups to create clusters using your template, you can give th
|
||||
### Sharing Templates with All Users
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the template that you want to share and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. Go to the template that you want to share and click the **⋮ > Edit.**
|
||||
1. Under **Share Template,** click **Make Public (read-only).** Then click **Save.**
|
||||
|
||||
**Result:** All users in the Rancher setup can create clusters using the template.
|
||||
@@ -53,7 +53,7 @@ In that case, you can give users the Owner access type, which allows another use
|
||||
To give Owner access to a user or group,
|
||||
|
||||
1. From the **Global** view, click **Tools > RKE Templates.**
|
||||
1. Go to the RKE template that you want to share and click the **Vertical Ellipsis (...) > Edit.**
|
||||
1. Go to the RKE template that you want to share and click the **⋮ > Edit.**
|
||||
1. Under **Share Template**, click on **Add Member** and search in the **Name** field for the user or group you want to share the template with.
|
||||
1. In the **Access Type** field, click **Owner.**
|
||||
1. Click **Save.**
|
||||
|
||||
@@ -97,7 +97,7 @@ The [global administrators]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/gl
|
||||
|
||||
1. From the **Global View**, select **Tools > Global DNS Providers**.
|
||||
|
||||
1. For the Global DNS provider that you want to edit, click the **Vertical Ellipsis (...) > Edit**.
|
||||
1. For the Global DNS provider that you want to edit, click the **⋮ > Edit**.
|
||||
|
||||
## Editing a Global DNS Entry
|
||||
|
||||
@@ -115,4 +115,4 @@ Permission checks are relaxed for removing target projects in order to support s
|
||||
|
||||
1. From the **Global View**, select **Tools > Global DNS Entries**.
|
||||
|
||||
1. For the Global DNS entry that you want to edit, click the **Vertical Ellipsis (...) > Edit**.
|
||||
1. For the Global DNS entry that you want to edit, click the **⋮ > Edit**.
|
||||
|
||||
@@ -22,7 +22,7 @@ After an application is deployed, you can easily upgrade to a different template
|
||||
|
||||
1. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
|
||||
|
||||
3. Find the application that you want to upgrade, and then click the Ellipsis to find **Upgrade**.
|
||||
3. Find the application that you want to upgrade, and then click the ⋮ to find **Upgrade**.
|
||||
|
||||
4. Select the **Template Version** that you want to deploy.
|
||||
|
||||
@@ -48,7 +48,7 @@ After an application has been upgraded, you can easily rollback to a different t
|
||||
|
||||
1. From the main navigation bar, choose **Apps**. In versions prior to v2.2.0, choose **Catalog Apps** on the main navigation bar. Click **Launch**.
|
||||
|
||||
3. Find the application that you want to rollback, and then click the Ellipsis to find **Rollback**.
|
||||
3. Find the application that you want to rollback, and then click the ⋮ to find **Rollback**.
|
||||
|
||||
4. Select the **Revision** that you want to roll back to. By default, Rancher saves up to the last 10 revisions.
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ One of the benefits of using a multi-cluster application as opposed to multiple
|
||||
|
||||
1. From the **Global** view, choose **Apps** in the navigation bar.
|
||||
|
||||
2. Choose the multi-cluster application you want to take one of these actions on and click the **Vertical Ellipsis (...)**. Select one of the following options:
|
||||
2. Choose the multi-cluster application you want to take one of these actions on and click the **⋮**. Select one of the following options:
|
||||
|
||||
* **Clone**: Creates another multi-cluster application with the same configuration. By using this option, you can easily duplicate a multi-cluster application.
|
||||
* **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members).
|
||||
@@ -156,6 +156,6 @@ One of the benefits of using a multi-cluster application as opposed to multiple
|
||||
|
||||
1. From the **Global** view, choose **Apps** in the navigation bar.
|
||||
|
||||
2. Choose the multi-cluster application you want to delete and click the **Vertical Ellipsis (...) > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
|
||||
2. Choose the multi-cluster application you want to delete and click the **⋮ > Delete**. When deleting the multi-cluster application, all applications and namespaces are deleted in all of the target projects.
|
||||
|
||||
> **Note:** The applications in the target projects, that are created for a multi-cluster application, cannot be deleted individually. The applications can only be deleted when the multi-cluster application is deleted.
|
||||
|
||||
@@ -77,7 +77,7 @@ In addition to recurring snapshots, you may want to take a "one-time" snapshot.
|
||||
|
||||
1. In the **Global** view, navigate to the cluster that you want to take a one-time snapshot.
|
||||
|
||||
2. Click the **Vertical Ellipsis (...) > Snapshot Now**.
|
||||
2. Click the **⋮ > Snapshot Now**.
|
||||
|
||||
**Result:** Based on your [snapshot backup target](#snapshot-backup-targets), a one-time snapshot will be taken and saved in the selected backup target.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
|
||||
|
||||
1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
|
||||
|
||||
2. Select the **Ellipsis (...) > Rotate Certificates**.
|
||||
2. Select the **⋮ > Rotate Certificates**.
|
||||
|
||||
3. Select which certificates that you want to rotate.
|
||||
|
||||
@@ -47,7 +47,7 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
|
||||
|
||||
1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
|
||||
|
||||
2. Select the **Ellipsis (...) > View in API**.
|
||||
2. Select the **⋮ > View in API**.
|
||||
|
||||
3. Click on **RotateCertificates**.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Cluster Configuration
|
||||
weight: 2025
|
||||
---
|
||||
|
||||
After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster. To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **Ellipsis (...) > Edit** for the cluster that you want to edit.
|
||||
After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster. To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **⋮ > Edit** for the cluster that you want to edit.
|
||||
|
||||
<sup>To Edit an Existing Cluster</sup>
|
||||

|
||||
|
||||
@@ -72,7 +72,7 @@ Editing a node lets you:
|
||||
* Add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
|
||||
* Add/Remove [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
|
||||
|
||||
To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. You can open the options menu for a node by clicking its **Ellipsis** icon (**...**).
|
||||
To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. You can open the options menu for a node by clicking its **⋮** icon (**...**).
|
||||
|
||||
# Viewing a Node in the Rancher API
|
||||
|
||||
@@ -96,7 +96,7 @@ For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en
|
||||
|
||||
1. From the cluster hosted by an infrastructure provider, select **Nodes** from the main menu.
|
||||
|
||||
1. Find the node that you want to remote into. Select **Ellipsis (...) > Download Keys**.
|
||||
1. Find the node that you want to remote into. Select **⋮ > Download Keys**.
|
||||
|
||||
**Step Result:** A ZIP file containing files used for SSH is downloaded.
|
||||
|
||||
@@ -201,7 +201,7 @@ You can label nodes to be ignored by using a setting in the Rancher UI, or by us
|
||||
To add a node that is ignored by Rancher,
|
||||
|
||||
1. From the **Global** view, click the **Settings** tab.
|
||||
1. Go to the `ignore-node-name` setting and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the `ignore-node-name` setting and click **⋮ > Edit.**
|
||||
1. Enter a name that Rancher will use to ignore nodes. All nodes with this name will be ignored.
|
||||
1. Click **Save.**
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ When your cluster is running pods with security-sensitive configurations, assign
|
||||
|
||||
You can assign a pod security policy when you provision a cluster. However, if you need to relax or restrict security for your pods later, you can update the policy while editing your cluster.
|
||||
|
||||
1. From the **Global** view, find the cluster to which you want to apply a pod security policy. Select **Vertical Ellipsis (...) > Edit**.
|
||||
1. From the **Global** view, find the cluster to which you want to apply a pod security policy. Select **⋮ > Edit**.
|
||||
|
||||
2. Expand **Cluster Options**.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
1. In the **Global** view, navigate to the cluster that you want to restore from a snapshots.
|
||||
|
||||
2. Click the **Vertical Ellipsis (...) > Restore Snapshot**.
|
||||
2. Click the **⋮ > Restore Snapshot**.
|
||||
|
||||
3. Select the snapshot that you want to use for restoring your cluster from the dropdown of available snapshots.
|
||||
|
||||
@@ -67,7 +67,7 @@ When rolling back to a prior Kubernetes version, the [upgrade strategy options](
|
||||
|
||||
1. In the **Global** view, navigate to the cluster that you want to restore from a snapshot.
|
||||
|
||||
2. Click the **Vertical Ellipsis (...) > Restore Snapshot**.
|
||||
2. Click the **⋮ > Restore Snapshot**.
|
||||
|
||||
3. Select the snapshot that you want to use for restoring your cluster from the dropdown of available snapshots.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ To disable Istio,
|
||||
# Disable Istio in a Namespace
|
||||
|
||||
1. In the Rancher UI, go to the project that has the namespace where you want to disable Istio.
|
||||
1. On the **Workloads** tab, you will see a list of namespaces and the workloads deployed in them. Go to the namespace where you want to disable and click the **Ellipsis (...) > Disable Istio Auto Injection.**
|
||||
1. On the **Workloads** tab, you will see a list of namespaces and the workloads deployed in them. Go to the namespace where you want to disable and click the **⋮ > Disable Istio Auto Injection.**
|
||||
|
||||
**Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 4
|
||||
|
||||
Enabling Istio in a namespace only enables automatic sidecar injection for new workloads. To enable the Envoy sidecar for existing workloads, you need to enable it manually for each workload.
|
||||
|
||||
To inject the Istio sidecar on an existing workload in the namespace, go to the workload, click the **Ellipsis (...),** and click **Redeploy.** When the workload is redeployed, it will have the Envoy sidecar automatically injected.
|
||||
To inject the Istio sidecar on an existing workload in the namespace, go to the workload, click the **⋮,** and click **Redeploy.** When the workload is redeployed, it will have the Envoy sidecar automatically injected.
|
||||
|
||||
Wait a few minutes for the workload to upgrade to have the istio sidecar. Click it and go to the Containers section. You should be able to see istio-init and istio-proxy alongside your original workload. This means the Istio sidecar is enabled for the workload. Istio is doing all the wiring for the sidecar envoy. Now Istio can do all the features automatically if you enable them in the yaml.
|
||||
|
||||
|
||||
+1
-1
@@ -15,7 +15,7 @@ The Istio CNI plugin removes the need for each application pod to have a privile
|
||||
### 1. Configure the System Project Policy to allow Istio install
|
||||
|
||||
1. From the main menu of the **Dashboard**, select **Projects/Namespaces**.
|
||||
1. Find the **Project: System** project and select the **Ellipsis (...) > Edit**.
|
||||
1. Find the **Project: System** project and select the **⋮ > Edit**.
|
||||
1. Change the Pod Security Policy option to be unrestricted, then click Save.
|
||||
|
||||
|
||||
|
||||
+2
-2
@@ -10,7 +10,7 @@ This namespace setting will only affect new workloads in the namespace. Any pree
|
||||
> **Prerequisite:** To enable Istio in a namespace, the cluster must have Istio enabled.
|
||||
|
||||
1. In the Rancher UI, go to the cluster view. Click the **Projects/Namespaces** tab.
|
||||
1. Go to the namespace where you want to enable the Istio sidecar auto injection and click the **Ellipsis (...).**
|
||||
1. Go to the namespace where you want to enable the Istio sidecar auto injection and click the **⋮.**
|
||||
1. Click **Edit.**
|
||||
1. In the **Istio sidecar auto injection** section, click **Enable.**
|
||||
1. Click **Save.**
|
||||
@@ -33,7 +33,7 @@ To add the annotation to a workload,
|
||||
|
||||
1. From the **Global** view, open the project that has the workload that should not have the sidecar.
|
||||
1. Click **Resources > Workloads.**
|
||||
1. Go to the workload that should not have the sidecar and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the workload that should not have the sidecar and click **⋮ > Edit.**
|
||||
1. Click **Show Advanced Options.** Then expand the **Labels & Annotations** section.
|
||||
1. Click **Add Annotation.**
|
||||
1. In the **Key** field, enter `sidecar.istio.io/inject`.
|
||||
|
||||
@@ -14,7 +14,7 @@ In larger deployments, it is strongly advised that Istio's infrastructure be pla
|
||||
First, add a label to the node where Istio components should be deployed. This label can have any key-value pair. For this example, we will use the key `istio` and the value `enabled`.
|
||||
|
||||
1. From the cluster view, go to the **Nodes** tab.
|
||||
1. Go to a worker node that will host the Istio components and click **Ellipsis (...) > Edit.**
|
||||
1. Go to a worker node that will host the Istio components and click **⋮ > Edit.**
|
||||
1. Expand the **Labels & Annotations** section.
|
||||
1. Click **Add Label.**
|
||||
1. In the fields that appear, enter `istio` for the key and `enabled` for the value.
|
||||
|
||||
@@ -91,7 +91,7 @@ The detail view of each constraint lists information about the resource that vio
|
||||
|
||||
1. Navigate to the cluster's Dashboard view
|
||||
1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper.**
|
||||
1. Click the **Vertical Ellipsis (...) > Disable**.
|
||||
1. Click the **⋮ > Disable**.
|
||||
|
||||
**Result:** Upon disabling OPA Gatekeeper, all constraint templates and constraints will also be deleted.
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ The cluster cannot be downgraded to a previous Kubernetes version.
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) and [imported K3s Kubernetes clusters.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
> - Before upgrading Kubernetes, [back up your cluster.]({{<baseurl>}}/rancher/v2.x/en/backups)
|
||||
|
||||
1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **Vertical Ellipsis (...) > Edit**.
|
||||
1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **⋮ > Edit**.
|
||||
|
||||
1. Expand **Cluster Options**.
|
||||
|
||||
@@ -107,7 +107,7 @@ By default, the maximum number of unavailable worker is defined as 10 percent of
|
||||
To change the default number or percentage of worker nodes,
|
||||
|
||||
1. Go to the cluster view in the Rancher UI.
|
||||
1. Click **Ellipsis (...) > Edit.**
|
||||
1. Click **⋮ > Edit.**
|
||||
1. In the **Advanced Options** section, go to the **Maxiumum Worker Nodes Unavailable** field. Enter the percentage of worker nodes that can be upgraded in a batch. Optionally, select **Count** from the drop-down menu and enter the maximum unavailable worker nodes as an integer.
|
||||
1. Click **Save.**
|
||||
|
||||
@@ -120,7 +120,7 @@ By default, RKE [cordons](https://kubernetes.io/docs/concepts/architecture/nodes
|
||||
To enable draining each node during a cluster upgrade,
|
||||
|
||||
1. Go to the cluster view in the Rancher UI.
|
||||
1. Click **Ellipsis (...) > Edit.**
|
||||
1. Click **⋮ > Edit.**
|
||||
1. In the **Advanced Options** section, go to the **Drain nodes** field and click **Yes.**
|
||||
1. Choose a safe or aggressive drain option. For more information about each option, refer to [this section.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/nodes/#aggressive-and-safe-draining-options)
|
||||
1. Optionally, configure a grace period. The grace period is the timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. Pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If this value is negative, the default value specified in the pod will be used.
|
||||
|
||||
+1
-1
@@ -93,7 +93,7 @@ The following steps describe how to assign existing storage to a new workload th
|
||||
The following steps describe how to assign persistent storage to an existing workload:
|
||||
|
||||
1. From the **Project** view, go to the **Workloads** tab.
|
||||
1. Go to the workload that you want to add the persistent storage to. The workload type should be a stateful set. Click **Ellipsis (...) > Edit.**
|
||||
1. Go to the workload that you want to add the persistent storage to. The workload type should be a stateful set. Click **⋮ > Edit.**
|
||||
1. Expand the **Volumes** section and click **Add Volume > Use an existing persistent volume (claim).**.
|
||||
1. In the **Persistent Volume Claim** field, select the PVC that you created.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
|
||||
+1
-1
@@ -100,7 +100,7 @@ To attach the PVC to a new workload,
|
||||
To attach the PVC to an existing workload,
|
||||
|
||||
1. Go to the project that has the workload that will have the PVC attached.
|
||||
1. Go to the workload that will have persistent storage and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the workload that will have persistent storage and click **⋮ > Edit.**
|
||||
1. Expand the **Volumes** section and click **Add Volume > Add a New Persistent Volume (Claim).**
|
||||
1. In the **Persistent Volume Claim** section, select the newly created persistent volume claim that is attached to the storage class.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
|
||||
@@ -54,7 +54,7 @@ To access all node templates, an administrator will need to do the following:
|
||||
1. In the Rancher UI, click the user profile icon in the upper right corner.
|
||||
1. Click **Node Templates.**
|
||||
|
||||
**Result:** All node templates are listed and grouped by owner. The templates can be edited or cloned by clicking the **Ellipsis (...).**
|
||||
**Result:** All node templates are listed and grouped by owner. The templates can be edited or cloned by clicking the **⋮.**
|
||||
|
||||
# Node Pools
|
||||
|
||||
@@ -97,7 +97,7 @@ When you create the node pool, you can specify the amount of time in minutes tha
|
||||
You can also enable node auto-replace after the cluster is created with the following steps:
|
||||
|
||||
1. From the Global view, click the Clusters tab.
|
||||
1. Go to the cluster where you want to enable node auto-replace, click the vertical ellipsis **(…)**, and click **Edit.**
|
||||
1. Go to the cluster where you want to enable node auto-replace, click the vertical ⋮ **(…)**, and click **Edit.**
|
||||
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 the number of minutes that Rancher should wait for a node to respond before replacing the node.
|
||||
1. Click **Save.**
|
||||
|
||||
@@ -108,7 +108,7 @@ You can also enable node auto-replace after the cluster is created with the foll
|
||||
You can disable node auto-replace from the Rancher UI with the following steps:
|
||||
|
||||
1. From the Global view, click the Clusters tab.
|
||||
1. Go to the cluster where you want to enable node auto-replace, click the vertical ellipsis **(…)**, and click **Edit.**
|
||||
1. Go to the cluster where you want to enable node auto-replace, click the vertical ⋮ **(…)**, and click **Edit.**
|
||||
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.**
|
||||
|
||||
|
||||
+2
-2
@@ -193,7 +193,7 @@ After the initial provisioning of your custom cluster, your cluster only has a s
|
||||
|
||||
1. From the **Global** view, click **Clusters.**
|
||||
|
||||
1. Go to the custom cluster that you created and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the custom cluster that you created and click **⋮ > Edit.**
|
||||
|
||||
1. Scroll down to **Node Operating System**. Choose **Linux**.
|
||||
|
||||
@@ -221,7 +221,7 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin
|
||||
|
||||
1. From the **Global** view, click **Clusters.**
|
||||
|
||||
1. Go to the custom cluster that you created and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the custom cluster that you created and click **⋮ > Edit.**
|
||||
|
||||
1. Scroll down to **Node Operating System**. Choose **Windows**. Note: You will see that the **worker** role is the only available role.
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ If an imported cluster is deleted from the Rancher UI, the cluster is detached f
|
||||
To detach the cluster,
|
||||
|
||||
1. From the **Global** view in Rancher, go to the **Clusters** tab.
|
||||
2. Go to the imported cluster that should be detached from Rancher and click **Ellipsis (...) > Delete.**
|
||||
2. Go to the imported cluster that should be detached from Rancher and click **⋮ > Delete.**
|
||||
3. Click **Delete.**
|
||||
|
||||
**Result:** The imported cluster is detached from Rancher and functions normally outside of Rancher.
|
||||
|
||||
@@ -81,7 +81,7 @@ We follow the validated Docker versions for upstream Kubernetes releases. The va
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ellipsis button at the end of the row, and choose **Download Keys** as shown in the picture below.
|
||||
SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ⋮ button at the end of the row, and choose **Download Keys** as shown in the picture below.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -70,7 +70,7 @@ kubectl -n cattle-system logs -f rancher-84d886bdbb-s4s69 rancher-audit-log
|
||||
|
||||

|
||||
|
||||
1. Pick one of the `rancher` pods and select **Ellipsis (...) > View Logs**.
|
||||
1. Pick one of the `rancher` pods and select **⋮ > View Logs**.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -119,7 +119,7 @@ _Available as of Rancher v2.3.3_
|
||||
|
||||
1. Go to the **Global** view and click **Settings.**
|
||||
1. Click the **Feature Flags** tab. You will see a list of experimental features.
|
||||
1. To enable a feature, go to the disabled feature you want to enable and click **Ellipsis (...) > Activate.**
|
||||
1. To enable a feature, go to the disabled feature you want to enable and click **⋮ > Activate.**
|
||||
|
||||
**Result:** The feature is enabled.
|
||||
|
||||
@@ -127,7 +127,7 @@ _Available as of Rancher v2.3.3_
|
||||
|
||||
1. Go to the **Global** view and click **Settings.**
|
||||
1. Click the **Feature Flags** tab. You will see a list of experimental features.
|
||||
1. To disable a feature, go to the enabled feature you want to disable and click **Ellipsis (...) > Deactivate.**
|
||||
1. To disable a feature, go to the enabled feature you want to disable and click **⋮ > Deactivate.**
|
||||
|
||||
**Result:** The feature is disabled.
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ In the catalog management page in the Rancher UI, follow these steps:
|
||||
|
||||
1. Click **Tools > Catalogs.**
|
||||
|
||||
1. The system chart is displayed under the name `system-library`. To edit the configuration of the system chart, click **Ellipsis (...) > Edit.**
|
||||
1. The system chart is displayed under the name `system-library`. To edit the configuration of the system chart, click **⋮ > Edit.**
|
||||
|
||||
1. In the **Catalog URL** field, enter the location of the Git mirror of the `system-charts` repository.
|
||||
|
||||
|
||||
+1
-1
@@ -19,7 +19,7 @@ Be sure that your Kubernetes cluster services are running with these flags at mi
|
||||
- `horizontal-pod-autoscaler-upscale-delay: "3m0s"`
|
||||
- `horizontal-pod-autoscaler-sync-period: "30s"`
|
||||
|
||||
For an RKE Kubernetes cluster definition, add this snippet in the `services` section. To add this snippet using the Rancher v2.0 UI, open the **Clusters** view and select **Ellipsis (...) > Edit** for the cluster in which you want to use HPA. Then, from **Cluster Options**, click **Edit as YAML**. Add the following snippet to the `services` section:
|
||||
For an RKE Kubernetes cluster definition, add this snippet in the `services` section. To add this snippet using the Rancher v2.0 UI, open the **Clusters** view and select **⋮ > Edit** for the cluster in which you want to use HPA. Then, from **Cluster Options**, click **Edit as YAML**. Add the following snippet to the `services` section:
|
||||
|
||||
```
|
||||
services:
|
||||
|
||||
+1
-1
@@ -48,7 +48,7 @@ If you want to create HPAs that scale based on other metrics than CPU and memory
|
||||
|
||||
1. Find the HPA which you would like to delete.
|
||||
|
||||
1. Click **Ellipsis (...) > Delete**.
|
||||
1. Click **⋮ > Delete**.
|
||||
|
||||
1. Click **Delete** to confirm.
|
||||
|
||||
|
||||
@@ -205,8 +205,8 @@ Now that repositories are added to your project, you can start configuring the p
|
||||
|
||||
1. Configure the pipeline through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`. Pipeline configuration is split into stages and steps. Stages must fully complete before moving onto the next stage, but steps in a stage run concurrently. For each stage, you can add different step types. Note: As you build out each step, there are different advanced options based on the step type. Advanced options include trigger rules, environment variables, and secrets. For more information on configuring the pipeline through the UI or the YAML file, refer to the [pipeline configuration reference.]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/pipelines/config)
|
||||
|
||||
* If you are going to use the UI, select the vertical **Ellipsis (...) > Edit Config** to configure the pipeline using the UI. After the pipeline is configured, you must view the YAML file and push it to the repository.
|
||||
* If you are going to use the YAML file, select the vertical **Ellipsis (...) > View/Edit YAML** to configure the pipeline. If you choose to use a YAML file, you need to push it to the repository after any changes in order for it to be updated in the repository. When editing the pipeline configuration, it takes a few moments for Rancher to check for an existing pipeline configuration.
|
||||
* If you are going to use the UI, select the vertical **⋮ > Edit Config** to configure the pipeline using the UI. After the pipeline is configured, you must view the YAML file and push it to the repository.
|
||||
* If you are going to use the YAML file, select the vertical **⋮ > View/Edit YAML** to configure the pipeline. If you choose to use a YAML file, you need to push it to the repository after any changes in order for it to be updated in the repository. When editing the pipeline configuration, it takes a few moments for Rancher to check for an existing pipeline configuration.
|
||||
|
||||
1. Select which `branch` to use from the list of branches.
|
||||
|
||||
@@ -242,7 +242,7 @@ The configuration reference also covers how to configure:
|
||||
|
||||
# Running your Pipelines
|
||||
|
||||
Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions prior to v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **Ellipsis (...) > Run**.
|
||||
Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions prior to v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **⋮ > Run**.
|
||||
|
||||
During this initial run, your pipeline is tested, and the following pipeline components are deployed to your project as workloads in a new namespace dedicated to the pipeline:
|
||||
|
||||
@@ -270,7 +270,7 @@ Available Events:
|
||||
|
||||
1. 1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. Find the repository that you want to modify the event triggers. Select the vertical **Ellipsis (...) > Setting**.
|
||||
1. Find the repository that you want to modify the event triggers. Select the vertical **⋮ > Setting**.
|
||||
|
||||
1. Select which event triggers (**Push**, **Pull Request** or **Tag**) you want for the repository.
|
||||
|
||||
|
||||
@@ -393,7 +393,7 @@ This section covers the following topics:
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **⋮ > Edit Config**.
|
||||
|
||||
1. Click on **Show Advanced Options**.
|
||||
|
||||
@@ -411,7 +411,7 @@ This section covers the following topics:
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **⋮ > Edit Config**.
|
||||
|
||||
1. Find the **stage** that you want to manage trigger rules, click the **Edit** icon for that stage.
|
||||
|
||||
@@ -436,7 +436,7 @@ This section covers the following topics:
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**.
|
||||
1. From the repository for which you want to manage trigger rules, select the vertical **⋮ > Edit Config**.
|
||||
|
||||
1. Find the **step** that you want to manage trigger rules, click the **Edit** icon for that step.
|
||||
|
||||
@@ -491,7 +491,7 @@ When configuring a pipeline, certain [step types](#step-types) allow you to use
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**.
|
||||
1. From the pipeline for which you want to edit build triggers, select **⋮ > Edit Config**.
|
||||
|
||||
1. Within one of the stages, find the **step** that you want to add an environment variable for, click the **Edit** icon.
|
||||
|
||||
@@ -534,7 +534,7 @@ Create a secret in the same project as your pipeline, or explicitly in the names
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**.
|
||||
1. From the pipeline for which you want to edit build triggers, select **⋮ > Edit Config**.
|
||||
|
||||
1. Within one of the stages, find the **step** that you want to use a secret for, click the **Edit** icon.
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@ After enabling an example repository, review the pipeline to see how it is set u
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. Find the example repository, select the vertical **Ellipsis (...)**. There are two ways to view the pipeline:
|
||||
1. Find the example repository, select the vertical **⋮**. There are two ways to view the pipeline:
|
||||
* **Rancher UI**: Click on **Edit Config** to view the stages and steps of the pipeline.
|
||||
* **YAML**: Click on View/Edit YAML to view the `./rancher-pipeline.yml` file.
|
||||
|
||||
@@ -65,7 +65,7 @@ After enabling an example repository, run the pipeline to see how it works.
|
||||
|
||||
1. Click **Resources > Pipelines.** In versions prior to v2.3.0, click **Workloads > Pipelines.**
|
||||
|
||||
1. Find the example repository, select the vertical **Ellipsis (...) > Run**.
|
||||
1. Find the example repository, select the vertical **⋮ > Run**.
|
||||
|
||||
>**Note:** When you run a pipeline the first time, it takes a few minutes to pull relevant images and provision necessary pipeline components.
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
1. From the project that you're configuring a pipeline for, and click **Resources > Workloads.** In versions prior to v2.3.0, select the **Workloads** tab.
|
||||
|
||||
1. Find the `docker-registry` workload and select **Ellipsis (...) > Edit**.
|
||||
1. Find the `docker-registry` workload and select **⋮ > Edit**.
|
||||
|
||||
1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
|
||||
|
||||
@@ -59,7 +59,7 @@ This section assumes that you understand how persistent storage works in Kuberne
|
||||
|
||||
### B. Configuring Persistent Data for Minio
|
||||
|
||||
1. From the project view, click **Resources > Workloads.** (In versions prior to v2.3.0, click the **Workloads** tab.) Find the `minio` workload and select **Ellipsis (...) > Edit**.
|
||||
1. From the project view, click **Resources > Workloads.** (In versions prior to v2.3.0, click the **Workloads** tab.) Find the `minio` workload and select **⋮ > Edit**.
|
||||
|
||||
1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section:
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ A _sidecar_ is a container that extends or enhances the main container in a pod.
|
||||
|
||||
1. Click **Resources > Workloads.** In versions prior to v2.3.0, select the **Workloads** tab.
|
||||
|
||||
1. Find the workload that you want to extend. Select **Ellipsis icon (...) > Add a Sidecar**.
|
||||
1. Find the workload that you want to extend. Select **⋮ icon (...) > Add a Sidecar**.
|
||||
|
||||
1. Enter a **Name** for the sidecar.
|
||||
|
||||
@@ -30,7 +30,7 @@ A _sidecar_ is a container that extends or enhances the main container in a pod.
|
||||
|
||||
1. Click **Launch**.
|
||||
|
||||
**Result:** The sidecar is deployed according to your parameters. Following its deployment, you can view the sidecar by selecting **Ellipsis icon (...) > Edit** for the main deployment.
|
||||
**Result:** The sidecar is deployed according to your parameters. Following its deployment, you can view the sidecar by selecting **⋮ icon (...) > Edit** for the main deployment.
|
||||
|
||||
## Related Links
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ Sometimes there is a need to rollback to the previous version of the application
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to rollback.
|
||||
|
||||
1. Find the workload that you want to rollback and select **Vertical Ellipsis (... ) > Rollback**.
|
||||
1. Find the workload that you want to rollback and select **Vertical ⋮ (... ) > Rollback**.
|
||||
|
||||
1. Choose the revision that you want to roll back to. Click **Rollback**.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ When a new version of an application image is released on Docker Hub, you can up
|
||||
|
||||
1. From the **Global** view, open the project running the workload you want to upgrade.
|
||||
|
||||
1. Find the workload that you want to upgrade and select **Vertical Ellipsis (... ) > Edit**.
|
||||
1. Find the workload that you want to upgrade and select **Vertical ⋮ (... ) > Edit**.
|
||||
|
||||
1. Update the **Docker Image** to the updated version of the application image on Docker Hub.
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ You can always assign a pod security policy (PSP) to an existing project if you
|
||||
|
||||
1. From the **Global** view, find the cluster containing the project you want to apply a PSP to.
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
1. Find the project that you want to add a PSP to. From that project, select **Vertical Ellipsis (...) > Edit**.
|
||||
1. Find the project that you want to add a PSP to. From that project, select **⋮ > Edit**.
|
||||
1. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project.
|
||||
Assigning a PSP to a project will:
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ Edit [resource quotas]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/projects-and
|
||||
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
1. Find the project that you want to add a resource quota to. From that project, select **Ellipsis (...) > Edit**.
|
||||
1. Find the project that you want to add a resource quota to. From that project, select **⋮ > Edit**.
|
||||
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ Edit [container default resource limit]({{<baseurl>}}/rancher/v2.x/en/k8s-in-ran
|
||||
|
||||
1. From the **Global** view, open the cluster containing the project to which you want to edit the container default resource limit.
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
1. Find the project that you want to edit the container default resource limit. From that project, select **Ellipsis (...) > Edit**.
|
||||
1. Find the project that you want to edit the container default resource limit. From that project, select **⋮ > Edit**.
|
||||
1. Expand **Container Default Resource Limit** and edit the values.
|
||||
|
||||
### Resource Limit Propagation
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ If there is a [resource quota]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/proj
|
||||
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**.
|
||||
1. Find the namespace for which you want to edit the resource quota. Select **⋮ > Edit**.
|
||||
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits.
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ To schedule scans for an existing cluster:
|
||||
|
||||
1. Go to the cluster view in Rancher.
|
||||
1. Click **Tools > CIS Scans.**
|
||||
1. Click **Add Schedule.** This takes you to the section of the cluster editing page that is applicable to configuring a schedule for CIS scans. (This section can also be reached by going to the cluster view, clicking **Ellipsis (...) > Edit,** and going to the **Advanced Options.**)
|
||||
1. Click **Add Schedule.** This takes you to the section of the cluster editing page that is applicable to configuring a schedule for CIS scans. (This section can also be reached by going to the cluster view, clicking **⋮ > Edit,** and going to the **Advanced Options.**)
|
||||
1. In the **CIS Scan Enabled** field, click **Yes.**
|
||||
1. In the **CIS Scan Profile** field, choose a **Permissive** or **Hardened** profile. The corresponding CIS Benchmark version is included in the profile name. Note: Any skipped tests [defined in a separate ConfigMap](#skipping-tests) will be skipped regardless of whether a **Permissive** or **Hardened** profile is selected. When selecting the the permissive profile, you should see which tests were skipped by Rancher (tests that are skipped by default for RKE clusters) and which tests were skipped by a Rancher user. In the hardened test profile, the only skipped tests will be skipped by users.
|
||||
1. In the **CIS Scan Interval (cron)** job, enter a [cron expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) to define how often the cluster will be scanned.
|
||||
@@ -216,8 +216,8 @@ To activate an existing alert for a CIS scan result,
|
||||
|
||||
1. From the cluster view in Rancher, click **Tools > Alerts.**
|
||||
1. Go to the section called **A set of alerts for cluster scans.**
|
||||
1. Go to the alert you want to activate and click **Ellipsis (...) > Activate.**
|
||||
1. Go to the alert rule group **A set of alerts for cluster scans** and click **Ellipsis (...) > Edit.**
|
||||
1. Go to the alert you want to activate and click **⋮ > Activate.**
|
||||
1. Go to the alert rule group **A set of alerts for cluster scans** and click **⋮ > Edit.**
|
||||
1. Scroll down to the **Alert** section. In the **To** field, select the notifier that you would like to use for sending alert notifications.
|
||||
1. Optional: To limit the frequency of the notifications, click on **Show advanced options** and configure the time interval of the alerts.
|
||||
1. Click **Save.**
|
||||
@@ -242,12 +242,12 @@ For more information about alerts, refer to [this page.]({{<baseurl>}}/rancher/v
|
||||
|
||||
1. From the cluster view in Rancher, click **Tools > CIS Scans.**
|
||||
1. Go to the report that should be deleted.
|
||||
1. Click the **Ellipsis (...) > Delete.**
|
||||
1. Click the **⋮ > Delete.**
|
||||
1. Click **Delete.**
|
||||
|
||||
# Downloading a Report
|
||||
|
||||
1. From the cluster view in Rancher, click **Tools > CIS Scans.**
|
||||
1. Go to the report that you want to download. Click **Ellipsis (...) > Download.**
|
||||
1. Go to the report that you want to download. Click **⋮ > Download.**
|
||||
|
||||
**Result:** The report is downloaded in CSV format. For more information on each columns, refer to the [section about the generated report.](#about-the-generated-report)
|
||||
|
||||
@@ -34,7 +34,7 @@ All cloud credentials are bound to the user profile of who created it. They **ca
|
||||
When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.
|
||||
|
||||
1. From your user settings, select **User Avatar > Cloud Credentials**.
|
||||
1. Choose the cloud credential you want to edit and click the **Vertical Ellipsis (...) > Edit**.
|
||||
1. Choose the cloud credential you want to edit and click the **⋮ > Edit**.
|
||||
1. Update the credential information and click **Save**.
|
||||
|
||||
**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/).
|
||||
@@ -46,6 +46,6 @@ In order to delete cloud credentials, there must not be any node template associ
|
||||
1. From your user settings, select **User Avatar > Cloud Credentials**.
|
||||
1. You can either individually delete a cloud credential or bulk delete.
|
||||
|
||||
- To individually delete one, choose the cloud credential you want to edit and click the **Vertical Ellipsis (...) > Delete**.
|
||||
- To individually delete one, choose the cloud credential you want to edit and click the **⋮ > Delete**.
|
||||
- To bulk delete cloud credentials, select one or more cloud credentials from the list. Click **Delete**.
|
||||
1. Confirm that you want to delete these cloud credentials.
|
||||
|
||||
@@ -21,7 +21,7 @@ When you create a node template, it is bound to your user profile. Node template
|
||||
## Updating a Node Template
|
||||
|
||||
1. From your user settings, select **User Avatar > Node Templates**.
|
||||
1. Choose the node template that you want to edit and click the **Vertical Ellipsis (...) > Edit**.
|
||||
1. Choose the node template that you want to edit and click the **⋮ > Edit**.
|
||||
|
||||
> **Note:** As of v2.2.0, the default `active` [node drivers]({{<baseurl>}}/rancher/v2.x/en/admin-settings/drivers/node-drivers/) and any node driver, that has fields marked as `password`, are required to use [cloud credentials]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#cloud-credentials). If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.
|
||||
|
||||
@@ -34,7 +34,7 @@ When you create a node template, it is bound to your user profile. Node template
|
||||
When creating new node templates from your user settings, you can clone an existing template and quickly update its settings rather than creating a new one from scratch. Cloning templates saves you the hassle of re-entering access keys for the cloud provider.
|
||||
|
||||
1. From your user settings, select **User Avatar > Node Templates**.
|
||||
1. Find the template you want to clone. Then select **Ellipsis > Clone**.
|
||||
1. Find the template you want to clone. Then select **⋮ > Clone**.
|
||||
1. Complete the rest of the form.
|
||||
|
||||
**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools).
|
||||
|
||||
Reference in New Issue
Block a user