mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Merge remote-tracking branch 'upstream/main' into move-pages-for-subheaders-latest
This commit is contained in:
Billy Tat
@@ -82,3 +82,12 @@ You can use browser developer tools to capture how the Rancher API is called. Fo
|
||||
1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`.
|
||||
1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.**
|
||||
1. Paste the result into any text editor. You will be able to see the POST request, including the URL it was sent to, all of the headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: The request should be stored in a safe place because it contains credentials.
|
||||
|
||||
### Enable View in API
|
||||
|
||||
You can also view captured Rancher API calls for your respective clusters and resources. This feature is not enabled by default. To enable it:
|
||||
|
||||
1. Click on your **User Tile** in the top right corner of the UI and select **Preferences** from the dropdown menu.
|
||||
2. Under the **Advanced Features** section, click **Enable "View in API"**
|
||||
|
||||
Once checked, the **View in API** link will now appear under the **⋮** sub-menu on resource pages in the UI.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Examples
|
||||
title: Backup and Restore Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+29
-1
@@ -13,7 +13,7 @@ This section covers the configuration options that are available in Rancher for
|
||||
You can configure the Kubernetes options one of two ways:
|
||||
|
||||
- [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
|
||||
- [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
|
||||
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
|
||||
|
||||
## Editing Clusters in the Rancher UI
|
||||
|
||||
@@ -231,6 +231,7 @@ spec:
|
||||
kubernetesVersion: v1.26.7+k3s1
|
||||
localClusterAuthEndpoint: {}
|
||||
rkeConfig:
|
||||
additionalManifest: ""
|
||||
chartValues: {}
|
||||
etcd:
|
||||
snapshotRetention: 5
|
||||
@@ -307,10 +308,37 @@ spec:
|
||||
```
|
||||
</details>
|
||||
|
||||
### additionalManifest
|
||||
|
||||
Specify additional manifests to deliver to the control plane nodes.
|
||||
|
||||
The value is a String, and will be placed at the path `/var/lib/rancher/k3s/server/manifests/rancher/addons.yaml` on target nodes.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
additionalManifest: |-
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: name-xxxx
|
||||
```
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
If you want to customize system charts, you should use the `chartValues` field as described below.
|
||||
|
||||
Alternatives, such as using a HelmChartConfig to customize the system charts via `additionalManifest`, can cause unexpected behavior, due to having multiple HelmChartConfigs for the same chart.
|
||||
|
||||
:::
|
||||
|
||||
### chartValues
|
||||
|
||||
Specify the values for the system charts installed by K3s.
|
||||
|
||||
For more information about how K3s manges packaged components, please refer to [K3s documentation](https://docs.k3s.io/installation/packaged-components).
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
|
||||
+34
-3
@@ -115,7 +115,7 @@ For more details on the different networking providers and how to configure them
|
||||
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
|
||||
###### Additional Configuration {#dual-stack-additional-config}
|
||||
###### Dual-stack Additional Configuration
|
||||
|
||||
When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
|
||||
|
||||
@@ -191,7 +191,7 @@ IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
|
||||
##### Service CIDR
|
||||
|
||||
@@ -201,7 +201,7 @@ IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
|
||||
|
||||
##### Cluster DNS
|
||||
|
||||
@@ -280,6 +280,7 @@ spec:
|
||||
kubernetesVersion: v1.25.12+rke2r1
|
||||
localClusterAuthEndpoint: {}
|
||||
rkeConfig:
|
||||
additionalManifest: ""
|
||||
chartValues:
|
||||
rke2-calico: {}
|
||||
etcd:
|
||||
@@ -337,10 +338,37 @@ spec:
|
||||
```
|
||||
</details>
|
||||
|
||||
### additionalManifest
|
||||
|
||||
Specify additional manifests to deliver to the control plane nodes.
|
||||
|
||||
The value is a String, and will be placed at the path `/var/lib/rancher/rke2/server/manifests/rancher/addons.yaml` on target nodes.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
additionalManifest: |-
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: name-xxxx
|
||||
```
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
If you want to customize system charts, you should use the `chartValues` field as described below.
|
||||
|
||||
Alternatives, such as using a HelmChartConfig to customize the system charts via `additionalManifest`, can cause unexpected behavior, due to having multiple HelmChartConfigs for the same chart.
|
||||
|
||||
:::
|
||||
|
||||
### chartValues
|
||||
|
||||
Specify the values for the system charts installed by RKE2.
|
||||
|
||||
For more information about how RKE2 manges packaged components, please refer to [RKE2 documentation](https://docs.rke2.io/helm).
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
@@ -362,6 +390,9 @@ machineGlobalConfig:
|
||||
- key2=value2
|
||||
```
|
||||
|
||||
There are some configuration options that can't be changed when provisioning via Rancher:
|
||||
- data-dir (folder to hold state), which defaults to `/var/lib/rancher/rke2`.
|
||||
|
||||
To make it easier to put files on nodes beforehand, Rancher expects the following values to be included in the configuration, while RKE2 expects the values to be entered as file paths:
|
||||
- audit-policy-file
|
||||
- cloud-provider-config
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Syncing
|
||||
title: Syncing Hosted Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Examples
|
||||
title: Monitoring V2 Configuration Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
@@ -8,20 +8,20 @@ title: Examples
|
||||
|
||||
### ServiceMonitor
|
||||
|
||||
An example ServiceMonitor custom resource can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml)
|
||||
See the official prometheus-operator GitHub repo for an example [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) YAML.
|
||||
|
||||
### PodMonitor
|
||||
|
||||
An example PodMonitor can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/example-app-pod-monitor.yaml) An example Prometheus resource that refers to it can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/prometheus-pod-monitor.yaml)
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.
|
||||
|
||||
### PrometheusRule
|
||||
|
||||
For users who are familiar with Prometheus, a PrometheusRule contains the alerting and recording rules that you would normally place in a [Prometheus rule file](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/).
|
||||
A PrometheusRule contains the alerting and recording rules that you would usually place in a [Prometheus rule file](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/).
|
||||
|
||||
For a more fine-grained application of PrometheusRules within your cluster, the ruleSelector field on a Prometheus resource allows you to select which PrometheusRules should be loaded onto Prometheus based on the labels attached to the PrometheusRules resources.
|
||||
For a more fine-grained approach, the `ruleSelector` field on a Prometheus resource can select which PrometheusRules should be loaded onto Prometheus, based on the labels attached to the PrometheusRules resources.
|
||||
|
||||
An example PrometheusRule is on [this page.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/alerting.md)
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/alerting/) for an example PrometheusRule.
|
||||
|
||||
### Alertmanager Config
|
||||
|
||||
For an example configuration, refer to [this section](./receivers.md#example-alertmanager-configs).
|
||||
See the Rancher docs page on Receivers for an example [Alertmanager config](./receivers.md#example-alertmanager-configs).
|
||||
|
||||
@@ -16,7 +16,7 @@ The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/ra
|
||||
|
||||
:::note Requirement:
|
||||
|
||||
The rancher-selinux RPM was tested with CentOS 7 and 8.
|
||||
The rancher-selinux RPM was tested with CentOS 7, 8 and 9.
|
||||
|
||||
:::
|
||||
|
||||
@@ -49,6 +49,20 @@ gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
|
||||
In order to use the RPM repository, on a CentOS 9 or RHEL 9 system, run the following bash snippet:
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/9/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
|
||||
### 2. Installing the RPM
|
||||
|
||||
Install the RPM:
|
||||
@@ -61,10 +75,10 @@ yum -y install rancher-selinux
|
||||
|
||||
:::note Requirement:
|
||||
|
||||
Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
|
||||
Logging v2 was tested with SELinux on RHEL/CentOS 7, 8 and 9.
|
||||
|
||||
:::
|
||||
|
||||
Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM.
|
||||
|
||||
To configure the `rancher-logging` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the chart.
|
||||
To configure the `rancher-logging` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the chart.
|
||||
|
||||
Reference in New Issue
Block a user