Convert h1 to h2 (2.0-2.4)

2026-09-25 12:38:05 +00:00 · 2022-10-28 18:48:50 -07:00
parent bb76e99d20
commit eaa89030f6
89 changed files with 377 additions and 354 deletions
@@ -7,7 +7,7 @@ There are two recommended deployment strategies. Each one has its own pros and c
 * [Hub and Spoke](#hub-and-spoke-strategy)
 * [Regional](#regional-strategy)

-# Hub and Spoke Strategy
+## Hub and Spoke Strategy
 ---

 In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run on a high-availability Kubernetes cluster, and there would be impact due to latencies.
@@ -25,7 +25,7 @@ In this deployment scenario, there is a single Rancher control plane managing Ku
 * Subject to network latencies.
 * If the control plane goes out, global provisioning of new services is unavailable until it is restored. However, each Kubernetes cluster can continue to be managed individually.

-# Regional Strategy
+## Regional Strategy
 ---
 In the regional deployment model a control plane is deployed in close proximity to the compute nodes.

@@ -12,30 +12,36 @@ Rancher allows you to set up numerous combinations of configurations. Some confi
 - [Class of Service and Kubernetes Clusters](#class-of-service-and-kubernetes-clusters)
 - [Network Security](#network-security)

-# Tips for Preventing and Handling Problems
+## Tips for Preventing and Handling Problems

 These tips can help you solve problems before they happen.

 ### Run Rancher on a Supported OS and Supported Docker Version
+
 Rancher is container-based and can potentially run on any Linux-based operating system. However, only operating systems listed in the [requirements documentation](../../pages-for-subheaders/installation-requirements.md) should be used for running Rancher, along with a supported version of Docker. These versions have been most thoroughly tested and can be properly supported by the Rancher Support team.

 ### Upgrade Your Kubernetes Version
+
 Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous three minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). After a new version is released, the third-oldest supported version reaches EOL (End of Life) status. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (every three months).

 Rancher’s SLAs are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target.

 ### Kill Pods Randomly During Testing
+
 Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment.

 ### Deploy Complicated Clusters with Terraform
+
 Rancher's "Add Cluster" UI is preferable for getting started with Kubernetes cluster orchestration or for simple use cases. However, for more complex or demanding use cases, it is recommended to use a CLI/API driven approach. [Terraform](https://www.terraform.io/) is recommended as the tooling to implement this. When you use Terraform with version control and a CI/CD environment, you can have high assurances of consistency and reliability when deploying Kubernetes clusters. This approach also gives you the most customization options.

 Rancher [maintains a Terraform provider](https://rancher.com/blog/2019/rancher-2-terraform-provider/) for working with Rancher 2.0 Kubernetes. It is called the [Rancher2 Provider.](https://www.terraform.io/docs/providers/rancher2/index.html)

 ### Upgrade Rancher in a Staging Environment
+
 All upgrades, both patch and feature upgrades, should be first tested on a staging environment before production is upgraded. The more closely the staging environment mirrors production, the higher chance your production upgrade will be successful.

 ### Renew Certificates Before they Expire
+
 Multiple people in your organization should set up calendar reminders for certificate renewal. Consider renewing the certificate two weeks to one month in advance. If you have multiple certificates to track, consider using [monitoring and alerting mechanisms](../rancher-cluster-tools.md) to track certificate expiration.

 Rancher-provisioned Kubernetes clusters will use certificates that expire in one year. Clusters provisioned by other means may have a longer or shorter expiration.
@@ -43,12 +49,15 @@ Rancher-provisioned Kubernetes clusters will use certificates that expire in one
 Certificates can be renewed for Rancher-provisioned clusters [through the Rancher user interface](../../how-to-guides/advanced-user-guides/manage-clusters/rotate-certificates.md).

 ### Enable Recurring Snapshots for Backing up and Restoring the Cluster
+
 Make sure etcd recurring snapshots are enabled. Extend the snapshot retention to a period of time that meets your business needs. In the event of a catastrophic failure or deletion of data, this may be your only recourse for recovery. For details about configuring snapshots, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or the [Rancher documentation on backups](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md).

 ### Provision Clusters with Rancher
+
 When possible, use Rancher to provision your Kubernetes cluster rather than importing a cluster. This will ensure the best compatibility and supportability.

 ### Use Stable and Supported Rancher Versions for Production
+
 Do not upgrade production environments to alpha, beta, release candidate (rc), or "latest" versions. These early releases are often not stable and may not have a future upgrade path.

 When installing or upgrading a non-production environment to an early release, anticipate problems such as features not working, data loss, outages, and inability to upgrade without a reinstall.
@@ -59,81 +68,103 @@ Keep in mind that Rancher does End of Life support for old versions, so you will

 For more detail on what happens during the Rancher product lifecycle, refer to the [Support Maintenance Terms](https://rancher.com/support-maintenance-terms/).

-# Network Topology
+## Network Topology
+
 These tips can help Rancher work more smoothly with your network.

 ### Use Low-latency Networks for Communication Within Clusters
+
 Kubernetes clusters are best served by low-latency networks. This is especially true for the control plane components and etcd, where lots of coordination and leader election traffic occurs. Networking between Rancher server and the Kubernetes clusters it manages are more tolerant of latency.

 ### Allow Rancher to Communicate Directly with Clusters
+
 Limit the use of proxies or load balancers between Rancher server and Kubernetes clusters. As Rancher is maintaining a long-lived web sockets connection, these intermediaries can interfere with the connection lifecycle as they often weren't configured with this use case in mind.

+## Tips for Scaling and Reliability

-# Tips for Scaling and Reliability
 These tips can help you scale your cluster more easily.

 ### Use One Kubernetes Role Per Host
+
 Separate the etcd, control plane, and worker roles onto different hosts. Don't assign multiple roles to the same host, such as a worker and control plane. This will give you maximum scalability.

 ### Run the Control Plane and etcd on Virtual Machines
+
 Run your etcd and control plane nodes on virtual machines where you can scale vCPU and memory easily if needed in the future.

 ### Use at Least Three etcd Nodes
+
 Provision 3 or 5 etcd nodes. Etcd requires a quorum to determine a leader by the majority of nodes, therefore it is not recommended to have clusters of even numbers. Three etcd nodes is generally sufficient for smaller clusters and five etcd nodes for large clusters.

 ### Use at Least Three Control Plane Nodes
+
 Provision three or more control plane nodes. Some control plane components, such as the `kube-apiserver`, run in [active-active](https://www.jscape.com/blog/active-active-vs-active-passive-high-availability-cluster) mode and will give you more scalability. Other components such as kube-scheduler and kube-controller run in active-passive mode (leader elect) and give you more fault tolerance.

 ### Monitor Your Cluster
+
 Closely monitor and scale your nodes as needed. You should [enable cluster monitoring](../../pages-for-subheaders/cluster-monitoring.md) and use the Prometheus metrics and Grafana visualization options as a starting point.

+## Tips for Security

-# Tips for Security
 Below are some basic tips for increasing security in Rancher. For more detailed information about securing your cluster, you can refer to these resources:

 - Rancher's [security documentation and Kubernetes cluster hardening guide](../../pages-for-subheaders/rancher-security.md)
 - [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)

 ### Update Rancher with Security Patches
+
 Keep your Rancher installation up to date with the latest patches. Patch updates have important software fixes and sometimes have security fixes. When patches with security fixes are released, customers with Rancher licenses are notified by e-mail. These updates are also posted on Rancher's [forum](https://forums.rancher.com/).

 ### Report Security Issues Directly to Rancher
+
 If you believe you have uncovered a security-related problem in Rancher, please communicate this immediately and discretely to the Rancher team (security@rancher.com). Posting security issues on public forums such as Twitter, Rancher Slack, GitHub, etc. can potentially compromise security for all Rancher customers. Reporting security issues discretely allows Rancher to assess and mitigate the problem. Security patches are typically given high priority and released as quickly as possible.

 ### Only Upgrade One Component at a Time
+
 In addition to Rancher software updates, closely monitor security fixes for related software, such as Docker, Linux, and any libraries used by your workloads. For production environments, try to avoid upgrading too many entities during a single maintenance window. Upgrading multiple components can make it difficult to root cause an issue in the event of a failure. As business requirements allow, upgrade one component at a time.

-# Tips for Multi-Tenant Clusters
+## Tips for Multi-Tenant Clusters

 ### Namespaces
+
 Each tenant should have their own unique namespaces within the cluster. This avoids naming conflicts and allows resources to be only visible to their owner through use of RBAC policy

 ### Project Isolation
+
 Use Rancher's Project Isolation to automatically generate Network Policy between Projects (sets of Namespaces). This further protects workloads from interference

 ### Resource Limits
+
 Enforce use of sane resource limit definitions for every deployment in your cluster. This not only protects the owners of the deployment, but the neighboring resources from other tenants as well. Remember, namespaces do not isolate at the node level, so over-consumption of resources on a node affects other namespace deployments. Admission controllers can be written to require resource limit definitions

 ### Resource Requirements
+
 Enforce use of resource requirement definitions for each deployment in your cluster. This enables the scheduler to appropriately schedule workloads. Otherwise you will eventually end up with over-provisioned nodes.

-# Class of Service and Kubernetes Clusters
+## Class of Service and Kubernetes Clusters
+
 A class of service describes the expectations around cluster uptime, durability, and duration of maintenance windows. Typically organizations group these characteristics into labels such as "dev" or "prod"

 ### Consider fault domains
+
 Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk.

 ### Upgrade risks
+
 Upgrades of Kubernetes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous.

 ### Resource Efficiency
+
 Clusters can be built with varying degrees of redundancy. In a class of service with low expectations for uptime, resources and cost can be conserved by building clusters without redundant Kubernetes control components. This approach may also free up more budget/resources to increase the redundancy at the production level

-# Network Security
+## Network Security
+
 In general, you can use network security best practices in your Rancher and Kubernetes clusters. Consider the following:

 ### Use a Firewall Between your Hosts and the Internet
+
 Firewalls should be used between your hosts and the Internet (or corporate Intranet). This could be enterprise firewall appliances in a datacenter or SDN constructs in the cloud, such as VPCs, security groups, ingress, and egress rules. Try to limit inbound access only to ports and IP addresses that require it. Outbound access can be shut off (air gap) if environment sensitive information that requires this restriction. If available, use firewalls with intrusion detection and DDoS prevention.

 ### Run Periodic Security Scans
+
 Run security and penetration scans on your environment periodically. Even with well design infrastructure, a poorly designed microservice could compromise the entire environment.
@@ -2,7 +2,7 @@
 title: kubectl Utility
 ---

-# kubectl
+## kubectl

 Interact with Rancher using kubectl.

@@ -338,7 +338,7 @@ The table below indicates what DNS provider is deployed by default. See [RKE doc
 | v2.2.5 and higher | v1.13.x and lower | kube-dns |
 | v2.2.4 and lower | any | kube-dns |

-# Rancher specific parameters
+## Rancher specific parameters

 _Available as of v2.2.0_

@@ -21,7 +21,7 @@ For further details on configuring OpenLDAP, refer to the [official documentatio
 3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password.
 4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute.

-# OpenLDAP Server Configuration
+## OpenLDAP Server Configuration

 You will need to enter the address, port, and protocol to connect to your OpenLDAP server. `389` is the standard port for insecure traffic, `636` for TLS traffic.

@@ -44,7 +44,7 @@ If you are in doubt about the correct values to enter in the user/group Search B
 | User Search Base | Enter the Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".|
 | Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave this field empty. For example: "ou=groups,dc=acme,dc=com".|

-# User/Group Schema Configuration
+## User/Group Schema Configuration

 If your OpenLDAP directory deviates from the standard OpenLDAP schema, you must complete the **Customize Schema** section to match it.

@@ -150,7 +150,7 @@ For details on installing Rancher with a private registry, see:

 - [Air Gap: Kubernetes Install](../../pages-for-subheaders/air-gap-helm2.md)

-# External TLS Termination
+## External TLS Termination

 We recommend configuring your load balancer as a Layer 4 balancer, forwarding plain 80/tcp and 443/tcp to the Rancher Management cluster nodes. The Ingress Controller on the cluster will redirect http traffic on port 80 to https on port 443.

@@ -4,7 +4,7 @@ title: TLS Settings

 In Rancher v2.1.7, the default TLS configuration changed to only accept TLS 1.2 and secure TLS cipher suites. TLS 1.3 and TLS 1.3 exclusive cipher suites are not supported.

-# Configuring TLS settings
+## Configuring TLS settings

 The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.

@@ -12,15 +12,14 @@ The Audit Log is enabled and configured by passing environment variables to the

 - [TLS settings in Helm chart options](helm-chart-options.md#tls-settings)

-# TLS Environment Variables
+## TLS Environment Variables

 | Parameter | Description | Default | Available options |
 |-----|-----|-----|-----|
 | `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2` |
 | `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |

-
-# Legacy configuration
+## Legacy configuration

 If you need to configure TLS the same way as it was before Rancher v2.1.7, please use the following settings:

@@ -5,7 +5,7 @@ title: Tools for Logging, Monitoring, and More
 Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.


-# Logging
+## Logging

 Logging is helpful because it allows you to:

@@ -19,24 +19,27 @@ Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.

 Refer to the logging documentation [here.](../pages-for-subheaders/cluster-logging.md)

-# Monitoring
+## Monitoring

 Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution.

 For details, refer to [Monitoring.](../pages-for-subheaders/cluster-monitoring.md)
-# Alerts
+
+## Alerts

 After monitoring is enabled, you can set up alerts and notifiers that provide the mechanism to receive them.

 Alerts are rules that trigger notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level.

 For details, refer to [Alerts.](../pages-for-subheaders/cluster-alerts.md)
-# Notifiers
+
+## Notifiers

 Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Notifications can be sent with Slack, email, PagerDuty, WeChat, and webhooks.

 For details, refer to [Notifiers.](../explanations/integrations-in-rancher/notifiers.md)
-# Istio
+
+## Istio

 _Available as of v2.3_

@@ -44,12 +47,11 @@ _Available as of v2.3_

 Refer to the Istio documentation [here.](../pages-for-subheaders/istio.md)

-# OPA Gatekeeper
+## OPA Gatekeeper

 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../explanations/integrations-in-rancher/opa-gatekeeper.md)

-
-# CIS Scans
+## CIS Scans

 Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.

@@ -4,7 +4,7 @@ title: Architecture Recommendations

 Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the cluster running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)

-# Separation of Rancher and User Clusters
+## Separation of Rancher and User Clusters

 A user cluster is a downstream Kubernetes cluster that runs your apps and services.

@@ -14,7 +14,7 @@ In Kubernetes installations of Rancher, the Rancher server cluster should also b

 ![Separation of Rancher Server from User Clusters](/img/rancher-architecture-separation-of-rancher-server.svg)

-# Why HA is Better for Rancher in Production
+## Why HA is Better for Rancher in Production

 We recommend installing the Rancher server on a high-availability Kubernetes cluster, primarily because it protects the Rancher server data. In a high-availability installation, a load balancer serves as the single point of contact for clients, distributing network traffic across multiple servers in the cluster and helping to prevent any one server from becoming a point of failure.

@@ -44,7 +44,7 @@ In an RKE installation, the cluster data is replicated on each of three etcd nod

 ![Architecture of an RKE Kubernetes cluster running the Rancher management server](/img/rke-server-storage.svg)

-# Recommended Load Balancer Configuration for Kubernetes Installations
+## Recommended Load Balancer Configuration for Kubernetes Installations

 We recommend the following configurations for the load balancer and Ingress controllers:

@@ -57,7 +57,7 @@ We recommend the following configurations for the load balancer and Ingress cont

 ![Rancher HA](/img/ha/rancher2ha.svg)

-# Environment for Kubernetes Installations
+## Environment for Kubernetes Installations

 It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.

@@ -65,7 +65,7 @@ For the best performance and greater security, we recommend a dedicated Kubernet

 It is not recommended to install Rancher on top of a managed Kubernetes service such as Amazon’s EKS or Google Kubernetes Engine. These hosted Kubernetes solutions do not expose etcd to a degree that is manageable for Rancher, and their customizations can interfere with Rancher operations.

-# Recommended Node Roles for Kubernetes Installations
+## Recommended Node Roles for Kubernetes Installations

 Our recommendations for the roles of each node differ depending on whether Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.

@@ -107,7 +107,7 @@ Because no additional workloads will be deployed on the Rancher server cluster,

 For more best practices for downstream clusters, refer to the [production checklist](../../pages-for-subheaders/checklist-for-production-ready-clusters.md) or our [best practices guide.](../../pages-for-subheaders/best-practices.md)

-# Architecture for an Authorized Cluster Endpoint
+## Architecture for an Authorized Cluster Endpoint

 If you are using an [authorized cluster endpoint,](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.

@@ -18,7 +18,7 @@ Rancher supports the following services:

 Only [administrators](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), [cluster owners or members](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or [project owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) can configure Rancher to send Kubernetes logs to a logging service.

-# Requirements
+## Requirements

 The Docker daemon on each node in the cluster should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command:

@@ -27,7 +27,7 @@ $ docker info | grep 'Logging Driver'
 Logging Driver: json-file
 ```

-# Advantages
+## Advantages

 Setting up a logging service to collect logs from your cluster/project has several advantages:

@@ -36,7 +36,7 @@ Setting up a logging service to collect logs from your cluster/project has sever
 - Helps you when troubleshooting or debugging.
 - Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.

-# Logging Scope
+## Logging Scope

 You can configure logging at either cluster level or project level.

@@ -50,7 +50,7 @@ Logs that are sent to your logging service are from the following locations:

  - Kubernetes system components logs stored at `/var/lib/rancher/rke/logs/`.

-# Enabling Project Logging
+## Enabling Project Logging

 1. From the **Global** view, navigate to the project that you want to configure project logging.

@@ -102,6 +102,6 @@ Logs that are sent to your logging service are from the following locations:

 **Result:** Rancher is now configured to send logs to the selected service. Log into the logging service so that you can start viewing the logs.

-# Related Links
+## Related Links

 [Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
@@ -15,7 +15,7 @@ The following commands are available:
 | [stats](#stats) | Stream system metrics from nodes.
 | [remove](#remove) | Remove Kubernetes resources created by Rancher.

-# Download System Tools
+## Download System Tools

 You can download the latest version of System Tools from the [GitHub releases page](https://github.com/rancher/system-tools/releases/latest). Download the version of `system-tools` for the OS that you are using to interact with the cluster.

@@ -38,7 +38,7 @@ After you download the tools, complete the following actions:
    chmod +x system-tools
    ```

-# Logs
+## Logs

 The logs subcommand will collect log files of core Kubernetes cluster components from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes on an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md). See [Troubleshooting](../troubleshooting.md) for a list of core Kubernetes cluster components.

@@ -58,7 +58,7 @@ The following are the options for the logs command:
 | `--output <FILENAME>, -o cluster-logs.tar`             | Name of the created tarball containing the logs. If no output filename is defined, the options defaults to `cluster-logs.tar`.
 | `--node <NODENAME>, -n node1`                         | Specify the nodes to collect the logs from. If no node is specified, logs from all nodes in the cluster will be collected.

-# Stats
+## Stats

 The stats subcommand will display system metrics from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes in an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md).

@@ -78,7 +78,7 @@ The following are the options for the stats command:
 | `--node <NODENAME>, -n node1`                          | Specify the nodes to display the system metrics from. If no node is specified, logs from all nodes in the cluster will be displayed.
 | `--stats-command value, -s value`                      | The command to run to display the system metrics. If no command is defined, the options defaults to `/usr/bin/sar -u -r -F 1 1`.

-# Remove
+## Remove

 >**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../pages-for-subheaders/backup-restore-and-disaster-recovery.md) before executing the command.