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

Fix tabs: add import statements, specify value, spacing

Browse Source
This commit is contained in:
Billy Tat
2022-07-14 20:14:23 -07:00
parent afbabffdeb
commit c55f4b2931
122 changed files with 1162 additions and 712 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
+8 -2
View File
@@ -7,6 +7,9 @@ aliases:
- /rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
When you use Rancher to install Kubernetes on new nodes in an infrastructure provider, resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created.
@@ -59,7 +62,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>
<TabItem label="By UI / API">
<TabItem value="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 +76,10 @@ 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.
</TabItem>
<TabItem label="By Script">
<TabItem value="By Script">
Rather than cleaning registered cluster nodes using the Rancher UI, you can run a script instead.
>**Prerequisite:**
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
+11 -12
View File
@@ -4,8 +4,11 @@ shortTitle: EKS Cluster Configuration
weight: 2
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.6+">
<TabItem value="Rancher v2.5.6+">
### Account Access
@@ -101,7 +104,7 @@ For more information on EKS control plane logging, refer to the official [docume
<a id="managed-node-groups-2-5-6"></a>
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)
@@ -151,9 +154,8 @@ The following settings are also configurable. All of these except for the "Node
| Labels | Kubernetes labels applied to the nodes in the managed node group. Note: Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) |
| Tags | These are tags for the managed node group and do not propagate to any of the associated resources. |
</TabItem>
<TabItem label="Rancher v2.5.0-v2.5.5">
<TabItem value="Rancher v2.5.0-v2.5.5">
### Changes in Rancher v2.5
@@ -271,7 +273,7 @@ For more information on EKS control plane logging, refer to the official [docume
<a id="managed-node-groups-2-5"></a>
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
Amazon EKS managed node groups automate the provisioning and lifecycle management of nodes (Amazon EC2 instances) for Amazon EKS Kubernetes clusters.
For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)
@@ -284,8 +286,7 @@ Amazon will use the [EKS-optimized AMI](https://docs.aws.amazon.com/eks/latest/u
| 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. |
</TabItem>
<TabItem label="Rancher prior to v2.5">
<TabItem value="Rancher prior to v2.5">
### Account Access
@@ -393,12 +394,10 @@ User Data | Custom commands can to be passed to perform automated configuration
</TabItem>
</Tabs>
### Configuring the Refresh Interval
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="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.
@@ -411,9 +410,9 @@ 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.
</TabItem>
<TabItem label="Before v2.5.8">
<TabItem value="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 * * * *`.
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.
versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/gke-config-reference.md
+9 -6
View File
@@ -4,8 +4,11 @@ shortTitle: GKE Cluster Configuration
weight: 3
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
<Tabs>
<TabItem label="Rancher v2.5.8+">
<TabItem value="Rancher v2.5.8+">
# Changes in v2.5.8
@@ -303,8 +306,7 @@ 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.
</TabItem>
<TabItem label="Rancher before v2.5.8">
<TabItem value="Rancher before v2.5.8">
# Labels & Annotations
@@ -315,7 +317,7 @@ Invalid labels can prevent upgrades or can prevent Rancher from starting. For de
# Kubernetes Options
### Location Type
Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
For [regional clusters,](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters) you can select a region. For more information about available regions and zones, refer to [this section](https://cloud.google.com/compute/docs/regions-zones#available). The first part of each zone name is the name of the region.
@@ -327,7 +329,7 @@ Each region in Compute engine contains a number of zones.
For more information about available regions and zones, refer to [these docs.](https://cloud.google.com/compute/docs/regions-zones#available)
### Additional Zones
For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)
For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)
### Kubernetes Version
Link to list of GKE kubernetes versions
@@ -405,7 +407,7 @@ Standard persistent disks are backed by standard hard disk drives (HDD), while S
The size in GB of the [root disk.](https://cloud.google.com/compute/docs/disks)
### Local SSD disks
Configure each node's local SSD disk storage in GB.
Configure each node's local SSD disk storage in GB.
Local SSDs are physically attached to the server that hosts your VM instance. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks. The data that you store on a local SSD persists only until the instance is stopped or deleted. For more information, see [this section.](https://cloud.google.com/compute/docs/disks#localssds)
@@ -449,5 +451,6 @@ 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)
</TabItem>
</Tabs>