mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Change tab indentations to space indentations
This commit is contained in:
@@ -84,22 +84,22 @@ Configuration of external authentication affects how principal users are managed
|
||||
|
||||
1. Sign into Rancher as the local principal and complete configuration of external authentication.
|
||||
|
||||

|
||||

|
||||
|
||||
2. Rancher associates the external principal with the local principal. These two users share the local principal's user ID.
|
||||
|
||||

|
||||

|
||||
|
||||
3. After you complete configuration, Rancher automatically signs out the local principal.
|
||||
|
||||

|
||||

|
||||
|
||||
4. Then, Rancher automatically signs you back in as the external principal.
|
||||
|
||||

|
||||

|
||||
|
||||
5. Because the external principal and the local principal share an ID, no unique object for the external principal displays on the Users page.
|
||||
|
||||

|
||||

|
||||
|
||||
6. The external principal and the local principal share the same access rights.
|
||||
|
||||
@@ -12,17 +12,17 @@ import TabItem from '@theme/TabItem';
|
||||
|
||||
# Changes in v2.5.8
|
||||
|
||||
- We now support private GKE clusters. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters.md)
|
||||
- [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc) are now supported.
|
||||
- We now support more configuration options for Rancher managed GKE clusters:
|
||||
- Project
|
||||
- Network policy
|
||||
- Network policy config
|
||||
- Node pools and node configuration options:
|
||||
- More image types are available for the nodes
|
||||
- The maximum number of pods per node can be configured
|
||||
- Node pools can be added while configuring the GKE cluster
|
||||
- When provisioning a GKE cluster, you can now use reusable cloud credentials instead of using a service account token directly to create the cluster.
|
||||
- We now support private GKE clusters. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters.md)
|
||||
- [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc) are now supported.
|
||||
- We now support more configuration options for Rancher managed GKE clusters:
|
||||
- Project
|
||||
- Network policy
|
||||
- Network policy config
|
||||
- Node pools and node configuration options:
|
||||
- More image types are available for the nodes
|
||||
- The maximum number of pods per node can be configured
|
||||
- Node pools can be added while configuring the GKE cluster
|
||||
- When provisioning a GKE cluster, you can now use reusable cloud credentials instead of using a service account token directly to create the cluster.
|
||||
|
||||
# Cluster Location
|
||||
|
||||
|
||||
@@ -56,10 +56,10 @@ Clusters won't begin provisioning until all three node roles (worker, etcd and c
|
||||
|
||||
7. From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.](../reference-guides/kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters)
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>**Notes:**
|
||||
>
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section](use-windows-clusters.md).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
@@ -67,7 +67,7 @@ Clusters won't begin provisioning until all three node roles (worker, etcd and c
|
||||
|
||||
10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
>**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
|
||||
>**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
|
||||
|
||||
11. When you finish running the command(s) on your Linux host(s), click **Done**.
|
||||
|
||||
@@ -98,7 +98,7 @@ The following resources need to be tagged with a `ClusterID`:
|
||||
- **Subnet**: The subnet used for your cluster
|
||||
- **Security Group**: The security group used for your cluster.
|
||||
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
|
||||
>**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
|
||||
|
||||
The tag that should be used is:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user