mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Sync content from rancher/docs
Start: cb708da8d Jul 7 2022 End: 09d646cfc Sep 2 2022
This commit is contained in:
+1
-1
@@ -24,7 +24,7 @@ services:
|
||||
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
|
||||
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
|
||||
|
||||
To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etcd/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
|
||||
|
||||
|
||||
+1
-1
@@ -80,7 +80,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl
|
||||
* [helm](https://helm.sh/docs/intro/install/)
|
||||
|
||||
```
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
|
||||
chmod +x get_helm.sh
|
||||
sudo ./get_helm.sh
|
||||
```
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
|
||||
3. **Optional:** Edit `config.yaml` to:
|
||||
|
||||
- Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`default_password`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`admin_password`)
|
||||
|
||||
4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
|
||||
|
||||
|
||||
@@ -13,8 +13,6 @@ Rancher was originally built to work with multiple orchestrators, and it include
|
||||
|
||||
Rancher can provision Kubernetes from a hosted provider, provision compute nodes and then install Kubernetes onto them, or import existing Kubernetes clusters running anywhere.
|
||||
|
||||
One Rancher server installation can manage thousands of Kubernetes clusters and thousands of nodes from the same user interface.
|
||||
|
||||
Rancher adds significant value on top of Kubernetes, first by centralizing authentication and role-based access control (RBAC) for all of the clusters, giving global admins the ability to control cluster access from one location.
|
||||
|
||||
It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes a pipeline engine to help you automatically deploy and upgrade workloads.
|
||||
|
||||
@@ -37,7 +37,7 @@ _**Available as of v2.4.6**_
|
||||
|
||||
Starting Rancher v2.4.6, admins can set a global TTL on Kubeconfig tokens. Once the token expires the kubectl command will require the user to authenticate to Rancher.
|
||||
|
||||
_**Note:**_:
|
||||
_**Note:**_
|
||||
|
||||
Existing kubeconfig tokens won't be updated with the new TTL. Admins can [delete old kubeconfig tokens](#deleting-tokens).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user