public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-23 21:28:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updating tabs

Browse Source
This commit is contained in:
Jennifer Travinski
2022-07-14 14:40:53 -04:00
parent e0b784ad21
commit d7eb4f8378
122 changed files with 876 additions and 876 deletions
Download Patch File Download Diff File Expand all files Collapse all files
versioned_docs/version-2.5/v2.5/en/cluster-admin/cleaning-cluster-nodes/cleaning-cluster-nodes.md
+6 -6
View File
@@ -58,8 +58,8 @@ For registered clusters, the process for removing Rancher is a little different.
After the registered cluster is detached from Rancher, the cluster's workloads will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
{{% tabs %}}
{{% tab "By UI / API" %}}
<Tabs>
<TabItem label="By UI / API">
>**Warning:** This process will remove data from your cluster. Make sure you have created a backup of files you want to keep before executing the command, as data will be lost.
After you initiate the removal of a registered cluster using the Rancher UI (or API), the following events occur.
@@ -72,8 +72,8 @@ After you initiate the removal of a registered cluster using the Rancher UI (or
**Result:** All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
{{% /tab %}}
{{% tab "By Script" %}}
</TabItem>
<TabItem label="By Script">
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
>**Prerequisite:**
@@ -103,8 +103,8 @@ Rather than cleaning registered cluster nodes using the Rancher UI, you can run
**Result:** The script runs. All components listed for registered clusters in [What Gets Removed?](#what-gets-removed) are deleted.
{{% /tab %}}
{{% /tabs %}}
</TabItem>
</Tabs>
### Windows Nodes
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
+14 -14
View File
@@ -4,8 +4,8 @@ shortTitle: EKS Cluster Configuration
weight: 2
---
{{% tabs %}}
{{% tab "Rancher v2.5.6+" %}}
<Tabs>
<TabItem label="Rancher v2.5.6+">
### Account Access
@@ -152,8 +152,8 @@ The following settings are also configurable. All of these except for the "Node
| Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |
{{% /tab %}}
{{% tab "Rancher v2.5.0-v2.5.5" %}}
</TabItem>
<TabItem label="Rancher v2.5.0-v2.5.5">
### Changes in Rancher v2.5
@@ -283,8 +283,8 @@ Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/u
| Maximum ASG Size | The maximum number of instances. This setting won't take effect until the [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) is installed. |
| Minimum ASG Size | The minimum number of instances. This setting won't take effect until the [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html) is installed. |
{{% /tab %}}
{{% tab "Rancher prior to v2.5" %}}
</TabItem>
<TabItem label="Rancher prior to v2.5">
### Account Access
@@ -390,15 +390,15 @@ Custom AMI Override | If you want to use a custom [Amazon Machine Image](https:/
Desired ASG Size | The number of instances that your cluster will provision.
User Data | Custom commands can to be passed to perform automated configuration tasks **WARNING: Modifying this may cause your nodes to be unable to join the cluster.** _Note: Available as of v2.2.0_
{{% /tab %}}
{{% /tabs %}}
</TabItem>
</Tabs>
### Configuring the Refresh Interval
{{% tabs %}}
{{% tab "Rancher v2.5.8+" %}}
<Tabs>
<TabItem label="Rancher v2.5.8+">
The `eks-refresh-cron` setting is deprecated. It has been migrated to the `eks-refresh` setting, which is an integer representing seconds.
@@ -410,12 +410,12 @@ If the `eks-refresh-cron` setting was previously set, the migration will happen
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.
{{% /tab %}}
{{% tab "Before v2.5.8" %}}
</TabItem>
<TabItem label="Before v2.5.8">
It is possible to change the refresh interval through the setting `eks-refresh-cron`. This setting accepts values in the Cron format. The default is `*/5 * * * *`.
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.
{{% /tab %}}
{{% /tabs %}}
</TabItem>
</Tabs>
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/gke-config-reference.md
+6 -6
View File
@@ -4,8 +4,8 @@ shortTitle: GKE Cluster Configuration
weight: 3
---
{{% tabs %}}
{{% tab "Rancher v2.5.8+" %}}
<Tabs>
<TabItem label="Rancher v2.5.8+">
# Changes in v2.5.8
@@ -302,8 +302,8 @@ The syncing interval can be changed by running `kubectl edit setting gke-refresh
The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for GCP APIs.
{{% /tab %}}
{{% tab "Rancher before v2.5.8" %}}
</TabItem>
<TabItem label="Rancher before v2.5.8">
# Labels & Annotations
@@ -449,5 +449,5 @@ Access scopes are the legacy method of specifying permissions for your nodes.
- **Set access for each API:** Alternatively, you can choose to set specific scopes that permit access to the particular API methods that the service will call.
For more information, see the [section about enabling service accounts for a VM.](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)
{{% /tab %}}
{{% /tabs %}}
</TabItem>
</Tabs>