public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 20:48:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Removing/updating RKE in adv user guide pages.

Browse Source 
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
2025-09-29 15:55:10 -07:00
parent a1d77d98a4
commit e52555e081
16 changed files with 24 additions and 292 deletions
Download Patch File Download Diff File Expand all files Collapse all files
versioned_docs/version-2.12/how-to-guides/advanced-user-guides/enable-api-audit-log-in-downstream-clusters.md
-59
View File
@@ -186,64 +186,5 @@ You can also use the directive `machineSelectorConfig` with proper machineLabelS
For more information about cluster configuration, refer to the [K3s cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) pages.
</TabItem>
<TabItem value="RKE1">
The audit log can be enabled and configured by editing the cluster with YAML.
When the audit log is enabled, RKE1 default values will be applied.
```yaml
#
# Rancher Config
#
rancher_kubernetes_engine_config:
services:
kube-api:
audit_log:
enabled: true
```
You can customize the audit log by using the configuration directive.
```yaml
#
# Rancher Config
#
rancher_kubernetes_engine_config:
services:
kube-api:
audit_log:
enabled: true
configuration:
max_age: 6
max_backup: 6
max_size: 110
path: /var/log/kube-audit/audit-log.json
format: json
policy:
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
```
For configuration details, refer to the official [RKE1 documentation](https://rke.docs.rancher.com/config-options/audit-log).
</TabItem>
</Tabs>
versioned_docs/version-2.12/how-to-guides/advanced-user-guides/enable-experimental-features/rancher-on-arm64.md
+2 -3
View File
@@ -27,8 +27,7 @@ The following options are available when using an ARM64 platform:
:::note
To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
version's release notes in the following two ways:
To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your version's release notes in the following two ways:
- Manually find your version using https://github.com/rancher/rancher/releases.
- Go directly to your version using the tag and the specific version number. If you plan to use v2.5.8, for example, you may navigate to https://github.com/rancher/rancher/releases/tag/v2.5.8.
@@ -41,7 +40,7 @@ version's release notes in the following two ways:
- Importing clusters that contain ARM64 based nodes
- Kubernetes cluster version must be 1.12 or higher
Please see [Cluster Options](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md) how to configure the cluster options.
Depending on your cluster provisioning refer to [RKE2 cluster configuration options](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) or [K3s cluster configuration options](../../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) for more information.
The following features are not tested:
versioned_docs/version-2.12/how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md
-8
View File
@@ -17,14 +17,6 @@ You can enable monitoring with or without SSL.
- Allow traffic on port 9796 for each of your nodes. Prometheus scrapes metrics from these ports.
- You may also need to allow traffic on port 10254 for each of your nodes, if [PushProx](../../../integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#pushprox) is disabled (`ingressNginx.enabled` set to `false`), or you've upgraded from a previous Rancher version that had v1 monitoring already installed.
- Make sure that your cluster fulfills the resource requirements. The cluster should have at least 1950Mi memory available, 2700m CPU, and 50Gi storage. See [Configuring Resource Limits and Requests](../../../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests) for a breakdown of the resource limits and requests.
- When you install monitoring on an RKE cluster that uses RancherOS or Flatcar Linux nodes, change the etcd node certificate directory to `/opt/rke/etc/kubernetes/ssl`.
- For clusters that have been provisioned with the RKE CLI and that have the address set to a hostname instead of an IP address, set `rkeEtcd.clients.useLocalhost` to `true` when you configure the Values during installation. For example:
```yaml
rkeEtcd:
clients:
useLocalhost: true
```
:::note
versioned_docs/version-2.12/how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md
+5 -5
View File
@@ -8,12 +8,12 @@ title: Tuning etcd for Large Installations
When Rancher is used to manage [a large infrastructure](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) it is recommended to increase the default keyspace for etcd from the default 2 GB. The maximum setting is 8 GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.
The etcd data set is automatically cleaned up on a five-minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.
## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB
## Example: This Snippet of the RKE2/K3s config.yaml file Increases the Keyspace Size to 5GB
```yaml
# RKE cluster.yml
# RKE2/K3s config.yaml
---
services:
etcd:
@@ -27,10 +27,10 @@ You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.
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.
To implement this solution in an RKE2/K3s 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.
```yaml
# RKE cluster.yml
# RKE2/K3s config.yaml
---
services:
etcd: